2013-05-21 18:00:22 +00:00
|
|
|
/*
|
|
|
|
* Asterisk -- An open source telephony toolkit.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2013, Digium, Inc.
|
|
|
|
*
|
|
|
|
* Kinsey Moore <kmoore@digium.com>
|
|
|
|
*
|
|
|
|
* See http://www.asterisk.org for more information about
|
|
|
|
* the Asterisk project. Please do not directly contact
|
|
|
|
* any of the maintainers of this project for assistance;
|
|
|
|
* the project provides a web site, mailing lists and IRC
|
|
|
|
* channels for your use.
|
|
|
|
*
|
|
|
|
* This program is free software, distributed under the terms of
|
|
|
|
* the GNU General Public License Version 2. See the LICENSE file
|
|
|
|
* at the top of the source tree.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*! \file
|
|
|
|
*
|
|
|
|
* \brief Stasis Messages and Data Types for Bridge Objects
|
|
|
|
*
|
|
|
|
* \author Kinsey Moore <kmoore@digium.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*** MODULEINFO
|
|
|
|
<support_level>core</support_level>
|
|
|
|
***/
|
|
|
|
|
|
|
|
#include "asterisk.h"
|
|
|
|
|
|
|
|
#include "asterisk/astobj2.h"
|
|
|
|
#include "asterisk/stasis.h"
|
2013-08-01 13:49:34 +00:00
|
|
|
#include "asterisk/stasis_cache_pattern.h"
|
2013-05-21 18:00:22 +00:00
|
|
|
#include "asterisk/channel.h"
|
2013-07-25 04:18:05 +00:00
|
|
|
#include "asterisk/stasis_bridges.h"
|
2013-05-21 18:00:22 +00:00
|
|
|
#include "asterisk/stasis_channels.h"
|
2013-07-25 04:06:32 +00:00
|
|
|
#include "asterisk/bridge.h"
|
|
|
|
#include "asterisk/bridge_technology.h"
|
2013-05-21 18:00:22 +00:00
|
|
|
|
Fix a performance problem CDRs
There is a large performance price currently in the CDR engine. We currently
perform two ao2_callback calls on a container that has an entry for every
channel in the system. This is done to create matching pairs between channels
in a bridge.
As such, the portion of the CDR logic that this patch deals with is how we
make pairings when a channel enters a mixing bridge. In general, when a
channel enters such a bridge, we need to do two things:
(1) Figure out if anyone in the bridge can be this channel's Party B.
(2) Make pairings with every other channel in the bridge that is not already
our Party B.
This is a two step process. In the first step, we look through everyone in the
bridge and see if they can be our Party B (single_state_process_bridge_enter).
If they can - yay! We mark our CDR as having gotten a Party B. If not, we keep
searching. If we don't find one, we wait until someone joins who can be our
Party B.
Step 2 is where we changed the logic
(handle_bridge_pairings and bridge_candidate_process). Previously, we would
first find candidates - those channels in the bridge with us - from the
active_cdrs_by_channel container. Because a channel could be a candidate if it
was Party B to an item in the container, the code implemented multiple
ao2_container callbacks to get all the candidates. We also had to store them
in another container with some other meta information. This was rather complex
and costly, particularly if you have 300 Local channels (600 channels!) going
at once.
Luckily, none of it is needed: when a channel enters a bridge (which is when
we're figuring all this stuff out), the bridge snapshot tells us the unique
IDs of everyone already in the bridge. All we need to do is:
For all channels in the bridge:
If the channel is us or our Party B that we got in step 1, skip it
Compare us and the candidate to figure out who is Party A (based on some
specific rules)
If we are Party A:
Make a new CDR for us, append it to our chain, and set the candidate as
Party B
If they are Party A:
If they don't have a Party B:
Make a new CDR for them, append us to their chain, and us as Party B
Otherwise:
Copy us over as Party B on their existing CDR.
This patch does that.
Because we now use channel unique IDs to find the candidates during bridging,
active_cdrs_by_channel now looks up things using uniqueid instead of channel
name. This makes the more complex code simpler; it does, however, have the
drawback that dialplan applications and functions will be slightly slower as
they have to iterate through the container looking for the CDR by name.
That's a small price to pay however as the bridging code will be called a lot
more often.
This patch also does two other minor changes:
(1) It reduces the container size of the channels in a bridge snapshot to 1.
In order to be predictable for multi-party bridges, the order of the
channels in the container must be stable; that is, it must always devolve
to a linked list.
(2) CDRs and the multi-party test was updated to show the relationship between
two dialed channels. You still want to know if they talked - previously,
dialed channels were always ignored, which is wrong when they have
managed to get a Party B.
(closes issue ASTERISK-22488)
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/2861/
........
Merged revisions 399666 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399667 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-09-24 18:10:20 +00:00
|
|
|
/* The container of channel snapshots in a bridge snapshot should always be
|
|
|
|
equivalent to a linked list; otherwise things (like CDRs) that depend on some
|
|
|
|
consistency in the ordering of channels in a bridge will break. */
|
|
|
|
#define SNAPSHOT_CHANNELS_BUCKETS 1
|
2013-05-21 18:00:22 +00:00
|
|
|
|
2013-06-28 18:42:24 +00:00
|
|
|
/*** DOCUMENTATION
|
|
|
|
<managerEvent language="en_US" name="BlindTransfer">
|
|
|
|
<managerEventInstance class="EVENT_FLAG_CALL">
|
|
|
|
<synopsis>Raised when a blind transfer is complete.</synopsis>
|
|
|
|
<syntax>
|
|
|
|
<parameter name="Result">
|
|
|
|
<para>Indicates if the transfer was successful or if it failed.</para>
|
|
|
|
<enumlist>
|
|
|
|
<enum name="Fail"><para>An internal error occurred.</para></enum>
|
|
|
|
<enum name="Invalid"><para>Invalid configuration for transfer (e.g. Not bridged)</para></enum>
|
|
|
|
<enum name="Not Permitted"><para>Bridge does not permit transfers</para></enum>
|
|
|
|
<enum name="Success"><para>Transfer completed successfully</para></enum>
|
|
|
|
</enumlist>
|
|
|
|
<note><para>A result of <literal>Success</literal> does not necessarily mean that a target was succesfully
|
|
|
|
contacted. It means that a party was succesfully placed into the dialplan at the expected location.</para></note>
|
|
|
|
</parameter>
|
2013-08-01 17:07:52 +00:00
|
|
|
<channel_snapshot prefix="Transferer"/>
|
2014-08-07 15:30:19 +00:00
|
|
|
<channel_snapshot prefix="Transferee"/>
|
2013-08-01 17:07:52 +00:00
|
|
|
<bridge_snapshot/>
|
2013-06-28 18:42:24 +00:00
|
|
|
<parameter name="IsExternal">
|
|
|
|
<para>Indicates if the transfer was performed outside of Asterisk. For instance,
|
|
|
|
a channel protocol native transfer is external. A DTMF transfer is internal.</para>
|
|
|
|
<enumlist>
|
|
|
|
<enum name="Yes" />
|
|
|
|
<enum name="No" />
|
|
|
|
</enumlist>
|
|
|
|
</parameter>
|
|
|
|
<parameter name="Context">
|
|
|
|
<para>Destination context for the blind transfer.</para>
|
|
|
|
</parameter>
|
|
|
|
<parameter name="Extension">
|
|
|
|
<para>Destination extension for the blind transfer.</para>
|
|
|
|
</parameter>
|
|
|
|
</syntax>
|
2016-08-14 01:16:58 +00:00
|
|
|
<see-also>
|
|
|
|
<ref type="manager">BlindTransfer</ref>
|
|
|
|
</see-also>
|
2013-06-28 18:42:24 +00:00
|
|
|
</managerEventInstance>
|
|
|
|
</managerEvent>
|
|
|
|
<managerEvent language="en_US" name="AttendedTransfer">
|
|
|
|
<managerEventInstance class="EVENT_FLAG_CALL">
|
|
|
|
<synopsis>Raised when an attended transfer is complete.</synopsis>
|
|
|
|
<syntax>
|
|
|
|
<xi:include xpointer="xpointer(docs/managerEvent[@name='BlindTransfer']/managerEventInstance/syntax/parameter[@name='Result'])" />
|
2013-08-01 17:07:52 +00:00
|
|
|
<channel_snapshot prefix="OrigTransferer"/>
|
|
|
|
<bridge_snapshot prefix="Orig"/>
|
|
|
|
<channel_snapshot prefix="SecondTransferer"/>
|
|
|
|
<bridge_snapshot prefix="Second"/>
|
2013-06-28 18:42:24 +00:00
|
|
|
<parameter name="DestType">
|
|
|
|
<para>Indicates the method by which the attended transfer completed.</para>
|
|
|
|
<enumlist>
|
|
|
|
<enum name="Bridge"><para>The transfer was accomplished by merging two bridges into one.</para></enum>
|
|
|
|
<enum name="App"><para>The transfer was accomplished by having a channel or bridge run a dialplan application.</para></enum>
|
|
|
|
<enum name="Link"><para>The transfer was accomplished by linking two bridges together using a local channel pair.</para></enum>
|
2013-07-23 15:28:11 +00:00
|
|
|
<enum name="Threeway"><para>The transfer was accomplished by placing all parties into a threeway call.</para></enum>
|
2013-06-28 18:42:24 +00:00
|
|
|
<enum name="Fail"><para>The transfer failed.</para></enum>
|
|
|
|
</enumlist>
|
|
|
|
</parameter>
|
|
|
|
<parameter name="DestBridgeUniqueid">
|
|
|
|
<para>Indicates the surviving bridge when bridges were merged to complete the transfer</para>
|
2013-07-23 15:28:11 +00:00
|
|
|
<note><para>This header is only present when <replaceable>DestType</replaceable> is <literal>Bridge</literal> or <literal>Threeway</literal></para></note>
|
2013-06-28 18:42:24 +00:00
|
|
|
</parameter>
|
|
|
|
<parameter name="DestApp">
|
|
|
|
<para>Indicates the application that is running when the transfer completes</para>
|
|
|
|
<note><para>This header is only present when <replaceable>DestType</replaceable> is <literal>App</literal></para></note>
|
|
|
|
</parameter>
|
2013-08-01 17:07:52 +00:00
|
|
|
<channel_snapshot prefix="LocalOne"/>
|
|
|
|
<channel_snapshot prefix="LocalTwo"/>
|
2013-07-23 15:28:11 +00:00
|
|
|
<parameter name="DestTransfererChannel">
|
|
|
|
<para>The name of the surviving transferer channel when a transfer results in a threeway call</para>
|
|
|
|
<note><para>This header is only present when <replaceable>DestType</replaceable> is <literal>Threeway</literal></para></note>
|
|
|
|
</parameter>
|
2014-08-07 15:30:19 +00:00
|
|
|
<channel_snapshot prefix="Transferee" />
|
2013-06-28 18:42:24 +00:00
|
|
|
</syntax>
|
|
|
|
<description>
|
|
|
|
<para>The headers in this event attempt to describe all the major details of the attended transfer. The two transferer channels
|
|
|
|
and the two bridges are determined based on their chronological establishment. So consider that Alice calls Bob, and then Alice
|
|
|
|
transfers the call to Voicemail. The transferer and bridge headers would be arranged as follows:</para>
|
|
|
|
<para> <replaceable>OrigTransfererChannel</replaceable>: Alice's channel in the bridge with Bob.</para>
|
2013-08-01 17:07:52 +00:00
|
|
|
<para> <replaceable>OrigBridgeUniqueid</replaceable>: The bridge between Alice and Bob.</para>
|
2013-06-28 18:42:24 +00:00
|
|
|
<para> <replaceable>SecondTransfererChannel</replaceable>: Alice's channel that called Voicemail.</para>
|
2013-08-01 17:07:52 +00:00
|
|
|
<para> <replaceable>SecondBridgeUniqueid</replaceable>: Not present, since a call to Voicemail has no bridge.</para>
|
2013-06-28 18:42:24 +00:00
|
|
|
<para>Now consider if the order were reversed; instead of having Alice call Bob and transfer him to Voicemail, Alice instead
|
|
|
|
calls her Voicemail and transfers that to Bob. The transferer and bridge headers would be arranged as follows:</para>
|
|
|
|
<para> <replaceable>OrigTransfererChannel</replaceable>: Alice's channel that called Voicemail.</para>
|
2013-08-01 17:07:52 +00:00
|
|
|
<para> <replaceable>OrigBridgeUniqueid</replaceable>: Not present, since a call to Voicemail has no bridge.</para>
|
2013-06-28 18:42:24 +00:00
|
|
|
<para> <replaceable>SecondTransfererChannel</replaceable>: Alice's channel in the bridge with Bob.</para>
|
2013-08-01 17:07:52 +00:00
|
|
|
<para> <replaceable>SecondBridgeUniqueid</replaceable>: The bridge between Alice and Bob.</para>
|
2013-06-28 18:42:24 +00:00
|
|
|
</description>
|
2016-08-14 01:16:58 +00:00
|
|
|
<see-also>
|
|
|
|
<ref type="manager">AtxFer</ref>
|
|
|
|
</see-also>
|
2013-06-28 18:42:24 +00:00
|
|
|
</managerEventInstance>
|
|
|
|
</managerEvent>
|
|
|
|
***/
|
|
|
|
|
2014-02-01 16:26:57 +00:00
|
|
|
static struct ast_json *attended_transfer_to_json(struct stasis_message *msg,
|
|
|
|
const struct stasis_message_sanitizer *sanitize);
|
2013-06-28 18:42:24 +00:00
|
|
|
static struct ast_manager_event_blob *attended_transfer_to_ami(struct stasis_message *message);
|
2014-02-01 16:26:57 +00:00
|
|
|
static struct ast_json *blind_transfer_to_json(struct stasis_message *msg,
|
|
|
|
const struct stasis_message_sanitizer *sanitize);
|
2013-06-28 18:42:24 +00:00
|
|
|
static struct ast_manager_event_blob *blind_transfer_to_ami(struct stasis_message *message);
|
2013-11-22 20:10:46 +00:00
|
|
|
static struct ast_json *ast_channel_entered_bridge_to_json(
|
|
|
|
struct stasis_message *msg,
|
|
|
|
const struct stasis_message_sanitizer *sanitize);
|
|
|
|
static struct ast_json *ast_channel_left_bridge_to_json(
|
|
|
|
struct stasis_message *msg,
|
|
|
|
const struct stasis_message_sanitizer *sanitize);
|
|
|
|
static struct ast_json *ast_bridge_merge_message_to_json(
|
|
|
|
struct stasis_message *msg,
|
|
|
|
const struct stasis_message_sanitizer *sanitize);
|
2013-06-28 18:42:24 +00:00
|
|
|
|
2013-08-01 13:49:34 +00:00
|
|
|
static struct stasis_cp_all *bridge_cache_all;
|
|
|
|
|
2013-05-21 18:00:22 +00:00
|
|
|
/*!
|
|
|
|
* @{ \brief Define bridge message types.
|
|
|
|
*/
|
|
|
|
STASIS_MESSAGE_TYPE_DEFN(ast_bridge_snapshot_type);
|
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
|
|
|
STASIS_MESSAGE_TYPE_DEFN(ast_bridge_merge_message_type,
|
|
|
|
.to_json = ast_bridge_merge_message_to_json);
|
|
|
|
STASIS_MESSAGE_TYPE_DEFN(ast_channel_entered_bridge_type,
|
|
|
|
.to_json = ast_channel_entered_bridge_to_json);
|
|
|
|
STASIS_MESSAGE_TYPE_DEFN(ast_channel_left_bridge_type,
|
|
|
|
.to_json = ast_channel_left_bridge_to_json);
|
2014-02-01 16:26:57 +00:00
|
|
|
STASIS_MESSAGE_TYPE_DEFN(ast_blind_transfer_type,
|
|
|
|
.to_json = blind_transfer_to_json,
|
|
|
|
.to_ami = blind_transfer_to_ami);
|
|
|
|
STASIS_MESSAGE_TYPE_DEFN(ast_attended_transfer_type,
|
|
|
|
.to_json = attended_transfer_to_json,
|
|
|
|
.to_ami = attended_transfer_to_ami);
|
2013-05-21 18:00:22 +00:00
|
|
|
/*! @} */
|
|
|
|
|
2013-08-01 13:49:34 +00:00
|
|
|
struct stasis_cache *ast_bridge_cache(void)
|
|
|
|
{
|
|
|
|
return stasis_cp_all_cache(bridge_cache_all);
|
|
|
|
}
|
2013-05-21 18:00:22 +00:00
|
|
|
|
2013-08-01 13:49:34 +00:00
|
|
|
struct stasis_topic *ast_bridge_topic_all(void)
|
|
|
|
{
|
|
|
|
return stasis_cp_all_topic(bridge_cache_all);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct stasis_topic *ast_bridge_topic_all_cached(void)
|
|
|
|
{
|
|
|
|
return stasis_cp_all_topic_cached(bridge_cache_all);
|
|
|
|
}
|
2013-05-21 18:00:22 +00:00
|
|
|
|
2013-08-01 13:49:34 +00:00
|
|
|
int bridge_topics_init(struct ast_bridge *bridge)
|
|
|
|
{
|
|
|
|
if (ast_strlen_zero(bridge->uniqueid)) {
|
|
|
|
ast_log(LOG_ERROR, "Bridge id initialization required\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
bridge->topics = stasis_cp_single_create(bridge_cache_all,
|
|
|
|
bridge->uniqueid);
|
|
|
|
if (!bridge->topics) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct stasis_topic *ast_bridge_topic(struct ast_bridge *bridge)
|
|
|
|
{
|
|
|
|
if (!bridge) {
|
|
|
|
return ast_bridge_topic_all();
|
|
|
|
}
|
|
|
|
|
|
|
|
return stasis_cp_single_topic(bridge->topics);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct stasis_topic *ast_bridge_topic_cached(struct ast_bridge *bridge)
|
|
|
|
{
|
|
|
|
if (!bridge) {
|
|
|
|
return ast_bridge_topic_all_cached();
|
|
|
|
}
|
|
|
|
|
|
|
|
return stasis_cp_single_topic_cached(bridge->topics);
|
|
|
|
}
|
2013-05-21 18:00:22 +00:00
|
|
|
|
|
|
|
/*! \brief Destructor for bridge snapshots */
|
|
|
|
static void bridge_snapshot_dtor(void *obj)
|
|
|
|
{
|
|
|
|
struct ast_bridge_snapshot *snapshot = obj;
|
|
|
|
ast_string_field_free_memory(snapshot);
|
|
|
|
ao2_cleanup(snapshot->channels);
|
|
|
|
snapshot->channels = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct ast_bridge_snapshot *ast_bridge_snapshot_create(struct ast_bridge *bridge)
|
|
|
|
{
|
2018-01-09 17:16:58 +00:00
|
|
|
struct ast_bridge_snapshot *snapshot;
|
2013-05-21 18:00:22 +00:00
|
|
|
struct ast_bridge_channel *bridge_channel;
|
|
|
|
|
2016-05-09 19:27:53 +00:00
|
|
|
if (ast_test_flag(&bridge->feature_flags, AST_BRIDGE_FLAG_INVISIBLE)) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2015-03-10 23:09:49 +00:00
|
|
|
snapshot = ao2_alloc_options(sizeof(*snapshot), bridge_snapshot_dtor,
|
|
|
|
AO2_ALLOC_OPT_LOCK_NOLOCK);
|
2016-11-08 16:11:41 +00:00
|
|
|
if (!snapshot) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2018-04-16 21:38:49 +00:00
|
|
|
if (ast_string_field_init(snapshot, 128)) {
|
2016-11-08 16:11:41 +00:00
|
|
|
ao2_ref(snapshot, -1);
|
2018-01-09 17:16:58 +00:00
|
|
|
|
2013-05-21 18:00:22 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
snapshot->channels = ast_str_container_alloc(SNAPSHOT_CHANNELS_BUCKETS);
|
|
|
|
if (!snapshot->channels) {
|
2018-01-09 17:16:58 +00:00
|
|
|
ao2_ref(snapshot, -1);
|
|
|
|
|
2013-05-21 18:00:22 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
AST_LIST_TRAVERSE(&bridge->channels, bridge_channel, entry) {
|
|
|
|
if (ast_str_container_add(snapshot->channels,
|
|
|
|
ast_channel_uniqueid(bridge_channel->chan))) {
|
2018-01-09 17:16:58 +00:00
|
|
|
ao2_ref(snapshot, -1);
|
|
|
|
|
2013-05-21 18:00:22 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_string_field_set(snapshot, uniqueid, bridge->uniqueid);
|
|
|
|
ast_string_field_set(snapshot, technology, bridge->technology->name);
|
2013-06-18 14:30:06 +00:00
|
|
|
ast_string_field_set(snapshot, subclass, bridge->v_table->name);
|
2013-12-17 23:25:49 +00:00
|
|
|
ast_string_field_set(snapshot, creator, bridge->creator);
|
|
|
|
ast_string_field_set(snapshot, name, bridge->name);
|
2013-05-21 18:00:22 +00:00
|
|
|
|
|
|
|
snapshot->feature_flags = bridge->feature_flags;
|
2013-06-13 13:15:56 +00:00
|
|
|
snapshot->capabilities = bridge->technology->capabilities;
|
2013-05-21 18:00:22 +00:00
|
|
|
snapshot->num_channels = bridge->num_channels;
|
|
|
|
snapshot->num_active = bridge->num_active;
|
2016-11-08 16:11:41 +00:00
|
|
|
snapshot->video_mode = bridge->softmix.video_mode.mode;
|
|
|
|
if (snapshot->video_mode == AST_BRIDGE_VIDEO_MODE_SINGLE_SRC
|
|
|
|
&& bridge->softmix.video_mode.mode_data.single_src_data.chan_vsrc) {
|
|
|
|
ast_string_field_set(snapshot, video_source_id,
|
|
|
|
ast_channel_uniqueid(bridge->softmix.video_mode.mode_data.single_src_data.chan_vsrc));
|
|
|
|
} else if (snapshot->video_mode == AST_BRIDGE_VIDEO_MODE_TALKER_SRC
|
|
|
|
&& bridge->softmix.video_mode.mode_data.talker_src_data.chan_vsrc) {
|
|
|
|
ast_string_field_set(snapshot, video_source_id,
|
|
|
|
ast_channel_uniqueid(bridge->softmix.video_mode.mode_data.talker_src_data.chan_vsrc));
|
|
|
|
}
|
2013-05-21 18:00:22 +00:00
|
|
|
|
|
|
|
return snapshot;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ast_bridge_publish_state(struct ast_bridge *bridge)
|
|
|
|
{
|
2018-01-09 17:16:58 +00:00
|
|
|
struct ast_bridge_snapshot *snapshot;
|
|
|
|
struct stasis_message *msg;
|
2013-05-21 18:00:22 +00:00
|
|
|
|
2014-08-06 12:55:28 +00:00
|
|
|
if (!ast_bridge_snapshot_type()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-05-21 18:00:22 +00:00
|
|
|
ast_assert(bridge != NULL);
|
|
|
|
|
|
|
|
snapshot = ast_bridge_snapshot_create(bridge);
|
|
|
|
if (!snapshot) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
msg = stasis_message_create(ast_bridge_snapshot_type(), snapshot);
|
2018-01-09 17:16:58 +00:00
|
|
|
ao2_ref(snapshot, -1);
|
2013-05-21 18:00:22 +00:00
|
|
|
if (!msg) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
stasis_publish(ast_bridge_topic(bridge), msg);
|
2018-01-09 17:16:58 +00:00
|
|
|
ao2_ref(msg, -1);
|
2013-05-21 18:00:22 +00:00
|
|
|
}
|
|
|
|
|
2013-08-01 13:49:34 +00:00
|
|
|
static void bridge_publish_state_from_blob(struct ast_bridge *bridge,
|
|
|
|
struct ast_bridge_blob *obj)
|
2013-05-21 18:00:22 +00:00
|
|
|
{
|
2018-01-09 17:16:58 +00:00
|
|
|
struct stasis_message *msg;
|
2013-05-21 18:00:22 +00:00
|
|
|
|
|
|
|
ast_assert(obj != NULL);
|
|
|
|
|
|
|
|
msg = stasis_message_create(ast_bridge_snapshot_type(), obj->bridge);
|
|
|
|
if (!msg) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-08-01 13:49:34 +00:00
|
|
|
stasis_publish(ast_bridge_topic(bridge), msg);
|
2018-01-09 17:16:58 +00:00
|
|
|
ao2_ref(msg, -1);
|
2013-05-21 18:00:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*! \brief Destructor for bridge merge messages */
|
|
|
|
static void bridge_merge_message_dtor(void *obj)
|
|
|
|
{
|
|
|
|
struct ast_bridge_merge_message *msg = obj;
|
|
|
|
|
|
|
|
ao2_cleanup(msg->to);
|
|
|
|
msg->to = NULL;
|
|
|
|
ao2_cleanup(msg->from);
|
|
|
|
msg->from = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*! \brief Bridge merge message creation helper */
|
|
|
|
static struct ast_bridge_merge_message *bridge_merge_message_create(struct ast_bridge *to, struct ast_bridge *from)
|
|
|
|
{
|
2018-01-09 17:16:58 +00:00
|
|
|
struct ast_bridge_merge_message *msg;
|
2013-05-21 18:00:22 +00:00
|
|
|
|
|
|
|
msg = ao2_alloc(sizeof(*msg), bridge_merge_message_dtor);
|
|
|
|
if (!msg) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
msg->to = ast_bridge_snapshot_create(to);
|
|
|
|
msg->from = ast_bridge_snapshot_create(from);
|
2018-01-09 17:16:58 +00:00
|
|
|
if (!msg->to || !msg->from) {
|
|
|
|
ao2_ref(msg, -1);
|
|
|
|
|
2013-05-21 18:00:22 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return msg;
|
|
|
|
}
|
|
|
|
|
2013-11-22 20:10:46 +00:00
|
|
|
static struct ast_json *ast_bridge_merge_message_to_json(
|
|
|
|
struct stasis_message *msg,
|
|
|
|
const struct stasis_message_sanitizer *sanitize)
|
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
|
|
|
{
|
2013-11-22 20:10:46 +00:00
|
|
|
struct ast_bridge_merge_message *merge = stasis_message_data(msg);
|
2018-01-09 17:16:58 +00:00
|
|
|
struct ast_json *json_bridge_to = ast_bridge_snapshot_to_json(merge->to, sanitize);
|
|
|
|
struct ast_json *json_bridge_from = ast_bridge_snapshot_to_json(merge->from, sanitize);
|
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
|
|
|
|
2013-11-22 20:10:46 +00:00
|
|
|
if (!json_bridge_to || !json_bridge_from) {
|
2018-01-09 17:16:58 +00:00
|
|
|
ast_json_unref(json_bridge_to);
|
|
|
|
ast_json_unref(json_bridge_from);
|
|
|
|
|
2013-11-22 20:10:46 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
|
|
|
|
2018-01-09 17:16:58 +00:00
|
|
|
return ast_json_pack("{s: s, s: o, s: o, s: o}",
|
2014-04-15 18:01:47 +00:00
|
|
|
"type", "BridgeMerged",
|
|
|
|
"timestamp", ast_json_timeval(*stasis_message_timestamp(msg), NULL),
|
|
|
|
"bridge", json_bridge_to,
|
|
|
|
"bridge_from", json_bridge_from);
|
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
|
|
|
}
|
|
|
|
|
2013-05-21 18:00:22 +00:00
|
|
|
void ast_bridge_publish_merge(struct ast_bridge *to, struct ast_bridge *from)
|
|
|
|
{
|
2018-01-09 17:16:58 +00:00
|
|
|
struct ast_bridge_merge_message *merge_msg;
|
|
|
|
struct stasis_message *msg;
|
2013-05-21 18:00:22 +00:00
|
|
|
|
2014-08-06 12:55:28 +00:00
|
|
|
if (!ast_bridge_merge_message_type()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-05-21 18:00:22 +00:00
|
|
|
ast_assert(to != NULL);
|
|
|
|
ast_assert(from != NULL);
|
2016-05-09 19:27:53 +00:00
|
|
|
ast_assert(ast_test_flag(&to->feature_flags, AST_BRIDGE_FLAG_INVISIBLE) == 0);
|
|
|
|
ast_assert(ast_test_flag(&from->feature_flags, AST_BRIDGE_FLAG_INVISIBLE) == 0);
|
2013-05-21 18:00:22 +00:00
|
|
|
|
|
|
|
merge_msg = bridge_merge_message_create(to, from);
|
|
|
|
if (!merge_msg) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
msg = stasis_message_create(ast_bridge_merge_message_type(), merge_msg);
|
2018-01-09 17:16:58 +00:00
|
|
|
ao2_ref(merge_msg, -1);
|
2013-05-21 18:00:22 +00:00
|
|
|
if (!msg) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
stasis_publish(ast_bridge_topic_all(), msg);
|
2018-01-09 17:16:58 +00:00
|
|
|
ao2_ref(msg, -1);
|
2013-05-21 18:00:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void bridge_blob_dtor(void *obj)
|
|
|
|
{
|
|
|
|
struct ast_bridge_blob *event = obj;
|
|
|
|
ao2_cleanup(event->bridge);
|
|
|
|
event->bridge = NULL;
|
|
|
|
ao2_cleanup(event->channel);
|
|
|
|
event->channel = NULL;
|
|
|
|
ast_json_unref(event->blob);
|
|
|
|
event->blob = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct stasis_message *ast_bridge_blob_create(
|
|
|
|
struct stasis_message_type *message_type,
|
|
|
|
struct ast_bridge *bridge,
|
|
|
|
struct ast_channel *chan,
|
|
|
|
struct ast_json *blob)
|
|
|
|
{
|
2018-01-09 17:16:58 +00:00
|
|
|
struct ast_bridge_blob *obj;
|
|
|
|
struct stasis_message *msg;
|
2013-05-21 18:00:22 +00:00
|
|
|
|
2014-08-06 12:55:28 +00:00
|
|
|
if (!message_type) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-05-21 18:00:22 +00:00
|
|
|
obj = ao2_alloc(sizeof(*obj), bridge_blob_dtor);
|
|
|
|
if (!obj) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (bridge) {
|
|
|
|
obj->bridge = ast_bridge_snapshot_create(bridge);
|
|
|
|
if (obj->bridge == NULL) {
|
2018-01-09 17:16:58 +00:00
|
|
|
ao2_ref(obj, -1);
|
|
|
|
|
2013-05-21 18:00:22 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (chan) {
|
stasis: Reduce creation of channel snapshots to improve performance
During some performance testing of Asterisk with AGI, ARI, and lots of Local
channels, we noticed that there's quite a hit in performance during channel
creation and releasing to the dialplan (ARI continue). After investigating
the performance spike that occurs during channel creation, we discovered
that we create a lot of channel snapshots that are technically unnecessary.
This includes creating snapshots during:
* AGI execution
* Returning objects for ARI commands
* During some Local channel operations
* During some dialling operations
* During variable setting
* During some bridging operations
And more.
This patch does the following:
- It removes a number of fields from channel snapshots. These fields were
rarely used, were expensive to have on the snapshot, and hurt performance.
This included formats, translation paths, Log Call ID, callgroup, pickup
group, and all channel variables. As a result, AMI Status,
"core show channel", "core show channelvar", and "pjsip show channel" were
modified to either hit the live channel or not show certain pieces of data.
While this is unfortunate, the performance gain from this patch is worth
the loss in behaviour.
- It adds a mechanism to publish a cached snapshot + blob. A large number of
publications were changed to use this, including:
- During Dial begin
- During Variable assignment (if no AMI variables are emitted - if AMI
variables are set, we have to make snapshots when a variable is changed)
- During channel pickup
- When a channel is put on hold/unhold
- When a DTMF digit is begun/ended
- When creating a bridge snapshot
- When an AOC event is raised
- During Local channel optimization/Local bridging
- When endpoint snapshots are generated
- All AGI events
- All ARI responses that return a channel
- Events in the AgentPool, MeetMe, and some in Queue
- Additionally, some extraneous channel snapshots were being made that were
unnecessary. These were removed.
- The result of ast_hashtab_hash_string is now cached in stasis_cache. This
reduces a large number of calls to ast_hashtab_hash_string, which reduced
the amount of time spent in this function in gprof by around 50%.
#ASTERISK-23811 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3568/
........
Merged revisions 416211 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-06-13 18:24:49 +00:00
|
|
|
obj->channel = ast_channel_snapshot_get_latest(ast_channel_uniqueid(chan));
|
2013-05-21 18:00:22 +00:00
|
|
|
if (obj->channel == NULL) {
|
2018-01-09 17:16:58 +00:00
|
|
|
ao2_ref(obj, -1);
|
|
|
|
|
2013-05-21 18:00:22 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (blob) {
|
|
|
|
obj->blob = ast_json_ref(blob);
|
|
|
|
}
|
|
|
|
|
|
|
|
msg = stasis_message_create(message_type, obj);
|
2018-01-09 17:16:58 +00:00
|
|
|
ao2_ref(obj, -1);
|
2013-05-21 18:00:22 +00:00
|
|
|
|
|
|
|
return msg;
|
|
|
|
}
|
|
|
|
|
2013-08-02 14:13:04 +00:00
|
|
|
void ast_bridge_publish_enter(struct ast_bridge *bridge, struct ast_channel *chan,
|
|
|
|
struct ast_channel *swap)
|
2013-05-21 18:00:22 +00:00
|
|
|
{
|
2018-01-09 17:16:58 +00:00
|
|
|
struct stasis_message *msg;
|
|
|
|
struct ast_json *blob = NULL;
|
2013-05-21 18:00:22 +00:00
|
|
|
|
2016-05-09 19:27:53 +00:00
|
|
|
if (ast_test_flag(&bridge->feature_flags, AST_BRIDGE_FLAG_INVISIBLE)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-08-02 14:13:04 +00:00
|
|
|
if (swap) {
|
|
|
|
blob = ast_json_pack("{s: s}", "swap", ast_channel_uniqueid(swap));
|
|
|
|
if (!blob) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
msg = ast_bridge_blob_create(ast_channel_entered_bridge_type(), bridge, chan, blob);
|
2018-01-09 17:16:58 +00:00
|
|
|
ast_json_unref(blob);
|
2013-05-21 18:00:22 +00:00
|
|
|
if (!msg) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* enter blob first, then state */
|
|
|
|
stasis_publish(ast_bridge_topic(bridge), msg);
|
2013-08-01 13:49:34 +00:00
|
|
|
bridge_publish_state_from_blob(bridge, stasis_message_data(msg));
|
2018-01-09 17:16:58 +00:00
|
|
|
ao2_ref(msg, -1);
|
2013-05-21 18:00:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void ast_bridge_publish_leave(struct ast_bridge *bridge, struct ast_channel *chan)
|
|
|
|
{
|
2018-01-09 17:16:58 +00:00
|
|
|
struct stasis_message *msg;
|
2013-05-21 18:00:22 +00:00
|
|
|
|
2016-05-09 19:27:53 +00:00
|
|
|
if (ast_test_flag(&bridge->feature_flags, AST_BRIDGE_FLAG_INVISIBLE)) {
|
|
|
|
return;
|
|
|
|
}
|
2013-05-21 18:00:22 +00:00
|
|
|
msg = ast_bridge_blob_create(ast_channel_left_bridge_type(), bridge, chan, NULL);
|
|
|
|
if (!msg) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* state first, then leave blob (opposite of enter, preserves nesting of events) */
|
2013-08-01 13:49:34 +00:00
|
|
|
bridge_publish_state_from_blob(bridge, stasis_message_data(msg));
|
2013-05-21 18:00:22 +00:00
|
|
|
stasis_publish(ast_bridge_topic(bridge), msg);
|
2018-01-09 17:16:58 +00:00
|
|
|
ao2_ref(msg, -1);
|
2013-05-21 18:00:22 +00:00
|
|
|
}
|
|
|
|
|
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
|
|
|
static struct ast_json *simple_bridge_channel_event(
|
2014-04-15 18:01:47 +00:00
|
|
|
const char *type,
|
|
|
|
struct ast_bridge_snapshot *bridge_snapshot,
|
|
|
|
struct ast_channel_snapshot *channel_snapshot,
|
|
|
|
const struct timeval *tv,
|
2013-11-22 20:10:46 +00:00
|
|
|
const struct stasis_message_sanitizer *sanitize)
|
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
|
|
|
{
|
2018-01-09 17:16:58 +00:00
|
|
|
struct ast_json *json_bridge = ast_bridge_snapshot_to_json(bridge_snapshot, sanitize);
|
|
|
|
struct ast_json *json_channel = ast_channel_snapshot_to_json(channel_snapshot, sanitize);
|
2013-11-22 20:10:46 +00:00
|
|
|
|
|
|
|
if (!json_bridge || !json_channel) {
|
2018-01-09 17:16:58 +00:00
|
|
|
ast_json_unref(json_bridge);
|
|
|
|
ast_json_unref(json_channel);
|
|
|
|
|
2013-11-22 20:10:46 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2018-01-09 17:16:58 +00:00
|
|
|
return ast_json_pack("{s: s, s: o, s: o, s: o}",
|
2014-04-15 18:01:47 +00:00
|
|
|
"type", type,
|
|
|
|
"timestamp", ast_json_timeval(*tv, NULL),
|
|
|
|
"bridge", json_bridge,
|
|
|
|
"channel", json_channel);
|
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
|
|
|
}
|
|
|
|
|
2013-11-22 20:10:46 +00:00
|
|
|
struct ast_json *ast_channel_entered_bridge_to_json(
|
|
|
|
struct stasis_message *msg,
|
|
|
|
const struct stasis_message_sanitizer *sanitize)
|
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
|
|
|
{
|
2014-04-15 18:01:47 +00:00
|
|
|
struct ast_bridge_blob *obj = stasis_message_data(msg);
|
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
|
|
|
|
|
|
|
return simple_bridge_channel_event("ChannelEnteredBridge", obj->bridge,
|
2014-04-15 18:01:47 +00:00
|
|
|
obj->channel, stasis_message_timestamp(msg), sanitize);
|
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
|
|
|
}
|
|
|
|
|
2013-11-22 20:10:46 +00:00
|
|
|
struct ast_json *ast_channel_left_bridge_to_json(
|
|
|
|
struct stasis_message *msg,
|
|
|
|
const struct stasis_message_sanitizer *sanitize)
|
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
|
|
|
{
|
2014-04-15 18:01:47 +00:00
|
|
|
struct ast_bridge_blob *obj = stasis_message_data(msg);
|
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
|
|
|
|
|
|
|
return simple_bridge_channel_event("ChannelLeftBridge", obj->bridge,
|
2014-04-15 18:01:47 +00:00
|
|
|
obj->channel, stasis_message_timestamp(msg), sanitize);
|
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
|
|
|
}
|
|
|
|
|
2013-11-22 20:10:46 +00:00
|
|
|
static struct ast_json *container_to_json_array(struct ao2_container *items,
|
|
|
|
const struct stasis_message_sanitizer *sanitize)
|
2013-06-18 14:30:06 +00:00
|
|
|
{
|
2018-01-09 17:16:58 +00:00
|
|
|
struct ast_json *json_items = ast_json_array_create();
|
2013-11-22 20:10:46 +00:00
|
|
|
char *item;
|
2013-06-18 14:30:06 +00:00
|
|
|
struct ao2_iterator it;
|
2018-01-09 17:16:58 +00:00
|
|
|
|
2013-06-18 14:30:06 +00:00
|
|
|
if (!json_items) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-11-22 20:10:46 +00:00
|
|
|
for (it = ao2_iterator_init(items, 0);
|
|
|
|
(item = ao2_iterator_next(&it)); ao2_cleanup(item)) {
|
|
|
|
if (sanitize && sanitize->channel_id && sanitize->channel_id(item)) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ast_json_array_append(json_items, ast_json_string_create(item))) {
|
|
|
|
ao2_cleanup(item);
|
2013-06-18 14:30:06 +00:00
|
|
|
ao2_iterator_destroy(&it);
|
2018-01-09 17:16:58 +00:00
|
|
|
ast_json_unref(json_items);
|
|
|
|
|
2013-06-18 14:30:06 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
ao2_iterator_destroy(&it);
|
|
|
|
|
2018-01-09 17:16:58 +00:00
|
|
|
return json_items;
|
2013-06-18 14:30:06 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static const char *capability2str(uint32_t capabilities)
|
|
|
|
{
|
|
|
|
if (capabilities & AST_BRIDGE_CAPABILITY_HOLDING) {
|
|
|
|
return "holding";
|
|
|
|
} else {
|
|
|
|
return "mixing";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-11-22 20:10:46 +00:00
|
|
|
struct ast_json *ast_bridge_snapshot_to_json(
|
|
|
|
const struct ast_bridge_snapshot *snapshot,
|
|
|
|
const struct stasis_message_sanitizer *sanitize)
|
2013-05-21 18:00:22 +00:00
|
|
|
{
|
2018-01-09 17:16:58 +00:00
|
|
|
struct ast_json *json_bridge;
|
2013-06-18 14:30:06 +00:00
|
|
|
struct ast_json *json_channels;
|
2013-05-21 18:00:22 +00:00
|
|
|
|
|
|
|
if (snapshot == NULL) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-11-22 20:10:46 +00:00
|
|
|
json_channels = container_to_json_array(snapshot->channels, sanitize);
|
2013-06-18 14:30:06 +00:00
|
|
|
if (!json_channels) {
|
|
|
|
return NULL;
|
|
|
|
}
|
2013-05-21 18:00:22 +00:00
|
|
|
|
2016-11-08 16:11:41 +00:00
|
|
|
json_bridge = ast_json_pack("{s: s, s: s, s: s, s: s, s: s, s: s, s: o, s: s}",
|
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", snapshot->uniqueid,
|
|
|
|
"technology", snapshot->technology,
|
|
|
|
"bridge_type", capability2str(snapshot->capabilities),
|
|
|
|
"bridge_class", snapshot->subclass,
|
2013-12-17 23:25:49 +00:00
|
|
|
"creator", snapshot->creator,
|
|
|
|
"name", snapshot->name,
|
2016-11-08 16:11:41 +00:00
|
|
|
"channels", json_channels,
|
|
|
|
"video_mode", ast_bridge_video_mode_to_string(snapshot->video_mode));
|
2013-06-18 14:30:06 +00:00
|
|
|
if (!json_bridge) {
|
|
|
|
return NULL;
|
|
|
|
}
|
2013-05-21 18:00:22 +00:00
|
|
|
|
2016-11-08 16:11:41 +00:00
|
|
|
if (snapshot->video_mode != AST_BRIDGE_VIDEO_MODE_NONE
|
|
|
|
&& !ast_strlen_zero(snapshot->video_source_id)) {
|
|
|
|
ast_json_object_set(json_bridge, "video_source_id",
|
|
|
|
ast_json_string_create(snapshot->video_source_id));
|
|
|
|
}
|
|
|
|
|
2018-01-09 17:16:58 +00:00
|
|
|
return json_bridge;
|
2013-05-21 18:00:22 +00:00
|
|
|
}
|
|
|
|
|
2013-06-28 18:42:24 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Allocate the fields of an \ref ast_bridge_channel_snapshot_pair.
|
|
|
|
*
|
|
|
|
* \param pair A bridge and channel to get snapshots of
|
|
|
|
* \param[out] snapshot_pair An allocated snapshot pair.
|
|
|
|
* \retval 0 Success
|
|
|
|
* \retval non-zero Failure
|
|
|
|
*/
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
static int bridge_channel_snapshot_pair_init(struct ast_channel *channel, struct ast_bridge *bridge,
|
|
|
|
struct ast_bridge_channel_snapshot_pair *snapshot_pair)
|
2013-06-28 18:42:24 +00:00
|
|
|
{
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
if (bridge) {
|
|
|
|
ast_bridge_lock(bridge);
|
|
|
|
snapshot_pair->bridge_snapshot = ast_bridge_snapshot_create(bridge);
|
|
|
|
ast_bridge_unlock(bridge);
|
2013-06-28 18:42:24 +00:00
|
|
|
if (!snapshot_pair->bridge_snapshot) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
snapshot_pair->channel_snapshot = ast_channel_snapshot_get_latest(ast_channel_uniqueid(channel));
|
2013-06-28 18:42:24 +00:00
|
|
|
if (!snapshot_pair->channel_snapshot) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Free the fields of an \ref ast_bridge_channel_snapshot_pair.
|
|
|
|
*
|
|
|
|
* \param pair The snapshot pair whose fields are to be cleaned up
|
|
|
|
*/
|
|
|
|
static void bridge_channel_snapshot_pair_cleanup(struct ast_bridge_channel_snapshot_pair *pair)
|
|
|
|
{
|
|
|
|
ao2_cleanup(pair->bridge_snapshot);
|
|
|
|
ao2_cleanup(pair->channel_snapshot);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const char *result_strs[] = {
|
|
|
|
[AST_BRIDGE_TRANSFER_FAIL] = "Fail",
|
|
|
|
[AST_BRIDGE_TRANSFER_INVALID] = "Invalid",
|
|
|
|
[AST_BRIDGE_TRANSFER_NOT_PERMITTED] = "Not Permitted",
|
|
|
|
[AST_BRIDGE_TRANSFER_SUCCESS] = "Success",
|
|
|
|
};
|
|
|
|
|
2014-02-01 16:26:57 +00:00
|
|
|
static struct ast_json *blind_transfer_to_json(struct stasis_message *msg,
|
|
|
|
const struct stasis_message_sanitizer *sanitize)
|
|
|
|
{
|
2014-08-07 15:30:19 +00:00
|
|
|
struct ast_blind_transfer_message *transfer_msg = stasis_message_data(msg);
|
2014-08-20 13:06:33 +00:00
|
|
|
struct ast_json *json_transferer;
|
|
|
|
struct ast_json *json_transferee = NULL;
|
|
|
|
struct ast_json *out;
|
|
|
|
struct ast_json *json_replace = NULL;
|
2014-02-01 16:26:57 +00:00
|
|
|
const struct timeval *tv = stasis_message_timestamp(msg);
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
json_transferer = ast_channel_snapshot_to_json(transfer_msg->transferer, sanitize);
|
2014-08-07 15:30:19 +00:00
|
|
|
if (!json_transferer) {
|
2014-02-01 16:26:57 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2014-08-07 15:30:19 +00:00
|
|
|
if (transfer_msg->transferee) {
|
|
|
|
json_transferee = ast_channel_snapshot_to_json(transfer_msg->transferee, sanitize);
|
|
|
|
if (!json_transferee) {
|
2014-08-20 13:06:33 +00:00
|
|
|
ast_json_unref(json_transferer);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (transfer_msg->replace_channel) {
|
|
|
|
json_replace = ast_channel_snapshot_to_json(transfer_msg->replace_channel, sanitize);
|
|
|
|
if (!json_replace) {
|
|
|
|
ast_json_unref(json_transferee);
|
|
|
|
ast_json_unref(json_transferer);
|
2014-08-07 15:30:19 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-08-07 21:17:05 +00:00
|
|
|
out = ast_json_pack("{s: s, s: o, s: o, s: s, s: s, s: s, s: o}",
|
2014-02-01 16:26:57 +00:00
|
|
|
"type", "BridgeBlindTransfer",
|
|
|
|
"timestamp", ast_json_timeval(*tv, NULL),
|
2014-08-07 21:17:05 +00:00
|
|
|
"channel", json_transferer,
|
2014-08-07 15:30:19 +00:00
|
|
|
"exten", transfer_msg->exten,
|
|
|
|
"context", transfer_msg->context,
|
|
|
|
"result", result_strs[transfer_msg->result],
|
|
|
|
"is_external", ast_json_boolean(transfer_msg->is_external));
|
2014-02-01 16:26:57 +00:00
|
|
|
|
|
|
|
if (!out) {
|
2014-08-20 13:06:33 +00:00
|
|
|
ast_json_unref(json_transferee);
|
|
|
|
ast_json_unref(json_replace);
|
2014-02-01 16:26:57 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2014-08-07 20:24:15 +00:00
|
|
|
if (json_transferee && ast_json_object_set(out, "transferee", json_transferee)) {
|
2014-08-20 13:06:33 +00:00
|
|
|
ast_json_unref(out);
|
|
|
|
ast_json_unref(json_replace);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (json_replace && ast_json_object_set(out, "replace_channel", json_replace)) {
|
2014-08-07 20:24:15 +00:00
|
|
|
ast_json_unref(out);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
if (transfer_msg->bridge) {
|
2014-08-07 15:30:19 +00:00
|
|
|
struct ast_json *json_bridge = ast_bridge_snapshot_to_json(
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
transfer_msg->bridge, sanitize);
|
2014-02-01 16:26:57 +00:00
|
|
|
|
|
|
|
if (!json_bridge || ast_json_object_set(out, "bridge", json_bridge)) {
|
|
|
|
ast_json_unref(out);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return out;
|
|
|
|
}
|
|
|
|
|
2013-06-28 18:42:24 +00:00
|
|
|
static struct ast_manager_event_blob *blind_transfer_to_ami(struct stasis_message *msg)
|
|
|
|
{
|
2014-08-07 15:30:19 +00:00
|
|
|
RAII_VAR(struct ast_str *, transferer_state, NULL, ast_free_ptr);
|
2013-06-28 18:42:24 +00:00
|
|
|
RAII_VAR(struct ast_str *, bridge_state, NULL, ast_free_ptr);
|
2014-08-07 15:30:19 +00:00
|
|
|
RAII_VAR(struct ast_str *, transferee_state, NULL, ast_free_ptr);
|
|
|
|
struct ast_blind_transfer_message *transfer_msg = stasis_message_data(msg);
|
2013-06-28 18:42:24 +00:00
|
|
|
|
2014-08-07 15:30:19 +00:00
|
|
|
if (!transfer_msg) {
|
2013-06-28 18:42:24 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2014-08-07 15:30:19 +00:00
|
|
|
transferer_state = ast_manager_build_channel_state_string_prefix(
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
transfer_msg->transferer, "Transferer");
|
2014-08-07 15:30:19 +00:00
|
|
|
if (!transferer_state) {
|
2013-06-28 18:42:24 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
if (transfer_msg->bridge) {
|
|
|
|
bridge_state = ast_manager_build_bridge_state_string(transfer_msg->bridge);
|
2013-08-29 15:43:23 +00:00
|
|
|
if (!bridge_state) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-08-07 15:30:19 +00:00
|
|
|
if (transfer_msg->transferee) {
|
|
|
|
transferee_state = ast_manager_build_channel_state_string_prefix(
|
|
|
|
transfer_msg->transferee, "Transferee");
|
|
|
|
if (!transferee_state) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
2013-06-28 18:42:24 +00:00
|
|
|
|
|
|
|
return ast_manager_event_blob_create(EVENT_FLAG_CALL, "BlindTransfer",
|
|
|
|
"Result: %s\r\n"
|
|
|
|
"%s"
|
|
|
|
"%s"
|
2014-08-07 15:30:19 +00:00
|
|
|
"%s"
|
2013-06-28 18:42:24 +00:00
|
|
|
"IsExternal: %s\r\n"
|
|
|
|
"Context: %s\r\n"
|
|
|
|
"Extension: %s\r\n",
|
2014-08-07 15:30:19 +00:00
|
|
|
result_strs[transfer_msg->result],
|
|
|
|
ast_str_buffer(transferer_state),
|
|
|
|
transferee_state ? ast_str_buffer(transferee_state) : "",
|
2013-08-29 15:43:23 +00:00
|
|
|
bridge_state ? ast_str_buffer(bridge_state) : "",
|
2014-08-07 15:30:19 +00:00
|
|
|
transfer_msg->is_external ? "Yes" : "No",
|
|
|
|
transfer_msg->context,
|
|
|
|
transfer_msg->exten);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void blind_transfer_dtor(void *obj)
|
|
|
|
{
|
|
|
|
struct ast_blind_transfer_message *msg = obj;
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
ao2_cleanup(msg->transferer);
|
|
|
|
ao2_cleanup(msg->bridge);
|
2014-08-07 15:30:19 +00:00
|
|
|
ao2_cleanup(msg->transferee);
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
ao2_cleanup(msg->replace_channel);
|
2013-06-28 18:42:24 +00:00
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
struct ast_blind_transfer_message *ast_blind_transfer_message_create(int is_external,
|
|
|
|
struct ast_channel *transferer, const char *exten, const char *context)
|
2013-06-28 18:42:24 +00:00
|
|
|
{
|
2014-08-07 15:30:19 +00:00
|
|
|
struct ast_blind_transfer_message *msg;
|
2013-06-28 18:42:24 +00:00
|
|
|
|
2014-08-07 15:30:19 +00:00
|
|
|
msg = ao2_alloc(sizeof(*msg), blind_transfer_dtor);
|
|
|
|
if (!msg) {
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
return NULL;
|
2014-08-07 15:30:19 +00:00
|
|
|
}
|
2013-06-28 18:42:24 +00:00
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
msg->transferer = ast_channel_snapshot_get_latest(ast_channel_uniqueid(transferer));
|
|
|
|
if (!msg->transferer) {
|
2014-08-07 15:30:19 +00:00
|
|
|
ao2_cleanup(msg);
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
return NULL;
|
2013-06-28 18:42:24 +00:00
|
|
|
}
|
|
|
|
|
2014-08-07 15:30:19 +00:00
|
|
|
msg->is_external = is_external;
|
|
|
|
ast_copy_string(msg->context, context, sizeof(msg->context));
|
|
|
|
ast_copy_string(msg->exten, exten, sizeof(msg->exten));
|
2013-06-28 18:42:24 +00:00
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
return msg;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void ast_bridge_publish_blind_transfer(struct ast_blind_transfer_message *transfer_message)
|
|
|
|
{
|
|
|
|
struct stasis_message *stasis;
|
|
|
|
|
|
|
|
stasis = stasis_message_create(ast_blind_transfer_type(), transfer_message);
|
2014-08-07 15:30:19 +00:00
|
|
|
if (!stasis) {
|
2013-06-28 18:42:24 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-08-07 15:30:19 +00:00
|
|
|
stasis_publish(ast_bridge_topic_all(), stasis);
|
|
|
|
|
|
|
|
ao2_cleanup(stasis);
|
2013-06-28 18:42:24 +00:00
|
|
|
}
|
|
|
|
|
2014-02-01 16:26:57 +00:00
|
|
|
static struct ast_json *attended_transfer_to_json(struct stasis_message *msg,
|
|
|
|
const struct stasis_message_sanitizer *sanitize)
|
|
|
|
{
|
|
|
|
struct ast_attended_transfer_message *transfer_msg = stasis_message_data(msg);
|
|
|
|
RAII_VAR(struct ast_json *, out, NULL, ast_json_unref);
|
2014-08-07 20:24:15 +00:00
|
|
|
struct ast_json *json_transferer1, *json_transferer2, *json_bridge, *json_channel;
|
|
|
|
struct ast_json *json_transferee = NULL, *json_target = NULL;
|
2014-02-01 16:26:57 +00:00
|
|
|
const struct timeval *tv = stasis_message_timestamp(msg);
|
|
|
|
int res = 0;
|
|
|
|
|
|
|
|
json_transferer1 = ast_channel_snapshot_to_json(transfer_msg->to_transferee.channel_snapshot, sanitize);
|
|
|
|
if (!json_transferer1) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
json_transferer2 = ast_channel_snapshot_to_json(transfer_msg->to_transfer_target.channel_snapshot, sanitize);
|
|
|
|
if (!json_transferer2) {
|
|
|
|
ast_json_unref(json_transferer1);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2014-08-07 15:30:19 +00:00
|
|
|
if (transfer_msg->transferee) {
|
|
|
|
json_transferee = ast_channel_snapshot_to_json(transfer_msg->transferee, sanitize);
|
2014-08-07 20:24:15 +00:00
|
|
|
if (!json_transferee) {
|
2017-11-03 23:08:37 +00:00
|
|
|
ast_json_unref(json_transferer2);
|
|
|
|
ast_json_unref(json_transferer1);
|
2014-08-07 20:24:15 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
2014-08-07 15:30:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (transfer_msg->target) {
|
|
|
|
json_target = ast_channel_snapshot_to_json(transfer_msg->target, sanitize);
|
2014-08-07 20:24:15 +00:00
|
|
|
if (!json_target) {
|
2017-11-03 23:08:37 +00:00
|
|
|
ast_json_unref(json_transferee);
|
|
|
|
ast_json_unref(json_transferer2);
|
|
|
|
ast_json_unref(json_transferer1);
|
2014-08-07 20:24:15 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
2014-08-07 15:30:19 +00:00
|
|
|
}
|
|
|
|
|
2014-08-07 20:24:15 +00:00
|
|
|
out = ast_json_pack("{s: s, s: o, s: o, s: o, s: s, s: o}",
|
2014-02-01 16:26:57 +00:00
|
|
|
"type", "BridgeAttendedTransfer",
|
|
|
|
"timestamp", ast_json_timeval(*tv, NULL),
|
|
|
|
"transferer_first_leg", json_transferer1,
|
|
|
|
"transferer_second_leg", json_transferer2,
|
|
|
|
"result", result_strs[transfer_msg->result],
|
|
|
|
"is_external", ast_json_boolean(transfer_msg->is_external));
|
|
|
|
if (!out) {
|
2017-11-03 23:08:37 +00:00
|
|
|
ast_json_unref(json_target);
|
|
|
|
ast_json_unref(json_transferee);
|
2014-02-01 16:26:57 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
2014-08-07 20:24:15 +00:00
|
|
|
if (json_transferee && ast_json_object_set(out, "transferee", json_transferee)) {
|
2017-11-03 23:08:37 +00:00
|
|
|
ast_json_unref(json_target);
|
2014-08-07 20:24:15 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
if (json_target && ast_json_object_set(out, "transfer_target", json_target)) {
|
|
|
|
return NULL;
|
|
|
|
}
|
2014-02-01 16:26:57 +00:00
|
|
|
|
|
|
|
if (transfer_msg->to_transferee.bridge_snapshot) {
|
|
|
|
json_bridge = ast_bridge_snapshot_to_json(transfer_msg->to_transferee.bridge_snapshot, sanitize);
|
|
|
|
|
|
|
|
if (!json_bridge) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
res |= ast_json_object_set(out, "transferer_first_leg_bridge", json_bridge);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (transfer_msg->to_transfer_target.bridge_snapshot) {
|
|
|
|
json_bridge = ast_bridge_snapshot_to_json(transfer_msg->to_transfer_target.bridge_snapshot, sanitize);
|
|
|
|
|
|
|
|
if (!json_bridge) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
res |= ast_json_object_set(out, "transferer_second_leg_bridge", json_bridge);
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (transfer_msg->dest_type) {
|
|
|
|
case AST_ATTENDED_TRANSFER_DEST_BRIDGE_MERGE:
|
|
|
|
res |= ast_json_object_set(out, "destination_type", ast_json_string_create("bridge"));
|
|
|
|
res |= ast_json_object_set(out, "destination_bridge", ast_json_string_create(transfer_msg->dest.bridge));
|
|
|
|
break;
|
2014-08-07 15:30:19 +00:00
|
|
|
case AST_ATTENDED_TRANSFER_DEST_LOCAL_APP:
|
|
|
|
res |= ast_json_object_set(out, "replace_channel", ast_channel_snapshot_to_json(transfer_msg->replace_channel, sanitize));
|
|
|
|
/* fallthrough */
|
2014-02-01 16:26:57 +00:00
|
|
|
case AST_ATTENDED_TRANSFER_DEST_APP:
|
|
|
|
res |= ast_json_object_set(out, "destination_type", ast_json_string_create("application"));
|
|
|
|
res |= ast_json_object_set(out, "destination_application", ast_json_string_create(transfer_msg->dest.app));
|
|
|
|
break;
|
|
|
|
case AST_ATTENDED_TRANSFER_DEST_LINK:
|
|
|
|
res |= ast_json_object_set(out, "destination_type", ast_json_string_create("link"));
|
|
|
|
|
|
|
|
json_channel = ast_channel_snapshot_to_json(transfer_msg->dest.links[0], sanitize);
|
|
|
|
if (!json_channel) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
res |= ast_json_object_set(out, "destination_link_first_leg", json_channel);
|
|
|
|
|
|
|
|
json_channel = ast_channel_snapshot_to_json(transfer_msg->dest.links[1], sanitize);
|
|
|
|
if (!json_channel) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
res |= ast_json_object_set(out, "destination_link_second_leg", json_channel);
|
|
|
|
|
|
|
|
break;
|
|
|
|
case AST_ATTENDED_TRANSFER_DEST_THREEWAY:
|
|
|
|
res |= ast_json_object_set(out, "destination_type", ast_json_string_create("threeway"));
|
|
|
|
|
|
|
|
json_channel = ast_channel_snapshot_to_json(transfer_msg->dest.threeway.channel_snapshot, sanitize);
|
|
|
|
if (!json_channel) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
res |= ast_json_object_set(out, "destination_threeway_channel", json_channel);
|
|
|
|
|
|
|
|
json_bridge = ast_bridge_snapshot_to_json(transfer_msg->dest.threeway.bridge_snapshot, sanitize);
|
|
|
|
if (!json_bridge) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
res |= ast_json_object_set(out, "destination_threeway_bridge", json_bridge);
|
|
|
|
|
|
|
|
break;
|
|
|
|
case AST_ATTENDED_TRANSFER_DEST_FAIL:
|
|
|
|
res |= ast_json_object_set(out, "destination_type", ast_json_string_create("fail"));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (res) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ast_json_ref(out);
|
|
|
|
}
|
|
|
|
|
2013-06-28 18:42:24 +00:00
|
|
|
static struct ast_manager_event_blob *attended_transfer_to_ami(struct stasis_message *msg)
|
|
|
|
{
|
|
|
|
RAII_VAR(struct ast_str *, variable_data, ast_str_create(64), ast_free_ptr);
|
|
|
|
RAII_VAR(struct ast_str *, transferer1_state, NULL, ast_free_ptr);
|
|
|
|
RAII_VAR(struct ast_str *, bridge1_state, NULL, ast_free_ptr);
|
|
|
|
RAII_VAR(struct ast_str *, transferer2_state, NULL, ast_free_ptr);
|
|
|
|
RAII_VAR(struct ast_str *, bridge2_state, NULL, ast_free_ptr);
|
|
|
|
RAII_VAR(struct ast_str *, local1_state, NULL, ast_free_ptr);
|
|
|
|
RAII_VAR(struct ast_str *, local2_state, NULL, ast_free_ptr);
|
2014-08-07 15:30:19 +00:00
|
|
|
RAII_VAR(struct ast_str *, transferee_state, NULL, ast_free_ptr);
|
|
|
|
RAII_VAR(struct ast_str *, target_state, NULL, ast_free_ptr);
|
2013-06-28 18:42:24 +00:00
|
|
|
struct ast_attended_transfer_message *transfer_msg = stasis_message_data(msg);
|
|
|
|
|
|
|
|
if (!variable_data) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
transferer1_state = ast_manager_build_channel_state_string_prefix(transfer_msg->to_transferee.channel_snapshot, "OrigTransferer");
|
|
|
|
transferer2_state = ast_manager_build_channel_state_string_prefix(transfer_msg->to_transfer_target.channel_snapshot, "SecondTransferer");
|
|
|
|
if (!transferer1_state || !transferer2_state) {
|
|
|
|
return NULL;
|
|
|
|
}
|
2014-08-07 15:30:19 +00:00
|
|
|
if (transfer_msg->transferee) {
|
|
|
|
transferee_state = ast_manager_build_channel_state_string_prefix(transfer_msg->transferee, "Transferee");
|
|
|
|
if (!transferee_state) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (transfer_msg->target) {
|
|
|
|
target_state = ast_manager_build_channel_state_string_prefix(transfer_msg->target, "TransferTarget");
|
|
|
|
if (!target_state) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
2013-06-28 18:42:24 +00:00
|
|
|
|
|
|
|
if (transfer_msg->to_transferee.bridge_snapshot) {
|
2013-08-08 19:16:33 +00:00
|
|
|
bridge1_state = ast_manager_build_bridge_state_string_prefix(
|
|
|
|
transfer_msg->to_transferee.bridge_snapshot, "Orig");
|
2013-06-28 18:42:24 +00:00
|
|
|
if (!bridge1_state) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (transfer_msg->to_transfer_target.bridge_snapshot) {
|
2013-08-08 19:16:33 +00:00
|
|
|
bridge2_state = ast_manager_build_bridge_state_string_prefix(
|
|
|
|
transfer_msg->to_transfer_target.bridge_snapshot, "Second");
|
2013-06-28 18:42:24 +00:00
|
|
|
if (!bridge2_state) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (transfer_msg->dest_type) {
|
|
|
|
case AST_ATTENDED_TRANSFER_DEST_BRIDGE_MERGE:
|
|
|
|
ast_str_append(&variable_data, 0, "DestType: Bridge\r\n");
|
|
|
|
ast_str_append(&variable_data, 0, "DestBridgeUniqueid: %s\r\n", transfer_msg->dest.bridge);
|
|
|
|
break;
|
|
|
|
case AST_ATTENDED_TRANSFER_DEST_APP:
|
2014-08-07 15:30:19 +00:00
|
|
|
case AST_ATTENDED_TRANSFER_DEST_LOCAL_APP:
|
2013-06-28 18:42:24 +00:00
|
|
|
ast_str_append(&variable_data, 0, "DestType: App\r\n");
|
|
|
|
ast_str_append(&variable_data, 0, "DestApp: %s\r\n", transfer_msg->dest.app);
|
|
|
|
break;
|
|
|
|
case AST_ATTENDED_TRANSFER_DEST_LINK:
|
|
|
|
local1_state = ast_manager_build_channel_state_string_prefix(transfer_msg->dest.links[0], "LocalOne");
|
|
|
|
local2_state = ast_manager_build_channel_state_string_prefix(transfer_msg->dest.links[1], "LocalTwo");
|
|
|
|
if (!local1_state || !local2_state) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
ast_str_append(&variable_data, 0, "DestType: Link\r\n");
|
|
|
|
ast_str_append(&variable_data, 0, "%s", ast_str_buffer(local1_state));
|
|
|
|
ast_str_append(&variable_data, 0, "%s", ast_str_buffer(local2_state));
|
|
|
|
break;
|
2013-07-23 15:28:11 +00:00
|
|
|
case AST_ATTENDED_TRANSFER_DEST_THREEWAY:
|
|
|
|
ast_str_append(&variable_data, 0, "DestType: Threeway\r\n");
|
|
|
|
ast_str_append(&variable_data, 0, "DestBridgeUniqueid: %s\r\n", transfer_msg->dest.threeway.bridge_snapshot->uniqueid);
|
|
|
|
ast_str_append(&variable_data, 0, "DestTransfererChannel: %s\r\n", transfer_msg->dest.threeway.channel_snapshot->name);
|
|
|
|
break;
|
2013-06-28 18:42:24 +00:00
|
|
|
case AST_ATTENDED_TRANSFER_DEST_FAIL:
|
|
|
|
ast_str_append(&variable_data, 0, "DestType: Fail\r\n");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ast_manager_event_blob_create(EVENT_FLAG_CALL, "AttendedTransfer",
|
|
|
|
"Result: %s\r\n"
|
|
|
|
"%s"
|
|
|
|
"%s"
|
|
|
|
"%s"
|
|
|
|
"%s"
|
2014-08-07 15:30:19 +00:00
|
|
|
"%s"
|
|
|
|
"%s"
|
2013-06-28 18:42:24 +00:00
|
|
|
"IsExternal: %s\r\n"
|
2013-08-08 20:51:38 +00:00
|
|
|
"%s",
|
2013-06-28 18:42:24 +00:00
|
|
|
result_strs[transfer_msg->result],
|
|
|
|
ast_str_buffer(transferer1_state),
|
|
|
|
bridge1_state ? ast_str_buffer(bridge1_state) : "",
|
|
|
|
ast_str_buffer(transferer2_state),
|
|
|
|
bridge2_state ? ast_str_buffer(bridge2_state) : "",
|
2014-08-07 15:30:19 +00:00
|
|
|
transferee_state ? ast_str_buffer(transferee_state) : "",
|
|
|
|
target_state ? ast_str_buffer(target_state) : "",
|
2013-06-28 18:42:24 +00:00
|
|
|
transfer_msg->is_external ? "Yes" : "No",
|
|
|
|
ast_str_buffer(variable_data));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void attended_transfer_dtor(void *obj)
|
|
|
|
{
|
|
|
|
struct ast_attended_transfer_message *msg = obj;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
bridge_channel_snapshot_pair_cleanup(&msg->to_transferee);
|
|
|
|
bridge_channel_snapshot_pair_cleanup(&msg->to_transfer_target);
|
2014-08-07 15:30:19 +00:00
|
|
|
ao2_cleanup(msg->replace_channel);
|
|
|
|
ao2_cleanup(msg->transferee);
|
|
|
|
ao2_cleanup(msg->target);
|
2013-06-28 18:42:24 +00:00
|
|
|
|
|
|
|
if (msg->dest_type != AST_ATTENDED_TRANSFER_DEST_LINK) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_LEN(msg->dest.links); ++i) {
|
|
|
|
ao2_cleanup(msg->dest.links[i]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
struct ast_attended_transfer_message *ast_attended_transfer_message_create(int is_external,
|
|
|
|
struct ast_channel *to_transferee, struct ast_bridge *transferee_bridge,
|
|
|
|
struct ast_channel *to_transfer_target, struct ast_bridge *target_bridge,
|
|
|
|
struct ast_channel *transferee, struct ast_channel *transfer_target)
|
2013-06-28 18:42:24 +00:00
|
|
|
{
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
struct ast_attended_transfer_message *transfer_msg;
|
2013-06-28 18:42:24 +00:00
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
transfer_msg = ao2_alloc(sizeof(*transfer_msg), attended_transfer_dtor);
|
|
|
|
if (!transfer_msg) {
|
2013-06-28 18:42:24 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
if (bridge_channel_snapshot_pair_init(to_transferee, transferee_bridge, &transfer_msg->to_transferee) ||
|
|
|
|
bridge_channel_snapshot_pair_init(to_transfer_target, target_bridge, &transfer_msg->to_transfer_target)) {
|
|
|
|
ao2_cleanup(transfer_msg);
|
2013-06-28 18:42:24 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
if (transferee) {
|
|
|
|
transfer_msg->transferee = ast_channel_snapshot_get_latest(ast_channel_uniqueid(transferee));
|
|
|
|
if (!transfer_msg->transferee) {
|
|
|
|
ao2_cleanup(transfer_msg);
|
2014-08-07 15:30:19 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
} else if (transferee_bridge) {
|
|
|
|
transferee = ast_bridge_peer(transferee_bridge, to_transferee);
|
|
|
|
if (transferee) {
|
|
|
|
transfer_msg->transferee = ast_channel_snapshot_get_latest(ast_channel_uniqueid(transferee));
|
|
|
|
ao2_cleanup(transferee);
|
|
|
|
if (!transfer_msg->transferee) {
|
|
|
|
ao2_cleanup(transfer_msg);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
2014-08-07 15:30:19 +00:00
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
if (transfer_target) {
|
|
|
|
transfer_msg->target = ast_channel_snapshot_get_latest(ast_channel_uniqueid(transfer_target));
|
|
|
|
if (!transfer_msg->target) {
|
|
|
|
ao2_cleanup(transfer_msg);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
} else if (target_bridge) {
|
|
|
|
transfer_target = ast_bridge_peer(target_bridge, to_transfer_target);
|
|
|
|
if (transfer_target) {
|
|
|
|
transfer_msg->target = ast_channel_snapshot_get_latest(ast_channel_uniqueid(transfer_target));
|
|
|
|
ao2_cleanup(transfer_target);
|
|
|
|
if (!transfer_msg->target) {
|
|
|
|
ao2_cleanup(transfer_msg);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
2013-06-28 18:42:24 +00:00
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
return transfer_msg;
|
2013-06-28 18:42:24 +00:00
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
int ast_attended_transfer_message_add_merge(struct ast_attended_transfer_message *transfer_msg,
|
|
|
|
struct ast_bridge *final_bridge)
|
2013-06-28 18:42:24 +00:00
|
|
|
{
|
|
|
|
transfer_msg->dest_type = AST_ATTENDED_TRANSFER_DEST_BRIDGE_MERGE;
|
|
|
|
ast_copy_string(transfer_msg->dest.bridge, final_bridge->uniqueid,
|
|
|
|
sizeof(transfer_msg->dest.bridge));
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
return 0;
|
2013-06-28 18:42:24 +00:00
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
int ast_attended_transfer_message_add_threeway(struct ast_attended_transfer_message *transfer_msg,
|
|
|
|
struct ast_channel *survivor_channel, struct ast_bridge *survivor_bridge)
|
2013-07-23 15:28:11 +00:00
|
|
|
{
|
|
|
|
transfer_msg->dest_type = AST_ATTENDED_TRANSFER_DEST_THREEWAY;
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
|
|
|
|
if (!strcmp(ast_channel_uniqueid(survivor_channel), transfer_msg->to_transferee.channel_snapshot->uniqueid)) {
|
2013-07-23 15:28:11 +00:00
|
|
|
transfer_msg->dest.threeway.channel_snapshot = transfer_msg->to_transferee.channel_snapshot;
|
|
|
|
} else {
|
|
|
|
transfer_msg->dest.threeway.channel_snapshot = transfer_msg->to_transfer_target.channel_snapshot;
|
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
if (!strcmp(survivor_bridge->uniqueid, transfer_msg->to_transferee.bridge_snapshot->uniqueid)) {
|
2013-07-23 15:28:11 +00:00
|
|
|
transfer_msg->dest.threeway.bridge_snapshot = transfer_msg->to_transferee.bridge_snapshot;
|
|
|
|
} else {
|
|
|
|
transfer_msg->dest.threeway.bridge_snapshot = transfer_msg->to_transfer_target.bridge_snapshot;
|
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
return 0;
|
2013-07-23 15:28:11 +00:00
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
int ast_attended_transfer_message_add_app(struct ast_attended_transfer_message *transfer_msg,
|
|
|
|
const char *app, struct ast_channel *replace_channel)
|
2013-06-28 18:42:24 +00:00
|
|
|
{
|
2014-08-07 15:30:19 +00:00
|
|
|
transfer_msg->dest_type = replace_channel ? AST_ATTENDED_TRANSFER_DEST_LOCAL_APP : AST_ATTENDED_TRANSFER_DEST_APP;
|
2013-06-28 18:42:24 +00:00
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
if (replace_channel) {
|
|
|
|
transfer_msg->replace_channel = ast_channel_snapshot_get_latest(ast_channel_uniqueid(replace_channel));
|
|
|
|
if (!transfer_msg->replace_channel) {
|
|
|
|
return -1;
|
|
|
|
}
|
2013-06-28 18:42:24 +00:00
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
ast_copy_string(transfer_msg->dest.app, app, sizeof(transfer_msg->dest.app));
|
|
|
|
|
|
|
|
return 0;
|
2013-06-28 18:42:24 +00:00
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
int ast_attended_transfer_message_add_link(struct ast_attended_transfer_message *transfer_msg,
|
|
|
|
struct ast_channel *locals[2])
|
2013-06-28 18:42:24 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
transfer_msg->dest_type = AST_ATTENDED_TRANSFER_DEST_LINK;
|
|
|
|
for (i = 0; i < 2; ++i) {
|
stasis: Reduce creation of channel snapshots to improve performance
During some performance testing of Asterisk with AGI, ARI, and lots of Local
channels, we noticed that there's quite a hit in performance during channel
creation and releasing to the dialplan (ARI continue). After investigating
the performance spike that occurs during channel creation, we discovered
that we create a lot of channel snapshots that are technically unnecessary.
This includes creating snapshots during:
* AGI execution
* Returning objects for ARI commands
* During some Local channel operations
* During some dialling operations
* During variable setting
* During some bridging operations
And more.
This patch does the following:
- It removes a number of fields from channel snapshots. These fields were
rarely used, were expensive to have on the snapshot, and hurt performance.
This included formats, translation paths, Log Call ID, callgroup, pickup
group, and all channel variables. As a result, AMI Status,
"core show channel", "core show channelvar", and "pjsip show channel" were
modified to either hit the live channel or not show certain pieces of data.
While this is unfortunate, the performance gain from this patch is worth
the loss in behaviour.
- It adds a mechanism to publish a cached snapshot + blob. A large number of
publications were changed to use this, including:
- During Dial begin
- During Variable assignment (if no AMI variables are emitted - if AMI
variables are set, we have to make snapshots when a variable is changed)
- During channel pickup
- When a channel is put on hold/unhold
- When a DTMF digit is begun/ended
- When creating a bridge snapshot
- When an AOC event is raised
- During Local channel optimization/Local bridging
- When endpoint snapshots are generated
- All AGI events
- All ARI responses that return a channel
- Events in the AgentPool, MeetMe, and some in Queue
- Additionally, some extraneous channel snapshots were being made that were
unnecessary. These were removed.
- The result of ast_hashtab_hash_string is now cached in stasis_cache. This
reduces a large number of calls to ast_hashtab_hash_string, which reduced
the amount of time spent in this function in gprof by around 50%.
#ASTERISK-23811 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3568/
........
Merged revisions 416211 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-06-13 18:24:49 +00:00
|
|
|
transfer_msg->dest.links[i] = ast_channel_snapshot_get_latest(ast_channel_uniqueid(locals[i]));
|
2013-06-28 18:42:24 +00:00
|
|
|
if (!transfer_msg->dest.links[i]) {
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
return -1;
|
2013-06-28 18:42:24 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ast_bridge_publish_attended_transfer(struct ast_attended_transfer_message *transfer_msg)
|
|
|
|
{
|
2018-01-09 17:16:58 +00:00
|
|
|
struct stasis_message *msg;
|
Fix race condition that could result in ARI transfer messages not being sent.
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14 15:28:42 +00:00
|
|
|
|
2013-06-28 18:42:24 +00:00
|
|
|
msg = stasis_message_create(ast_attended_transfer_type(), transfer_msg);
|
|
|
|
if (!msg) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
stasis_publish(ast_bridge_topic_all(), msg);
|
2018-01-09 17:16:58 +00:00
|
|
|
ao2_ref(msg, -1);
|
2013-06-28 18:42:24 +00:00
|
|
|
}
|
|
|
|
|
2013-06-10 13:07:11 +00:00
|
|
|
struct ast_bridge_snapshot *ast_bridge_snapshot_get_latest(const char *uniqueid)
|
|
|
|
{
|
2018-01-09 17:16:58 +00:00
|
|
|
struct stasis_message *message;
|
2013-06-10 13:07:11 +00:00
|
|
|
struct ast_bridge_snapshot *snapshot;
|
|
|
|
|
|
|
|
ast_assert(!ast_strlen_zero(uniqueid));
|
|
|
|
|
2013-08-01 13:49:34 +00:00
|
|
|
message = stasis_cache_get(ast_bridge_cache(),
|
2013-06-10 13:07:11 +00:00
|
|
|
ast_bridge_snapshot_type(),
|
|
|
|
uniqueid);
|
|
|
|
if (!message) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2018-01-09 17:16:58 +00:00
|
|
|
snapshot = ao2_bump(stasis_message_data(message));
|
|
|
|
ao2_ref(message, -1);
|
|
|
|
|
2013-06-10 13:07:11 +00:00
|
|
|
return snapshot;
|
|
|
|
}
|
|
|
|
|
2013-05-21 18:00:22 +00:00
|
|
|
/*! \brief snapshot ID getter for caching topic */
|
|
|
|
static const char *bridge_snapshot_get_id(struct stasis_message *msg)
|
|
|
|
{
|
|
|
|
struct ast_bridge_snapshot *snapshot;
|
|
|
|
if (stasis_message_type(msg) != ast_bridge_snapshot_type()) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
snapshot = stasis_message_data(msg);
|
|
|
|
return snapshot->uniqueid;
|
|
|
|
}
|
|
|
|
|
2013-08-01 13:49:34 +00:00
|
|
|
static void stasis_bridging_cleanup(void)
|
|
|
|
{
|
|
|
|
STASIS_MESSAGE_TYPE_CLEANUP(ast_bridge_snapshot_type);
|
|
|
|
STASIS_MESSAGE_TYPE_CLEANUP(ast_bridge_merge_message_type);
|
|
|
|
STASIS_MESSAGE_TYPE_CLEANUP(ast_channel_entered_bridge_type);
|
|
|
|
STASIS_MESSAGE_TYPE_CLEANUP(ast_channel_left_bridge_type);
|
|
|
|
STASIS_MESSAGE_TYPE_CLEANUP(ast_blind_transfer_type);
|
|
|
|
STASIS_MESSAGE_TYPE_CLEANUP(ast_attended_transfer_type);
|
|
|
|
|
|
|
|
ao2_cleanup(bridge_cache_all);
|
|
|
|
bridge_cache_all = NULL;
|
|
|
|
}
|
|
|
|
|
2013-05-21 18:00:22 +00:00
|
|
|
int ast_stasis_bridging_init(void)
|
|
|
|
{
|
2013-08-01 13:49:34 +00:00
|
|
|
int res = 0;
|
|
|
|
|
Avoid unnecessary cleanups during immediate shutdown
This patch addresses issues during immediate shutdowns, where modules
are not unloaded, but Asterisk atexit handlers are run.
In the typical case, this usually isn't a big deal. But the
introduction of the Stasis message bus makes it much more likely for
asynchronous activity to be happening off in some thread during
shutdown.
During an immediate shutdown, Asterisk skips unloading modules. But
while it is processing the atexit handlers, there is a window of time
where some of the core message types have been cleaned up, but the
message bus is still running. Specifically, it's still running
module subscriptions that might be using the core message types. If a
message is received by that subscription in that window, it will
attempt to use a message type that has been cleaned up.
To solve this problem, this patch introduces ast_register_cleanup().
This function operates identically to ast_register_atexit(), except
that cleanup calls are not invoked on an immediate shutdown. All of
the core message type and topic cleanup was moved from atexit handlers
to cleanup handlers.
This ensures that core type and topic cleanup only happens if the
modules that used them are first unloaded.
This patch also changes the ast_assert() when accessing a cleaned up
or uninitialized message type to an error log message. Message type
functions are actually NULL safe across the board, so the assert was a
bit heavy handed. Especially for anyone with DO_CRASH enabled.
Review: https://reviewboard.asterisk.org/r/2562/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390122 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-30 17:05:53 +00:00
|
|
|
ast_register_cleanup(stasis_bridging_cleanup);
|
|
|
|
|
2013-08-01 13:49:34 +00:00
|
|
|
bridge_cache_all = stasis_cp_all_create("ast_bridge_topic_all",
|
|
|
|
bridge_snapshot_get_id);
|
|
|
|
|
|
|
|
if (!bridge_cache_all) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
res |= STASIS_MESSAGE_TYPE_INIT(ast_bridge_snapshot_type);
|
|
|
|
res |= STASIS_MESSAGE_TYPE_INIT(ast_bridge_merge_message_type);
|
|
|
|
res |= STASIS_MESSAGE_TYPE_INIT(ast_channel_entered_bridge_type);
|
|
|
|
res |= STASIS_MESSAGE_TYPE_INIT(ast_channel_left_bridge_type);
|
|
|
|
res |= STASIS_MESSAGE_TYPE_INIT(ast_blind_transfer_type);
|
|
|
|
res |= STASIS_MESSAGE_TYPE_INIT(ast_attended_transfer_type);
|
|
|
|
|
|
|
|
return res;
|
2013-05-21 18:00:22 +00:00
|
|
|
}
|