----------------------------------------------------------- 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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
