2013-06-22 14:03:22 +00:00
|
|
|
/*
|
|
|
|
* Asterisk -- An open source telephony toolkit.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2013, Digium, Inc.
|
|
|
|
*
|
|
|
|
* Kevin Harwell <kharwell@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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*** MODULEINFO
|
|
|
|
<depend>pjproject</depend>
|
2013-07-30 18:14:50 +00:00
|
|
|
<depend>res_pjsip</depend>
|
|
|
|
<depend>res_pjsip_session</depend>
|
2013-06-22 14:03:22 +00:00
|
|
|
<support_level>core</support_level>
|
|
|
|
***/
|
|
|
|
|
2013-12-13 21:35:50 +00:00
|
|
|
/*** DOCUMENTATION
|
2016-08-15 20:29:53 +00:00
|
|
|
<info name="MessageFromInfo" language="en_US" tech="PJSIP">
|
2013-12-13 21:35:50 +00:00
|
|
|
<para>The <literal>from</literal> parameter can be a configured endpoint
|
|
|
|
or in the form of "display-name" <URI>.</para>
|
|
|
|
</info>
|
2016-08-15 20:29:53 +00:00
|
|
|
<info name="MessageToInfo" language="en_US" tech="PJSIP">
|
2013-12-13 21:35:50 +00:00
|
|
|
<para>Specifying a prefix of <literal>pjsip:</literal> will send the
|
|
|
|
message as a SIP MESSAGE request.</para>
|
|
|
|
</info>
|
|
|
|
***/
|
2013-06-22 14:03:22 +00:00
|
|
|
#include "asterisk.h"
|
|
|
|
|
|
|
|
#include "pjsua-lib/pjsua.h"
|
|
|
|
|
|
|
|
#include "asterisk/message.h"
|
|
|
|
#include "asterisk/module.h"
|
|
|
|
#include "asterisk/pbx.h"
|
2013-07-30 18:14:50 +00:00
|
|
|
#include "asterisk/res_pjsip.h"
|
|
|
|
#include "asterisk/res_pjsip_session.h"
|
2015-04-03 21:54:36 +00:00
|
|
|
#include "asterisk/taskprocessor.h"
|
2013-06-22 14:03:22 +00:00
|
|
|
|
|
|
|
const pjsip_method pjsip_message_method = {PJSIP_OTHER_METHOD, {"MESSAGE", 7} };
|
|
|
|
|
|
|
|
#define MAX_HDR_SIZE 512
|
|
|
|
#define MAX_BODY_SIZE 1024
|
|
|
|
#define MAX_USER_SIZE 128
|
|
|
|
|
2015-04-03 21:54:36 +00:00
|
|
|
static struct ast_taskprocessor *message_serializer;
|
|
|
|
|
2013-06-22 14:03:22 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Checks to make sure the request has the correct content type.
|
|
|
|
*
|
|
|
|
* \details This module supports the following media types: "text/plain".
|
|
|
|
* Return unsupported otherwise.
|
|
|
|
*
|
|
|
|
* \param rdata The SIP request
|
|
|
|
*/
|
|
|
|
static enum pjsip_status_code check_content_type(const pjsip_rx_data *rdata)
|
|
|
|
{
|
2013-12-11 20:24:50 +00:00
|
|
|
int res;
|
|
|
|
if (rdata->msg_info.msg->body && rdata->msg_info.msg->body->len) {
|
|
|
|
res = ast_sip_is_content_type(
|
|
|
|
&rdata->msg_info.msg->body->content_type, "text", "plain");
|
2013-06-22 14:03:22 +00:00
|
|
|
} else {
|
2013-12-11 20:24:50 +00:00
|
|
|
res = rdata->msg_info.ctype &&
|
|
|
|
!pj_strcmp2(&rdata->msg_info.ctype->media.type, "text") &&
|
|
|
|
!pj_strcmp2(&rdata->msg_info.ctype->media.subtype, "plain");
|
2013-06-22 14:03:22 +00:00
|
|
|
}
|
2013-12-11 20:24:50 +00:00
|
|
|
|
|
|
|
return res ? PJSIP_SC_OK : PJSIP_SC_UNSUPPORTED_MEDIA_TYPE;
|
2013-06-22 14:03:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Puts pointer past 'sip[s]:' string that should be at the
|
|
|
|
* front of the given 'fromto' parameter
|
|
|
|
*
|
|
|
|
* \param fromto 'From' or 'To' field containing 'sip:'
|
|
|
|
*/
|
2014-01-09 23:39:31 +00:00
|
|
|
static const char *skip_sip(const char *fromto)
|
2013-06-22 14:03:22 +00:00
|
|
|
{
|
2014-01-09 23:39:31 +00:00
|
|
|
const char *p;
|
2013-06-22 14:03:22 +00:00
|
|
|
|
|
|
|
/* need to be one past 'sip:' or 'sips:' */
|
|
|
|
if (!(p = strstr(fromto, "sip"))) {
|
|
|
|
return fromto;
|
|
|
|
}
|
|
|
|
|
|
|
|
p += 3;
|
|
|
|
if (*p == 's') {
|
|
|
|
++p;
|
|
|
|
}
|
2014-01-09 23:39:31 +00:00
|
|
|
|
2013-06-22 14:03:22 +00:00
|
|
|
return ++p;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \internal
|
2014-01-09 23:39:31 +00:00
|
|
|
* \brief Retrieves an endpoint if specified in the given 'to'
|
2013-06-22 14:03:22 +00:00
|
|
|
*
|
2014-01-09 23:39:31 +00:00
|
|
|
* Expects the given 'to' to be in one of the following formats:
|
2013-06-22 14:03:22 +00:00
|
|
|
* sip[s]:endpoint[/aor]
|
2016-09-06 16:46:16 +00:00
|
|
|
* sip[s]:endpoint[/uri] - Where uri is: sip[s]:user@domain
|
|
|
|
* sip[s]:endpoint[@domain]
|
|
|
|
* sip[s]:unknown_user@domain <-- will use default outbound endpoint
|
2013-06-22 14:03:22 +00:00
|
|
|
*
|
|
|
|
* If an optional aor is given it will try to find an associated uri
|
|
|
|
* to return. If an optional uri is given then that will be returned,
|
|
|
|
* otherwise uri will be NULL.
|
|
|
|
*
|
2014-01-09 23:39:31 +00:00
|
|
|
* \param to 'From' or 'To' field with possible endpoint
|
2013-06-22 14:03:22 +00:00
|
|
|
* \param uri Optional uri to return
|
|
|
|
*/
|
2016-09-06 16:46:16 +00:00
|
|
|
static struct ast_sip_endpoint *get_outbound_endpoint(const char *to, char **uri)
|
2013-06-22 14:03:22 +00:00
|
|
|
{
|
2016-09-06 16:46:16 +00:00
|
|
|
char *name;
|
|
|
|
char *aor_uri;
|
|
|
|
struct ast_sip_endpoint *endpoint;
|
2013-12-11 20:24:50 +00:00
|
|
|
|
2014-01-09 23:39:31 +00:00
|
|
|
name = ast_strdupa(skip_sip(to));
|
|
|
|
|
|
|
|
/* attempt to extract the endpoint name */
|
2013-12-11 20:24:50 +00:00
|
|
|
if ((aor_uri = strchr(name, '/'))) {
|
2016-09-06 16:46:16 +00:00
|
|
|
/* format was 'endpoint/(aor_name | uri)' */
|
2013-12-11 20:24:50 +00:00
|
|
|
*aor_uri++ = '\0';
|
|
|
|
} else if ((aor_uri = strchr(name, '@'))) {
|
2016-09-06 16:46:16 +00:00
|
|
|
/* format was 'endpoint@domain' - discard the domain */
|
2013-12-11 20:24:50 +00:00
|
|
|
*aor_uri = '\0';
|
2016-08-29 23:08:22 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We may want to match without any user options getting
|
|
|
|
* in the way.
|
|
|
|
*/
|
|
|
|
AST_SIP_USER_OPTIONS_TRUNCATE_CHECK(name);
|
2013-06-22 14:03:22 +00:00
|
|
|
}
|
|
|
|
|
2014-01-09 23:39:31 +00:00
|
|
|
/* at this point, if name is not empty then it
|
|
|
|
might be an endpoint, so try to retrieve it */
|
2016-09-06 16:46:16 +00:00
|
|
|
if (ast_strlen_zero(name)
|
|
|
|
|| !(endpoint = ast_sorcery_retrieve_by_id(ast_sip_get_sorcery(), "endpoint",
|
|
|
|
name))) {
|
2014-01-09 23:39:31 +00:00
|
|
|
/* an endpoint was not found, so assume sending directly
|
|
|
|
to a uri and use the default outbound endpoint */
|
|
|
|
*uri = ast_strdup(to);
|
2013-12-11 20:24:50 +00:00
|
|
|
return ast_sip_default_outbound_endpoint();
|
2013-06-22 14:03:22 +00:00
|
|
|
}
|
|
|
|
|
2016-09-06 16:46:16 +00:00
|
|
|
if (ast_strlen_zero(aor_uri)) {
|
|
|
|
*uri = NULL;
|
|
|
|
} else {
|
|
|
|
struct ast_sip_aor *aor;
|
|
|
|
struct ast_sip_contact *contact = NULL;
|
|
|
|
char *end;
|
|
|
|
|
|
|
|
/* Trim off any stray angle bracket that shouldn't be here */
|
|
|
|
end = strchr(aor_uri, '>');
|
2014-01-09 23:39:31 +00:00
|
|
|
if (end) {
|
2016-09-06 16:46:16 +00:00
|
|
|
*end = '\0';
|
2014-01-09 23:39:31 +00:00
|
|
|
}
|
|
|
|
|
2016-09-06 16:46:16 +00:00
|
|
|
/*
|
|
|
|
* if what's in 'uri' is a retrievable aor use the uri on it
|
|
|
|
* instead, otherwise assume what's there is already a uri
|
|
|
|
*/
|
|
|
|
aor = ast_sip_location_retrieve_aor(aor_uri);
|
|
|
|
if (aor && (contact = ast_sip_location_retrieve_first_aor_contact(aor))) {
|
|
|
|
aor_uri = (char *) contact->uri;
|
2013-12-11 20:24:50 +00:00
|
|
|
}
|
2014-01-09 23:39:31 +00:00
|
|
|
/* need to copy because underlying uri goes away */
|
2016-09-06 16:46:16 +00:00
|
|
|
*uri = ast_strdup(aor_uri);
|
|
|
|
|
|
|
|
ao2_cleanup(contact);
|
|
|
|
ao2_cleanup(aor);
|
2013-06-22 14:03:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return endpoint;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \internal
|
2014-01-09 23:39:31 +00:00
|
|
|
* \brief Overwrite fields in the outbound 'To' header
|
|
|
|
*
|
|
|
|
* Updates display name in an outgoing To header.
|
2013-06-22 14:03:22 +00:00
|
|
|
*
|
2014-01-09 23:39:31 +00:00
|
|
|
* \param tdata the outbound message data structure
|
|
|
|
* \param to info to copy into the header
|
2013-06-22 14:03:22 +00:00
|
|
|
*/
|
2014-01-09 23:39:31 +00:00
|
|
|
static void update_to(pjsip_tx_data *tdata, char *to)
|
2013-06-22 14:03:22 +00:00
|
|
|
{
|
2016-09-06 16:46:16 +00:00
|
|
|
pjsip_name_addr *parsed_name_addr;
|
2013-06-22 14:03:22 +00:00
|
|
|
|
2016-09-06 16:46:16 +00:00
|
|
|
parsed_name_addr = (pjsip_name_addr *) pjsip_parse_uri(tdata->pool, to, strlen(to),
|
|
|
|
PJSIP_PARSE_URI_AS_NAMEADDR);
|
|
|
|
if (parsed_name_addr) {
|
2014-01-09 23:39:31 +00:00
|
|
|
if (pj_strlen(&parsed_name_addr->display)) {
|
2016-09-06 16:46:16 +00:00
|
|
|
pjsip_name_addr *name_addr =
|
|
|
|
(pjsip_name_addr *) PJSIP_MSG_TO_HDR(tdata->msg)->uri;
|
|
|
|
|
|
|
|
pj_strdup(tdata->pool, &name_addr->display, &parsed_name_addr->display);
|
2014-01-09 23:39:31 +00:00
|
|
|
}
|
2013-06-22 14:03:22 +00:00
|
|
|
}
|
2014-01-09 23:39:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Overwrite fields in the outbound 'From' header
|
|
|
|
*
|
|
|
|
* The outbound 'From' header is created/added in ast_sip_create_request with
|
|
|
|
* default data. If available that data may be info specified in the 'from_user'
|
|
|
|
* and 'from_domain' options found on the endpoint. That information will be
|
|
|
|
* overwritten with data in the given 'from' parameter.
|
|
|
|
*
|
|
|
|
* \param tdata the outbound message data structure
|
|
|
|
* \param from info to copy into the header
|
|
|
|
*/
|
|
|
|
static void update_from(pjsip_tx_data *tdata, char *from)
|
|
|
|
{
|
2016-09-06 16:46:16 +00:00
|
|
|
pjsip_name_addr *name_addr;
|
|
|
|
pjsip_sip_uri *uri;
|
|
|
|
pjsip_name_addr *parsed_name_addr;
|
2013-06-22 14:03:22 +00:00
|
|
|
|
2014-01-09 23:39:31 +00:00
|
|
|
if (ast_strlen_zero(from)) {
|
2013-06-22 14:03:22 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-09-06 16:46:16 +00:00
|
|
|
name_addr = (pjsip_name_addr *) PJSIP_MSG_FROM_HDR(tdata->msg)->uri;
|
|
|
|
uri = pjsip_uri_get_uri(name_addr);
|
|
|
|
|
|
|
|
parsed_name_addr = (pjsip_name_addr *) pjsip_parse_uri(tdata->pool, from,
|
|
|
|
strlen(from), PJSIP_PARSE_URI_AS_NAMEADDR);
|
|
|
|
if (parsed_name_addr) {
|
2017-03-21 13:26:28 +00:00
|
|
|
pjsip_sip_uri *parsed_uri;
|
|
|
|
|
|
|
|
if (!PJSIP_URI_SCHEME_IS_SIP(parsed_name_addr->uri)
|
|
|
|
&& !PJSIP_URI_SCHEME_IS_SIPS(parsed_name_addr->uri)) {
|
|
|
|
ast_log(LOG_WARNING, "From address '%s' is not a valid SIP/SIPS URI\n", from);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
parsed_uri = pjsip_uri_get_uri(parsed_name_addr->uri);
|
2016-09-06 16:46:16 +00:00
|
|
|
|
2014-01-09 23:39:31 +00:00
|
|
|
if (pj_strlen(&parsed_name_addr->display)) {
|
2016-09-06 16:46:16 +00:00
|
|
|
pj_strdup(tdata->pool, &name_addr->display, &parsed_name_addr->display);
|
2013-12-11 20:24:50 +00:00
|
|
|
}
|
|
|
|
|
2014-01-09 23:39:31 +00:00
|
|
|
pj_strdup(tdata->pool, &uri->user, &parsed_uri->user);
|
|
|
|
pj_strdup(tdata->pool, &uri->host, &parsed_uri->host);
|
|
|
|
uri->port = parsed_uri->port;
|
2013-06-22 14:03:22 +00:00
|
|
|
} else {
|
|
|
|
/* assume it is 'user[@domain]' format */
|
2014-01-09 23:39:31 +00:00
|
|
|
char *domain = strchr(from, '@');
|
2016-09-06 16:46:16 +00:00
|
|
|
|
2013-06-22 14:03:22 +00:00
|
|
|
if (domain) {
|
2016-09-06 16:46:16 +00:00
|
|
|
pj_str_t pj_from;
|
|
|
|
|
|
|
|
pj_strset3(&pj_from, from, domain);
|
|
|
|
pj_strdup(tdata->pool, &uri->user, &pj_from);
|
|
|
|
|
|
|
|
pj_strdup2(tdata->pool, &uri->host, domain + 1);
|
|
|
|
} else {
|
|
|
|
pj_strdup2(tdata->pool, &uri->user, from);
|
2013-06-22 14:03:22 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Checks if the given msg var name should be blocked.
|
|
|
|
*
|
|
|
|
* \details Some headers are not allowed to be overriden by the user.
|
|
|
|
* Determine if the given var header name from the user is blocked for
|
|
|
|
* an outgoing MESSAGE.
|
|
|
|
*
|
|
|
|
* \param name name of header to see if it is blocked.
|
|
|
|
*
|
|
|
|
* \retval TRUE if the given header is blocked.
|
|
|
|
*/
|
|
|
|
static int is_msg_var_blocked(const char *name)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't block Content-Type or Max-Forwards headers because the
|
|
|
|
* user can override them.
|
|
|
|
*/
|
|
|
|
static const char *hdr[] = {
|
|
|
|
"To",
|
|
|
|
"From",
|
|
|
|
"Via",
|
|
|
|
"Route",
|
|
|
|
"Contact",
|
|
|
|
"Call-ID",
|
|
|
|
"CSeq",
|
|
|
|
"Allow",
|
|
|
|
"Content-Length",
|
|
|
|
"Request-URI",
|
|
|
|
};
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_LEN(hdr); ++i) {
|
|
|
|
if (!strcasecmp(name, hdr[i])) {
|
|
|
|
/* Block addition of this header. */
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Copies any other msg vars over to the request headers.
|
|
|
|
*
|
|
|
|
* \param msg The msg structure to copy headers from
|
|
|
|
* \param tdata The SIP transmission data
|
|
|
|
*/
|
|
|
|
static enum pjsip_status_code vars_to_headers(const struct ast_msg *msg, pjsip_tx_data *tdata)
|
|
|
|
{
|
|
|
|
const char *name;
|
|
|
|
const char *value;
|
|
|
|
int max_forwards;
|
2014-04-30 21:03:29 +00:00
|
|
|
struct ast_msg_var_iterator *iter;
|
2013-06-22 14:03:22 +00:00
|
|
|
|
2014-04-30 21:03:29 +00:00
|
|
|
for (iter = ast_msg_var_iterator_init(msg);
|
|
|
|
ast_msg_var_iterator_next(msg, iter, &name, &value);
|
|
|
|
ast_msg_var_unref_current(iter)) {
|
2013-06-22 14:03:22 +00:00
|
|
|
if (!strcasecmp(name, "Max-Forwards")) {
|
|
|
|
/* Decrement Max-Forwards for SIP loop prevention. */
|
|
|
|
if (sscanf(value, "%30d", &max_forwards) != 1 || --max_forwards == 0) {
|
2014-04-30 21:03:29 +00:00
|
|
|
ast_msg_var_iterator_destroy(iter);
|
2013-06-22 14:03:22 +00:00
|
|
|
ast_log(LOG_NOTICE, "MESSAGE(Max-Forwards) reached zero. MESSAGE not sent.\n");
|
|
|
|
return -1;
|
|
|
|
}
|
2014-04-30 21:03:29 +00:00
|
|
|
sprintf((char *) value, "%d", max_forwards);
|
2013-06-22 14:03:22 +00:00
|
|
|
ast_sip_add_header(tdata, name, value);
|
2013-09-18 14:56:22 +00:00
|
|
|
} else if (!is_msg_var_blocked(name)) {
|
2013-06-22 14:03:22 +00:00
|
|
|
ast_sip_add_header(tdata, name, value);
|
|
|
|
}
|
|
|
|
}
|
2014-04-30 21:03:29 +00:00
|
|
|
ast_msg_var_iterator_destroy(iter);
|
|
|
|
|
2013-06-22 14:03:22 +00:00
|
|
|
return PJSIP_SC_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
2013-09-18 14:56:22 +00:00
|
|
|
* \internal
|
2013-06-22 14:03:22 +00:00
|
|
|
* \brief Copies any other request header data over to ast_msg structure.
|
|
|
|
*
|
|
|
|
* \param rdata The SIP request
|
|
|
|
* \param msg The msg structure to copy headers into
|
|
|
|
*/
|
|
|
|
static int headers_to_vars(const pjsip_rx_data *rdata, struct ast_msg *msg)
|
|
|
|
{
|
|
|
|
char *c;
|
2013-12-11 20:24:50 +00:00
|
|
|
char name[MAX_HDR_SIZE];
|
2013-06-22 14:03:22 +00:00
|
|
|
char buf[MAX_HDR_SIZE];
|
|
|
|
int res = 0;
|
|
|
|
pjsip_hdr *h = rdata->msg_info.msg->hdr.next;
|
|
|
|
pjsip_hdr *end= &rdata->msg_info.msg->hdr;
|
|
|
|
|
|
|
|
while (h != end) {
|
|
|
|
if ((res = pjsip_hdr_print_on(h, buf, sizeof(buf)-1)) > 0) {
|
|
|
|
buf[res] = '\0';
|
|
|
|
if ((c = strchr(buf, ':'))) {
|
2013-12-11 20:24:50 +00:00
|
|
|
ast_copy_string(buf, ast_skip_blanks(c + 1), sizeof(buf));
|
2013-06-22 14:03:22 +00:00
|
|
|
}
|
|
|
|
|
2013-12-11 20:24:50 +00:00
|
|
|
ast_copy_pj_str(name, &h->name, sizeof(name));
|
|
|
|
if ((res = ast_msg_set_var(msg, name, buf)) != 0) {
|
2013-06-22 14:03:22 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
h = h->next;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Prints the message body into the given char buffer.
|
|
|
|
*
|
|
|
|
* \details Copies body content from the received data into the given
|
|
|
|
* character buffer removing any extra carriage return/line feeds.
|
|
|
|
*
|
|
|
|
* \param rdata The SIP request
|
|
|
|
* \param buf Buffer to fill
|
|
|
|
* \param len The length of the buffer
|
|
|
|
*/
|
|
|
|
static int print_body(pjsip_rx_data *rdata, char *buf, int len)
|
|
|
|
{
|
2013-12-11 20:24:50 +00:00
|
|
|
int res;
|
|
|
|
|
|
|
|
if (!rdata->msg_info.msg->body || !rdata->msg_info.msg->body->len) {
|
|
|
|
return 0;
|
|
|
|
}
|
2013-06-22 14:03:22 +00:00
|
|
|
|
2013-12-11 20:24:50 +00:00
|
|
|
if ((res = rdata->msg_info.msg->body->print_body(
|
|
|
|
rdata->msg_info.msg->body, buf, len)) < 0) {
|
2013-06-22 14:03:22 +00:00
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* remove any trailing carriage return/line feeds */
|
|
|
|
while (res > 0 && ((buf[--res] == '\r') || (buf[res] == '\n')));
|
|
|
|
|
|
|
|
buf[++res] = '\0';
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2014-01-09 23:39:31 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Converts a 'sip:' uri to a 'pjsip:' so it can be found by
|
|
|
|
* the message tech.
|
|
|
|
*
|
|
|
|
* \param buf uri to insert 'pjsip' into
|
|
|
|
* \param size length of the uri in buf
|
|
|
|
* \param capacity total size of buf
|
|
|
|
*/
|
|
|
|
static char *sip_to_pjsip(char *buf, int size, int capacity)
|
|
|
|
{
|
|
|
|
int count;
|
|
|
|
const char *scheme;
|
|
|
|
char *res = buf;
|
|
|
|
|
|
|
|
/* remove any wrapping brackets */
|
|
|
|
if (*buf == '<') {
|
|
|
|
++buf;
|
|
|
|
--size;
|
|
|
|
}
|
|
|
|
|
|
|
|
scheme = strncmp(buf, "sip", 3) ? "pjsip:" : "pj";
|
|
|
|
count = strlen(scheme);
|
|
|
|
if (count + size >= capacity) {
|
|
|
|
ast_log(LOG_WARNING, "Unable to handle MESSAGE- incoming uri "
|
|
|
|
"too large for given buffer\n");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
memmove(res + count, buf, size);
|
|
|
|
memcpy(res, scheme, count);
|
|
|
|
|
|
|
|
buf += size - 1;
|
|
|
|
if (*buf == '>') {
|
|
|
|
*buf = '\0';
|
|
|
|
}
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2013-06-22 14:03:22 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Converts a pjsip_rx_data structure to an ast_msg structure.
|
|
|
|
*
|
|
|
|
* \details Attempts to fill in as much information as possible into the given
|
|
|
|
* msg structure copied from the given request data.
|
|
|
|
*
|
|
|
|
* \param rdata The SIP request
|
|
|
|
* \param msg The asterisk message structure to fill in.
|
|
|
|
*/
|
|
|
|
static enum pjsip_status_code rx_data_to_ast_msg(pjsip_rx_data *rdata, struct ast_msg *msg)
|
|
|
|
{
|
2015-03-20 19:54:48 +00:00
|
|
|
RAII_VAR(struct ast_sip_endpoint *, endpt, NULL, ao2_cleanup);
|
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
|
|
|
pjsip_uri *ruri = rdata->msg_info.msg->line.req.uri;
|
|
|
|
pjsip_sip_uri *sip_ruri;
|
2013-06-22 14:03:22 +00:00
|
|
|
pjsip_name_addr *name_addr;
|
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 buf[MAX_BODY_SIZE];
|
2013-06-22 14:03:22 +00:00
|
|
|
const char *field;
|
2015-03-20 19:54:48 +00:00
|
|
|
const char *context;
|
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 exten[AST_MAX_EXTENSION];
|
|
|
|
int res = 0;
|
|
|
|
int size;
|
2013-06-22 14:03:22 +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
|
|
|
if (!PJSIP_URI_SCHEME_IS_SIP(ruri) && !PJSIP_URI_SCHEME_IS_SIPS(ruri)) {
|
|
|
|
return PJSIP_SC_UNSUPPORTED_URI_SCHEME;
|
2013-06-22 14:03:22 +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
|
|
|
sip_ruri = pjsip_uri_get_uri(ruri);
|
|
|
|
ast_copy_pj_str(exten, &sip_ruri->user, AST_MAX_EXTENSION);
|
|
|
|
|
2016-08-29 23:08:22 +00:00
|
|
|
/*
|
|
|
|
* We may want to match in the dialplan without any user
|
|
|
|
* options getting in the way.
|
|
|
|
*/
|
|
|
|
AST_SIP_USER_OPTIONS_TRUNCATE_CHECK(exten);
|
|
|
|
|
2015-03-20 19:54:48 +00:00
|
|
|
endpt = ast_pjsip_rdata_get_endpoint(rdata);
|
|
|
|
ast_assert(endpt != NULL);
|
|
|
|
|
|
|
|
context = S_OR(endpt->message_context, endpt->context);
|
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
|
|
|
res |= ast_msg_set_context(msg, "%s", context);
|
|
|
|
res |= ast_msg_set_exten(msg, "%s", exten);
|
2013-06-22 14:03:22 +00:00
|
|
|
|
|
|
|
/* to header */
|
2014-01-09 23:39:31 +00:00
|
|
|
name_addr = (pjsip_name_addr *)rdata->msg_info.to->uri;
|
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
|
|
|
size = pjsip_uri_print(PJSIP_URI_IN_FROMTO_HDR, name_addr, buf, sizeof(buf) - 1);
|
|
|
|
if (size <= 0) {
|
|
|
|
return PJSIP_SC_INTERNAL_SERVER_ERROR;
|
2014-01-09 23:39:31 +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
|
|
|
buf[size] = '\0';
|
|
|
|
res |= ast_msg_set_to(msg, "%s", sip_to_pjsip(buf, ++size, sizeof(buf) - 1));
|
2013-06-22 14:03:22 +00:00
|
|
|
|
|
|
|
/* from header */
|
|
|
|
name_addr = (pjsip_name_addr *)rdata->msg_info.from->uri;
|
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
|
|
|
size = pjsip_uri_print(PJSIP_URI_IN_FROMTO_HDR, name_addr, buf, sizeof(buf) - 1);
|
|
|
|
if (size <= 0) {
|
|
|
|
return PJSIP_SC_INTERNAL_SERVER_ERROR;
|
2013-06-22 14:03:22 +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
|
|
|
buf[size] = '\0';
|
|
|
|
res |= ast_msg_set_from(msg, "%s", buf);
|
2013-06-22 14:03:22 +00:00
|
|
|
|
2017-08-10 14:09:29 +00:00
|
|
|
field = pj_sockaddr_print(&rdata->pkt_info.src_addr, buf, sizeof(buf) - 1, 3);
|
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
|
|
|
res |= ast_msg_set_var(msg, "PJSIP_RECVADDR", field);
|
2013-06-22 14:03:22 +00:00
|
|
|
|
2016-06-21 15:53:05 +00:00
|
|
|
switch (rdata->tp_info.transport->key.type) {
|
|
|
|
case PJSIP_TRANSPORT_UDP:
|
|
|
|
case PJSIP_TRANSPORT_UDP6:
|
|
|
|
field = "udp";
|
|
|
|
break;
|
|
|
|
case PJSIP_TRANSPORT_TCP:
|
|
|
|
case PJSIP_TRANSPORT_TCP6:
|
|
|
|
field = "tcp";
|
|
|
|
break;
|
|
|
|
case PJSIP_TRANSPORT_TLS:
|
|
|
|
case PJSIP_TRANSPORT_TLS6:
|
|
|
|
field = "tls";
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
field = rdata->tp_info.transport->type_name;
|
|
|
|
}
|
|
|
|
ast_msg_set_var(msg, "PJSIP_TRANSPORT", field);
|
|
|
|
|
2013-06-22 14:03:22 +00:00
|
|
|
if (print_body(rdata, buf, sizeof(buf) - 1) > 0) {
|
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
|
|
|
res |= ast_msg_set_body(msg, "%s", buf);
|
2013-06-22 14:03:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* endpoint name */
|
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
|
|
|
res |= ast_msg_set_tech(msg, "%s", "PJSIP");
|
|
|
|
res |= ast_msg_set_endpoint(msg, "%s", ast_sorcery_object_get_id(endpt));
|
2013-07-30 15:17:56 +00:00
|
|
|
if (endpt->id.self.name.valid) {
|
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
|
|
|
res |= ast_msg_set_var(msg, "PJSIP_ENDPOINT", endpt->id.self.name.str);
|
2013-06-22 14:03:22 +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
|
|
|
res |= headers_to_vars(rdata, msg);
|
2013-06-22 14:03:22 +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
|
|
|
return !res ? PJSIP_SC_OK : PJSIP_SC_INTERNAL_SERVER_ERROR;
|
2013-06-22 14:03:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
struct msg_data {
|
|
|
|
struct ast_msg *msg;
|
|
|
|
char *to;
|
|
|
|
char *from;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void msg_data_destroy(void *obj)
|
|
|
|
{
|
|
|
|
struct msg_data *mdata = obj;
|
|
|
|
|
|
|
|
ast_free(mdata->from);
|
|
|
|
ast_free(mdata->to);
|
|
|
|
|
|
|
|
ast_msg_destroy(mdata->msg);
|
|
|
|
}
|
|
|
|
|
2016-09-06 16:46:16 +00:00
|
|
|
static struct msg_data *msg_data_create(const struct ast_msg *msg, const char *to, const char *from)
|
2013-06-22 14:03:22 +00:00
|
|
|
{
|
2016-08-29 23:08:22 +00:00
|
|
|
char *uri_params;
|
2013-06-22 14:03:22 +00:00
|
|
|
struct msg_data *mdata = ao2_alloc(sizeof(*mdata), msg_data_destroy);
|
|
|
|
|
|
|
|
if (!mdata) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* typecast to suppress const warning */
|
2016-09-06 16:46:16 +00:00
|
|
|
mdata->msg = ast_msg_ref((struct ast_msg *) msg);
|
2013-06-22 14:03:22 +00:00
|
|
|
|
2016-09-06 16:46:16 +00:00
|
|
|
/* To starts with 'pjsip:' which needs to be removed. */
|
2014-01-09 23:39:31 +00:00
|
|
|
if (!(to = strchr(to, ':'))) {
|
|
|
|
ao2_ref(mdata, -1);
|
|
|
|
return NULL;
|
|
|
|
}
|
2016-09-06 16:46:16 +00:00
|
|
|
++to;/* Now skip the ':' */
|
2014-01-09 23:39:31 +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
|
|
|
/* Make sure we start with sip: */
|
2016-09-06 16:46:16 +00:00
|
|
|
mdata->to = ast_begins_with(to, "sip:") ? ast_strdup(to) : ast_strdup(to - 4);
|
2013-06-22 14:03:22 +00:00
|
|
|
mdata->from = ast_strdup(from);
|
2016-03-02 15:34:10 +00:00
|
|
|
if (!mdata->to || !mdata->from) {
|
|
|
|
ao2_ref(mdata, -1);
|
|
|
|
return NULL;
|
|
|
|
}
|
2013-06-22 14:03:22 +00:00
|
|
|
|
2016-08-29 23:08:22 +00:00
|
|
|
/*
|
|
|
|
* Sometimes from URI can contain URI parameters, so remove them.
|
|
|
|
*
|
|
|
|
* sip:user;user-options@domain;uri-parameters
|
|
|
|
*/
|
|
|
|
uri_params = strchr(mdata->from, '@');
|
|
|
|
if (uri_params && (uri_params = strchr(mdata->from, ';'))) {
|
|
|
|
*uri_params = '\0';
|
2013-06-22 14:03:22 +00:00
|
|
|
}
|
|
|
|
return mdata;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int msg_send(void *data)
|
|
|
|
{
|
|
|
|
RAII_VAR(struct msg_data *, mdata, data, ao2_cleanup);
|
|
|
|
|
|
|
|
const struct ast_sip_body body = {
|
|
|
|
.type = "text",
|
|
|
|
.subtype = "plain",
|
|
|
|
.body_text = ast_msg_get_body(mdata->msg)
|
|
|
|
};
|
|
|
|
|
|
|
|
pjsip_tx_data *tdata;
|
2013-12-11 20:24:50 +00:00
|
|
|
RAII_VAR(char *, uri, NULL, ast_free);
|
2016-09-06 16:46:16 +00:00
|
|
|
RAII_VAR(struct ast_sip_endpoint *, endpoint, NULL, ao2_cleanup);
|
2013-12-11 20:24:50 +00:00
|
|
|
|
2016-09-06 16:46:16 +00:00
|
|
|
endpoint = get_outbound_endpoint(mdata->to, &uri);
|
2013-06-22 14:03:22 +00:00
|
|
|
if (!endpoint) {
|
2016-09-06 16:46:16 +00:00
|
|
|
ast_log(LOG_ERROR,
|
|
|
|
"PJSIP MESSAGE - Could not find endpoint '%s' and no default outbound endpoint configured\n",
|
|
|
|
mdata->to);
|
2013-06-22 14:03:22 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2014-01-15 13:16:10 +00:00
|
|
|
if (ast_sip_create_request("MESSAGE", NULL, endpoint, uri, NULL, &tdata)) {
|
2013-12-11 20:24:50 +00:00
|
|
|
ast_log(LOG_ERROR, "PJSIP MESSAGE - Could not create request\n");
|
2013-06-22 14:03:22 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2014-01-09 23:39:31 +00:00
|
|
|
update_to(tdata, mdata->to);
|
|
|
|
update_from(tdata, mdata->from);
|
|
|
|
|
2013-06-22 14:03:22 +00:00
|
|
|
if (ast_sip_add_body(tdata, &body)) {
|
|
|
|
pjsip_tx_data_dec_ref(tdata);
|
2013-12-11 20:24:50 +00:00
|
|
|
ast_log(LOG_ERROR, "PJSIP MESSAGE - Could not add body to request\n");
|
2013-06-22 14:03:22 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
vars_to_headers(mdata->msg, tdata);
|
2013-12-11 20:24:50 +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
|
|
|
ast_debug(1, "Sending message to '%s' (via endpoint %s) from '%s'\n",
|
|
|
|
mdata->to, ast_sorcery_object_get_id(endpoint), mdata->from);
|
|
|
|
|
2014-01-15 13:16:10 +00:00
|
|
|
if (ast_sip_send_request(tdata, NULL, endpoint, NULL, NULL)) {
|
2013-12-11 20:24:50 +00:00
|
|
|
ast_log(LOG_ERROR, "PJSIP MESSAGE - Could not send request\n");
|
2013-06-22 14:03:22 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return PJ_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int sip_msg_send(const struct ast_msg *msg, const char *to, const char *from)
|
|
|
|
{
|
|
|
|
struct msg_data *mdata;
|
|
|
|
|
|
|
|
if (ast_strlen_zero(to)) {
|
|
|
|
ast_log(LOG_ERROR, "SIP MESSAGE - a 'To' URI must be specified\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(mdata = msg_data_create(msg, to, from)) ||
|
2015-04-03 21:54:36 +00:00
|
|
|
ast_sip_push_task(message_serializer, msg_send, mdata)) {
|
2016-03-02 17:17:54 +00:00
|
|
|
ao2_cleanup(mdata);
|
2013-06-22 14:03:22 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct ast_msg_tech msg_tech = {
|
2013-09-18 14:56:22 +00:00
|
|
|
.name = "pjsip",
|
2013-06-22 14:03:22 +00:00
|
|
|
.msg_send = sip_msg_send,
|
|
|
|
};
|
|
|
|
|
|
|
|
static pj_status_t send_response(pjsip_rx_data *rdata, enum pjsip_status_code code,
|
|
|
|
pjsip_dialog *dlg, pjsip_transaction *tsx)
|
|
|
|
{
|
|
|
|
pjsip_tx_data *tdata;
|
|
|
|
pj_status_t status;
|
|
|
|
|
2014-01-15 13:16:10 +00:00
|
|
|
status = ast_sip_create_response(rdata, code, NULL, &tdata);
|
2013-06-22 14:03:22 +00:00
|
|
|
if (status != PJ_SUCCESS) {
|
|
|
|
ast_log(LOG_ERROR, "Unable to create response (%d)\n", status);
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dlg && tsx) {
|
|
|
|
status = pjsip_dlg_send_response(dlg, tsx, tdata);
|
|
|
|
} else {
|
2015-03-20 19:54:48 +00:00
|
|
|
struct ast_sip_endpoint *endpoint;
|
|
|
|
|
|
|
|
endpoint = ast_pjsip_rdata_get_endpoint(rdata);
|
2015-03-27 20:46:55 +00:00
|
|
|
status = ast_sip_send_stateful_response(rdata, tdata, endpoint);
|
2015-03-20 19:54:48 +00:00
|
|
|
ao2_cleanup(endpoint);
|
2013-06-22 14:03:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (status != PJ_SUCCESS) {
|
|
|
|
ast_log(LOG_ERROR, "Unable to send response (%d)\n", status);
|
|
|
|
}
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
static pj_bool_t module_on_rx_request(pjsip_rx_data *rdata)
|
|
|
|
{
|
|
|
|
enum pjsip_status_code code;
|
|
|
|
struct ast_msg *msg;
|
|
|
|
|
|
|
|
/* if not a MESSAGE, don't handle */
|
|
|
|
if (pjsip_method_cmp(&rdata->msg_info.msg->line.req.method, &pjsip_message_method)) {
|
|
|
|
return PJ_FALSE;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
code = check_content_type(rdata);
|
|
|
|
if (code != PJSIP_SC_OK) {
|
|
|
|
send_response(rdata, code, NULL, NULL);
|
|
|
|
return PJ_TRUE;
|
|
|
|
}
|
|
|
|
|
2013-06-22 14:03:22 +00:00
|
|
|
msg = ast_msg_alloc();
|
|
|
|
if (!msg) {
|
|
|
|
send_response(rdata, PJSIP_SC_INTERNAL_SERVER_ERROR, NULL, NULL);
|
|
|
|
return PJ_TRUE;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
code = rx_data_to_ast_msg(rdata, msg);
|
|
|
|
if (code != PJSIP_SC_OK) {
|
2013-06-22 14:03:22 +00:00
|
|
|
send_response(rdata, code, NULL, 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
|
|
|
ast_msg_destroy(msg);
|
2013-06-22 14:03:22 +00:00
|
|
|
return PJ_TRUE;
|
|
|
|
}
|
|
|
|
|
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 (!ast_msg_has_destination(msg)) {
|
|
|
|
ast_debug(1, "MESSAGE request received, but no handler wanted it\n");
|
|
|
|
send_response(rdata, PJSIP_SC_NOT_FOUND, NULL, NULL);
|
|
|
|
ast_msg_destroy(msg);
|
|
|
|
return PJ_TRUE;
|
2013-06-22 14:03:22 +00:00
|
|
|
}
|
|
|
|
|
2015-04-07 15:34:53 +00:00
|
|
|
/* Send it to the messaging core.
|
|
|
|
*
|
|
|
|
* If we are unable to send a response, the most likely reason is that we
|
|
|
|
* are handling a retransmission of an incoming MESSAGE and were unable to
|
|
|
|
* create a transaction due to a duplicate key. If we are unable to send
|
|
|
|
* a response, we should not queue the message to the dialplan
|
|
|
|
*/
|
|
|
|
if (!send_response(rdata, PJSIP_SC_ACCEPTED, NULL, NULL)) {
|
|
|
|
ast_msg_queue(msg);
|
|
|
|
}
|
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
|
|
|
|
2013-06-22 14:03:22 +00:00
|
|
|
return PJ_TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int incoming_in_dialog_request(struct ast_sip_session *session, struct pjsip_rx_data *rdata)
|
|
|
|
{
|
|
|
|
char buf[MAX_BODY_SIZE];
|
|
|
|
enum pjsip_status_code code;
|
|
|
|
struct ast_frame f;
|
|
|
|
pjsip_dialog *dlg = session->inv_session->dlg;
|
|
|
|
pjsip_transaction *tsx = pjsip_rdata_get_tsx(rdata);
|
|
|
|
|
2015-02-17 15:34:10 +00:00
|
|
|
if (!session->channel) {
|
|
|
|
send_response(rdata, PJSIP_SC_NOT_FOUND, dlg, tsx);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-06-22 14:03:22 +00:00
|
|
|
if ((code = check_content_type(rdata)) != PJSIP_SC_OK) {
|
|
|
|
send_response(rdata, code, dlg, tsx);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (print_body(rdata, buf, sizeof(buf)-1) < 1) {
|
|
|
|
/* invalid body size */
|
2015-02-17 15:34:10 +00:00
|
|
|
send_response(rdata, PJSIP_SC_REQUEST_ENTITY_TOO_LARGE, dlg, tsx);
|
2013-06-22 14:03:22 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-10-30 17:54:26 +00:00
|
|
|
ast_debug(3, "Received in dialog SIP message\n");
|
|
|
|
|
2013-06-22 14:03:22 +00:00
|
|
|
memset(&f, 0, sizeof(f));
|
|
|
|
f.frametype = AST_FRAME_TEXT;
|
|
|
|
f.subclass.integer = 0;
|
|
|
|
f.offset = 0;
|
|
|
|
f.data.ptr = buf;
|
|
|
|
f.datalen = strlen(buf) + 1;
|
|
|
|
ast_queue_frame(session->channel, &f);
|
|
|
|
|
|
|
|
send_response(rdata, PJSIP_SC_ACCEPTED, dlg, tsx);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct ast_sip_session_supplement messaging_supplement = {
|
|
|
|
.method = "MESSAGE",
|
|
|
|
.incoming_request = incoming_in_dialog_request
|
|
|
|
};
|
|
|
|
|
|
|
|
static pjsip_module messaging_module = {
|
|
|
|
.name = {"Messaging Module", 16},
|
|
|
|
.id = -1,
|
|
|
|
.priority = PJSIP_MOD_PRIORITY_APPLICATION,
|
|
|
|
.on_rx_request = module_on_rx_request,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int load_module(void)
|
|
|
|
{
|
2014-10-16 16:32:25 +00:00
|
|
|
CHECK_PJSIP_SESSION_MODULE_LOADED();
|
|
|
|
|
2013-06-22 14:03:22 +00:00
|
|
|
if (ast_sip_register_service(&messaging_module) != PJ_SUCCESS) {
|
|
|
|
return AST_MODULE_LOAD_DECLINE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pjsip_endpt_add_capability(ast_sip_get_pjsip_endpoint(),
|
|
|
|
NULL, PJSIP_H_ALLOW, NULL, 1,
|
|
|
|
&pjsip_message_method.name) != PJ_SUCCESS) {
|
|
|
|
|
|
|
|
ast_sip_unregister_service(&messaging_module);
|
|
|
|
return AST_MODULE_LOAD_DECLINE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ast_msg_tech_register(&msg_tech)) {
|
|
|
|
ast_sip_unregister_service(&messaging_module);
|
|
|
|
return AST_MODULE_LOAD_DECLINE;
|
|
|
|
}
|
|
|
|
|
2016-01-07 01:10:16 +00:00
|
|
|
message_serializer = ast_sip_create_serializer("pjsip/messaging");
|
2015-04-03 21:54:36 +00:00
|
|
|
if (!message_serializer) {
|
|
|
|
ast_sip_unregister_service(&messaging_module);
|
|
|
|
ast_msg_tech_unregister(&msg_tech);
|
|
|
|
return AST_MODULE_LOAD_DECLINE;
|
|
|
|
}
|
|
|
|
|
2013-06-22 14:03:22 +00:00
|
|
|
ast_sip_session_register_supplement(&messaging_supplement);
|
|
|
|
return AST_MODULE_LOAD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int unload_module(void)
|
|
|
|
{
|
|
|
|
ast_sip_session_unregister_supplement(&messaging_supplement);
|
|
|
|
ast_msg_tech_unregister(&msg_tech);
|
|
|
|
ast_sip_unregister_service(&messaging_module);
|
2015-04-03 21:54:36 +00:00
|
|
|
ast_taskprocessor_unreference(message_serializer);
|
2013-06-22 14:03:22 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-07-30 18:14:50 +00:00
|
|
|
AST_MODULE_INFO(ASTERISK_GPL_KEY, AST_MODFLAG_LOAD_ORDER, "PJSIP Messaging Support",
|
2015-05-06 00:49:04 +00:00
|
|
|
.support_level = AST_MODULE_SUPPORT_CORE,
|
|
|
|
.load = load_module,
|
|
|
|
.unload = unload_module,
|
|
|
|
.load_pri = AST_MODPRI_APP_DEPEND,
|
|
|
|
);
|