[asterisk-dev] [Code Review] 3760: ARI: Fix endpoint/channel subscription issues; allow for subscriptions to endpoint technologies

[opticron]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3760/#review12782
-----------------------------------------------------------

Ship it!


Ship It!

- opticron


On July 21, 2014, 9:48 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3760/
> -----------------------------------------------------------
> 
> (Updated July 21, 2014, 9:48 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23692
>     https://issues.asterisk.org/jira/browse/ASTERISK-23692
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This is 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:
> 
> ast_channel (PJSIP/foo-1) --
>                             \
>                              --> ast_endpoint (PJSIP/foo) --
>                             /                               \
> ast_channel (PJSIP/foo-2) --                                 \
>                                                               ---- > ast_endpoint (PJSIP)
>                                                              /
> ast_channel (PJSIP/bar-1) -----> ast_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)
> 
> 
> Diffs
> -----
> 
>   /branches/12/rest-api/api-docs/applications.json 419075 
>   /branches/12/res/res_xmpp.c 419075 
>   /branches/12/res/ari/resource_endpoints.c 419075 
>   /branches/12/res/ari/resource_applications.h 419075 
>   /branches/12/main/endpoints.c 419075 
>   /branches/12/main/channel_internal_api.c 419075 
>   /branches/12/main/channel.c 419075 
>   /branches/12/include/asterisk/xmpp.h 419075 
>   /branches/12/include/asterisk/endpoints.h 419075 
>   /branches/12/include/asterisk/channel.h 419075 
>   /branches/12/channels/chan_sip.c 419075 
>   /branches/12/channels/chan_pjsip.c 419075 
>   /branches/12/channels/chan_motif.c 419075 
>   /branches/12/channels/chan_iax2.c 419075 
> 
> Diff: https://reviewboard.asterisk.org/r/3760/diff/
> 
> 
> Testing
> -------
> 
> Automated tests were written and are up on https://reviewboard.asterisk.org/r/3762
> 
> In addition, OpenFire was set up and HTTP requests manually made to verify the XMPP endpoint had the appropriate state.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140721/6339dc0c/attachment.html>