[asterisk-dev] [Code Review] 3726: ari: Add message technology agnostic out of call text messaging

opticron reviewboard at asterisk.org
Wed Jul 30 10:31:07 CDT 2014 

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



/branches/12/include/asterisk/json.h
<https://reviewboard.asterisk.org/r/3726/#comment23295>

    Drop this change.



/branches/12/include/asterisk/manager.h
<https://reviewboard.asterisk.org/r/3726/#comment23296>

    Unrelated change?



/branches/12/include/asterisk/vector.h
<https://reviewboard.asterisk.org/r/3726/#comment23299>

    This seems to be unrelated and has already been committed.



/branches/12/main/json.c
<https://reviewboard.asterisk.org/r/3726/#comment23300>

    This should check the type of ast_json_object_iter_value(it_json_var) before getting its string value or check that the string value is non-NULL since if it is not a string, it will return NULL and ast_variable_new will segfault.



/branches/12/main/message.c
<https://reviewboard.asterisk.org/r/3726/#comment23305>

    This can be changed to ao2_bump for clarity. It may actually need to be ao2_replace depending on whether the value in the datastore can be set already.



/branches/12/main/message.c
<https://reviewboard.asterisk.org/r/3726/#comment23304>

    This needs to be dropped since the dialplan callback no longer owns the reference passed to it.



/branches/12/main/message.c
<https://reviewboard.asterisk.org/r/3726/#comment23302>

    This is not necessary since the callback already owns a reference passed to it via the taskprocessor via ast_msg_queue which is reference-stealing.



/branches/12/main/message.c
<https://reviewboard.asterisk.org/r/3726/#comment23303>

    This one is still necessary.



/branches/12/rest-api/api-docs/endpoints.json
<https://reviewboard.asterisk.org/r/3726/#comment23308>

    Doesn't this conflict with /endpoints/{tech} and /endpoints/{tech}/{resource} below? There are currently no other paths that override a path parameter like this.


- opticron


On July 27, 2014, 9:20 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3726/
> -----------------------------------------------------------
> 
> (Updated July 27, 2014, 9:20 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23692 and ASTERISK-23969
>     https://issues.asterisk.org/jira/browse/ASTERISK-23692
>     https://issues.asterisk.org/jira/browse/ASTERISK-23969
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This patch adds the ability to send and receive text messages from various technology stacks in Asterisk through ARI. This includes chan_sip (sip), res_pjsip_messaging (pjsip), and res_xmpp (xmpp).
> 
> The following would send the message "Hello there" to PJSIP endpoint alice with a display URI of sip:asterisk at mycooldomain.org:
> 
> ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk at mycooldomain.org&body=Hello+There
> 
> This is equivalent to the following as well:
> 
> ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk at mycooldomain.org&body=Hello+There
> 
> Both forms are available for message technologies that allow for arbitrary destinations, such as chan_sip.
> 
> Inbound messages can now be received over ARI. An ARI application that subscribes to endpoints will receive messages from those endpoints:
> 
> {
>   "type": "TextMessageReceived",
>   "timestamp": "2014-07-12T22:53:13.494-0500",
>   "endpoint": {
>     "technology": "PJSIP",
>     "resource": "alice",
>     "state": "online",
>     "channel_ids": []
>   },
>   "message": {
>     "from": "\"alice\" <sip:alice at 127.0.0.1>",
>     "to": "pjsip:asterisk at 127.0.0.1",
>     "body": "Watson, come here.",
>     "variables": []
>   },
>   "application": "testsuite"
> }
> 
> A few interesting things you could do with this:
> (1) Build your own XMPP to SIP gateway (without ever touching dialplan)
> (2) Make a conferencing application with built-in text messaging (speech to text would be fun with this... probably should write that too)
> (3) WebRTC! SIP stacks in the browser can send MESSAGE requests. Why limit yourself to just making calls when you can send arbitrary messages to a communications application? (Note: if you can't mention WebRTC in a release, you're not trying very hard)
> 
> The above was made possible due to some rather major changes in the message core. This includes (but is not limited to):
> - Users of the message API can now register message handlers. A handler has two callbacks: one to determine if the handler has a destination for the message, and another to handle it.
> - All dialplan functionality of handling a message was moved into a message handler provided by the message API.
> - Messages can now have the technology/endpoint associated with them. Various other properties are also now more easily accessible.
> - A number of ao2 containers that weren't really needed were replaced with vectors. Iteration over ao2_containers is expensive and pointless when the lifetime of things is well defined and the number of things is very small.
> 
> res_stasis now has a new file that makes up its structure, messaging. The messaging functionality implements a message handler, and passes received messages that match an interested endpoint over to the app for processing.
> 
> Note that inadvertently while testing this, I reproduced ASTERISK-23969. res_pjsip_messaging was incorrectly parsing out the 'to' field, such that arbitrary SIP URIs mangled the endpoint lookup. This patch includes the fix for that as well.
> 
> 
> Diffs
> -----
> 
>   /branches/12/tests/test_message.c PRE-CREATION 
>   /branches/12/rest-api/api-docs/events.json 419205 
>   /branches/12/rest-api/api-docs/endpoints.json 419205 
>   /branches/12/res/stasis/app.c 419205 
>   /branches/12/res/res_xmpp.c 419205 
>   /branches/12/res/res_stasis.c 419205 
>   /branches/12/res/res_pjsip_messaging.c 419205 
>   /branches/12/res/res_ari_endpoints.c 419205 
>   /branches/12/res/ari/resource_endpoints.c 419205 
>   /branches/12/res/ari/resource_endpoints.h 419205 
>   /branches/12/res/ari/resource_channels.c 419205 
>   /branches/12/res/ari/ari_model_validators.c 419205 
>   /branches/12/res/ari/ari_model_validators.h 419205 
>   /branches/12/main/message.c 419205 
>   /branches/12/main/json.c 419205 
>   /branches/12/include/asterisk/vector.h 419205 
>   /branches/12/include/asterisk/message.h 419205 
>   /branches/12/include/asterisk/manager.h 419205 
>   /branches/12/include/asterisk/json.h 419205 
>   /branches/12/channels/chan_sip.c 419205 
> 
> Diff: https://reviewboard.asterisk.org/r/3726/diff/
> 
> 
> Testing
> -------
> 
> Unit tests were added for the message core to make sure dialplan still worked.
> 
> Basic nominal tests have been added for the Asterisk Test Suite, and are up for review at https://reviewboard.asterisk.org/r/3864/
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140730/d4cd5283/attachment-0001.html>

More information about the asterisk-dev mailing list