sysmocom
/
asterisk
11
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
asterisk/tests/test_stasis_channels.c

415 lines
13 KiB
C
Raw Permalink Normal View History

Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
/*
* Asterisk -- An open source telephony toolkit.
*
* Copyright (C) 2013, Digium, Inc.
*
* Matt Jordan <mjordan@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.
*/
/*!
doxygen: Fix doxygen errors This patch fixes a number of errors and warning messages in the doxygen log. Specifically, it addresses: * A number of files incorrectly places a '\brief' tag immediately after a '\file' tag. Doing so emits a warning, as '\file' takes an optional argument specifying which file the doxygen comment is for. As '\brief' is not a file, doxygen was unamused. * A grouping of Stasis Topics and Messages in rtp_engine.h was incorrectly terminated. We now correctly terminate the grouping, which prevents members of rtp_engine.h from showing up in the wrong group. * Group indicators which are not part of the Stasis Topics and Messages group were removed. Group indicators without an \addtogroup or \ingroup have no meaning. Change-Id: Ia1415ffec6767e27233ae1cae5ed5970de5656d4
2015-05-17 12:15:15 +00:00
* \file
* \brief Test Stasis Channel messages and objects
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
*
* \author\verbatim Matt Jordan <mjordan@digium.com> \endverbatim
*
* \ingroup tests
*/
/*** MODULEINFO
<depend>TEST_FRAMEWORK</depend>
<support_level>core</support_level>
***/
#include "asterisk.h"
#include "asterisk/astobj2.h"
#include "asterisk/module.h"
#include "asterisk/stasis.h"
#include "asterisk/stasis_message_router.h"
#include "asterisk/test.h"
#include "asterisk/stasis_channels.h"
#include "asterisk/channel.h"
static const char *test_category = "/stasis/channels/";
static void safe_channel_release(struct ast_channel *chan)
{
if (!chan) {
return;
}
ast_channel_release(chan);
}
AST_TEST_DEFINE(channel_blob_create)
{
struct ast_channel_blob *blob;
Remove required type field from channel blobs When we first introduced the channel blob types, the JSON blobs were self identifying by a required "type" field in the JSON object itself. This, as it turns out, was a bad idea. When we introduced the message router, it was useless for routing based on the JSON type. And messages had two type fields to check: the stasis_message_type() of the message itself, plus the type field in the JSON blob (but only if it was a blob message). This patch corrects that mistake by removing the required type field from JSON blobs, and introducing first class stasis_message_type objects for the actual message type. Since we now will have a proliferation of message types, I introduced a few macros to help reduce the amount of boilerplate necessary to set them up. Review: https://reviewboard.asterisk.org/r/2509 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 18:34:50 +00:00
RAII_VAR(struct stasis_message_type *, type, NULL, ao2_cleanup);
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
RAII_VAR(struct stasis_message *, msg, NULL, ao2_cleanup);
RAII_VAR(struct ast_channel *, chan, NULL, safe_channel_release);
RAII_VAR(struct ast_json *, json, NULL, ast_json_unref);
RAII_VAR(struct ast_json *, bad_json, NULL, ast_json_unref);
switch (cmd) {
case TEST_INIT:
info->name = __func__;
info->category = test_category;
info->summary = "Test creation of ast_channel_blob objects";
info->description = "Test creation of ast_channel_blob objects";
return AST_TEST_NOT_RUN;
case TEST_EXECUTE:
break;
}
Stasis: Allow message types to be blocked This introduces stasis.conf and a mechanism to prevent certain message types from being published. Internally, this works by preventing the chosen message types from being created which ensures that those message types can never be published. This patch also adjusts message publishers such that message payloads are not created if the related message type is not available. ASTERISK-23943 #close Review: https://reviewboard.asterisk.org/r/3823/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-06 12:55:28 +00:00
ast_test_validate(test, stasis_message_type_create("test-type", NULL, &type) == STASIS_MESSAGE_TYPE_SUCCESS);
uniqueid: channel linkedid, ami, ari object creation with id's Much needed was a way to assign id to objects on creation, and much change was necessary to accomplish it. Channel uniqueids and linkedids are split into separate string and creation time components without breaking linkedid propgation. This allowed the uniqueid to be specified by the user interface - and those values are now carried through to channel creation, adding the assignedids value to every function in the chain including the channel drivers. For local channels, the second channel can be specified or left to default to a ;2 suffix of first. In ARI, bridge, playback, and snoop objects can also be created with a specified uniqueid. Along the way, the args order to allocating channels was fixed in chan_mgcp and chan_gtalk, and linkedid is no longer lost as masquerade occurs. (closes issue ASTERISK-23120) Review: https://reviewboard.asterisk.org/r/3191/ ........ Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
chan = ast_channel_alloc(0, AST_STATE_DOWN, "100", "Alice", "100", "100", "default", NULL, NULL, 0, "TEST/Alice");
channels: Return allocated channels locked. This change makes ast_channel_alloc return allocated channels locked. By doing so no other thread can acquire, lock, and manipulate the channel before it is completely set up. (closes issue AST-1256) Review: https://reviewboard.asterisk.org/r/3067/ ........ Merged revisions 404204 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404210 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 19:28:05 +00:00
ast_channel_unlock(chan);
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
json = ast_json_pack("{s: s}",
Remove required type field from channel blobs When we first introduced the channel blob types, the JSON blobs were self identifying by a required "type" field in the JSON object itself. This, as it turns out, was a bad idea. When we introduced the message router, it was useless for routing based on the JSON type. And messages had two type fields to check: the stasis_message_type() of the message itself, plus the type field in the JSON blob (but only if it was a blob message). This patch corrects that mistake by removing the required type field from JSON blobs, and introducing first class stasis_message_type objects for the actual message type. Since we now will have a proliferation of message types, I introduced a few macros to help reduce the amount of boilerplate necessary to set them up. Review: https://reviewboard.asterisk.org/r/2509 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 18:34:50 +00:00
"foo", "bar");
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
/* Off nominal creation */
channel locking: Add locking for channel snapshot creation Original commit message by mmichelson (asterisk 12 r403311): "This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such." The above was initially committed and then reverted at r403398. The problem was found to be in core_local.c in the publish_local_bridge_message function. The ast_unreal_lock_all function locks and adds a reference to the returned channels and while they were being unlocked they were not being unreffed when no longer needed. Fixed by unreffing the channels. Also in bridge.c a lock was obtained on "other->chan", but then an attempt was made to unlock "other" and not the previously locked channel. Fixed by unlocking "other->chan" (closes issue ASTERISK-22709) Reported by: John Bigelow ........ Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 20:33:37 +00:00
ast_channel_lock(chan);
Remove required type field from channel blobs When we first introduced the channel blob types, the JSON blobs were self identifying by a required "type" field in the JSON object itself. This, as it turns out, was a bad idea. When we introduced the message router, it was useless for routing based on the JSON type. And messages had two type fields to check: the stasis_message_type() of the message itself, plus the type field in the JSON blob (but only if it was a blob message). This patch corrects that mistake by removing the required type field from JSON blobs, and introducing first class stasis_message_type objects for the actual message type. Since we now will have a proliferation of message types, I introduced a few macros to help reduce the amount of boilerplate necessary to set them up. Review: https://reviewboard.asterisk.org/r/2509 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 18:34:50 +00:00
ast_test_validate(test, NULL == ast_channel_blob_create(chan, NULL, json));
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
/* Test for single channel */
Remove required type field from channel blobs When we first introduced the channel blob types, the JSON blobs were self identifying by a required "type" field in the JSON object itself. This, as it turns out, was a bad idea. When we introduced the message router, it was useless for routing based on the JSON type. And messages had two type fields to check: the stasis_message_type() of the message itself, plus the type field in the JSON blob (but only if it was a blob message). This patch corrects that mistake by removing the required type field from JSON blobs, and introducing first class stasis_message_type objects for the actual message type. Since we now will have a proliferation of message types, I introduced a few macros to help reduce the amount of boilerplate necessary to set them up. Review: https://reviewboard.asterisk.org/r/2509 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 18:34:50 +00:00
msg = ast_channel_blob_create(chan, type, json);
channel locking: Add locking for channel snapshot creation Original commit message by mmichelson (asterisk 12 r403311): "This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such." The above was initially committed and then reverted at r403398. The problem was found to be in core_local.c in the publish_local_bridge_message function. The ast_unreal_lock_all function locks and adds a reference to the returned channels and while they were being unlocked they were not being unreffed when no longer needed. Fixed by unreffing the channels. Also in bridge.c a lock was obtained on "other->chan", but then an attempt was made to unlock "other" and not the previously locked channel. Fixed by unlocking "other->chan" (closes issue ASTERISK-22709) Reported by: John Bigelow ........ Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 20:33:37 +00:00
ast_channel_unlock(chan);
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
ast_test_validate(test, NULL != msg);
blob = stasis_message_data(msg);
ast_test_validate(test, NULL != blob);
ast_test_validate(test, NULL != blob->snapshot);
ast_test_validate(test, NULL != blob->blob);
Remove required type field from channel blobs When we first introduced the channel blob types, the JSON blobs were self identifying by a required "type" field in the JSON object itself. This, as it turns out, was a bad idea. When we introduced the message router, it was useless for routing based on the JSON type. And messages had two type fields to check: the stasis_message_type() of the message itself, plus the type field in the JSON blob (but only if it was a blob message). This patch corrects that mistake by removing the required type field from JSON blobs, and introducing first class stasis_message_type objects for the actual message type. Since we now will have a proliferation of message types, I introduced a few macros to help reduce the amount of boilerplate necessary to set them up. Review: https://reviewboard.asterisk.org/r/2509 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 18:34:50 +00:00
ast_test_validate(test, type == stasis_message_type(msg));
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
ast_test_validate(test, 1 == ao2_ref(msg, 0));
ao2_cleanup(msg);
/* Test for global channels */
Remove required type field from channel blobs When we first introduced the channel blob types, the JSON blobs were self identifying by a required "type" field in the JSON object itself. This, as it turns out, was a bad idea. When we introduced the message router, it was useless for routing based on the JSON type. And messages had two type fields to check: the stasis_message_type() of the message itself, plus the type field in the JSON blob (but only if it was a blob message). This patch corrects that mistake by removing the required type field from JSON blobs, and introducing first class stasis_message_type objects for the actual message type. Since we now will have a proliferation of message types, I introduced a few macros to help reduce the amount of boilerplate necessary to set them up. Review: https://reviewboard.asterisk.org/r/2509 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 18:34:50 +00:00
msg = ast_channel_blob_create(NULL, type, json);
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
ast_test_validate(test, NULL != msg);
blob = stasis_message_data(msg);
ast_test_validate(test, NULL != blob);
ast_test_validate(test, NULL == blob->snapshot);
ast_test_validate(test, NULL != blob->blob);
Remove required type field from channel blobs When we first introduced the channel blob types, the JSON blobs were self identifying by a required "type" field in the JSON object itself. This, as it turns out, was a bad idea. When we introduced the message router, it was useless for routing based on the JSON type. And messages had two type fields to check: the stasis_message_type() of the message itself, plus the type field in the JSON blob (but only if it was a blob message). This patch corrects that mistake by removing the required type field from JSON blobs, and introducing first class stasis_message_type objects for the actual message type. Since we now will have a proliferation of message types, I introduced a few macros to help reduce the amount of boilerplate necessary to set them up. Review: https://reviewboard.asterisk.org/r/2509 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 18:34:50 +00:00
ast_test_validate(test, type == stasis_message_type(msg));
return AST_TEST_PASS;
}
AST_TEST_DEFINE(null_blob)
{
struct ast_channel_blob *blob;
RAII_VAR(struct stasis_message_type *, type, NULL, ao2_cleanup);
RAII_VAR(struct stasis_message *, msg, NULL, ao2_cleanup);
RAII_VAR(struct ast_channel *, chan, NULL, safe_channel_release);
RAII_VAR(struct ast_json *, json, NULL, ast_json_unref);
RAII_VAR(struct ast_json *, bad_json, NULL, ast_json_unref);
switch (cmd) {
case TEST_INIT:
info->name = __func__;
info->category = test_category;
info->summary = "Test creation of ast_channel_blob objects";
info->description = "Test creation of ast_channel_blob objects";
return AST_TEST_NOT_RUN;
case TEST_EXECUTE:
break;
}
Stasis: Allow message types to be blocked This introduces stasis.conf and a mechanism to prevent certain message types from being published. Internally, this works by preventing the chosen message types from being created which ensures that those message types can never be published. This patch also adjusts message publishers such that message payloads are not created if the related message type is not available. ASTERISK-23943 #close Review: https://reviewboard.asterisk.org/r/3823/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-06 12:55:28 +00:00
ast_test_validate(test, stasis_message_type_create("test-type", NULL, &type) == STASIS_MESSAGE_TYPE_SUCCESS);
uniqueid: channel linkedid, ami, ari object creation with id's Much needed was a way to assign id to objects on creation, and much change was necessary to accomplish it. Channel uniqueids and linkedids are split into separate string and creation time components without breaking linkedid propgation. This allowed the uniqueid to be specified by the user interface - and those values are now carried through to channel creation, adding the assignedids value to every function in the chain including the channel drivers. For local channels, the second channel can be specified or left to default to a ;2 suffix of first. In ARI, bridge, playback, and snoop objects can also be created with a specified uniqueid. Along the way, the args order to allocating channels was fixed in chan_mgcp and chan_gtalk, and linkedid is no longer lost as masquerade occurs. (closes issue ASTERISK-23120) Review: https://reviewboard.asterisk.org/r/3191/ ........ Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
chan = ast_channel_alloc(0, AST_STATE_DOWN, "100", "Alice", "100", "100", "default", NULL, NULL, 0, "TEST/Alice");
channels: Return allocated channels locked. This change makes ast_channel_alloc return allocated channels locked. By doing so no other thread can acquire, lock, and manipulate the channel before it is completely set up. (closes issue AST-1256) Review: https://reviewboard.asterisk.org/r/3067/ ........ Merged revisions 404204 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404210 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 19:28:05 +00:00
ast_channel_unlock(chan);
Remove required type field from channel blobs When we first introduced the channel blob types, the JSON blobs were self identifying by a required "type" field in the JSON object itself. This, as it turns out, was a bad idea. When we introduced the message router, it was useless for routing based on the JSON type. And messages had two type fields to check: the stasis_message_type() of the message itself, plus the type field in the JSON blob (but only if it was a blob message). This patch corrects that mistake by removing the required type field from JSON blobs, and introducing first class stasis_message_type objects for the actual message type. Since we now will have a proliferation of message types, I introduced a few macros to help reduce the amount of boilerplate necessary to set them up. Review: https://reviewboard.asterisk.org/r/2509 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 18:34:50 +00:00
json = ast_json_pack("{s: s}",
"foo", "bar");
/* Test for single channel */
channel locking: Add locking for channel snapshot creation Original commit message by mmichelson (asterisk 12 r403311): "This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such." The above was initially committed and then reverted at r403398. The problem was found to be in core_local.c in the publish_local_bridge_message function. The ast_unreal_lock_all function locks and adds a reference to the returned channels and while they were being unlocked they were not being unreffed when no longer needed. Fixed by unreffing the channels. Also in bridge.c a lock was obtained on "other->chan", but then an attempt was made to unlock "other" and not the previously locked channel. Fixed by unlocking "other->chan" (closes issue ASTERISK-22709) Reported by: John Bigelow ........ Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 20:33:37 +00:00
ast_channel_lock(chan);
Remove required type field from channel blobs When we first introduced the channel blob types, the JSON blobs were self identifying by a required "type" field in the JSON object itself. This, as it turns out, was a bad idea. When we introduced the message router, it was useless for routing based on the JSON type. And messages had two type fields to check: the stasis_message_type() of the message itself, plus the type field in the JSON blob (but only if it was a blob message). This patch corrects that mistake by removing the required type field from JSON blobs, and introducing first class stasis_message_type objects for the actual message type. Since we now will have a proliferation of message types, I introduced a few macros to help reduce the amount of boilerplate necessary to set them up. Review: https://reviewboard.asterisk.org/r/2509 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 18:34:50 +00:00
msg = ast_channel_blob_create(chan, type, NULL);
channel locking: Add locking for channel snapshot creation Original commit message by mmichelson (asterisk 12 r403311): "This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such." The above was initially committed and then reverted at r403398. The problem was found to be in core_local.c in the publish_local_bridge_message function. The ast_unreal_lock_all function locks and adds a reference to the returned channels and while they were being unlocked they were not being unreffed when no longer needed. Fixed by unreffing the channels. Also in bridge.c a lock was obtained on "other->chan", but then an attempt was made to unlock "other" and not the previously locked channel. Fixed by unlocking "other->chan" (closes issue ASTERISK-22709) Reported by: John Bigelow ........ Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 20:33:37 +00:00
ast_channel_unlock(chan);
Remove required type field from channel blobs When we first introduced the channel blob types, the JSON blobs were self identifying by a required "type" field in the JSON object itself. This, as it turns out, was a bad idea. When we introduced the message router, it was useless for routing based on the JSON type. And messages had two type fields to check: the stasis_message_type() of the message itself, plus the type field in the JSON blob (but only if it was a blob message). This patch corrects that mistake by removing the required type field from JSON blobs, and introducing first class stasis_message_type objects for the actual message type. Since we now will have a proliferation of message types, I introduced a few macros to help reduce the amount of boilerplate necessary to set them up. Review: https://reviewboard.asterisk.org/r/2509 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 18:34:50 +00:00
ast_test_validate(test, NULL != msg);
blob = stasis_message_data(msg);
ast_test_validate(test, NULL != blob);
ast_test_validate(test, NULL != blob->snapshot);
ast_test_validate(test, ast_json_null() == blob->blob);
ast_test_validate(test, type == stasis_message_type(msg));
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
return AST_TEST_PASS;
}
AST_TEST_DEFINE(multi_channel_blob_create)
{
RAII_VAR(struct ast_multi_channel_blob *, blob, NULL, ao2_cleanup);
RAII_VAR(struct ast_json *, json, NULL, ast_json_unref);
RAII_VAR(struct ast_json *, bad_json, NULL, ast_json_unref);
switch (cmd) {
case TEST_INIT:
info->name = __func__;
info->category = test_category;
info->summary = "Test creation of ast_multi_channel_blob objects";
info->description = "Test creation of ast_multi_channel_blob objects";
return AST_TEST_NOT_RUN;
case TEST_EXECUTE:
break;
}
json = ast_json_pack("{s: s}",
Remove required type field from channel blobs When we first introduced the channel blob types, the JSON blobs were self identifying by a required "type" field in the JSON object itself. This, as it turns out, was a bad idea. When we introduced the message router, it was useless for routing based on the JSON type. And messages had two type fields to check: the stasis_message_type() of the message itself, plus the type field in the JSON blob (but only if it was a blob message). This patch corrects that mistake by removing the required type field from JSON blobs, and introducing first class stasis_message_type objects for the actual message type. Since we now will have a proliferation of message types, I introduced a few macros to help reduce the amount of boilerplate necessary to set them up. Review: https://reviewboard.asterisk.org/r/2509 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 18:34:50 +00:00
"foo", "bar");
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
/* Test for single channel */
blob = ast_multi_channel_blob_create(json);
ast_test_validate(test, NULL != blob);
ast_test_validate(test, NULL != ast_multi_channel_blob_get_json(blob));
return AST_TEST_PASS;
}
AST_TEST_DEFINE(multi_channel_blob_snapshots)
{
RAII_VAR(struct ast_multi_channel_blob *, blob, NULL, ao2_cleanup);
RAII_VAR(struct ast_json *, json, NULL, ast_json_unref);
RAII_VAR(struct ast_channel *, chan_alice, NULL, safe_channel_release);
RAII_VAR(struct ast_channel *, chan_bob, NULL, safe_channel_release);
RAII_VAR(struct ast_channel *, chan_charlie, NULL, safe_channel_release);
struct ast_channel_snapshot *snapshot;
struct ao2_container *matches;
switch (cmd) {
case TEST_INIT:
info->name = __func__;
info->category = test_category;
info->summary = "Test creation of ast_multi_channel_blob objects";
info->description = "Test creation of ast_multi_channel_blob objects";
return AST_TEST_NOT_RUN;
case TEST_EXECUTE:
break;
}
json = ast_json_pack("{s: s}",
"type", "test");
uniqueid: channel linkedid, ami, ari object creation with id's Much needed was a way to assign id to objects on creation, and much change was necessary to accomplish it. Channel uniqueids and linkedids are split into separate string and creation time components without breaking linkedid propgation. This allowed the uniqueid to be specified by the user interface - and those values are now carried through to channel creation, adding the assignedids value to every function in the chain including the channel drivers. For local channels, the second channel can be specified or left to default to a ;2 suffix of first. In ARI, bridge, playback, and snoop objects can also be created with a specified uniqueid. Along the way, the args order to allocating channels was fixed in chan_mgcp and chan_gtalk, and linkedid is no longer lost as masquerade occurs. (closes issue ASTERISK-23120) Review: https://reviewboard.asterisk.org/r/3191/ ........ Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
chan_alice = ast_channel_alloc(0, AST_STATE_DOWN, "100", "Alice", "100", "100", "default", NULL, NULL, 0, "TEST/Alice");
channels: Return allocated channels locked. This change makes ast_channel_alloc return allocated channels locked. By doing so no other thread can acquire, lock, and manipulate the channel before it is completely set up. (closes issue AST-1256) Review: https://reviewboard.asterisk.org/r/3067/ ........ Merged revisions 404204 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404210 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 19:28:05 +00:00
ast_channel_unlock(chan_alice);
uniqueid: channel linkedid, ami, ari object creation with id's Much needed was a way to assign id to objects on creation, and much change was necessary to accomplish it. Channel uniqueids and linkedids are split into separate string and creation time components without breaking linkedid propgation. This allowed the uniqueid to be specified by the user interface - and those values are now carried through to channel creation, adding the assignedids value to every function in the chain including the channel drivers. For local channels, the second channel can be specified or left to default to a ;2 suffix of first. In ARI, bridge, playback, and snoop objects can also be created with a specified uniqueid. Along the way, the args order to allocating channels was fixed in chan_mgcp and chan_gtalk, and linkedid is no longer lost as masquerade occurs. (closes issue ASTERISK-23120) Review: https://reviewboard.asterisk.org/r/3191/ ........ Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
chan_bob = ast_channel_alloc(0, AST_STATE_DOWN, "200", "Bob", "200", "200", "default", NULL, NULL, 0, "TEST/Bob");
channels: Return allocated channels locked. This change makes ast_channel_alloc return allocated channels locked. By doing so no other thread can acquire, lock, and manipulate the channel before it is completely set up. (closes issue AST-1256) Review: https://reviewboard.asterisk.org/r/3067/ ........ Merged revisions 404204 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404210 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 19:28:05 +00:00
ast_channel_unlock(chan_bob);
uniqueid: channel linkedid, ami, ari object creation with id's Much needed was a way to assign id to objects on creation, and much change was necessary to accomplish it. Channel uniqueids and linkedids are split into separate string and creation time components without breaking linkedid propgation. This allowed the uniqueid to be specified by the user interface - and those values are now carried through to channel creation, adding the assignedids value to every function in the chain including the channel drivers. For local channels, the second channel can be specified or left to default to a ;2 suffix of first. In ARI, bridge, playback, and snoop objects can also be created with a specified uniqueid. Along the way, the args order to allocating channels was fixed in chan_mgcp and chan_gtalk, and linkedid is no longer lost as masquerade occurs. (closes issue ASTERISK-23120) Review: https://reviewboard.asterisk.org/r/3191/ ........ Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
chan_charlie = ast_channel_alloc(0, AST_STATE_DOWN, "300", "Bob", "300", "300", "default", NULL, NULL, 0, "TEST/Charlie");
channels: Return allocated channels locked. This change makes ast_channel_alloc return allocated channels locked. By doing so no other thread can acquire, lock, and manipulate the channel before it is completely set up. (closes issue AST-1256) Review: https://reviewboard.asterisk.org/r/3067/ ........ Merged revisions 404204 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404210 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 19:28:05 +00:00
ast_channel_unlock(chan_charlie);
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
blob = ast_multi_channel_blob_create(json);
channel locking: Add locking for channel snapshot creation Original commit message by mmichelson (asterisk 12 r403311): "This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such." The above was initially committed and then reverted at r403398. The problem was found to be in core_local.c in the publish_local_bridge_message function. The ast_unreal_lock_all function locks and adds a reference to the returned channels and while they were being unlocked they were not being unreffed when no longer needed. Fixed by unreffing the channels. Also in bridge.c a lock was obtained on "other->chan", but then an attempt was made to unlock "other" and not the previously locked channel. Fixed by unlocking "other->chan" (closes issue ASTERISK-22709) Reported by: John Bigelow ........ Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 20:33:37 +00:00
ast_channel_lock(chan_alice);
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
ast_multi_channel_blob_add_channel(blob, "Caller", ast_channel_snapshot_create(chan_alice));
channel locking: Add locking for channel snapshot creation Original commit message by mmichelson (asterisk 12 r403311): "This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such." The above was initially committed and then reverted at r403398. The problem was found to be in core_local.c in the publish_local_bridge_message function. The ast_unreal_lock_all function locks and adds a reference to the returned channels and while they were being unlocked they were not being unreffed when no longer needed. Fixed by unreffing the channels. Also in bridge.c a lock was obtained on "other->chan", but then an attempt was made to unlock "other" and not the previously locked channel. Fixed by unlocking "other->chan" (closes issue ASTERISK-22709) Reported by: John Bigelow ........ Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 20:33:37 +00:00
ast_channel_unlock(chan_alice);
ast_channel_lock(chan_bob);
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
ast_multi_channel_blob_add_channel(blob, "Peer", ast_channel_snapshot_create(chan_bob));
channel locking: Add locking for channel snapshot creation Original commit message by mmichelson (asterisk 12 r403311): "This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such." The above was initially committed and then reverted at r403398. The problem was found to be in core_local.c in the publish_local_bridge_message function. The ast_unreal_lock_all function locks and adds a reference to the returned channels and while they were being unlocked they were not being unreffed when no longer needed. Fixed by unreffing the channels. Also in bridge.c a lock was obtained on "other->chan", but then an attempt was made to unlock "other" and not the previously locked channel. Fixed by unlocking "other->chan" (closes issue ASTERISK-22709) Reported by: John Bigelow ........ Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 20:33:37 +00:00
ast_channel_unlock(chan_bob);
ast_channel_lock(chan_charlie);
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
ast_multi_channel_blob_add_channel(blob, "Peer", ast_channel_snapshot_create(chan_charlie));
channel locking: Add locking for channel snapshot creation Original commit message by mmichelson (asterisk 12 r403311): "This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such." The above was initially committed and then reverted at r403398. The problem was found to be in core_local.c in the publish_local_bridge_message function. The ast_unreal_lock_all function locks and adds a reference to the returned channels and while they were being unlocked they were not being unreffed when no longer needed. Fixed by unreffing the channels. Also in bridge.c a lock was obtained on "other->chan", but then an attempt was made to unlock "other" and not the previously locked channel. Fixed by unlocking "other->chan" (closes issue ASTERISK-22709) Reported by: John Bigelow ........ Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 20:33:37 +00:00
ast_channel_unlock(chan_charlie);
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
/* Test for unknown role */
ast_test_validate(test, NULL == ast_multi_channel_blob_get_channel(blob, "Foobar"));
/* Test for single match */
snapshot = ast_multi_channel_blob_get_channel(blob, "Caller");
ast_test_validate(test, NULL != snapshot);
stasis: Segment channel snapshot to reduce creation cost. When a channel snapshot was created it used to be done from scratch, copying all data (many strings). This incurs a cost when doing so. This change segments the channel snapshot into different components which can be reused if unchanged from the previous snapshot creation, reducing the cost. In normal cases this results in some pointers being copied with reference count being bumped, some integers being set, and a string or two copied. The other benefit is that it is now possible to determine if a channel snapshot update is redundant and thus stop it before a message is published to stasis. The specific segments in the channel snapshot were split up based on whether they are changed together, how often they are changed, and their general grouping. In practice only 1 (or 0) of the segments actually get changed in normal operation. Invalidation is done by setting a flag on the channel when the segment source is changed, forcing creation of a new segment when the channel snapshot is created. ASTERISK-28119 Change-Id: I5d7ef3df963a88ac47bc187d73c5225c315f8423
2018-11-07 17:18:34 +00:00
ast_test_validate(test, 0 == strcmp("TEST/Alice", snapshot->base->name));
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
/* Test for single match, multiple possibilities */
snapshot = ast_multi_channel_blob_get_channel(blob, "Peer");
ast_test_validate(test, NULL != snapshot);
stasis: Segment channel snapshot to reduce creation cost. When a channel snapshot was created it used to be done from scratch, copying all data (many strings). This incurs a cost when doing so. This change segments the channel snapshot into different components which can be reused if unchanged from the previous snapshot creation, reducing the cost. In normal cases this results in some pointers being copied with reference count being bumped, some integers being set, and a string or two copied. The other benefit is that it is now possible to determine if a channel snapshot update is redundant and thus stop it before a message is published to stasis. The specific segments in the channel snapshot were split up based on whether they are changed together, how often they are changed, and their general grouping. In practice only 1 (or 0) of the segments actually get changed in normal operation. Invalidation is done by setting a flag on the channel when the segment source is changed, forcing creation of a new segment when the channel snapshot is created. ASTERISK-28119 Change-Id: I5d7ef3df963a88ac47bc187d73c5225c315f8423
2018-11-07 17:18:34 +00:00
ast_test_validate(test, 0 != strcmp("TEST/Alice", snapshot->base->name));
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
/* Multi-match */
matches = ast_multi_channel_blob_get_channels(blob, "Peer");
ast_test_validate(test, NULL != matches);
ast_test_validate(test, 2 == ao2_container_count(matches));
snapshot = ao2_find(matches, "TEST/Bob", OBJ_KEY);
ast_test_validate(test, NULL != snapshot);
ao2_cleanup(snapshot);
snapshot = ao2_find(matches, "TEST/Charlie", OBJ_KEY);
ast_test_validate(test, NULL != snapshot);
ao2_cleanup(snapshot);
ast_test_validate(test, 1 == ao2_ref(matches, 0));
ao2_cleanup(matches);
return AST_TEST_PASS;
}
Moved core logic from app_stasis to res_stasis After some discussion on asterisk-dev, it was decided that the bulk of the logic in app_stasis actually belongs in a resource module instead of the application module. This patch does that, leaves the app specific stuff in app_stasis, and fixes up everything else to be consistent with that change. * Renamed test_app_stasis to test_res_stasis * Renamed app_stasis.h to stasis_app.h * This is still stasis application support, even though it's no longer in an app_ module. The name should never have been tied to the type of module, anyways. * Now that json isn't a resource module anymore, moved the ast_channel_snapshot_to_json function to main/stasis_channels.c, where it makes more sense. Review: https://reviewboard.asterisk.org/r/2430/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-15 16:43:47 +00:00
AST_TEST_DEFINE(channel_snapshot_json)
{
RAII_VAR(struct stasis_message *, msg, NULL, ao2_cleanup);
RAII_VAR(struct ast_channel *, chan, NULL, safe_channel_release);
RAII_VAR(struct ast_channel_snapshot *, snapshot, NULL, ao2_cleanup);
RAII_VAR(struct ast_json *, expected, NULL, ast_json_unref);
RAII_VAR(struct ast_json *, actual, NULL, ast_json_unref);
switch (cmd) {
case TEST_INIT:
info->name = __func__;
info->category = test_category;
info->summary = "Test creation of ast_channel_blob objects";
info->description = "Test creation of ast_channel_blob objects";
return AST_TEST_NOT_RUN;
case TEST_EXECUTE:
break;
}
Make sure unit tests compile This fixes the unit tests that were broken by r403069 and several functions requiring a new parameter for sanitization of JSON messages generated from object snapshots. ........ Merged revisions 403094 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403095 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-22 23:57:45 +00:00
ast_test_validate(test, NULL == ast_channel_snapshot_to_json(NULL, NULL));
Moved core logic from app_stasis to res_stasis After some discussion on asterisk-dev, it was decided that the bulk of the logic in app_stasis actually belongs in a resource module instead of the application module. This patch does that, leaves the app specific stuff in app_stasis, and fixes up everything else to be consistent with that change. * Renamed test_app_stasis to test_res_stasis * Renamed app_stasis.h to stasis_app.h * This is still stasis application support, even though it's no longer in an app_ module. The name should never have been tied to the type of module, anyways. * Now that json isn't a resource module anymore, moved the ast_channel_snapshot_to_json function to main/stasis_channels.c, where it makes more sense. Review: https://reviewboard.asterisk.org/r/2430/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-15 16:43:47 +00:00
uniqueid: channel linkedid, ami, ari object creation with id's Much needed was a way to assign id to objects on creation, and much change was necessary to accomplish it. Channel uniqueids and linkedids are split into separate string and creation time components without breaking linkedid propgation. This allowed the uniqueid to be specified by the user interface - and those values are now carried through to channel creation, adding the assignedids value to every function in the chain including the channel drivers. For local channels, the second channel can be specified or left to default to a ;2 suffix of first. In ARI, bridge, playback, and snoop objects can also be created with a specified uniqueid. Along the way, the args order to allocating channels was fixed in chan_mgcp and chan_gtalk, and linkedid is no longer lost as masquerade occurs. (closes issue ASTERISK-23120) Review: https://reviewboard.asterisk.org/r/3191/ ........ Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
chan = ast_channel_alloc(0, AST_STATE_DOWN, "cid_num", "cid_name", "acctcode", "exten", "context", NULL, NULL, 0, "TEST/name");
channels: Return allocated channels locked. This change makes ast_channel_alloc return allocated channels locked. By doing so no other thread can acquire, lock, and manipulate the channel before it is completely set up. (closes issue AST-1256) Review: https://reviewboard.asterisk.org/r/3067/ ........ Merged revisions 404204 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404210 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 19:28:05 +00:00
ast_channel_unlock(chan);
Moved core logic from app_stasis to res_stasis After some discussion on asterisk-dev, it was decided that the bulk of the logic in app_stasis actually belongs in a resource module instead of the application module. This patch does that, leaves the app specific stuff in app_stasis, and fixes up everything else to be consistent with that change. * Renamed test_app_stasis to test_res_stasis * Renamed app_stasis.h to stasis_app.h * This is still stasis application support, even though it's no longer in an app_ module. The name should never have been tied to the type of module, anyways. * Now that json isn't a resource module anymore, moved the ast_channel_snapshot_to_json function to main/stasis_channels.c, where it makes more sense. Review: https://reviewboard.asterisk.org/r/2430/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-15 16:43:47 +00:00
ast_test_validate(test, NULL != chan);
channel locking: Add locking for channel snapshot creation Original commit message by mmichelson (asterisk 12 r403311): "This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such." The above was initially committed and then reverted at r403398. The problem was found to be in core_local.c in the publish_local_bridge_message function. The ast_unreal_lock_all function locks and adds a reference to the returned channels and while they were being unlocked they were not being unreffed when no longer needed. Fixed by unreffing the channels. Also in bridge.c a lock was obtained on "other->chan", but then an attempt was made to unlock "other" and not the previously locked channel. Fixed by unlocking "other->chan" (closes issue ASTERISK-22709) Reported by: John Bigelow ........ Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 20:33:37 +00:00
ast_channel_lock(chan);
Moved core logic from app_stasis to res_stasis After some discussion on asterisk-dev, it was decided that the bulk of the logic in app_stasis actually belongs in a resource module instead of the application module. This patch does that, leaves the app specific stuff in app_stasis, and fixes up everything else to be consistent with that change. * Renamed test_app_stasis to test_res_stasis * Renamed app_stasis.h to stasis_app.h * This is still stasis application support, even though it's no longer in an app_ module. The name should never have been tied to the type of module, anyways. * Now that json isn't a resource module anymore, moved the ast_channel_snapshot_to_json function to main/stasis_channels.c, where it makes more sense. Review: https://reviewboard.asterisk.org/r/2430/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-15 16:43:47 +00:00
snapshot = ast_channel_snapshot_create(chan);
channel locking: Add locking for channel snapshot creation Original commit message by mmichelson (asterisk 12 r403311): "This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such." The above was initially committed and then reverted at r403398. The problem was found to be in core_local.c in the publish_local_bridge_message function. The ast_unreal_lock_all function locks and adds a reference to the returned channels and while they were being unlocked they were not being unreffed when no longer needed. Fixed by unreffing the channels. Also in bridge.c a lock was obtained on "other->chan", but then an attempt was made to unlock "other" and not the previously locked channel. Fixed by unlocking "other->chan" (closes issue ASTERISK-22709) Reported by: John Bigelow ........ Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18 20:33:37 +00:00
ast_channel_unlock(chan);
Moved core logic from app_stasis to res_stasis After some discussion on asterisk-dev, it was decided that the bulk of the logic in app_stasis actually belongs in a resource module instead of the application module. This patch does that, leaves the app specific stuff in app_stasis, and fixes up everything else to be consistent with that change. * Renamed test_app_stasis to test_res_stasis * Renamed app_stasis.h to stasis_app.h * This is still stasis application support, even though it's no longer in an app_ module. The name should never have been tied to the type of module, anyways. * Now that json isn't a resource module anymore, moved the ast_channel_snapshot_to_json function to main/stasis_channels.c, where it makes more sense. Review: https://reviewboard.asterisk.org/r/2430/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-15 16:43:47 +00:00
ast_test_validate(test, NULL != snapshot);
Make sure unit tests compile This fixes the unit tests that were broken by r403069 and several functions requiring a new parameter for sanitization of JSON messages generated from object snapshots. ........ Merged revisions 403094 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403095 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-22 23:57:45 +00:00
actual = ast_channel_snapshot_to_json(snapshot, NULL);
ari: expose channel driver's unique id to ARI channel resource This change exposes the channel driver's unique id (i.e. the Call-ID for chan_sip/chan_pjsip based channels) to ARI channel resources as `protocol_id`. ASTERISK-30027 Reported by: Moritz Fain Tested by: Moritz Fain Change-Id: I7cc6e7a9d29efe74bc27811d788dac20fe559b87
2022-04-25 22:40:49 +00:00
expected = ast_json_pack("{ s: s, s: s, s: s, s: s, s: s,"
main/json.c: Added app_name, app_data to channel type It was difficult to check the channel's current application and parameters using ARI for current channels. Added app_name, app_data items to show the current application information. ASTERISK-28343 Change-Id: Ia48972b3850e5099deab0faeaaf51223a1f2f38c
2019-03-21 23:09:14 +00:00
" s: { s: s, s: s, s: i, s: s, s: s },"
Moved core logic from app_stasis to res_stasis After some discussion on asterisk-dev, it was decided that the bulk of the logic in app_stasis actually belongs in a resource module instead of the application module. This patch does that, leaves the app specific stuff in app_stasis, and fixes up everything else to be consistent with that change. * Renamed test_app_stasis to test_res_stasis * Renamed app_stasis.h to stasis_app.h * This is still stasis application support, even though it's no longer in an app_ module. The name should never have been tied to the type of module, anyways. * Now that json isn't a resource module anymore, moved the ast_channel_snapshot_to_json function to main/stasis_channels.c, where it makes more sense. Review: https://reviewboard.asterisk.org/r/2430/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-15 16:43:47 +00:00
" s: { s: s, s: s },"
" s: { s: s, s: s },"
Stasis: Update unittest for channel snapshots This adjusts the unit test for channel snapshots to take the new language key into account. ........ Merged revisions 429352 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429353 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-11 13:53:39 +00:00
" s: s"
Moved core logic from app_stasis to res_stasis After some discussion on asterisk-dev, it was decided that the bulk of the logic in app_stasis actually belongs in a resource module instead of the application module. This patch does that, leaves the app specific stuff in app_stasis, and fixes up everything else to be consistent with that change. * Renamed test_app_stasis to test_res_stasis * Renamed app_stasis.h to stasis_app.h * This is still stasis application support, even though it's no longer in an app_ module. The name should never have been tied to the type of module, anyways. * Now that json isn't a resource module anymore, moved the ast_channel_snapshot_to_json function to main/stasis_channels.c, where it makes more sense. Review: https://reviewboard.asterisk.org/r/2430/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-15 16:43:47 +00:00
" s: o"
"}",
"name", "TEST/name",
"state", "Down",
"accountcode", "acctcode",
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
"id", ast_channel_uniqueid(chan),
ari: expose channel driver's unique id to ARI channel resource This change exposes the channel driver's unique id (i.e. the Call-ID for chan_sip/chan_pjsip based channels) to ARI channel resources as `protocol_id`. ASTERISK-30027 Reported by: Moritz Fain Tested by: Moritz Fain Change-Id: I7cc6e7a9d29efe74bc27811d788dac20fe559b87
2022-04-25 22:40:49 +00:00
"protocol_id", "",
Moved core logic from app_stasis to res_stasis After some discussion on asterisk-dev, it was decided that the bulk of the logic in app_stasis actually belongs in a resource module instead of the application module. This patch does that, leaves the app specific stuff in app_stasis, and fixes up everything else to be consistent with that change. * Renamed test_app_stasis to test_res_stasis * Renamed app_stasis.h to stasis_app.h * This is still stasis application support, even though it's no longer in an app_ module. The name should never have been tied to the type of module, anyways. * Now that json isn't a resource module anymore, moved the ast_channel_snapshot_to_json function to main/stasis_channels.c, where it makes more sense. Review: https://reviewboard.asterisk.org/r/2430/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-15 16:43:47 +00:00
"dialplan",
"context", "context",
"exten", "exten",
"priority", 1,
main/json.c: Added app_name, app_data to channel type It was difficult to check the channel's current application and parameters using ARI for current channels. Added app_name, app_data items to show the current application information. ASTERISK-28343 Change-Id: Ia48972b3850e5099deab0faeaaf51223a1f2f38c
2019-03-21 23:09:14 +00:00
"app_name", "",
"app_data", "",
Moved core logic from app_stasis to res_stasis After some discussion on asterisk-dev, it was decided that the bulk of the logic in app_stasis actually belongs in a resource module instead of the application module. This patch does that, leaves the app specific stuff in app_stasis, and fixes up everything else to be consistent with that change. * Renamed test_app_stasis to test_res_stasis * Renamed app_stasis.h to stasis_app.h * This is still stasis application support, even though it's no longer in an app_ module. The name should never have been tied to the type of module, anyways. * Now that json isn't a resource module anymore, moved the ast_channel_snapshot_to_json function to main/stasis_channels.c, where it makes more sense. Review: https://reviewboard.asterisk.org/r/2430/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-15 16:43:47 +00:00
"caller",
"name", "cid_name",
"number", "cid_num",
"connected",
"name", "",
"number", "",
Stasis: Update unittest for channel snapshots This adjusts the unit test for channel snapshots to take the new language key into account. ........ Merged revisions 429352 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429353 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-11 13:53:39 +00:00
"language", "en",
Moved core logic from app_stasis to res_stasis After some discussion on asterisk-dev, it was decided that the bulk of the logic in app_stasis actually belongs in a resource module instead of the application module. This patch does that, leaves the app specific stuff in app_stasis, and fixes up everything else to be consistent with that change. * Renamed test_app_stasis to test_res_stasis * Renamed app_stasis.h to stasis_app.h * This is still stasis application support, even though it's no longer in an app_ module. The name should never have been tied to the type of module, anyways. * Now that json isn't a resource module anymore, moved the ast_channel_snapshot_to_json function to main/stasis_channels.c, where it makes more sense. Review: https://reviewboard.asterisk.org/r/2430/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-15 16:43:47 +00:00
"creationtime",
ast_json_timeval(
ast_channel_creationtime(chan), NULL));
ast_test_validate(test, ast_json_equal(expected, actual));
return AST_TEST_PASS;
}
stasis: Update the snapshot after setting the redirect The previous commit added the caller_rdnis attribute. Make it avialble during a possible ChanngelHangupRequest. (cherry picked from commit 56733c73b44c8f4db87bb1f771b9e61bf86e14ea)
2023-10-21 09:39:50 +00:00
AST_TEST_DEFINE(channel_redirect_snapshot_json)
{
RAII_VAR(struct stasis_message *, msg, NULL, ao2_cleanup);
RAII_VAR(struct ast_channel *, chan, NULL, safe_channel_release);
RAII_VAR(struct ast_channel_snapshot *, snapshot, NULL, ao2_cleanup);
RAII_VAR(struct ast_json *, expected, NULL, ast_json_unref);
RAII_VAR(struct ast_json *, actual, NULL, ast_json_unref);
struct ast_party_redirecting data;
switch (cmd) {
case TEST_INIT:
info->name = __func__;
info->category = test_category;
info->summary = "Test creation of ast_channel_blob objects with rdnis";
info->description = "Test creation of ast_channel_blob objects with rdnis";
return AST_TEST_NOT_RUN;
case TEST_EXECUTE:
break;
}
ast_test_validate(test, NULL == ast_channel_snapshot_to_json(NULL, NULL));
chan = ast_channel_alloc(0, AST_STATE_DOWN, "cid_num", "cid_name", "acctcode", "exten", "context", NULL, NULL, 0, "TEST/name");
ast_channel_unlock(chan);
ast_test_validate(test, NULL != chan);
ast_channel_lock(chan);
ast_party_redirecting_init(&data);
data.from.number.valid = 1;
data.from.number.str = ast_strdup("123456");
ast_channel_set_redirecting(chan, &data, NULL);
ast_party_redirecting_free(&data);
ast_channel_unlock(chan);
ast_channel_lock(chan);
snapshot = ast_channel_snapshot_create(chan);
ast_channel_unlock(chan);
ast_test_validate(test, NULL != snapshot);
actual = ast_channel_snapshot_to_json(snapshot, NULL);
expected = ast_json_pack("{ s: s, s: s, s: s, s: s, s: s,"
" s: { s: s, s: s, s: i, s: s, s: s },"
" s: { s: s, s: s },"
" s: { s: s, s: s },"
" s: s"
" s: s"
" s: o"
"}",
"name", "TEST/name",
"state", "Down",
"accountcode", "acctcode",
"id", ast_channel_uniqueid(chan),
"protocol_id", "",
"dialplan",
"context", "context",
"exten", "exten",
"priority", 1,
"app_name", "",
"app_data", "",
"caller",
"name", "cid_name",
"number", "cid_num",
"connected",
"name", "",
"number", "",
"language", "en",
"caller_rdnis", "123456",
"creationtime",
ast_json_timeval(
ast_channel_creationtime(chan), NULL));
ast_test_validate(test, ast_json_equal(expected, actual));
return AST_TEST_PASS;
}
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
static int unload_module(void)
{
AST_TEST_UNREGISTER(channel_blob_create);
Remove required type field from channel blobs When we first introduced the channel blob types, the JSON blobs were self identifying by a required "type" field in the JSON object itself. This, as it turns out, was a bad idea. When we introduced the message router, it was useless for routing based on the JSON type. And messages had two type fields to check: the stasis_message_type() of the message itself, plus the type field in the JSON blob (but only if it was a blob message). This patch corrects that mistake by removing the required type field from JSON blobs, and introducing first class stasis_message_type objects for the actual message type. Since we now will have a proliferation of message types, I introduced a few macros to help reduce the amount of boilerplate necessary to set them up. Review: https://reviewboard.asterisk.org/r/2509 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 18:34:50 +00:00
AST_TEST_UNREGISTER(null_blob);
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
AST_TEST_UNREGISTER(multi_channel_blob_create);
AST_TEST_UNREGISTER(multi_channel_blob_snapshots);
Moved core logic from app_stasis to res_stasis After some discussion on asterisk-dev, it was decided that the bulk of the logic in app_stasis actually belongs in a resource module instead of the application module. This patch does that, leaves the app specific stuff in app_stasis, and fixes up everything else to be consistent with that change. * Renamed test_app_stasis to test_res_stasis * Renamed app_stasis.h to stasis_app.h * This is still stasis application support, even though it's no longer in an app_ module. The name should never have been tied to the type of module, anyways. * Now that json isn't a resource module anymore, moved the ast_channel_snapshot_to_json function to main/stasis_channels.c, where it makes more sense. Review: https://reviewboard.asterisk.org/r/2430/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-15 16:43:47 +00:00
AST_TEST_UNREGISTER(channel_snapshot_json);
stasis: Update the snapshot after setting the redirect The previous commit added the caller_rdnis attribute. Make it avialble during a possible ChanngelHangupRequest. (cherry picked from commit 56733c73b44c8f4db87bb1f771b9e61bf86e14ea)
2023-10-21 09:39:50 +00:00
AST_TEST_UNREGISTER(channel_redirect_snapshot_json);
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
return 0;
}
static int load_module(void)
{
AST_TEST_REGISTER(channel_blob_create);
Remove required type field from channel blobs When we first introduced the channel blob types, the JSON blobs were self identifying by a required "type" field in the JSON object itself. This, as it turns out, was a bad idea. When we introduced the message router, it was useless for routing based on the JSON type. And messages had two type fields to check: the stasis_message_type() of the message itself, plus the type field in the JSON blob (but only if it was a blob message). This patch corrects that mistake by removing the required type field from JSON blobs, and introducing first class stasis_message_type objects for the actual message type. Since we now will have a proliferation of message types, I introduced a few macros to help reduce the amount of boilerplate necessary to set them up. Review: https://reviewboard.asterisk.org/r/2509 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 18:34:50 +00:00
AST_TEST_REGISTER(null_blob);
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
AST_TEST_REGISTER(multi_channel_blob_create);
AST_TEST_REGISTER(multi_channel_blob_snapshots);
Moved core logic from app_stasis to res_stasis After some discussion on asterisk-dev, it was decided that the bulk of the logic in app_stasis actually belongs in a resource module instead of the application module. This patch does that, leaves the app specific stuff in app_stasis, and fixes up everything else to be consistent with that change. * Renamed test_app_stasis to test_res_stasis * Renamed app_stasis.h to stasis_app.h * This is still stasis application support, even though it's no longer in an app_ module. The name should never have been tied to the type of module, anyways. * Now that json isn't a resource module anymore, moved the ast_channel_snapshot_to_json function to main/stasis_channels.c, where it makes more sense. Review: https://reviewboard.asterisk.org/r/2430/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-15 16:43:47 +00:00
AST_TEST_REGISTER(channel_snapshot_json);
stasis: Update the snapshot after setting the redirect The previous commit added the caller_rdnis attribute. Make it avialble during a possible ChanngelHangupRequest. (cherry picked from commit 56733c73b44c8f4db87bb1f771b9e61bf86e14ea)
2023-10-21 09:39:50 +00:00
AST_TEST_REGISTER(channel_redirect_snapshot_json);
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-04-08 14:26:37 +00:00
return AST_MODULE_LOAD_SUCCESS;
}
AST_MODULE_INFO(ASTERISK_GPL_KEY, 0, "Stasis Channel Testing",
modules: Add missing run time module support levels. Change-Id: I29b9dbfa4bbfc49f21eba356858e38b1d3041824
2018-10-17 19:34:55 +00:00
.support_level = AST_MODULE_SUPPORT_CORE,
AST_MODULE_INFO: Format corrections to the usages of AST_MODULE_INFO macro. Change-Id: Icf88f9f861c6b2a16e5f626ff25795218a6f2723
2015-05-06 00:49:04 +00:00
.load = load_module,
.unload = unload_module
);