> On July 30, 2014, 10:31 a.m., opticron wrote:
> > /branches/12/rest-api/api-docs/endpoints.json, line 23
> > <https://reviewboard.asterisk.org/r/3726/diff/2/?file=65043#file65043line23>
> >
> > 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.
>
> Matt Jordan wrote:
> It is a direct operation on the endpoints resource itself. It doesn't
> make sense for it to be on a {tech} or on a {resource}: you specify both the
> tech and the resource in the "to" field.
>
> The only thing this could potentially conflict with is if someone created
> a channel technology named "sendMessage", and only if there was a PUT
> operation for /endpoints/{tech}. Since there isn't there is no conflict.
I should note as well: having a channel technology named "sendMessage" would be
silly and would be a highly non-standard channel technology name. Further, we
don't support a PUT operation on a channel technology via the endpoints
resource: what are you PUTting? Even if we support dynamic endpoint creation
(which would be cool), that would most likely be a POST to
/endpoints/{tech}/{resource}, which still avoids any collisions here.
- Matt
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3726/#review12920
-----------------------------------------------------------
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:[email protected]:
>
> ari/endpoints/sendMessage?to=pjsip:alice&from=sip:[email protected]&body=Hello+There
>
> This is equivalent to the following as well:
>
> ari/endpoints/PJSIP/alice/sendMessage?from=sip:[email protected]&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:[email protected]>",
> "to": "pjsip:[email protected]",
> "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
>
>
--
_____________________________________________________________________
-- 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
