asterisk/main/json.c

828 lines
21 KiB
C
Raw Normal View History

/*
* Asterisk -- An open source telephony toolkit.
*
* Copyright (C) 2012 - 2013, Digium, Inc.
*
* David M. Lee, II <dlee@digium.com>
*
* See http://www.asterisk.org for more information about
* the Asterisk project. Please do not directly contact
* any of the maintainers of this project for assistance;
* the project provides a web site, mailing lists and IRC
* channels for your use.
*
* This program is free software, distributed under the terms of
* the GNU General Public License Version 2. See the LICENSE file
* at the top of the source tree.
*/
/*! \file
*
* \brief JSON abstraction layer.
*
* This is a very thin wrapper around the Jansson API. For more details on it,
* see its docs at http://www.digip.org/jansson/doc/2.11/apiref.html.
*
* \author David M. Lee, II <dlee@digium.com>
*/
/*** MODULEINFO
<depend>jansson</depend>
<support_level>core</support_level>
***/
#include "asterisk.h"
#include "asterisk/json.h"
#include "asterisk/localtime.h"
#include "asterisk/module.h"
#include "asterisk/utils.h"
#include "asterisk/astobj2.h"
#include "asterisk/channel.h"
#include "asterisk/callerid.h"
#include <jansson.h>
#include <time.h>
void *ast_json_malloc(size_t size)
{
return ast_malloc(size);
}
void ast_json_free(void *p)
{
ast_free(p);
}
void ast_json_set_alloc_funcs(void *(*malloc_fn)(size_t), void (*free_fn)(void*))
{
json_set_alloc_funcs(malloc_fn, free_fn);
}
void ast_json_reset_alloc_funcs(void)
{
json_set_alloc_funcs(ast_json_malloc, ast_json_free);
}
struct ast_json *ast_json_ref(struct ast_json *json)
{
json_incref((json_t *)json);
return json;
}
void ast_json_unref(struct ast_json *json)
{
json_decref((json_t *) json);
}
enum ast_json_type ast_json_typeof(const struct ast_json *json)
{
int r = json_typeof((json_t*)json);
switch(r) {
case JSON_OBJECT: return AST_JSON_OBJECT;
case JSON_ARRAY: return AST_JSON_ARRAY;
case JSON_STRING: return AST_JSON_STRING;
case JSON_INTEGER: return AST_JSON_INTEGER;
case JSON_REAL: return AST_JSON_REAL;
case JSON_TRUE: return AST_JSON_TRUE;
case JSON_FALSE: return AST_JSON_FALSE;
case JSON_NULL: return AST_JSON_NULL;
}
ast_assert(0); /* Unexpect return from json_typeof */
return r;
}
Update events to use Swagger 1.3 subtyping, and related aftermath This patch started with the simple idea of changing the /events data model to be more sane. The original model would send out events like: { "stasis_start": { "args": [], "channel": { ... } } } The event discriminator was the field name instead of being a value in the object, due to limitations in how Swagger 1.1 could model objects. While technically sufficient in communicating event information, it was really difficult to deal with in terms of client side JSON handling. This patch takes advantage of a proposed extension[1] to Swagger which allows type variance through the use of a discriminator field. This had a domino effect that made this a surprisingly large patch. [1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ In changing the models, I also had to change the swagger_model.py processor so it can handle the type discriminator and subtyping. I took that a big step forward, and using that information to generate an ari_model module, which can validate a JSON object against the Swagger model. The REST and WebSocket generators were changed to take advantage of the validators. If compiled with AST_DEVMODE enabled, JSON objects that don't match their corresponding models will not be sent out. For REST API calls, a 500 Internal Server response is sent. For WebSockets, the invalid JSON message is replaced with an error message. Since this took over about half of the job of the existing JSON generators, and the .to_json virtual function on messages took over the other half, I reluctantly removed the generators. The validators turned up all sorts of errors and inconsistencies in our data models, and the code. These were cleaned up, with checks in the code generator avoid some of the consistency problems in the future. * The model for a channel snapshot was trimmed down to match the information sent via AMI. Many of the field being sent were not useful in the general case. * The model for a bridge snapshot was updated to be more consistent with the other ARI models. Another impact of introducing subtyping was that the swagger-codegen documentation generator was insufficient (at least until it catches up with Swagger 1.2). I wanted it to be easier to generate docs for the API anyways, so I ported the wiki pages to use the Asterisk Swagger generator. In the process, I was able to clean up many of the model links, which would occasionally give inconsistent results on the wiki. I also added error responses to the wiki docs, making the wiki documentation more complete. Finally, since Stasis-HTTP will now be named Asterisk REST Interface (ARI), any new functions and files I created carry the ari_ prefix. I changed a few stasis_http references to ari where it was non-intrusive and made sense. (closes issue ASTERISK-21885) Review: https://reviewboard.asterisk.org/r/2639/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
const char *ast_json_typename(enum ast_json_type type)
{
switch (type) {
case AST_JSON_OBJECT: return "object";
case AST_JSON_ARRAY: return "array";
case AST_JSON_STRING: return "string";
case AST_JSON_INTEGER: return "integer";
case AST_JSON_REAL: return "real";
case AST_JSON_TRUE: return "boolean";
case AST_JSON_FALSE: return "boolean";
case AST_JSON_NULL: return "null";
}
ast_assert(0);
return "?";
}
/* Ported from libjansson utf.c:utf8_check_first() */
static size_t json_utf8_check_first(char byte)
{
unsigned char ch = (unsigned char) byte;
if (ch < 0x80) {
return 1;
}
if (0x80 <= ch && ch <= 0xBF) {
/* second, third or fourth byte of a multi-byte
sequence, i.e. a "continuation byte" */
return 0;
} else if (ch == 0xC0 || ch == 0xC1) {
/* overlong encoding of an ASCII byte */
return 0;
} else if (0xC2 <= ch && ch <= 0xDF) {
/* 2-byte sequence */
return 2;
} else if (0xE0 <= ch && ch <= 0xEF) {
/* 3-byte sequence */
return 3;
} else if (0xF0 <= ch && ch <= 0xF4) {
/* 4-byte sequence */
return 4;
} else { /* ch >= 0xF5 */
/* Restricted (start of 4-, 5- or 6-byte sequence) or invalid
UTF-8 */
return 0;
}
}
/* Ported from libjansson utf.c:utf8_check_full() */
static size_t json_utf8_check_full(const char *str, size_t len)
{
size_t pos;
int32_t value;
unsigned char ch = (unsigned char) str[0];
if (len == 2) {
value = ch & 0x1F;
} else if (len == 3) {
value = ch & 0xF;
} else if (len == 4) {
value = ch & 0x7;
} else {
return 0;
}
for (pos = 1; pos < len; ++pos) {
ch = (unsigned char) str[pos];
if (ch < 0x80 || ch > 0xBF) {
/* not a continuation byte */
return 0;
}
value = (value << 6) + (ch & 0x3F);
}
if (value > 0x10FFFF) {
/* not in Unicode range */
return 0;
} else if (0xD800 <= value && value <= 0xDFFF) {
/* invalid code point (UTF-16 surrogate halves) */
return 0;
} else if ((len == 2 && value < 0x80)
|| (len == 3 && value < 0x800)
|| (len == 4 && value < 0x10000)) {
/* overlong encoding */
return 0;
}
return 1;
}
int ast_json_utf8_check_len(const char *str, size_t len)
{
size_t pos;
size_t count;
int res = 1;
if (!str) {
return 0;
}
/*
* Since the json library does not make the check function
* public we recreate/copy the function in our interface
* module.
*
* Loop ported from libjansson utf.c:utf8_check_string()
*/
for (pos = 0; pos < len; pos += count) {
count = json_utf8_check_first(str[pos]);
if (count == 0) {
res = 0;
break;
} else if (count > 1) {
if (count > len - pos) {
/* UTF-8 needs more than we have left in the string. */
res = 0;
break;
}
if (!json_utf8_check_full(&str[pos], count)) {
res = 0;
break;
}
}
}
if (!res) {
ast_debug(1, "String '%.*s' is not UTF-8 for json conversion\n", (int) len, str);
}
return res;
}
int ast_json_utf8_check(const char *str)
{
return str ? ast_json_utf8_check_len(str, strlen(str)) : 0;
}
Update events to use Swagger 1.3 subtyping, and related aftermath This patch started with the simple idea of changing the /events data model to be more sane. The original model would send out events like: { "stasis_start": { "args": [], "channel": { ... } } } The event discriminator was the field name instead of being a value in the object, due to limitations in how Swagger 1.1 could model objects. While technically sufficient in communicating event information, it was really difficult to deal with in terms of client side JSON handling. This patch takes advantage of a proposed extension[1] to Swagger which allows type variance through the use of a discriminator field. This had a domino effect that made this a surprisingly large patch. [1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ In changing the models, I also had to change the swagger_model.py processor so it can handle the type discriminator and subtyping. I took that a big step forward, and using that information to generate an ari_model module, which can validate a JSON object against the Swagger model. The REST and WebSocket generators were changed to take advantage of the validators. If compiled with AST_DEVMODE enabled, JSON objects that don't match their corresponding models will not be sent out. For REST API calls, a 500 Internal Server response is sent. For WebSockets, the invalid JSON message is replaced with an error message. Since this took over about half of the job of the existing JSON generators, and the .to_json virtual function on messages took over the other half, I reluctantly removed the generators. The validators turned up all sorts of errors and inconsistencies in our data models, and the code. These were cleaned up, with checks in the code generator avoid some of the consistency problems in the future. * The model for a channel snapshot was trimmed down to match the information sent via AMI. Many of the field being sent were not useful in the general case. * The model for a bridge snapshot was updated to be more consistent with the other ARI models. Another impact of introducing subtyping was that the swagger-codegen documentation generator was insufficient (at least until it catches up with Swagger 1.2). I wanted it to be easier to generate docs for the API anyways, so I ported the wiki pages to use the Asterisk Swagger generator. In the process, I was able to clean up many of the model links, which would occasionally give inconsistent results on the wiki. I also added error responses to the wiki docs, making the wiki documentation more complete. Finally, since Stasis-HTTP will now be named Asterisk REST Interface (ARI), any new functions and files I created carry the ari_ prefix. I changed a few stasis_http references to ari where it was non-intrusive and made sense. (closes issue ASTERISK-21885) Review: https://reviewboard.asterisk.org/r/2639/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
struct ast_json *ast_json_true(void)
{
return (struct ast_json *)json_true();
}
struct ast_json *ast_json_false(void)
{
return (struct ast_json *)json_false();
}
struct ast_json *ast_json_boolean(int value)
{
return (struct ast_json *)json_boolean(value);
}
struct ast_json *ast_json_null(void)
{
return (struct ast_json *)json_null();
}
int ast_json_is_true(const struct ast_json *json)
{
return json_is_true((const json_t *)json);
}
int ast_json_is_false(const struct ast_json *json)
{
return json_is_false((const json_t *)json);
}
int ast_json_is_null(const struct ast_json *json)
{
return json_is_null((const json_t *)json);
}
struct ast_json *ast_json_string_create(const char *value)
{
return (struct ast_json *)json_string(value);
}
const char *ast_json_string_get(const struct ast_json *string)
{
return json_string_value((json_t *)string);
}
int ast_json_string_set(struct ast_json *string, const char *value)
{
return json_string_set((json_t *)string, value);
}
struct ast_json *ast_json_stringf(const char *format, ...)
{
struct ast_json *ret;
va_list args;
va_start(args, format);
ret = ast_json_vstringf(format, args);
va_end(args);
return ret;
}
struct ast_json *ast_json_vstringf(const char *format, va_list args)
{
json_t *ret = NULL;
if (format) {
/* json_pack was not introduced until jansson-2.0 so Asterisk could never
* be compiled against older versions. The version check can never match
* anything older than 2.12. */
#if defined(HAVE_JANSSON_BUNDLED) || JANSSON_MAJOR_VERSION > 2 || JANSSON_MINOR_VERSION > 11
ret = json_vsprintf(format, args);
#else
char *str = NULL;
int err = ast_vasprintf(&str, format, args);
if (err >= 0) {
ret = json_string(str);
ast_free(str);
}
#endif
}
return (struct ast_json *)ret;
}
struct ast_json *ast_json_integer_create(intmax_t value)
{
return (struct ast_json *)json_integer(value);
}
intmax_t ast_json_integer_get(const struct ast_json *integer)
{
return json_integer_value((json_t *)integer);
}
int ast_json_integer_set(struct ast_json *integer, intmax_t value)
{
return json_integer_set((json_t *)integer, value);
}
Refactor RTCP events over to Stasis; associate with channels This patch does the following: * It merges Jaco Kroon's patch from ASTERISK-20754, which provides channel information in the RTCP events. Because Stasis provides a cache, Jaco's patch was modified to pass the channel uniqueid to the RTP layer as opposed to a pointer to the channel. This has the following benefits: (1) It keeps the RTP engine 'clean' of references back to channels (2) It prevents circular dependencies and other potential ref counting issues * The RTP engine now allows any RTP implementation to raise RTCP messages. Potentially, other implementations (such as res_rtp_multicast) could also raise RTCP information. The engine provides structs to represent RTCP headers and RTCP SR/RR reports. * Some general refactoring in res_rtp_asterisk was done to try and tame the RTCP code. It isn't perfect - that's *way* beyond the scope of this work - but it does feel marginally better. * A few random bugs were fixed in the RTCP statistics. (Example: performing an assignment of a = a is probably not correct) * We now raise RTCP events for each SR/RR sent/received. Previously we wouldn't raise an event when we sent a RR report. Note that this work will be of use to others who want to monitor call quality or build modules that report call quality statistics. Since the events are now moving across the Stasis message bus, this is far easier to accomplish. It is also a first step (though by no means the last step) towards getting Olle's pinefrog work incorporated. Again: note that the patch by Jaco Kroon was modified slightly for this work; however, he did all of the hard work in finding the right places to set the channel in the RTP engine across the channel drivers. Much thanks goes to Jaco for his hard work here. Review: https://reviewboard.asterisk.org/r/2603/ (closes issue ASTERISK-20574) Reported by: Jaco Kroon patches: asterisk-rtcp-channel.patch uploaded by jkroon (License 5671) (closes issue ASTERISK-21471) Reported by: Matt Jordan git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-05 17:33:33 +00:00
struct ast_json *ast_json_real_create(double value)
{
return (struct ast_json *)json_real(value);
}
double ast_json_real_get(const struct ast_json *real)
{
return json_real_value((json_t *)real);
}
int ast_json_real_set(struct ast_json *real, double value)
{
return json_real_set((json_t *)real, value);
}
int ast_json_equal(const struct ast_json *lhs, const struct ast_json *rhs)
{
return json_equal((json_t *)lhs, (json_t *)rhs);
}
struct ast_json *ast_json_array_create(void)
{
return (struct ast_json *)json_array();
}
size_t ast_json_array_size(const struct ast_json *array)
{
return json_array_size((json_t *)array);
}
struct ast_json *ast_json_array_get(const struct ast_json *array, size_t index)
{
return (struct ast_json *)json_array_get((json_t *)array, index);
}
int ast_json_array_set(struct ast_json *array, size_t index, struct ast_json *value)
{
return json_array_set_new((json_t *)array, index, (json_t *)value);
}
int ast_json_array_append(struct ast_json *array, struct ast_json *value)
{
return json_array_append_new((json_t *)array, (json_t *)value);
}
int ast_json_array_insert(struct ast_json *array, size_t index, struct ast_json *value)
{
return json_array_insert_new((json_t *)array, index, (json_t *)value);
}
int ast_json_array_remove(struct ast_json *array, size_t index)
{
return json_array_remove((json_t *)array, index);
}
int ast_json_array_clear(struct ast_json *array)
{
return json_array_clear((json_t *)array);
}
int ast_json_array_extend(struct ast_json *array, struct ast_json *tail)
{
return json_array_extend((json_t *)array, (json_t *)tail);
}
struct ast_json *ast_json_object_create(void)
{
return (struct ast_json *)json_object();
}
size_t ast_json_object_size(struct ast_json *object)
{
return json_object_size((json_t *)object);
}
struct ast_json *ast_json_object_get(struct ast_json *object, const char *key)
{
if (!key) {
return NULL;
}
return (struct ast_json *)json_object_get((json_t *)object, key);
}
int ast_json_object_set(struct ast_json *object, const char *key, struct ast_json *value)
{
return json_object_set_new((json_t *)object, key, (json_t *)value);
}
int ast_json_object_del(struct ast_json *object, const char *key)
{
return json_object_del((json_t *)object, key);
}
int ast_json_object_clear(struct ast_json *object)
{
return json_object_clear((json_t *)object);
}
int ast_json_object_update(struct ast_json *object, struct ast_json *other)
{
return json_object_update((json_t *)object, (json_t *)other);
}
int ast_json_object_update_existing(struct ast_json *object, struct ast_json *other)
{
return json_object_update_existing((json_t *)object, (json_t *)other);
}
int ast_json_object_update_missing(struct ast_json *object, struct ast_json *other)
{
return json_object_update_missing((json_t *)object, (json_t *)other);
}
struct ast_json_iter *ast_json_object_iter(struct ast_json *object)
{
return json_object_iter((json_t *)object);
}
struct ast_json_iter *ast_json_object_iter_at(struct ast_json *object, const char *key)
{
return json_object_iter_at((json_t *)object, key);
}
struct ast_json_iter *ast_json_object_iter_next(struct ast_json *object, struct ast_json_iter *iter)
{
return json_object_iter_next((json_t *)object, iter);
}
const char *ast_json_object_iter_key(struct ast_json_iter *iter)
{
return json_object_iter_key(iter);
}
struct ast_json *ast_json_object_iter_value(struct ast_json_iter *iter)
{
return (struct ast_json *)json_object_iter_value(iter);
}
int ast_json_object_iter_set(struct ast_json *object, struct ast_json_iter *iter, struct ast_json *value)
{
return json_object_iter_set_new((json_t *)object, iter, (json_t *)value);
}
/*!
* \brief Default flags for JSON encoding.
*/
static size_t dump_flags(enum ast_json_encoding_format format)
{
return format == AST_JSON_PRETTY ?
JSON_INDENT(2) | JSON_PRESERVE_ORDER : JSON_COMPACT;
}
char *ast_json_dump_string_format(struct ast_json *root, enum ast_json_encoding_format format)
{
return json_dumps((json_t *)root, dump_flags(format));
}
static int write_to_ast_str(const char *buffer, size_t size, void *data)
{
struct ast_str **dst = data;
size_t str_size = ast_str_size(*dst);
size_t remaining = str_size - ast_str_strlen(*dst);
int ret;
/* While ast_str_append will grow the ast_str, it won't report
* allocation errors. Fortunately, it's not that hard.
*/
/* Remaining needs to be big enough for buffer, plus null char */
while (remaining < size + 1) {
/* doubling the size of the buffer gives us 'amortized
* constant' time.
* See http://stackoverflow.com/a/249695/115478 for info.
*/
str_size *= 2;
remaining = str_size - ast_str_strlen(*dst);
}
ret = ast_str_make_space(dst, str_size);
if (ret == -1) {
/* Could not alloc; fail */
return -1;
}
ast_str_append_substr(dst, -1, buffer, size);
return 0;
}
int ast_json_dump_str_format(struct ast_json *root, struct ast_str **dst, enum ast_json_encoding_format format)
{
return json_dump_callback((json_t *)root, write_to_ast_str, dst, dump_flags(format));
}
int ast_json_dump_file_format(struct ast_json *root, FILE *output, enum ast_json_encoding_format format)
{
if (!root || !output) {
return -1;
}
return json_dumpf((json_t *)root, output, dump_flags(format));
}
int ast_json_dump_new_file_format(struct ast_json *root, const char *path, enum ast_json_encoding_format format)
{
if (!root || !path) {
return -1;
}
return json_dump_file((json_t *)root, path, dump_flags(format));
}
/*!
* \brief Copy Jansson error struct to ours.
*/
static void copy_error(struct ast_json_error *error, const json_error_t *jansson_error)
{
if (error && jansson_error) {
error->line = jansson_error->line;
error->column = jansson_error->column;
error->position = jansson_error->position;
ast_copy_string(error->text, jansson_error->text, sizeof(error->text));
ast_copy_string(error->source, jansson_error->source, sizeof(error->source));
}
}
static void parse_error(struct ast_json_error *error, const char *text, const char *source)
{
if (error != NULL) {
error->line = 0;
error->column = 0;
error->position = 0;
strncpy(error->text, text, sizeof(error->text));
strncpy(error->source, source, sizeof(error->text));
}
}
struct ast_json *ast_json_load_string(const char *input, struct ast_json_error *error)
{
json_error_t jansson_error = {};
struct ast_json *r = NULL;
if (input != NULL) {
r = (struct ast_json *)json_loads(input, 0, &jansson_error);
copy_error(error, &jansson_error);
} else {
parse_error(error, "NULL input string", "<null>");
}
return r;
}
struct ast_json *ast_json_load_str(const struct ast_str *input, struct ast_json_error *error)
{
return ast_json_load_string(ast_str_buffer(input), error);
}
struct ast_json *ast_json_load_buf(const char *buffer, size_t buflen, struct ast_json_error *error)
{
json_error_t jansson_error = {};
struct ast_json *r = (struct ast_json *)json_loadb(buffer, buflen, 0, &jansson_error);
copy_error(error, &jansson_error);
return r;
}
struct ast_json *ast_json_load_file(FILE *input, struct ast_json_error *error)
{
json_error_t jansson_error = {};
struct ast_json *r = NULL;
if (input != NULL) {
r = (struct ast_json *)json_loadf(input, 0, &jansson_error);
copy_error(error, &jansson_error);
} else {
parse_error(error, "NULL input file", "<null>");
}
return r;
}
struct ast_json *ast_json_load_new_file(const char *path, struct ast_json_error *error)
{
json_error_t jansson_error = {};
struct ast_json *r = (struct ast_json *)json_load_file(path, 0, &jansson_error);
copy_error(error, &jansson_error);
return r;
}
struct ast_json *ast_json_pack(char const *format, ...)
{
struct ast_json *ret;
va_list args;
va_start(args, format);
ret = ast_json_vpack(format, args);
va_end(args);
return ret;
}
struct ast_json *ast_json_vpack(char const *format, va_list ap)
{
json_error_t error;
struct ast_json *r = NULL;
if (format) {
r = (struct ast_json *)json_vpack_ex(&error, 0, format, ap);
if (!r && !ast_strlen_zero(error.text)) {
ast_log(LOG_ERROR,
"Error building JSON from '%s': %s.\n",
format, error.text);
ast_log_backtrace();
}
}
return r;
}
struct ast_json *ast_json_copy(const struct ast_json *value)
{
return (struct ast_json *)json_copy((json_t *)value);
}
struct ast_json *ast_json_deep_copy(const struct ast_json *value)
{
return (struct ast_json *)json_deep_copy((json_t *)value);
}
struct ast_json *ast_json_name_number(const char *name, const char *number)
{
return ast_json_pack("{s: s, s: s}",
"name", AST_JSON_UTF8_VALIDATE(name),
"number", AST_JSON_UTF8_VALIDATE(number));
}
struct ast_json *ast_json_dialplan_cep(const char *context, const char *exten, int priority)
{
return ast_json_pack("{s: o, s: o, s: o}",
"context", context ? ast_json_string_create(context) : ast_json_null(),
"exten", exten ? ast_json_string_create(exten) : ast_json_null(),
"priority", priority != -1 ? ast_json_integer_create(priority) : ast_json_null());
}
struct ast_json *ast_json_timeval(const struct timeval tv, const char *zone)
{
char buf[AST_ISO8601_LEN];
struct ast_tm tm = {};
ast_localtime(&tv, &tm, zone);
ast_strftime(buf, sizeof(buf),AST_ISO8601_FORMAT, &tm);
return ast_json_string_create(buf);
}
struct ast_json *ast_json_ipaddr(const struct ast_sockaddr *addr, enum ast_transport transport_type)
{
struct ast_str *string = ast_str_alloca(64);
if (!string) {
return NULL;
}
ast_str_set(&string, 0, (ast_sockaddr_is_ipv4(addr) ||
ast_sockaddr_is_ipv4_mapped(addr)) ? "IPV4/" : "IPV6/");
if (transport_type) {
char *transport_string = NULL;
/* NOTE: None will be applied if multiple transport types are specified in transport_type */
switch(transport_type) {
case AST_TRANSPORT_UDP:
transport_string = "UDP";
break;
case AST_TRANSPORT_TCP:
transport_string = "TCP";
break;
case AST_TRANSPORT_TLS:
transport_string = "TLS";
break;
case AST_TRANSPORT_WS:
transport_string = "WS";
break;
case AST_TRANSPORT_WSS:
transport_string = "WSS";
break;
}
if (transport_string) {
ast_str_append(&string, 0, "%s/", transport_string);
}
}
ast_str_append(&string, 0, "%s", ast_sockaddr_stringify_addr(addr));
ast_str_append(&string, 0, "/%s", ast_sockaddr_stringify_port(addr));
return ast_json_string_create(ast_str_buffer(string));
}
void ast_json_init(void)
{
/* Setup to use Asterisk custom allocators */
ast_json_reset_alloc_funcs();
}
static void json_payload_destructor(void *obj)
{
struct ast_json_payload *payload = obj;
ast_json_unref(payload->json);
}
struct ast_json_payload *ast_json_payload_create(struct ast_json *json)
{
struct ast_json_payload *payload;
if (!(payload = ao2_alloc(sizeof(*payload), json_payload_destructor))) {
return NULL;
}
ast_json_ref(json);
payload->json = json;
return payload;
}
static struct ast_json *json_party_number(struct ast_party_number *number)
{
if (!number->valid) {
return NULL;
}
return ast_json_pack("{s: s, s: i, s: i, s: s}",
"number", AST_JSON_UTF8_VALIDATE(number->str),
"plan", number->plan,
"presentation", number->presentation,
"presentation_txt", ast_describe_caller_presentation(number->presentation));
}
static struct ast_json *json_party_name(struct ast_party_name *name)
{
if (!name->valid) {
return NULL;
}
return ast_json_pack("{s: s, s: s, s: i, s: s}",
"name", AST_JSON_UTF8_VALIDATE(name->str),
"character_set", ast_party_name_charset_describe(name->char_set),
"presentation", name->presentation,
"presentation_txt", ast_describe_caller_presentation(name->presentation));
}
static struct ast_json *json_party_subaddress(struct ast_party_subaddress *subaddress)
{
if (!subaddress->valid) {
return NULL;
}
return ast_json_pack("{s: s, s: i, s: b}",
"subaddress", AST_JSON_UTF8_VALIDATE(subaddress->str),
"type", subaddress->type,
"odd", subaddress->odd_even_indicator);
}
struct ast_json *ast_json_party_id(struct ast_party_id *party)
{
int pres = ast_party_id_presentation(party);
/* Combined party presentation */
return ast_json_pack("{s: i, s: s, s: o*, s: o*, s: o*}",
"presentation", pres,
"presentation_txt", ast_describe_caller_presentation(pres),
"number", json_party_number(&party->number),
"name", json_party_name(&party->name),
"subaddress", json_party_subaddress(&party->subaddress));
}
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
enum ast_json_to_ast_vars_code ast_json_to_ast_variables(struct ast_json *json_variables, struct ast_variable **variables)
Multiple revisions 420089-420090,420097 ........ r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines ARI: Add channel technology agnostic out of call text messaging This patch adds the ability to send and receive text messages from various technology stacks in Asterisk through ARI. This includes chan_sip (sip), res_pjsip_messaging (pjsip), and res_xmpp (xmpp). Messages are sent using the endpoints resource, and can be sent directly through that resource, or to a particular endpoint. For example, the following would send the message "Hello there" to PJSIP endpoint alice with a display URI of sip:asterisk@mycooldomain.org: ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There This is equivalent to the following as well: ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@mycooldomain.org&body=Hello+There Both forms are available for message technologies that allow for arbitrary destinations, such as chan_sip. Inbound messages can now be received over ARI as well. An ARI application that subscribes to endpoints will receive messages from those endpoints: { "type": "TextMessageReceived", "timestamp": "2014-07-12T22:53:13.494-0500", "endpoint": { "technology": "PJSIP", "resource": "alice", "state": "online", "channel_ids": [] }, "message": { "from": "\"alice\" <sip:alice@127.0.0.1>", "to": "pjsip:asterisk@127.0.0.1", "body": "Watson, come here.", "variables": [] }, "application": "testsuite" } The above was made possible due to some rather major changes in the message core. This includes (but is not limited to): - Users of the message API can now register message handlers. A handler has two callbacks: one to determine if the handler has a destination for the message, and another to handle it. - All dialplan functionality of handling a message was moved into a message handler provided by the message API. - Messages can now have the technology/endpoint associated with them. Various other properties are also now more easily accessible. - A number of ao2 containers that weren't really needed were replaced with vectors. Iteration over ao2_containers is expensive and pointless when the lifetime of things is well defined and the number of things is very small. res_stasis now has a new file that makes up its structure, messaging. The messaging functionality implements a message handler, and passes received messages that match an interested endpoint over to the app for processing. Note that inadvertently while testing this, I reproduced ASTERISK-23969. res_pjsip_messaging was incorrectly parsing out the 'to' field, such that arbitrary SIP URIs mangled the endpoint lookup. This patch includes the fix for that as well. Review: https://reviewboard.asterisk.org/r/3726 ASTERISK-23692 #close Reported by: Matt Jordan ASTERISK-23969 #close Reported by: Andrew Nagy ........ r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines Remove automerge properties :-( ........ r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines test_message: Fix strict-aliasing compilation issue ........ Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-05 21:44:09 +00:00
{
struct ast_json_iter *it_json_var;
struct ast_variable *tail = 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
*variables = NULL;
for (it_json_var = ast_json_object_iter(json_variables); it_json_var;
it_json_var = ast_json_object_iter_next(json_variables, it_json_var)) {
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
struct ast_variable *new_var;
const char *key = ast_json_object_iter_key(it_json_var);
const char *value;
struct ast_json *json_value;
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_strlen_zero(key)) {
continue;
}
json_value = ast_json_object_iter_value(it_json_var);
if (ast_json_typeof(json_value) != AST_JSON_STRING) {
/* Error: Only strings allowed */
ast_variables_destroy(*variables);
*variables = NULL;
return AST_JSON_TO_AST_VARS_CODE_INVALID_TYPE;
}
value = ast_json_string_get(json_value);
/* Should never be NULL. Otherwise, how could it be a string type? */
ast_assert(value != NULL);
if (!value) {
/* To be safe. */
continue;
}
new_var = ast_variable_new(key, value, "");
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 (!new_var) {
/* Error: OOM */
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_variables_destroy(*variables);
*variables = NULL;
return AST_JSON_TO_AST_VARS_CODE_OOM;
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
}
tail = ast_variable_list_append_hint(variables, tail, new_var);
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 AST_JSON_TO_AST_VARS_CODE_SUCCESS;
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
}
struct ast_json *ast_json_channel_vars(struct varshead *channelvars)
{
struct ast_json *ret;
struct ast_var_t *var;
ret = ast_json_object_create();
AST_LIST_TRAVERSE(channelvars, var, entries) {
ast_json_object_set(ret, var->name, ast_json_string_create(var->value));
}
return ret;
}