asterisk

Commit Graph

Author	SHA1	Message	Date
Kevin Harwell	1c5def4b18	ARI event type filtering Event type filtering is now enabled, and configurable per application. An app is now able to specify which events are sent to the application by configuring an allowed and/or disallowed list(s). This can be done by issuing the following: PUT /applications/{applicationName}/eventFilter And then enumerating the allowed/disallowed event types as a body parameter. ASTERISK-28106 Change-Id: I9671ba1fcdb3b6c830b553d4c5365aed5d588d5b	8 years ago
Matthew Jordan	bb87796f67	ARI: Fix endpoint/channel subscription issues; allow for subscriptions to tech This patch serves two purposes: (1) It fixes some bugs with endpoint subscriptions not reporting all of the channel events (2) It serves as the preliminary work needed for ASTERISK-23692, which allows for sending/receiving arbitrary out of call text messages through ARI in a technology agnostic fashion. The messaging functionality described on ASTERISK-23692 requires two things: (1) The ability to send/receive messages associated with an endpoint. This is relatively straight forwards with the endpoint core in Asterisk now. (2) The ability to send/receive messages associated with a technology and an arbitrary technology defined URI. This is less straight forward, as endpoints are formed from a tech + resource pair. We don't have a mechanism to note that a technology that may have endpoints exists. This patch provides such a mechanism, and fixes a few bugs along the way. The first major bug this patch fixes is the forwarding of channel messages to their respective endpoints. Prior to this patch, there were two problems: (1) Channel caching messages weren't forwarded. Thus, the endpoints missed most of the interesting bits (such as channel creation, destruction, state changes, etc.) (2) Channels weren't associated with their endpoint until after creation. This resulted in endpoints missing the channel creation message, which limited the usefulness of the subscription in the first place (a major use case being 'tell me when this endpoint has a channel'). Unfortunately, this meant another parameter to ast_channel_alloc. Since not all channel technologies support an ast_endpoint, this patch makes such a call optional and opts for a new function, ast_channel_alloc_with_endpoint. When endpoints are created, they will implicitly create a technology endpoint for their technology (if one does not already exist). A technology endpoint is special in that it has no state, cannot have channels created for it, cannot be created explicitly, and cannot be destroyed except on shutdown. It does, however, have all messages from other endpoints in its technology forwarded to it. Combined with the bug fixes, we now have Stasis messages being properly forwarded. Consider the following scenario: two PJSIP endpoints (foo and bar), where bar has a single channel associated with it and foo has two channels associated with it. The messages would be forwarded as follows: channel PJSIP/foo-1 -- \ --> endpoint PJSIP/foo -- / \ channel PJSIP/foo-2 -- \ ---- > endpoint PJSIP / channel PJSIP/bar-1 -----> endpoint PJSIP/bar -- ARI, through the applications resource, can: - subscribe to endpoint:PJSIP/foo and get notifications for channels PJSIP/foo-1,PJSIP/foo-2 and endpoint PJSIP/foo - subscribe to endpoint:PJSIP/bar and get notifications for channels PJSIP/bar-1 and endpoint PJSIP/bar - subscribe to endpoint:PJSIP and get notifications for channels PJSIP/foo-1,PJSIP/foo-2,PJSIP/bar-1 and endpoints PJSIP/foo,PJSIP/bar Note that since endpoint PJSIP never changes, it never has events itself. It merely provides an aggregation point for all other endpoints in its technology (which in turn aggregate all channel messages associated with that endpoint). This patch also adds endpoints to res_xmpp and chan_motif, because the actual messaging work will need it (messaging without XMPP is just sad). Review: https://reviewboard.asterisk.org/r/3760/ ASTERISK-23692 ........ Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jonathan Rose	a69e0cd32a	ARI: Remove unnecessary \briefs from automatically generated documentation Review: https://reviewboard.asterisk.org/r/3440/ ........ Merged revisions 412653 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417770 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	1590d32ab0	ARI: Support channel variables in originate This adds back in support for specifying channel variables during an originate without compromising the ability to specify query parameters in the JSON body. This was accomplished by generating the body-parsing code in a separate function instead of being integrated with the URI query parameter parsing code such that it could be called by paths with body parameters. This is transparent to the user of the API and prevents manual duplication of code or data structures. (closes issue ASTERISK-23051) Review: https://reviewboard.asterisk.org/r/3122/ Reported by: Matt Jordan ........ Merged revisions 406003 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@406006 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	7ddfe12aff	res_stasis_device_state: Set resource type for subscriptions to deviceState The documentation for ARI already specifies that the device state resource when used for subscribing for events is "deviceState", not "device_state". The code, however, used "device_state"; although this was inconsistent as well in doxygen comments in resource_applications. Because the actual resource being subscribed to is /deviceStates/{device}/, it makes sense for the resource type specifier to be deviceState. Note that the key value in the events is still "device_state". ........ Merged revisions 404437 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404438 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kevin Harwell	ed48377994	ARI: Implement device state API Created a data model and implemented functionality for an ARI device state resource. The following operations have been added that allow a user to manipulate an ARI controlled device: Create/Change the state of an ARI controlled device PUT /deviceStates/{deviceName}&{deviceState} Retrieve all ARI controlled devices GET /deviceStates Retrieve the current state of a device GET /deviceStates/{deviceName} Destroy a device-state controlled by ARI DELETE /deviceStates/{deviceName} The ARI controlled device must begin with 'Stasis:'. An example controlled device name would be Stasis:Example. A 'DeviceStateChanged' event has also been added so that an application can subscribe and receive device change events. Any device state, ARI controlled or not, can be subscribed to. While adding the event, the underlying subscription control mechanism was refactored so that all current and future resource subscriptions would be the same. Each event resource must now register itself in order to be able to properly handle [un]subscribes. (issue ASTERISK-22838) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/3025/ ........ Merged revisions 403134 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403135 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	7d0d1a1efb	ari: User better nicknames for ARI operations While working on building client libraries from the Swagger API, I noticed a problem with the nicknames. channel.deleteChannel() channel.answerChannel() channel.muteChannel() Etc. We put the object name in the nickname (since we were generating C code), but it makes OO generators redundant. This patch makes the nicknames more OO friendly. This resulted in a lot of name changing within the res_ari_.so modules, but not much else. There were a couple of other fixed I made in the process. When reversible operations (POST /hold, POST /unhold) were made more RESTful (POST /hold, DELETE /unhold), the path for the second operation was left in the API declaration. This worked, but really the two operations should have been on the same API. * The POST /unmute operation had still not been REST-ified. Review: https://reviewboard.asterisk.org/r/2940/ ........ Merged revisions 402528 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402529 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	8d7873b836	ARI: Add subscription support This patch adds an /applications API to ARI, allowing explicit management of Stasis applications. * GET /applications - list current applications * GET /applications/{applicationName} - get details of a specific application * POST /applications/{applicationName}/subscription - explicitly subscribe to a channel, bridge or endpoint * DELETE /applications/{applicationName}/subscription - explicitly unsubscribe from a channel, bridge or endpoint Subscriptions work by a reference counting mechanism: if you subscript to an event source X number of times, you must unsubscribe X number of times to stop receiveing events for that event source. Review: https://reviewboard.asterisk.org/r/2862 (issue ASTERISK-22451) Reported by: Matt Jordan ........ Merged revisions 400522 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400523 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago

8 Commits (development/16/python3)