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

[Matt Jordan]

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

(Updated July 22, 2014, 11:12 a.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
-------

Committed in revision 419196


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/20140722/6790a792/attachment.html>