2014-07-09 16:34:51 +00:00
|
|
|
/*
|
|
|
|
* Asterisk -- An open source telephony toolkit.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2014, Digium, Inc.
|
|
|
|
*
|
|
|
|
* Richard Mudgett <rmudgett@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 bridge subclass.
|
|
|
|
*
|
|
|
|
* \author Richard Mudgett <rmudgett@digium.com>
|
|
|
|
*
|
|
|
|
* See Also:
|
|
|
|
* \arg \ref AstCREDITS
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
#include "asterisk.h"
|
|
|
|
|
|
|
|
#include "asterisk/bridge.h"
|
2014-08-07 15:30:19 +00:00
|
|
|
#include "asterisk/bridge_after.h"
|
2014-07-09 16:34:51 +00:00
|
|
|
#include "asterisk/bridge_internal.h"
|
2014-08-07 15:30:19 +00:00
|
|
|
#include "asterisk/bridge_features.h"
|
|
|
|
#include "asterisk/stasis_app.h"
|
|
|
|
#include "asterisk/stasis_channels.h"
|
2014-07-09 16:34:51 +00:00
|
|
|
#include "stasis_bridge.h"
|
2014-08-07 15:30:19 +00:00
|
|
|
#include "control.h"
|
|
|
|
#include "command.h"
|
|
|
|
#include "app.h"
|
|
|
|
#include "asterisk/stasis_app.h"
|
|
|
|
#include "asterisk/pbx.h"
|
2014-07-09 16:34:51 +00:00
|
|
|
|
|
|
|
/* ------------------------------------------------------------------- */
|
|
|
|
|
2014-08-07 15:30:19 +00:00
|
|
|
static struct ast_bridge_methods bridge_stasis_v_table;
|
|
|
|
|
|
|
|
static void bridge_stasis_run_cb(struct ast_channel *chan, void *data)
|
|
|
|
{
|
|
|
|
RAII_VAR(char *, app_name, NULL, ast_free);
|
|
|
|
struct ast_app *app_stasis;
|
|
|
|
|
|
|
|
/* Take ownership of the swap_app memory from the datastore */
|
|
|
|
app_name = app_get_replace_channel_app(chan);
|
|
|
|
if (!app_name) {
|
|
|
|
ast_log(LOG_ERROR, "Failed to get app name for %s (%p)\n", ast_channel_name(chan), chan);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* find Stasis() */
|
|
|
|
app_stasis = pbx_findapp("Stasis");
|
|
|
|
if (!app_stasis) {
|
|
|
|
ast_log(LOG_WARNING, "Could not find application (Stasis)\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ast_check_hangup_locked(chan)) {
|
|
|
|
/* channel hungup, don't run Stasis() */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* run Stasis() */
|
|
|
|
pbx_exec(chan, app_stasis, app_name);
|
|
|
|
}
|
|
|
|
|
2016-04-15 14:36:59 -05:00
|
|
|
struct defer_bridge_add_obj {
|
|
|
|
/*! Bridge to join (has ref) */
|
|
|
|
struct ast_bridge *bridge;
|
|
|
|
/*!
|
|
|
|
* \brief Channel to swap with in the bridge. (has ref)
|
|
|
|
*
|
|
|
|
* \note NULL if not swapping with a channel.
|
|
|
|
*/
|
|
|
|
struct ast_channel *swap;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void defer_bridge_add_dtor(void *obj)
|
|
|
|
{
|
|
|
|
struct defer_bridge_add_obj *defer = obj;
|
|
|
|
|
|
|
|
ao2_cleanup(defer->bridge);
|
|
|
|
ast_channel_cleanup(defer->swap);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int defer_bridge_add(
|
2014-08-07 15:30:19 +00:00
|
|
|
struct stasis_app_control *control,
|
|
|
|
struct ast_channel *chan, void *obj)
|
|
|
|
{
|
2016-04-15 14:36:59 -05:00
|
|
|
struct defer_bridge_add_obj *defer = obj;
|
2014-08-07 15:30:19 +00:00
|
|
|
|
2016-04-15 14:36:59 -05:00
|
|
|
return control_swap_channel_in_bridge(control, defer->bridge, chan, defer->swap);
|
2014-08-07 15:30:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void bridge_stasis_queue_join_action(struct ast_bridge *self,
|
2016-04-15 14:36:59 -05:00
|
|
|
struct ast_bridge_channel *bridge_channel, struct ast_bridge_channel *swap)
|
2014-08-07 15:30:19 +00:00
|
|
|
{
|
2016-04-15 14:36:59 -05:00
|
|
|
struct defer_bridge_add_obj *defer;
|
|
|
|
|
|
|
|
defer = ao2_alloc_options(sizeof(*defer), defer_bridge_add_dtor,
|
|
|
|
AO2_ALLOC_OPT_LOCK_NOLOCK);
|
|
|
|
if (!defer) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
ao2_ref(self, +1);
|
|
|
|
defer->bridge = self;
|
|
|
|
if (swap) {
|
|
|
|
ast_channel_ref(swap->chan);
|
|
|
|
defer->swap = swap->chan;
|
|
|
|
}
|
|
|
|
|
2014-08-07 15:30:19 +00:00
|
|
|
ast_channel_lock(bridge_channel->chan);
|
2016-04-15 14:36:59 -05:00
|
|
|
command_prestart_queue_command(bridge_channel->chan, defer_bridge_add,
|
|
|
|
defer, __ao2_cleanup);
|
2014-08-07 15:30:19 +00:00
|
|
|
ast_channel_unlock(bridge_channel->chan);
|
|
|
|
}
|
|
|
|
|
2015-01-29 23:03:14 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Peek at channel before it is pushed into bridge
|
|
|
|
* \since 13.2.0
|
|
|
|
*
|
|
|
|
* \param self Bridge to operate upon.
|
|
|
|
* \param bridge_channel Bridge channel to push.
|
|
|
|
* \param swap Bridge channel to swap places with if not NULL.
|
|
|
|
*
|
|
|
|
* \note On entry, self is already locked.
|
|
|
|
*
|
|
|
|
* \retval 0 on success.
|
|
|
|
* \retval -1 on failure. The channel should not be pushed.
|
|
|
|
*/
|
|
|
|
static int bridge_stasis_push_peek(struct ast_bridge *self, struct ast_bridge_channel *bridge_channel, struct ast_bridge_channel *swap)
|
|
|
|
{
|
|
|
|
struct stasis_app_control *swap_control;
|
|
|
|
struct ast_channel_snapshot *to_be_replaced;
|
|
|
|
|
|
|
|
if (!swap) {
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
|
|
|
swap_control = stasis_app_control_find_by_channel(swap->chan);
|
|
|
|
if (!swap_control) {
|
|
|
|
ast_log(LOG_ERROR,"Failed to find stasis app control for swapped channel %s\n", ast_channel_name(swap->chan));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
to_be_replaced = ast_channel_snapshot_get_latest(ast_channel_uniqueid(swap->chan));
|
|
|
|
|
2017-01-19 08:05:36 -07:00
|
|
|
ast_debug(3, "Copying stasis app name %s from %s to %s\n", stasis_app_name(control_app(swap_control)),
|
2015-01-29 23:03:14 +00:00
|
|
|
ast_channel_name(swap->chan), ast_channel_name(bridge_channel->chan));
|
|
|
|
|
|
|
|
ast_channel_lock(bridge_channel->chan);
|
|
|
|
|
|
|
|
/* copy the app name from the swap channel */
|
2017-01-19 08:05:36 -07:00
|
|
|
app_set_replace_channel_app(bridge_channel->chan, stasis_app_name(control_app(swap_control)));
|
2015-01-29 23:03:14 +00:00
|
|
|
|
|
|
|
/* set the replace channel snapshot */
|
|
|
|
app_set_replace_channel_snapshot(bridge_channel->chan, to_be_replaced);
|
|
|
|
|
|
|
|
ast_channel_unlock(bridge_channel->chan);
|
|
|
|
|
|
|
|
ao2_ref(swap_control, -1);
|
|
|
|
ao2_cleanup(to_be_replaced);
|
|
|
|
|
|
|
|
done:
|
|
|
|
return ast_bridge_base_v_table.push_peek(self, bridge_channel, swap);
|
|
|
|
}
|
|
|
|
|
2014-07-09 16:34:51 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Push this channel into the Stasis bridge.
|
|
|
|
* \since 12.5.0
|
|
|
|
*
|
|
|
|
* \param self Bridge to operate upon.
|
|
|
|
* \param bridge_channel Bridge channel to push.
|
|
|
|
* \param swap Bridge channel to swap places with if not NULL.
|
|
|
|
*
|
|
|
|
* \note On entry, self is already locked.
|
|
|
|
*
|
|
|
|
* \retval 0 on success.
|
|
|
|
* \retval -1 on failure. The channel did not get pushed.
|
|
|
|
*/
|
|
|
|
static int bridge_stasis_push(struct ast_bridge *self, struct ast_bridge_channel *bridge_channel, struct ast_bridge_channel *swap)
|
|
|
|
{
|
2014-08-07 15:30:19 +00:00
|
|
|
struct stasis_app_control *control = stasis_app_control_find_by_channel(bridge_channel->chan);
|
|
|
|
|
2014-08-11 18:38:15 +00:00
|
|
|
if (!control && !stasis_app_channel_is_internal(bridge_channel->chan)) {
|
2014-08-07 15:30:19 +00:00
|
|
|
/* channel not in Stasis(), get it there */
|
2016-04-15 16:51:58 -05:00
|
|
|
ast_debug(1, "Bridge %s: pushing non-stasis %p(%s) setup to come back in under stasis\n",
|
|
|
|
self->uniqueid, bridge_channel, ast_channel_name(bridge_channel->chan));
|
|
|
|
|
2014-08-07 15:30:19 +00:00
|
|
|
/* Attach after-bridge callback and pass ownership of swap_app to it */
|
|
|
|
if (ast_bridge_set_after_callback(bridge_channel->chan,
|
|
|
|
bridge_stasis_run_cb, NULL, NULL)) {
|
2016-04-15 16:51:58 -05:00
|
|
|
ast_log(LOG_ERROR,
|
|
|
|
"Failed to set after bridge callback for bridge %s non-stasis push of %s\n",
|
|
|
|
self->uniqueid, ast_channel_name(bridge_channel->chan));
|
2014-08-07 15:30:19 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2016-04-15 14:36:59 -05:00
|
|
|
bridge_stasis_queue_join_action(self, bridge_channel, swap);
|
2014-08-07 15:30:19 +00:00
|
|
|
|
2015-01-22 18:10:13 +00:00
|
|
|
/* Return -1 so the push fails and the after-bridge callback gets called
|
|
|
|
* This keeps the bridging framework from putting the channel into the bridge
|
|
|
|
* until the Stasis thread gets started, and then the channel is put into the bridge.
|
|
|
|
*/
|
2014-08-07 15:30:19 +00:00
|
|
|
return -1;
|
|
|
|
}
|
2017-01-13 19:08:53 -06:00
|
|
|
ao2_cleanup(control);
|
2014-08-07 15:30:19 +00:00
|
|
|
|
res_stasis: Don't play MoH to channels by default when added to holding bridges
When ARI manipulates a bridge, it generally doesn't care what the mixing
technology is. Operations on a bridge initiated through ARI should perform
their action in generally the same way, regardless of the bridge's mixing
technology. While the mixing technology may determine how media flows to
channels, the actual operations on a bridge themselves should be the same.
Currently, this isn't the case with holding bridges. When a channel joins
without a role, MoH is started on that channel automatically. Subsequent bridge
operations that would stop MoH would fail (as there is no Announcer channel
playing MoH to the bridge). Starting MoH on the bridge will also create two
MoH streams: one from the MoH being played on the participant channel, and one
from the announcer channel. From the perspective of ARI users, this is
counter-intuitive - I would not expect MoH to be started for me. The mixing
technology determines how media is shared between participants, not the
application experience.
This patch does the following:
* The Stasis bridge class now inspects channels as they are going into a
bridge. If the bridge has a holding capability, and the channel has no
roles, we give it a participant role and mark the default behaviour to have
no entertainment. This allows addChannel operations to continue to set a
participant role with an entertainment option if it felt like it (or could
do it).
* The music on hold channel is now Stasis approved (tm)
Review: https://reviewboard.asterisk.org/r/3929/
ASTERISK-24264 #close
Reported by: Samuel Galarneau
Tested by: Samuel Galarneau
........
Merged revisions 422503 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422504 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422505 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-09-01 14:15:32 +00:00
|
|
|
/*
|
|
|
|
* If going into a holding bridge, default the role to participant, if
|
|
|
|
* it has no compatible role currently
|
|
|
|
*/
|
|
|
|
if ((self->technology->capabilities & AST_BRIDGE_CAPABILITY_HOLDING)
|
|
|
|
&& !ast_channel_has_role(bridge_channel->chan, "announcer")
|
|
|
|
&& !ast_channel_has_role(bridge_channel->chan, "holding_participant")) {
|
|
|
|
if (ast_channel_add_bridge_role(bridge_channel->chan, "holding_participant")) {
|
|
|
|
ast_log(LOG_ERROR, "Failed to set holding participant on %s\n", ast_channel_name(bridge_channel->chan));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ast_channel_set_bridge_role_option(bridge_channel->chan, "holding_participant", "idle_mode", "none")) {
|
|
|
|
ast_log(LOG_ERROR, "Failed to set holding participant mode on %s\n", ast_channel_name(bridge_channel->chan));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-07-09 16:34:51 +00:00
|
|
|
if (self->allowed_capabilities & STASIS_BRIDGE_MIXING_CAPABILITIES) {
|
|
|
|
ast_bridge_channel_update_linkedids(bridge_channel, swap);
|
|
|
|
if (ast_test_flag(&self->feature_flags, AST_BRIDGE_FLAG_SMART)) {
|
|
|
|
ast_bridge_channel_update_accountcodes(bridge_channel, swap);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ast_bridge_base_v_table.push(self, bridge_channel, swap);
|
|
|
|
}
|
|
|
|
|
2014-08-07 15:30:19 +00:00
|
|
|
static int bridge_stasis_moving(struct ast_bridge_channel *bridge_channel, void *hook_pvt,
|
|
|
|
struct ast_bridge *src, struct ast_bridge *dst)
|
|
|
|
{
|
|
|
|
if (src->v_table == &bridge_stasis_v_table &&
|
|
|
|
dst->v_table != &bridge_stasis_v_table) {
|
2018-01-06 03:17:15 -05:00
|
|
|
struct stasis_app_control *control;
|
2014-08-07 15:30:19 +00:00
|
|
|
struct ast_channel *chan;
|
|
|
|
|
|
|
|
chan = bridge_channel->chan;
|
|
|
|
ast_assert(chan != NULL);
|
|
|
|
|
|
|
|
control = stasis_app_control_find_by_channel(chan);
|
|
|
|
if (!control) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2014-12-08 15:45:46 +00:00
|
|
|
stasis_app_channel_set_stasis_end_published(chan);
|
2014-11-13 15:46:48 +00:00
|
|
|
app_send_end_msg(control_app(control), chan);
|
2018-01-06 03:17:15 -05:00
|
|
|
ao2_ref(control, -1);
|
2014-08-07 15:30:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2014-07-09 16:34:51 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Pull this channel from the Stasis bridge.
|
|
|
|
* \since 12.5.0
|
|
|
|
*
|
|
|
|
* \param self Bridge to operate upon.
|
|
|
|
* \param bridge_channel Bridge channel to pull.
|
|
|
|
*
|
|
|
|
* \note On entry, self is already locked.
|
|
|
|
*/
|
|
|
|
static void bridge_stasis_pull(struct ast_bridge *self, struct ast_bridge_channel *bridge_channel)
|
|
|
|
{
|
|
|
|
if ((self->allowed_capabilities & STASIS_BRIDGE_MIXING_CAPABILITIES)
|
|
|
|
&& ast_test_flag(&self->feature_flags, AST_BRIDGE_FLAG_SMART)) {
|
|
|
|
ast_bridge_channel_update_accountcodes(NULL, bridge_channel);
|
|
|
|
}
|
|
|
|
|
res_stasis: Don't play MoH to channels by default when added to holding bridges
When ARI manipulates a bridge, it generally doesn't care what the mixing
technology is. Operations on a bridge initiated through ARI should perform
their action in generally the same way, regardless of the bridge's mixing
technology. While the mixing technology may determine how media flows to
channels, the actual operations on a bridge themselves should be the same.
Currently, this isn't the case with holding bridges. When a channel joins
without a role, MoH is started on that channel automatically. Subsequent bridge
operations that would stop MoH would fail (as there is no Announcer channel
playing MoH to the bridge). Starting MoH on the bridge will also create two
MoH streams: one from the MoH being played on the participant channel, and one
from the announcer channel. From the perspective of ARI users, this is
counter-intuitive - I would not expect MoH to be started for me. The mixing
technology determines how media is shared between participants, not the
application experience.
This patch does the following:
* The Stasis bridge class now inspects channels as they are going into a
bridge. If the bridge has a holding capability, and the channel has no
roles, we give it a participant role and mark the default behaviour to have
no entertainment. This allows addChannel operations to continue to set a
participant role with an entertainment option if it felt like it (or could
do it).
* The music on hold channel is now Stasis approved (tm)
Review: https://reviewboard.asterisk.org/r/3929/
ASTERISK-24264 #close
Reported by: Samuel Galarneau
Tested by: Samuel Galarneau
........
Merged revisions 422503 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422504 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422505 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-09-01 14:15:32 +00:00
|
|
|
if (self->technology->capabilities & AST_BRIDGE_CAPABILITY_HOLDING) {
|
|
|
|
ast_channel_clear_bridge_roles(bridge_channel->chan);
|
|
|
|
}
|
|
|
|
|
2014-08-07 15:30:19 +00:00
|
|
|
ast_bridge_move_hook(bridge_channel->features, bridge_stasis_moving, NULL, NULL, 0);
|
|
|
|
|
2014-07-09 16:34:51 +00:00
|
|
|
ast_bridge_base_v_table.pull(self, bridge_channel);
|
|
|
|
}
|
|
|
|
|
2023-05-25 10:58:45 +01:00
|
|
|
struct ast_bridge *bridge_stasis_new(uint32_t capabilities, unsigned int flags, const char *name, const char *id, enum ast_bridge_video_mode_type video_mode, unsigned int send_sdp_label)
|
2014-07-09 16:34:51 +00:00
|
|
|
{
|
bridging: Fix multiple bridging issues causing SEGVs and FRACKs.
Issues:
* The bridging core allowed multiple bridges to be created with the same
unique bridgeId at the same time. Only the last bridge created with the
duplicate name was actually saved to the core bridges container.
* The bridging core was creating a stasis topic for the bridge and saving it
in the bridge->topic field but not increasing its reference count. In the
case where two bridges were created with the same uniqueid (which is also
the topic name), the second bridge would get the _existing_ topic the first
bridge created. When the first bridge was destroyed, it would take the
topic with it so when the second bridge attempted to publish a message to
it it either FRACKed or SEGVd.
* The bridge destructor, which also destroys the bridge topic, is run from the
bridge manager thread not the caller's thread. This makes it possible for
an ARI developer to create a new one with the same uniqueid believing the
old one was destroyed when, in fact, the old one's destructor hadn't
completed. This could cause the new bridge to get the old one's topic just
before the topic was destroyed. When the new bridge attempted to publish
a message on that topic, asterisk could either FRACK or SEGV.
* The ARI bridges resource also allowed multiple bridges to be created with
the same uniqueid but it kept the duplicate bridges in its app_bridges
container. This created a situation where if you added two bridges with
the same "bridge1" uniqueid, all operations on "bridge1" were performed on
the first bridge created and the second was basically orphaned. If you
attempted to delete what you thought was the second bridge, you actually
deleted the first one created.
Changes:
* A new API `ast_bridge_topic_exists(uniqueid)` was created to determine if
a topic already exists for a bridge.
* `bridge_base_init()` in bridge.c and `ast_ari_bridges_create()` in
resource_bridges.c now call `ast_bridge_topic_exists(uniqueid)` to check
if a bridge with the requested uniqueid already exists and will fail if it
does.
* `bridge_register()` in bridges.c now checks the core bridges container to
make sure a bridge doesn't already exist with the requested uniqueid.
Although most callers of `bridge_register()` will have already called
`bridge_base_init()`, which will now fail on duplicate bridges, there
is no guarantee of this so we must check again.
* The core bridges container allocation was changed to reject duplicate
uniqueids instead of silently replacing an existing one. This is a "belt
and suspenders" check.
* A global mutex was added to bridge.c to prevent concurrent calls to
`bridge_base_init()` and `bridge_register()`.
* Even though you can no longer create multiple bridges with the same uniqueid
at the same time, it's still possible that the bridge topic might be
destroyed while a second bridge with the same uniqueid was trying to use
it. To address this, the bridging core now increments the reference count
on bridge->topic when a bridge is created and decrements it when the
bridge is destroyed.
* `bridge_create_common()` in res_stasis.c now checks the stasis app_bridges
container to make sure a bridge with the requested uniqueid doesn't already
exist. This may seem like overkill but there are so many entrypoints to
bridge creation that we need to be safe and catch issues as soon in the
process as possible.
* The stasis app_bridges container allocation was changed to reject duplicate
uniqueids instead of adding them. This is a "belt and suspenders" check.
* The `bridge show all` CLI command now shows the bridge name as well as the
bridge id.
* Response code 409 "Conflict" was added as a possible response from the ARI
bridge create resources to signal that a bridge with the requested uniqueid
already exists.
* Additional debugging was added to multiple bridging and stasis files.
Resolves: #211
2025-01-22 13:52:33 -07:00
|
|
|
struct ast_bridge *bridge;
|
2014-07-09 16:34:51 +00:00
|
|
|
|
bridging: Fix multiple bridging issues causing SEGVs and FRACKs.
Issues:
* The bridging core allowed multiple bridges to be created with the same
unique bridgeId at the same time. Only the last bridge created with the
duplicate name was actually saved to the core bridges container.
* The bridging core was creating a stasis topic for the bridge and saving it
in the bridge->topic field but not increasing its reference count. In the
case where two bridges were created with the same uniqueid (which is also
the topic name), the second bridge would get the _existing_ topic the first
bridge created. When the first bridge was destroyed, it would take the
topic with it so when the second bridge attempted to publish a message to
it it either FRACKed or SEGVd.
* The bridge destructor, which also destroys the bridge topic, is run from the
bridge manager thread not the caller's thread. This makes it possible for
an ARI developer to create a new one with the same uniqueid believing the
old one was destroyed when, in fact, the old one's destructor hadn't
completed. This could cause the new bridge to get the old one's topic just
before the topic was destroyed. When the new bridge attempted to publish
a message on that topic, asterisk could either FRACK or SEGV.
* The ARI bridges resource also allowed multiple bridges to be created with
the same uniqueid but it kept the duplicate bridges in its app_bridges
container. This created a situation where if you added two bridges with
the same "bridge1" uniqueid, all operations on "bridge1" were performed on
the first bridge created and the second was basically orphaned. If you
attempted to delete what you thought was the second bridge, you actually
deleted the first one created.
Changes:
* A new API `ast_bridge_topic_exists(uniqueid)` was created to determine if
a topic already exists for a bridge.
* `bridge_base_init()` in bridge.c and `ast_ari_bridges_create()` in
resource_bridges.c now call `ast_bridge_topic_exists(uniqueid)` to check
if a bridge with the requested uniqueid already exists and will fail if it
does.
* `bridge_register()` in bridges.c now checks the core bridges container to
make sure a bridge doesn't already exist with the requested uniqueid.
Although most callers of `bridge_register()` will have already called
`bridge_base_init()`, which will now fail on duplicate bridges, there
is no guarantee of this so we must check again.
* The core bridges container allocation was changed to reject duplicate
uniqueids instead of silently replacing an existing one. This is a "belt
and suspenders" check.
* A global mutex was added to bridge.c to prevent concurrent calls to
`bridge_base_init()` and `bridge_register()`.
* Even though you can no longer create multiple bridges with the same uniqueid
at the same time, it's still possible that the bridge topic might be
destroyed while a second bridge with the same uniqueid was trying to use
it. To address this, the bridging core now increments the reference count
on bridge->topic when a bridge is created and decrements it when the
bridge is destroyed.
* `bridge_create_common()` in res_stasis.c now checks the stasis app_bridges
container to make sure a bridge with the requested uniqueid doesn't already
exist. This may seem like overkill but there are so many entrypoints to
bridge creation that we need to be safe and catch issues as soon in the
process as possible.
* The stasis app_bridges container allocation was changed to reject duplicate
uniqueids instead of adding them. This is a "belt and suspenders" check.
* The `bridge show all` CLI command now shows the bridge name as well as the
bridge id.
* Response code 409 "Conflict" was added as a possible response from the ARI
bridge create resources to signal that a bridge with the requested uniqueid
already exists.
* Additional debugging was added to multiple bridging and stasis files.
Resolves: #211
2025-01-22 13:52:33 -07:00
|
|
|
ast_debug(1, "Creating Stasis bridge '%s' with id '%s'\n",
|
|
|
|
S_OR(name, "<unknown>"), S_OR(id, "<unknown>"));
|
2014-07-09 16:34:51 +00:00
|
|
|
bridge = bridge_alloc(sizeof(struct ast_bridge), &bridge_stasis_v_table);
|
|
|
|
bridge = bridge_base_init(bridge, capabilities, flags, "Stasis", name, id);
|
2020-07-11 01:14:53 +02:00
|
|
|
if (!bridge) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (video_mode == AST_BRIDGE_VIDEO_MODE_SFU) {
|
|
|
|
ast_bridge_set_sfu_video_mode(bridge);
|
|
|
|
/* We require a minimum 5 seconds between video updates to stop floods from clients,
|
|
|
|
* this should rarely be changed but should become configurable in the future.
|
|
|
|
*/
|
|
|
|
ast_bridge_set_video_update_discard(bridge, 5);
|
2020-08-30 22:42:06 +02:00
|
|
|
} else if (video_mode == AST_BRIDGE_VIDEO_MODE_SINGLE_SRC) {
|
|
|
|
ast_bridge_set_single_src_video_mode(bridge, NULL);
|
2020-07-11 01:14:53 +02:00
|
|
|
} else {
|
|
|
|
ast_bridge_set_talker_src_video_mode(bridge);
|
|
|
|
}
|
|
|
|
|
2023-05-25 10:58:45 +01:00
|
|
|
if (send_sdp_label) {
|
|
|
|
ast_bridge_set_send_sdp_label(bridge, 1);
|
|
|
|
}
|
|
|
|
|
2014-07-09 16:34:51 +00:00
|
|
|
bridge = bridge_register(bridge);
|
bridging: Fix multiple bridging issues causing SEGVs and FRACKs.
Issues:
* The bridging core allowed multiple bridges to be created with the same
unique bridgeId at the same time. Only the last bridge created with the
duplicate name was actually saved to the core bridges container.
* The bridging core was creating a stasis topic for the bridge and saving it
in the bridge->topic field but not increasing its reference count. In the
case where two bridges were created with the same uniqueid (which is also
the topic name), the second bridge would get the _existing_ topic the first
bridge created. When the first bridge was destroyed, it would take the
topic with it so when the second bridge attempted to publish a message to
it it either FRACKed or SEGVd.
* The bridge destructor, which also destroys the bridge topic, is run from the
bridge manager thread not the caller's thread. This makes it possible for
an ARI developer to create a new one with the same uniqueid believing the
old one was destroyed when, in fact, the old one's destructor hadn't
completed. This could cause the new bridge to get the old one's topic just
before the topic was destroyed. When the new bridge attempted to publish
a message on that topic, asterisk could either FRACK or SEGV.
* The ARI bridges resource also allowed multiple bridges to be created with
the same uniqueid but it kept the duplicate bridges in its app_bridges
container. This created a situation where if you added two bridges with
the same "bridge1" uniqueid, all operations on "bridge1" were performed on
the first bridge created and the second was basically orphaned. If you
attempted to delete what you thought was the second bridge, you actually
deleted the first one created.
Changes:
* A new API `ast_bridge_topic_exists(uniqueid)` was created to determine if
a topic already exists for a bridge.
* `bridge_base_init()` in bridge.c and `ast_ari_bridges_create()` in
resource_bridges.c now call `ast_bridge_topic_exists(uniqueid)` to check
if a bridge with the requested uniqueid already exists and will fail if it
does.
* `bridge_register()` in bridges.c now checks the core bridges container to
make sure a bridge doesn't already exist with the requested uniqueid.
Although most callers of `bridge_register()` will have already called
`bridge_base_init()`, which will now fail on duplicate bridges, there
is no guarantee of this so we must check again.
* The core bridges container allocation was changed to reject duplicate
uniqueids instead of silently replacing an existing one. This is a "belt
and suspenders" check.
* A global mutex was added to bridge.c to prevent concurrent calls to
`bridge_base_init()` and `bridge_register()`.
* Even though you can no longer create multiple bridges with the same uniqueid
at the same time, it's still possible that the bridge topic might be
destroyed while a second bridge with the same uniqueid was trying to use
it. To address this, the bridging core now increments the reference count
on bridge->topic when a bridge is created and decrements it when the
bridge is destroyed.
* `bridge_create_common()` in res_stasis.c now checks the stasis app_bridges
container to make sure a bridge with the requested uniqueid doesn't already
exist. This may seem like overkill but there are so many entrypoints to
bridge creation that we need to be safe and catch issues as soon in the
process as possible.
* The stasis app_bridges container allocation was changed to reject duplicate
uniqueids instead of adding them. This is a "belt and suspenders" check.
* The `bridge show all` CLI command now shows the bridge name as well as the
bridge id.
* Response code 409 "Conflict" was added as a possible response from the ARI
bridge create resources to signal that a bridge with the requested uniqueid
already exists.
* Additional debugging was added to multiple bridging and stasis files.
Resolves: #211
2025-01-22 13:52:33 -07:00
|
|
|
if (!bridge) {
|
|
|
|
ast_log(LOG_ERROR, "Failed to register Stasis bridge %s(%s)\n",
|
|
|
|
S_OR(id, "<unknown>"), S_OR(name, "<unknown>"));
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
ast_debug(1, "Created Stasis bridge " BRIDGE_PRINTF_SPEC "\n",
|
|
|
|
BRIDGE_PRINTF_VARS(bridge));
|
2014-07-09 16:34:51 +00:00
|
|
|
|
|
|
|
return bridge;
|
|
|
|
}
|
|
|
|
|
|
|
|
void bridge_stasis_init(void)
|
|
|
|
{
|
|
|
|
/* Setup the Stasis bridge subclass v_table. */
|
|
|
|
bridge_stasis_v_table = ast_bridge_base_v_table;
|
|
|
|
bridge_stasis_v_table.name = "stasis";
|
|
|
|
bridge_stasis_v_table.push = bridge_stasis_push;
|
|
|
|
bridge_stasis_v_table.pull = bridge_stasis_pull;
|
2015-01-29 23:03:14 +00:00
|
|
|
bridge_stasis_v_table.push_peek = bridge_stasis_push_peek;
|
2014-07-09 16:34:51 +00:00
|
|
|
}
|