2013-05-08 13:39:08 +00:00
|
|
|
/*
|
2013-04-22 14:58:53 +00:00
|
|
|
* Asterisk -- An open source telephony toolkit.
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2012 - 2013, Digium, Inc.
|
|
|
|
|
*
|
|
|
|
|
* David M. Lee, II <dlee@digium.com>
|
|
|
|
|
*
|
|
|
|
|
* See http://www.asterisk.org for more information about
|
|
|
|
|
* the Asterisk project. Please do not directly contact
|
|
|
|
|
* any of the maintainers of this project for assistance;
|
|
|
|
|
* the project provides a web site, mailing lists and IRC
|
|
|
|
|
* channels for your use.
|
|
|
|
|
*
|
|
|
|
|
* This program is free software, distributed under the terms of
|
|
|
|
|
* the GNU General Public License Version 2. See the LICENSE file
|
|
|
|
|
* at the top of the source tree.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/*! \file
|
|
|
|
|
*
|
2013-05-08 13:39:08 +00:00
|
|
|
* \brief /api-docs/endpoints.{format} implementation- Endpoint resources
|
2013-04-22 14:58:53 +00:00
|
|
|
*
|
|
|
|
|
* \author David M. Lee, II <dlee@digium.com>
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "asterisk.h"
|
|
|
|
|
|
|
|
|
|
#include "resource_endpoints.h"
|
|
|
|
|
|
2013-05-08 13:39:08 +00:00
|
|
|
#include "asterisk/astobj2.h"
|
|
|
|
|
#include "asterisk/stasis.h"
|
2013-11-22 20:10:46 +00:00
|
|
|
#include "asterisk/stasis_app.h"
|
2013-05-08 13:39:08 +00:00
|
|
|
#include "asterisk/stasis_endpoints.h"
|
2013-11-12 23:17:45 +00:00
|
|
|
#include "asterisk/channel.h"
|
ARI: Fix endpoint/channel subscription issues; allow for subscriptions to tech
This patch serves two purposes:
(1) It fixes some bugs with endpoint subscriptions not reporting all of the
channel events
(2) It serves as 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:
channel PJSIP/foo-1 --
\
--> endpoint PJSIP/foo --
/ \
channel PJSIP/foo-2 -- \
---- > endpoint PJSIP
/
channel PJSIP/bar-1 -----> 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).
Review: https://reviewboard.asterisk.org/r/3760/
ASTERISK-23692
........
Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-22 16:20:58 +00:00
|
|
|
#include "asterisk/message.h"
|
2013-05-08 13:39:08 +00:00
|
|
|
|
2013-11-07 21:10:31 +00:00
|
|
|
void ast_ari_endpoints_list(struct ast_variable *headers,
|
|
|
|
|
struct ast_ari_endpoints_list_args *args,
|
2013-07-27 23:11:02 +00:00
|
|
|
struct ast_ari_response *response)
|
2013-05-08 13:39:08 +00:00
|
|
|
{
|
2013-08-01 13:49:34 +00:00
|
|
|
RAII_VAR(struct stasis_cache *, cache, NULL, ao2_cleanup);
|
2013-05-08 13:39:08 +00:00
|
|
|
RAII_VAR(struct ao2_container *, snapshots, NULL, ao2_cleanup);
|
|
|
|
|
RAII_VAR(struct ast_json *, json, NULL, ast_json_unref);
|
|
|
|
|
struct ao2_iterator i;
|
|
|
|
|
void *obj;
|
|
|
|
|
|
2013-08-01 13:49:34 +00:00
|
|
|
cache = ast_endpoint_cache();
|
|
|
|
|
if (!cache) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(
|
2013-05-08 13:39:08 +00:00
|
|
|
response, 500, "Internal Server Error",
|
|
|
|
|
"Message bus not initialized");
|
|
|
|
|
return;
|
|
|
|
|
}
|
2013-08-01 13:49:34 +00:00
|
|
|
ao2_ref(cache, +1);
|
2013-05-08 13:39:08 +00:00
|
|
|
|
2013-08-01 13:49:34 +00:00
|
|
|
snapshots = stasis_cache_dump(cache, ast_endpoint_snapshot_type());
|
2013-05-08 13:39:08 +00:00
|
|
|
if (!snapshots) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-05-08 13:39:08 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
json = ast_json_array_create();
|
|
|
|
|
if (!json) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-05-08 13:39:08 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
i = ao2_iterator_init(snapshots, 0);
|
|
|
|
|
while ((obj = ao2_iterator_next(&i))) {
|
|
|
|
|
RAII_VAR(struct stasis_message *, msg, obj, ao2_cleanup);
|
|
|
|
|
struct ast_endpoint_snapshot *snapshot = stasis_message_data(msg);
|
2013-11-22 20:10:46 +00:00
|
|
|
struct ast_json *json_endpoint = ast_endpoint_snapshot_to_json(snapshot, stasis_app_get_sanitizer());
|
|
|
|
|
|
2014-02-21 18:04:54 +00:00
|
|
|
if (!json_endpoint || ast_json_array_append(json, json_endpoint)) {
|
2013-12-20 20:00:50 +00:00
|
|
|
ao2_iterator_destroy(&i);
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-05-08 13:39:08 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
ao2_iterator_destroy(&i);
|
|
|
|
|
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_ok(response, ast_json_ref(json));
|
2013-05-08 13:39:08 +00:00
|
|
|
}
|
ARI: Fix endpoint/channel subscription issues; allow for subscriptions to tech
This patch serves two purposes:
(1) It fixes some bugs with endpoint subscriptions not reporting all of the
channel events
(2) It serves as 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:
channel PJSIP/foo-1 --
\
--> endpoint PJSIP/foo --
/ \
channel PJSIP/foo-2 -- \
---- > endpoint PJSIP
/
channel PJSIP/bar-1 -----> 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).
Review: https://reviewboard.asterisk.org/r/3760/
ASTERISK-23692
........
Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-22 16:20:58 +00:00
|
|
|
|
2013-11-07 21:10:31 +00:00
|
|
|
void ast_ari_endpoints_list_by_tech(struct ast_variable *headers,
|
|
|
|
|
struct ast_ari_endpoints_list_by_tech_args *args,
|
2013-07-27 23:11:02 +00:00
|
|
|
struct ast_ari_response *response)
|
2013-04-22 14:58:53 +00:00
|
|
|
{
|
2013-08-01 13:49:34 +00:00
|
|
|
RAII_VAR(struct stasis_cache *, cache, NULL, ao2_cleanup);
|
2013-05-08 13:39:08 +00:00
|
|
|
RAII_VAR(struct ao2_container *, snapshots, NULL, ao2_cleanup);
|
|
|
|
|
RAII_VAR(struct ast_json *, json, NULL, ast_json_unref);
|
ARI: Fix endpoint/channel subscription issues; allow for subscriptions to tech
This patch serves two purposes:
(1) It fixes some bugs with endpoint subscriptions not reporting all of the
channel events
(2) It serves as 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:
channel PJSIP/foo-1 --
\
--> endpoint PJSIP/foo --
/ \
channel PJSIP/foo-2 -- \
---- > endpoint PJSIP
/
channel PJSIP/bar-1 -----> 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).
Review: https://reviewboard.asterisk.org/r/3760/
ASTERISK-23692
........
Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-22 16:20:58 +00:00
|
|
|
struct ast_endpoint *tech_endpoint;
|
2013-05-08 13:39:08 +00:00
|
|
|
struct ao2_iterator i;
|
|
|
|
|
void *obj;
|
|
|
|
|
|
ARI: Fix endpoint/channel subscription issues; allow for subscriptions to tech
This patch serves two purposes:
(1) It fixes some bugs with endpoint subscriptions not reporting all of the
channel events
(2) It serves as 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:
channel PJSIP/foo-1 --
\
--> endpoint PJSIP/foo --
/ \
channel PJSIP/foo-2 -- \
---- > endpoint PJSIP
/
channel PJSIP/bar-1 -----> 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).
Review: https://reviewboard.asterisk.org/r/3760/
ASTERISK-23692
........
Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-22 16:20:58 +00:00
|
|
|
tech_endpoint = ast_endpoint_find_by_id(args->tech);
|
|
|
|
|
if (!tech_endpoint) {
|
2013-11-12 23:17:45 +00:00
|
|
|
ast_ari_response_error(response, 404, "Not Found",
|
|
|
|
|
"No Endpoints found - invalid tech %s", args->tech);
|
|
|
|
|
return;
|
|
|
|
|
}
|
ARI: Fix endpoint/channel subscription issues; allow for subscriptions to tech
This patch serves two purposes:
(1) It fixes some bugs with endpoint subscriptions not reporting all of the
channel events
(2) It serves as 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:
channel PJSIP/foo-1 --
\
--> endpoint PJSIP/foo --
/ \
channel PJSIP/foo-2 -- \
---- > endpoint PJSIP
/
channel PJSIP/bar-1 -----> 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).
Review: https://reviewboard.asterisk.org/r/3760/
ASTERISK-23692
........
Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-22 16:20:58 +00:00
|
|
|
ao2_ref(tech_endpoint, -1);
|
2013-11-12 23:17:45 +00:00
|
|
|
|
2013-08-01 13:49:34 +00:00
|
|
|
cache = ast_endpoint_cache();
|
|
|
|
|
if (!cache) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(
|
2013-05-08 13:39:08 +00:00
|
|
|
response, 500, "Internal Server Error",
|
|
|
|
|
"Message bus not initialized");
|
|
|
|
|
return;
|
|
|
|
|
}
|
2013-08-01 13:49:34 +00:00
|
|
|
ao2_ref(cache, +1);
|
2013-05-08 13:39:08 +00:00
|
|
|
|
2013-08-01 13:49:34 +00:00
|
|
|
snapshots = stasis_cache_dump(cache, ast_endpoint_snapshot_type());
|
2013-05-08 13:39:08 +00:00
|
|
|
if (!snapshots) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-05-08 13:39:08 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
json = ast_json_array_create();
|
|
|
|
|
if (!json) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-05-08 13:39:08 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
i = ao2_iterator_init(snapshots, 0);
|
|
|
|
|
while ((obj = ao2_iterator_next(&i))) {
|
|
|
|
|
RAII_VAR(struct stasis_message *, msg, obj, ao2_cleanup);
|
|
|
|
|
struct ast_endpoint_snapshot *snapshot = stasis_message_data(msg);
|
2013-11-22 20:10:46 +00:00
|
|
|
struct ast_json *json_endpoint;
|
2013-05-08 13:39:08 +00:00
|
|
|
int r;
|
|
|
|
|
|
2013-11-12 23:17:45 +00:00
|
|
|
if (strcasecmp(args->tech, snapshot->tech) != 0) {
|
2013-05-08 13:39:08 +00:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2013-11-22 20:10:46 +00:00
|
|
|
json_endpoint = ast_endpoint_snapshot_to_json(snapshot, stasis_app_get_sanitizer());
|
|
|
|
|
if (!json_endpoint) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2013-05-08 13:39:08 +00:00
|
|
|
r = ast_json_array_append(
|
2013-11-22 20:10:46 +00:00
|
|
|
json, json_endpoint);
|
2013-05-08 13:39:08 +00:00
|
|
|
if (r != 0) {
|
2013-12-20 20:00:50 +00:00
|
|
|
ao2_iterator_destroy(&i);
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-05-08 13:39:08 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
ao2_iterator_destroy(&i);
|
2013-11-12 23:17:45 +00:00
|
|
|
ast_ari_response_ok(response, ast_json_ref(json));
|
2013-04-22 14:58:53 +00:00
|
|
|
}
|
ARI: Fix endpoint/channel subscription issues; allow for subscriptions to tech
This patch serves two purposes:
(1) It fixes some bugs with endpoint subscriptions not reporting all of the
channel events
(2) It serves as 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:
channel PJSIP/foo-1 --
\
--> endpoint PJSIP/foo --
/ \
channel PJSIP/foo-2 -- \
---- > endpoint PJSIP
/
channel PJSIP/bar-1 -----> 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).
Review: https://reviewboard.asterisk.org/r/3760/
ASTERISK-23692
........
Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-22 16:20:58 +00:00
|
|
|
|
2013-11-07 21:10:31 +00:00
|
|
|
void ast_ari_endpoints_get(struct ast_variable *headers,
|
|
|
|
|
struct ast_ari_endpoints_get_args *args,
|
2013-07-27 23:11:02 +00:00
|
|
|
struct ast_ari_response *response)
|
2013-04-22 14:58:53 +00:00
|
|
|
{
|
2014-01-12 22:24:27 +00:00
|
|
|
struct ast_json *json;
|
2013-05-08 13:39:08 +00:00
|
|
|
RAII_VAR(struct ast_endpoint_snapshot *, snapshot, NULL, ao2_cleanup);
|
|
|
|
|
|
2013-10-02 22:22:17 +00:00
|
|
|
snapshot = ast_endpoint_latest_snapshot(args->tech, args->resource);
|
2013-05-08 13:39:08 +00:00
|
|
|
if (!snapshot) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(response, 404, "Not Found",
|
2013-05-08 13:39:08 +00:00
|
|
|
"Endpoint not found");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2013-11-22 20:10:46 +00:00
|
|
|
json = ast_endpoint_snapshot_to_json(snapshot, stasis_app_get_sanitizer());
|
2013-05-08 13:39:08 +00:00
|
|
|
if (!json) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-05-08 13:39:08 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2014-01-12 22:24:27 +00:00
|
|
|
ast_ari_response_ok(response, json);
|
2013-04-22 14:58:53 +00:00
|
|
|
}
|
Multiple revisions 420089-420090,420097
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
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). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@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 as well. 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@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
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.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-05 21:44:09 +00:00
|
|
|
|
|
|
|
|
static void send_message(const char *to, const char *from, const char *body, struct ast_variable *variables, struct ast_ari_response *response)
|
|
|
|
|
{
|
|
|
|
|
struct ast_variable *current;
|
|
|
|
|
struct ast_msg *msg;
|
|
|
|
|
int res = 0;
|
|
|
|
|
|
|
|
|
|
if (ast_strlen_zero(to)) {
|
|
|
|
|
ast_ari_response_error(response, 400, "Bad Request",
|
|
|
|
|
"To must be specified");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
msg = ast_msg_alloc();
|
|
|
|
|
if (!msg) {
|
|
|
|
|
ast_ari_response_alloc_failed(response);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
res |= ast_msg_set_from(msg, "%s", from);
|
|
|
|
|
res |= ast_msg_set_to(msg, "%s", to);
|
|
|
|
|
|
|
|
|
|
if (!ast_strlen_zero(body)) {
|
|
|
|
|
res |= ast_msg_set_body(msg, "%s", body);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (current = variables; current; current = current->next) {
|
|
|
|
|
res |= ast_msg_set_var_outbound(msg, current->name, current->value);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (res) {
|
|
|
|
|
ast_ari_response_alloc_failed(response);
|
|
|
|
|
ast_msg_destroy(msg);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ast_msg_send(msg, to, from)) {
|
|
|
|
|
ast_ari_response_error(response, 404, "Not Found",
|
|
|
|
|
"Endpoint not found");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
response->message = ast_json_null();
|
|
|
|
|
response->response_code = 202;
|
|
|
|
|
response->response_text = "Accepted";
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-27 18:31:31 +00:00
|
|
|
/*!
|
|
|
|
|
* \internal
|
|
|
|
|
* \brief Convert a \c ast_json list of key/value pair tuples into a \c ast_variable list
|
|
|
|
|
* \since 13.3.0
|
|
|
|
|
*
|
|
|
|
|
* \param[out] response HTTP response if error
|
|
|
|
|
* \param json_variables The JSON blob containing the variable
|
|
|
|
|
* \param[out] variables An out reference to the variables to populate.
|
|
|
|
|
*
|
|
|
|
|
* \retval 0 on success.
|
|
|
|
|
* \retval -1 on error.
|
|
|
|
|
*/
|
|
|
|
|
static int json_to_ast_variables(struct ast_ari_response *response, struct ast_json *json_variables, struct ast_variable **variables)
|
|
|
|
|
{
|
|
|
|
|
enum ast_json_to_ast_vars_code res;
|
|
|
|
|
|
|
|
|
|
res = ast_json_to_ast_variables(json_variables, variables);
|
|
|
|
|
switch (res) {
|
|
|
|
|
case AST_JSON_TO_AST_VARS_CODE_SUCCESS:
|
|
|
|
|
return 0;
|
|
|
|
|
case AST_JSON_TO_AST_VARS_CODE_INVALID_TYPE:
|
|
|
|
|
ast_ari_response_error(response, 400, "Bad Request",
|
|
|
|
|
"Only string values in the 'variables' object allowed");
|
|
|
|
|
break;
|
|
|
|
|
case AST_JSON_TO_AST_VARS_CODE_OOM:
|
|
|
|
|
ast_ari_response_alloc_failed(response);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
ast_log(AST_LOG_ERROR, "Unable to convert 'variables' in JSON body to Asterisk variables\n");
|
|
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
Multiple revisions 420089-420090,420097
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
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). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@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 as well. 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@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
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.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-05 21:44:09 +00:00
|
|
|
void ast_ari_endpoints_send_message(struct ast_variable *headers,
|
|
|
|
|
struct ast_ari_endpoints_send_message_args *args,
|
|
|
|
|
struct ast_ari_response *response)
|
|
|
|
|
{
|
2015-02-27 18:31:31 +00:00
|
|
|
struct ast_variable *variables = NULL;
|
Multiple revisions 420089-420090,420097
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
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). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@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 as well. 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@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
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.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-05 21:44:09 +00:00
|
|
|
|
|
|
|
|
if (args->variables) {
|
|
|
|
|
struct ast_json *json_variables;
|
|
|
|
|
|
|
|
|
|
ast_ari_endpoints_send_message_parse_body(args->variables, args);
|
|
|
|
|
json_variables = ast_json_object_get(args->variables, "variables");
|
2015-02-27 18:31:31 +00:00
|
|
|
if (json_variables
|
|
|
|
|
&& json_to_ast_variables(response, json_variables, &variables)) {
|
|
|
|
|
return;
|
Multiple revisions 420089-420090,420097
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
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). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@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 as well. 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@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
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.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-05 21:44:09 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
send_message(args->to, args->from, args->body, variables, response);
|
2015-02-27 18:31:31 +00:00
|
|
|
ast_variables_destroy(variables);
|
Multiple revisions 420089-420090,420097
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
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). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@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 as well. 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@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
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.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-05 21:44:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ast_ari_endpoints_send_message_to_endpoint(struct ast_variable *headers,
|
|
|
|
|
struct ast_ari_endpoints_send_message_to_endpoint_args *args,
|
|
|
|
|
struct ast_ari_response *response)
|
|
|
|
|
{
|
2015-02-27 18:31:31 +00:00
|
|
|
struct ast_variable *variables = NULL;
|
|
|
|
|
struct ast_endpoint_snapshot *snapshot;
|
Multiple revisions 420089-420090,420097
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
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). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@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 as well. 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@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
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.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-05 21:44:09 +00:00
|
|
|
char msg_to[128];
|
|
|
|
|
char *tech = ast_strdupa(args->tech);
|
|
|
|
|
|
|
|
|
|
/* Really, we just want to know if this thing exists */
|
|
|
|
|
snapshot = ast_endpoint_latest_snapshot(args->tech, args->resource);
|
|
|
|
|
if (!snapshot) {
|
|
|
|
|
ast_ari_response_error(response, 404, "Not Found",
|
|
|
|
|
"Endpoint not found");
|
|
|
|
|
return;
|
|
|
|
|
}
|
2015-02-27 18:31:31 +00:00
|
|
|
ao2_ref(snapshot, -1);
|
Multiple revisions 420089-420090,420097
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
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). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@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 as well. 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@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
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.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-05 21:44:09 +00:00
|
|
|
|
|
|
|
|
if (args->variables) {
|
|
|
|
|
struct ast_json *json_variables;
|
|
|
|
|
|
|
|
|
|
ast_ari_endpoints_send_message_to_endpoint_parse_body(args->variables, args);
|
|
|
|
|
json_variables = ast_json_object_get(args->variables, "variables");
|
2015-02-27 18:31:31 +00:00
|
|
|
if (json_variables
|
|
|
|
|
&& json_to_ast_variables(response, json_variables, &variables)) {
|
|
|
|
|
return;
|
Multiple revisions 420089-420090,420097
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
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). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@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 as well. 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@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
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.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-05 21:44:09 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
snprintf(msg_to, sizeof(msg_to), "%s:%s", ast_str_to_lower(tech), args->resource);
|
|
|
|
|
|
|
|
|
|
send_message(msg_to, args->from, args->body, variables, response);
|
2015-02-27 18:31:31 +00:00
|
|
|
ast_variables_destroy(variables);
|
Multiple revisions 420089-420090,420097
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
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). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@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 as well. 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@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
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.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-05 21:44:09 +00:00
|
|
|
}
|
