asterisk/res/ari/resource_events.h

129 lines
4.1 KiB
C
Raw Normal View History

/*
* Asterisk -- An open source telephony toolkit.
*
* Copyright (C) 2012 - 2013, Digium, Inc.
*
* David M. Lee, II <dlee@digium.com>
*
* See http://www.asterisk.org for more information about
* the Asterisk project. Please do not directly contact
* any of the maintainers of this project for assistance;
* the project provides a web site, mailing lists and IRC
* channels for your use.
*
* This program is free software, distributed under the terms of
* the GNU General Public License Version 2. See the LICENSE file
* at the top of the source tree.
*/
/*! \file
*
* \brief Generated file - declares stubs to be implemented in
* res/ari/resource_events.c
*
* WebSocket resource
*
* \author David M. Lee, II <dlee@digium.com>
*/
/*
* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
* !!!!! DO NOT EDIT !!!!!
* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
* This file is generated by a mustache template. Please see the original
* template in rest-api-templates/ari_resource.h.mustache
*/
#ifndef _ASTERISK_RESOURCE_EVENTS_H
#define _ASTERISK_RESOURCE_EVENTS_H
#include "asterisk/ari.h"
/*! Argument struct for ast_ari_events_event_websocket() */
struct ast_ari_events_event_websocket_args {
/*! Array of Applications to subscribe to. */
const char **app;
/*! Length of app array. */
size_t app_count;
/*! Parsing context for app. */
char *app_parse;
/*! Subscribe to all Asterisk events. If provided, the applications listed will be subscribed to all events, effectively disabling the application specific subscriptions. Default is 'false'. */
int subscribe_all;
};
ARI: Channels added to Stasis application during WebSocket creation ... Prior to ASTERISK-24988, the WebSocket handshake was resolved before Stasis applications were registered. This was done such that the WebSocket would be ready when an application is registered. However, by creating the WebSocket first, the client had the ability to make requests for the Stasis application it thought had been created with the initial handshake request. The inevitable conclusion of this scenario was the cart being put before the horse. ASTERISK-24988 resolved half of the problem by ensuring that the applications were created and registered with Stasis prior to completing the handshake with the client. While this meant that Stasis was ready when the client received the green-light from Asterisk, it also meant that the WebSocket was not yet ready for Stasis to dispatch messages. This patch introduces a message queuing mechanism for delaying messages from Stasis applications while the WebSocket is being constructed. When the ARI event processor receives the message from the WebSocket that it is being created, the event processor instantiates an event session which contains a message queue. It then tries to create and register the requested applications with Stasis. Messages that are dispatched from Stasis between this point and the point at which the event processor is notified the WebSocket is ready, are stashed in the queue. Once the WebSocket has been built, the queue's messages are dispatched in the order in which they were originally received and the queue is concurrently cleared. ASTERISK-25181 #close Reported By: Matt Jordan Change-Id: Iafef7b85a2e0bf78c114db4c87ffc3d16d671a17
2015-07-31 16:27:23 +00:00
/*!
* \brief WebSocket connection for events.
*
* \retval 0 success
* \retval -1 error
*/
int ast_ari_websocket_events_event_websocket_init(void);
/*!
* \brief WebSocket connection for events.
*
* \return Nothing
*/
void ast_ari_websocket_events_event_websocket_dtor(void);
/*!
* \brief WebSocket connection for events.
*
* \param ser HTTP TCP/TLS Server Session
* \param headers HTTP headers
* \param args Swagger parameters
ARI: Channels added to Stasis application during WebSocket creation ... Prior to ASTERISK-24988, the WebSocket handshake was resolved before Stasis applications were registered. This was done such that the WebSocket would be ready when an application is registered. However, by creating the WebSocket first, the client had the ability to make requests for the Stasis application it thought had been created with the initial handshake request. The inevitable conclusion of this scenario was the cart being put before the horse. ASTERISK-24988 resolved half of the problem by ensuring that the applications were created and registered with Stasis prior to completing the handshake with the client. While this meant that Stasis was ready when the client received the green-light from Asterisk, it also meant that the WebSocket was not yet ready for Stasis to dispatch messages. This patch introduces a message queuing mechanism for delaying messages from Stasis applications while the WebSocket is being constructed. When the ARI event processor receives the message from the WebSocket that it is being created, the event processor instantiates an event session which contains a message queue. It then tries to create and register the requested applications with Stasis. Messages that are dispatched from Stasis between this point and the point at which the event processor is notified the WebSocket is ready, are stashed in the queue. Once the WebSocket has been built, the queue's messages are dispatched in the order in which they were originally received and the queue is concurrently cleared. ASTERISK-25181 #close Reported By: Matt Jordan Change-Id: Iafef7b85a2e0bf78c114db4c87ffc3d16d671a17
2015-07-31 16:27:23 +00:00
* \param session_id The id of the current session.
*
* \retval 0 success
* \retval non-zero error
*/
ARI: Channels added to Stasis application during WebSocket creation ... Prior to ASTERISK-24988, the WebSocket handshake was resolved before Stasis applications were registered. This was done such that the WebSocket would be ready when an application is registered. However, by creating the WebSocket first, the client had the ability to make requests for the Stasis application it thought had been created with the initial handshake request. The inevitable conclusion of this scenario was the cart being put before the horse. ASTERISK-24988 resolved half of the problem by ensuring that the applications were created and registered with Stasis prior to completing the handshake with the client. While this meant that Stasis was ready when the client received the green-light from Asterisk, it also meant that the WebSocket was not yet ready for Stasis to dispatch messages. This patch introduces a message queuing mechanism for delaying messages from Stasis applications while the WebSocket is being constructed. When the ARI event processor receives the message from the WebSocket that it is being created, the event processor instantiates an event session which contains a message queue. It then tries to create and register the requested applications with Stasis. Messages that are dispatched from Stasis between this point and the point at which the event processor is notified the WebSocket is ready, are stashed in the queue. Once the WebSocket has been built, the queue's messages are dispatched in the order in which they were originally received and the queue is concurrently cleared. ASTERISK-25181 #close Reported By: Matt Jordan Change-Id: Iafef7b85a2e0bf78c114db4c87ffc3d16d671a17
2015-07-31 16:27:23 +00:00
int ast_ari_websocket_events_event_websocket_attempted(struct ast_tcptls_session_instance *ser,
struct ast_variable *headers, struct ast_ari_events_event_websocket_args *args, const char *session_id);
/*!
* \brief WebSocket connection for events.
*
* \param session ARI WebSocket.
* \param headers HTTP headers.
* \param args Swagger parameters.
ARI: Channels added to Stasis application during WebSocket creation ... Prior to ASTERISK-24988, the WebSocket handshake was resolved before Stasis applications were registered. This was done such that the WebSocket would be ready when an application is registered. However, by creating the WebSocket first, the client had the ability to make requests for the Stasis application it thought had been created with the initial handshake request. The inevitable conclusion of this scenario was the cart being put before the horse. ASTERISK-24988 resolved half of the problem by ensuring that the applications were created and registered with Stasis prior to completing the handshake with the client. While this meant that Stasis was ready when the client received the green-light from Asterisk, it also meant that the WebSocket was not yet ready for Stasis to dispatch messages. This patch introduces a message queuing mechanism for delaying messages from Stasis applications while the WebSocket is being constructed. When the ARI event processor receives the message from the WebSocket that it is being created, the event processor instantiates an event session which contains a message queue. It then tries to create and register the requested applications with Stasis. Messages that are dispatched from Stasis between this point and the point at which the event processor is notified the WebSocket is ready, are stashed in the queue. Once the WebSocket has been built, the queue's messages are dispatched in the order in which they were originally received and the queue is concurrently cleared. ASTERISK-25181 #close Reported By: Matt Jordan Change-Id: Iafef7b85a2e0bf78c114db4c87ffc3d16d671a17
2015-07-31 16:27:23 +00:00
* \param session_id The id of the current session.
*/
ARI: Channels added to Stasis application during WebSocket creation ... Prior to ASTERISK-24988, the WebSocket handshake was resolved before Stasis applications were registered. This was done such that the WebSocket would be ready when an application is registered. However, by creating the WebSocket first, the client had the ability to make requests for the Stasis application it thought had been created with the initial handshake request. The inevitable conclusion of this scenario was the cart being put before the horse. ASTERISK-24988 resolved half of the problem by ensuring that the applications were created and registered with Stasis prior to completing the handshake with the client. While this meant that Stasis was ready when the client received the green-light from Asterisk, it also meant that the WebSocket was not yet ready for Stasis to dispatch messages. This patch introduces a message queuing mechanism for delaying messages from Stasis applications while the WebSocket is being constructed. When the ARI event processor receives the message from the WebSocket that it is being created, the event processor instantiates an event session which contains a message queue. It then tries to create and register the requested applications with Stasis. Messages that are dispatched from Stasis between this point and the point at which the event processor is notified the WebSocket is ready, are stashed in the queue. Once the WebSocket has been built, the queue's messages are dispatched in the order in which they were originally received and the queue is concurrently cleared. ASTERISK-25181 #close Reported By: Matt Jordan Change-Id: Iafef7b85a2e0bf78c114db4c87ffc3d16d671a17
2015-07-31 16:27:23 +00:00
void ast_ari_websocket_events_event_websocket_established(struct ast_ari_websocket_session *session,
struct ast_variable *headers, struct ast_ari_events_event_websocket_args *args);
/*! Argument struct for ast_ari_events_user_event() */
struct ast_ari_events_user_event_args {
/*! Event name */
const char *event_name;
/*! The name of the application that will receive this event */
const char *application;
/*! Array of URI for event source (channel:{channelId}, bridge:{bridgeId}, endpoint:{tech}/{resource}, deviceState:{deviceName} */
const char **source;
/*! Length of source array. */
size_t source_count;
/*! Parsing context for source. */
char *source_parse;
/*! The "variables" key in the body object holds custom key/value pairs to add to the user event. Ex. { "variables": { "key": "value" } } */
struct ast_json *variables;
};
/*!
* \brief Body parsing function for /events/user/{eventName}.
* \param body The JSON body from which to parse parameters.
* \param[out] args The args structure to parse into.
* \retval zero on success
* \retval non-zero on failure
*/
int ast_ari_events_user_event_parse_body(
struct ast_json *body,
struct ast_ari_events_user_event_args *args);
/*!
* \brief Generate a user event.
*
* \param headers HTTP headers
* \param args Swagger parameters
* \param[out] response HTTP response
*/
void ast_ari_events_user_event(struct ast_variable *headers, struct ast_ari_events_user_event_args *args, struct ast_ari_response *response);
#endif /* _ASTERISK_RESOURCE_EVENTS_H */