2013-08-02 14:36:32 +00:00
|
|
|
/*
|
2013-04-22 14:58:53 +00:00
|
|
|
* Asterisk -- An open source telephony toolkit.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2012 - 2013, Digium, Inc.
|
|
|
|
*
|
|
|
|
* David M. Lee, II <dlee@digium.com>
|
|
|
|
*
|
|
|
|
* See http://www.asterisk.org for more information about
|
|
|
|
* the Asterisk project. Please do not directly contact
|
|
|
|
* any of the maintainers of this project for assistance;
|
|
|
|
* the project provides a web site, mailing lists and IRC
|
|
|
|
* channels for your use.
|
|
|
|
*
|
|
|
|
* This program is free software, distributed under the terms of
|
|
|
|
* the GNU General Public License Version 2. See the LICENSE file
|
|
|
|
* at the top of the source tree.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*! \file
|
|
|
|
*
|
2013-07-27 23:11:02 +00:00
|
|
|
* \brief Implementation for ARI stubs.
|
2013-04-22 14:58:53 +00:00
|
|
|
*
|
|
|
|
* \author David M. Lee, II <dlee@digium.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*** MODULEINFO
|
|
|
|
<support_level>core</support_level>
|
|
|
|
***/
|
|
|
|
|
|
|
|
#include "asterisk.h"
|
|
|
|
|
|
|
|
#include "resource_bridges.h"
|
2013-06-10 13:07:11 +00:00
|
|
|
#include "asterisk/stasis.h"
|
2013-07-25 04:18:05 +00:00
|
|
|
#include "asterisk/stasis_bridges.h"
|
2013-06-10 13:07:11 +00:00
|
|
|
#include "asterisk/stasis_app.h"
|
2016-11-08 16:11:41 +00:00
|
|
|
#include "asterisk/stasis_app_impl.h"
|
2013-07-19 19:35:21 +00:00
|
|
|
#include "asterisk/stasis_app_playback.h"
|
|
|
|
#include "asterisk/stasis_app_recording.h"
|
|
|
|
#include "asterisk/stasis_channels.h"
|
|
|
|
#include "asterisk/core_unreal.h"
|
2013-06-10 13:07:11 +00:00
|
|
|
#include "asterisk/channel.h"
|
2013-07-25 04:06:32 +00:00
|
|
|
#include "asterisk/bridge.h"
|
2013-07-19 19:35:21 +00:00
|
|
|
#include "asterisk/format_cap.h"
|
|
|
|
#include "asterisk/file.h"
|
2013-08-23 00:26:19 +00:00
|
|
|
#include "asterisk/musiconhold.h"
|
media formats: re-architect handling of media for performance improvements
In the old times media formats were represented using a bit field. This was
fast but had a few limitations.
1. Asterisk was limited in how many formats it could handle.
2. Formats, being a bit field, could not include any attribute information.
A format was strictly its type, e.g., "this is ulaw".
This was changed in Asterisk 10 (see
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal for
notes on that work) which led to the creation of the ast_format structure.
This structure allowed Asterisk to handle attributes and bundle information
with a format.
Additionally, ast_format_cap was created to act as a container for multiple
formats that, together, formed the capability of some entity. Another
mechanism was added to allow logic to be registered which performed format
attribute negotiation. Everywhere throughout the codebase Asterisk was
changed to use this strategy.
Unfortunately, in software, there is no free lunch. These new capabilities
came at a cost.
Performance analysis and profiling showed that we spend an inordinate
amount of time comparing, copying, and generally manipulating formats and
their related structures. Basic prototyping has shown that a reasonably
large performance improvement could be made in this area. This patch is the
result of that project, which overhauled the media format architecture
and its usage in Asterisk to improve performance.
Generally, the new philosophy for handling formats is as follows:
* The ast_format structure is reference counted. This removed a large amount
of the memory allocations and copying that was done in prior versions.
* In order to prevent race conditions while keeping things performant, the
ast_format structure is immutable by convention and lock-free. Violate this
tenet at your peril!
* Because formats are reference counted, codecs are also reference counted.
The Asterisk core generally provides built-in codecs and caches the
ast_format structures created to represent them. Generally, to prevent
inordinate amounts of module reference bumping, codecs and formats can be
added at run-time but cannot be removed.
* All compatibility with the bit field representation of codecs/formats has
been moved to a compatibility API. The primary user of this representation
is chan_iax2, which must continue to maintain its bit-field usage of formats
for interoperability concerns.
* When a format is negotiated with attributes, or when a format cannot be
represented by one of the cached formats, a new format object is created or
cloned from an existing format. That format may have the same codec
underlying it, but is a different format than a version of the format with
different attributes or without attributes.
* While formats are reference counted objects, the reference count maintained
on the format should be manipulated with care. Formats are generally cached
and will persist for the lifetime of Asterisk and do not explicitly need
to have their lifetime modified. An exception to this is when the user of a
format does not know where the format came from *and* the user may outlive
the provider of the format. This occurs, for example, when a format is read
from a channel: the channel may have a format with attributes (hence,
non-cached) and the user of the format may last longer than the channel (if
the reference to the channel is released prior to the format's reference).
For more information on this work, see the API design notes:
https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite
Finally, this work was the culmination of a large number of developer's
efforts. Extra thanks goes to Corey Farrell, who took on a large amount of the
work in the Asterisk core, chan_sip, and was an invaluable resource in peer
reviews throughout this project.
There were a substantial number of patches contributed during this work; the
following issues/patch names simply reflect some of the work (and will cause
the release scripts to give attribution to the individuals who work on them).
Reviews:
https://reviewboard.asterisk.org/r/3814
https://reviewboard.asterisk.org/r/3808
https://reviewboard.asterisk.org/r/3805
https://reviewboard.asterisk.org/r/3803
https://reviewboard.asterisk.org/r/3801
https://reviewboard.asterisk.org/r/3798
https://reviewboard.asterisk.org/r/3800
https://reviewboard.asterisk.org/r/3794
https://reviewboard.asterisk.org/r/3793
https://reviewboard.asterisk.org/r/3792
https://reviewboard.asterisk.org/r/3791
https://reviewboard.asterisk.org/r/3790
https://reviewboard.asterisk.org/r/3789
https://reviewboard.asterisk.org/r/3788
https://reviewboard.asterisk.org/r/3787
https://reviewboard.asterisk.org/r/3786
https://reviewboard.asterisk.org/r/3784
https://reviewboard.asterisk.org/r/3783
https://reviewboard.asterisk.org/r/3778
https://reviewboard.asterisk.org/r/3774
https://reviewboard.asterisk.org/r/3775
https://reviewboard.asterisk.org/r/3772
https://reviewboard.asterisk.org/r/3761
https://reviewboard.asterisk.org/r/3754
https://reviewboard.asterisk.org/r/3753
https://reviewboard.asterisk.org/r/3751
https://reviewboard.asterisk.org/r/3750
https://reviewboard.asterisk.org/r/3748
https://reviewboard.asterisk.org/r/3747
https://reviewboard.asterisk.org/r/3746
https://reviewboard.asterisk.org/r/3742
https://reviewboard.asterisk.org/r/3740
https://reviewboard.asterisk.org/r/3739
https://reviewboard.asterisk.org/r/3738
https://reviewboard.asterisk.org/r/3737
https://reviewboard.asterisk.org/r/3736
https://reviewboard.asterisk.org/r/3734
https://reviewboard.asterisk.org/r/3722
https://reviewboard.asterisk.org/r/3713
https://reviewboard.asterisk.org/r/3703
https://reviewboard.asterisk.org/r/3689
https://reviewboard.asterisk.org/r/3687
https://reviewboard.asterisk.org/r/3674
https://reviewboard.asterisk.org/r/3671
https://reviewboard.asterisk.org/r/3667
https://reviewboard.asterisk.org/r/3665
https://reviewboard.asterisk.org/r/3625
https://reviewboard.asterisk.org/r/3602
https://reviewboard.asterisk.org/r/3519
https://reviewboard.asterisk.org/r/3518
https://reviewboard.asterisk.org/r/3516
https://reviewboard.asterisk.org/r/3515
https://reviewboard.asterisk.org/r/3512
https://reviewboard.asterisk.org/r/3506
https://reviewboard.asterisk.org/r/3413
https://reviewboard.asterisk.org/r/3410
https://reviewboard.asterisk.org/r/3387
https://reviewboard.asterisk.org/r/3388
https://reviewboard.asterisk.org/r/3389
https://reviewboard.asterisk.org/r/3390
https://reviewboard.asterisk.org/r/3321
https://reviewboard.asterisk.org/r/3320
https://reviewboard.asterisk.org/r/3319
https://reviewboard.asterisk.org/r/3318
https://reviewboard.asterisk.org/r/3266
https://reviewboard.asterisk.org/r/3265
https://reviewboard.asterisk.org/r/3234
https://reviewboard.asterisk.org/r/3178
ASTERISK-23114 #close
Reported by: mjordan
media_formats_translation_core.diff uploaded by kharwell (License 6464)
rb3506.diff uploaded by mjordan (License 6283)
media_format_app_file.diff uploaded by kharwell (License 6464)
misc-2.diff uploaded by file (License 5000)
chan_mild-3.diff uploaded by file (License 5000)
chan_obscure.diff uploaded by file (License 5000)
jingle.diff uploaded by file (License 5000)
funcs.diff uploaded by file (License 5000)
formats.diff uploaded by file (License 5000)
core.diff uploaded by file (License 5000)
bridges.diff uploaded by file (License 5000)
mf-codecs-2.diff uploaded by file (License 5000)
mf-app_fax.diff uploaded by file (License 5000)
mf-apps-3.diff uploaded by file (License 5000)
media-formats-3.diff uploaded by file (License 5000)
ASTERISK-23715
rb3713.patch uploaded by coreyfarrell (License 5909)
rb3689.patch uploaded by mjordan (License 6283)
ASTERISK-23957
rb3722.patch uploaded by mjordan (License 6283)
mf-attributes-3.diff uploaded by file (License 5000)
ASTERISK-23958
Tested by: jrose
rb3822.patch uploaded by coreyfarrell (License 5909)
rb3800.patch uploaded by jrose (License 6182)
chan_sip.diff uploaded by mjordan (License 6283)
rb3747.patch uploaded by jrose (License 6182)
ASTERISK-23959 #close
Tested by: sgriepentrog, mjordan, coreyfarrell
sip_cleanup.diff uploaded by opticron (License 6273)
chan_sip_caps.diff uploaded by mjordan (License 6283)
rb3751.patch uploaded by coreyfarrell (License 5909)
chan_sip-3.diff uploaded by file (License 5000)
ASTERISK-23960 #close
Tested by: opticron
direct_media.diff uploaded by opticron (License 6273)
pjsip-direct-media.diff uploaded by file (License 5000)
format_cap_remove.diff uploaded by opticron (License 6273)
media_format_fixes.diff uploaded by opticron (License 6273)
chan_pjsip-2.diff uploaded by file (License 5000)
ASTERISK-23966 #close
Tested by: rmudgett
rb3803.patch uploaded by rmudgetti (License 5621)
chan_dahdi.diff uploaded by file (License 5000)
ASTERISK-24064 #close
Tested by: coreyfarrell, mjordan, opticron, file, rmudgett, sgriepentrog, jrose
rb3814.patch uploaded by rmudgett (License 5621)
moh_cleanup.diff uploaded by opticron (License 6273)
bridge_leak.diff uploaded by opticron (License 6273)
translate.diff uploaded by file (License 5000)
rb3795.patch uploaded by rmudgett (License 5621)
tls_fix.diff uploaded by mjordan (License 6283)
fax-mf-fix-2.diff uploaded by file (License 5000)
rtp_transfer_stuff uploaded by mjordan (License 6283)
rb3787.patch uploaded by rmudgett (License 5621)
media-formats-explicit-translate-format-3.diff uploaded by file (License 5000)
format_cache_case_fix.diff uploaded by opticron (License 6273)
rb3774.patch uploaded by rmudgett (License 5621)
rb3775.patch uploaded by rmudgett (License 5621)
rtp_engine_fix.diff uploaded by opticron (License 6273)
rtp_crash_fix.diff uploaded by opticron (License 6273)
rb3753.patch uploaded by mjordan (License 6283)
rb3750.patch uploaded by mjordan (License 6283)
rb3748.patch uploaded by rmudgett (License 5621)
media_format_fixes.diff uploaded by opticron (License 6273)
rb3740.patch uploaded by mjordan (License 6283)
rb3739.patch uploaded by mjordan (License 6283)
rb3734.patch uploaded by mjordan (License 6283)
rb3689.patch uploaded by mjordan (License 6283)
rb3674.patch uploaded by coreyfarrell (License 5909)
rb3671.patch uploaded by coreyfarrell (License 5909)
rb3667.patch uploaded by coreyfarrell (License 5909)
rb3665.patch uploaded by mjordan (License 6283)
rb3625.patch uploaded by coreyfarrell (License 5909)
rb3602.patch uploaded by coreyfarrell (License 5909)
format_compatibility-2.diff uploaded by file (License 5000)
core.diff uploaded by file (License 5000)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-20 22:06:33 +00:00
|
|
|
#include "asterisk/format_cache.h"
|
2013-06-10 13:07:11 +00:00
|
|
|
|
|
|
|
/*!
|
|
|
|
* \brief Finds a bridge, filling the response with an error, if appropriate.
|
|
|
|
*
|
|
|
|
* \param[out] response Response to fill with an error if control is not found.
|
|
|
|
* \param bridge_id ID of the bridge to lookup.
|
|
|
|
*
|
|
|
|
* \return Bridget.
|
|
|
|
* \return \c NULL if bridge does not exist.
|
|
|
|
*/
|
|
|
|
static struct ast_bridge *find_bridge(
|
2013-07-27 23:11:02 +00:00
|
|
|
struct ast_ari_response *response,
|
2013-06-10 13:07:11 +00:00
|
|
|
const char *bridge_id)
|
|
|
|
{
|
|
|
|
RAII_VAR(struct ast_bridge *, bridge, NULL, ao2_cleanup);
|
|
|
|
|
|
|
|
ast_assert(response != NULL);
|
|
|
|
|
|
|
|
bridge = stasis_app_bridge_find_by_id(bridge_id);
|
|
|
|
if (bridge == NULL) {
|
|
|
|
RAII_VAR(struct ast_bridge_snapshot *, snapshot,
|
2018-09-19 19:34:41 +00:00
|
|
|
ast_bridge_get_snapshot_by_uniqueid(bridge_id), ao2_cleanup);
|
2013-06-10 13:07:11 +00:00
|
|
|
if (!snapshot) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(response, 404, "Not found",
|
2013-06-10 13:07:11 +00:00
|
|
|
"Bridge not found");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(response, 409, "Conflict",
|
2013-06-10 13:07:11 +00:00
|
|
|
"Bridge not in Stasis application");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
ao2_ref(bridge, +1);
|
|
|
|
return bridge;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \brief Finds the control object for a channel, filling the response with an
|
|
|
|
* error, if appropriate.
|
|
|
|
* \param[out] response Response to fill with an error if control is not found.
|
|
|
|
* \param channel_id ID of the channel to lookup.
|
|
|
|
* \return Channel control object.
|
|
|
|
* \return \c NULL if control object does not exist.
|
|
|
|
*/
|
|
|
|
static struct stasis_app_control *find_channel_control(
|
2013-07-27 23:11:02 +00:00
|
|
|
struct ast_ari_response *response,
|
2013-06-10 13:07:11 +00:00
|
|
|
const char *channel_id)
|
|
|
|
{
|
|
|
|
RAII_VAR(struct stasis_app_control *, control, NULL, ao2_cleanup);
|
|
|
|
|
|
|
|
ast_assert(response != NULL);
|
|
|
|
|
|
|
|
control = stasis_app_control_find_by_channel_id(channel_id);
|
|
|
|
if (control == NULL) {
|
2013-08-23 17:19:02 +00:00
|
|
|
/* Distinguish between 400 and 422 errors */
|
|
|
|
RAII_VAR(struct ast_channel_snapshot *, snapshot, NULL,
|
|
|
|
ao2_cleanup);
|
|
|
|
snapshot = ast_channel_snapshot_get_latest(channel_id);
|
|
|
|
if (snapshot == NULL) {
|
|
|
|
ast_log(LOG_DEBUG, "Couldn't find '%s'\n", channel_id);
|
|
|
|
ast_ari_response_error(response, 400, "Bad Request",
|
|
|
|
"Channel not found");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_log(LOG_DEBUG, "Found non-stasis '%s'\n", channel_id);
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(response, 422, "Unprocessable Entity",
|
2013-06-10 13:07:11 +00:00
|
|
|
"Channel not in Stasis application");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
ao2_ref(control, +1);
|
|
|
|
return control;
|
|
|
|
}
|
2013-04-22 14:58:53 +00:00
|
|
|
|
2013-08-02 14:36:32 +00:00
|
|
|
struct control_list {
|
|
|
|
size_t count;
|
|
|
|
struct stasis_app_control *controls[];
|
|
|
|
};
|
|
|
|
|
|
|
|
static void control_list_dtor(void *obj) {
|
|
|
|
struct control_list *list = obj;
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
for (i = 0; i < list->count; ++i) {
|
|
|
|
ao2_cleanup(list->controls[i]);
|
|
|
|
list->controls[i] = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct control_list *control_list_create(struct ast_ari_response *response, size_t count, const char **channels) {
|
|
|
|
RAII_VAR(struct control_list *, list, NULL, ao2_cleanup);
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
if (count == 0 || !channels) {
|
|
|
|
ast_ari_response_error(response, 400, "Bad Request", "Missing parameter channel");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
list = ao2_alloc(sizeof(*list) + count * sizeof(list->controls[0]), control_list_dtor);
|
|
|
|
if (!list) {
|
|
|
|
ast_ari_response_alloc_failed(response);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < count; ++i) {
|
|
|
|
if (ast_strlen_zero(channels[i])) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
list->controls[list->count] =
|
|
|
|
find_channel_control(response, channels[i]);
|
|
|
|
if (!list->controls[list->count]) {
|
2013-08-23 17:19:02 +00:00
|
|
|
/* response filled in by find_channel_control() */
|
2013-08-02 14:36:32 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
++list->count;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (list->count == 0) {
|
|
|
|
ast_ari_response_error(response, 400, "Bad Request", "Missing parameter channel");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
ao2_ref(list, +1);
|
|
|
|
return list;
|
|
|
|
}
|
|
|
|
|
2013-12-13 16:38:57 +00:00
|
|
|
static int check_add_remove_channel(struct ast_ari_response *response,
|
|
|
|
struct stasis_app_control *control,
|
|
|
|
enum stasis_app_control_channel_result result)
|
|
|
|
{
|
|
|
|
switch (result) {
|
|
|
|
case STASIS_APP_CHANNEL_RECORDING :
|
|
|
|
ast_ari_response_error(
|
|
|
|
response, 409, "Conflict", "Channel %s currently recording",
|
|
|
|
stasis_app_control_get_channel_id(control));
|
|
|
|
return -1;
|
|
|
|
case STASIS_APP_CHANNEL_OKAY:
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-11-07 21:10:31 +00:00
|
|
|
void ast_ari_bridges_add_channel(struct ast_variable *headers,
|
|
|
|
struct ast_ari_bridges_add_channel_args *args,
|
|
|
|
struct ast_ari_response *response)
|
2013-04-22 14:58:53 +00:00
|
|
|
{
|
2013-06-10 13:07:11 +00:00
|
|
|
RAII_VAR(struct ast_bridge *, bridge, find_bridge(response, args->bridge_id), ao2_cleanup);
|
2013-08-02 14:36:32 +00:00
|
|
|
RAII_VAR(struct control_list *, list, NULL, ao2_cleanup);
|
|
|
|
size_t i;
|
2013-12-13 16:38:57 +00:00
|
|
|
int has_error = 0;
|
2013-08-02 14:36:32 +00:00
|
|
|
|
2013-06-10 13:07:11 +00:00
|
|
|
if (!bridge) {
|
2013-08-23 17:19:02 +00:00
|
|
|
/* Response filled in by find_bridge() */
|
2013-06-10 13:07:11 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-08-02 14:36:32 +00:00
|
|
|
list = control_list_create(response, args->channel_count, args->channel);
|
|
|
|
if (!list) {
|
|
|
|
/* Response filled in by control_list_create() */
|
2013-06-10 13:07:11 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-08-05 16:59:13 +00:00
|
|
|
for (i = 0; i < list->count; ++i) {
|
|
|
|
stasis_app_control_clear_roles(list->controls[i]);
|
|
|
|
if (!ast_strlen_zero(args->role)) {
|
|
|
|
if (stasis_app_control_add_role(list->controls[i], args->role)) {
|
|
|
|
ast_ari_response_alloc_failed(response);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
2017-10-07 01:48:48 +00:00
|
|
|
|
|
|
|
/* Apply bridge features to each of the channel controls */
|
|
|
|
if (!stasis_app_control_bridge_features_init(list->controls[i])) {
|
|
|
|
stasis_app_control_absorb_dtmf_in_bridge(list->controls[i], args->absorb_dtmf);
|
|
|
|
stasis_app_control_mute_in_bridge(list->controls[i], args->mute);
|
2019-11-22 14:32:42 +00:00
|
|
|
stasis_app_control_inhibit_colp_in_bridge(list->controls[i], args->inhibit_connected_line_updates);
|
2017-10-07 01:48:48 +00:00
|
|
|
}
|
2013-08-05 16:59:13 +00:00
|
|
|
}
|
|
|
|
|
2013-08-02 14:36:32 +00:00
|
|
|
for (i = 0; i < list->count; ++i) {
|
2013-12-13 16:38:57 +00:00
|
|
|
if ((has_error = check_add_remove_channel(response, list->controls[i],
|
|
|
|
stasis_app_control_add_channel_to_bridge(
|
|
|
|
list->controls[i], bridge)))) {
|
|
|
|
break;
|
|
|
|
}
|
2013-08-02 14:36:32 +00:00
|
|
|
}
|
|
|
|
|
2013-12-13 16:38:57 +00:00
|
|
|
if (!has_error) {
|
|
|
|
ast_ari_response_no_content(response);
|
|
|
|
}
|
2013-04-22 14:58:53 +00:00
|
|
|
}
|
2013-06-10 13:07:11 +00:00
|
|
|
|
2013-11-07 21:10:31 +00:00
|
|
|
void ast_ari_bridges_remove_channel(struct ast_variable *headers,
|
|
|
|
struct ast_ari_bridges_remove_channel_args *args,
|
|
|
|
struct ast_ari_response *response)
|
2013-04-22 14:58:53 +00:00
|
|
|
{
|
2013-06-10 13:07:11 +00:00
|
|
|
RAII_VAR(struct ast_bridge *, bridge, find_bridge(response, args->bridge_id), ao2_cleanup);
|
2013-08-02 14:36:32 +00:00
|
|
|
RAII_VAR(struct control_list *, list, NULL, ao2_cleanup);
|
|
|
|
size_t i;
|
|
|
|
|
2013-06-10 13:07:11 +00:00
|
|
|
if (!bridge) {
|
2013-08-23 17:19:02 +00:00
|
|
|
/* Response filled in by find_bridge() */
|
2013-06-10 13:07:11 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-08-02 14:36:32 +00:00
|
|
|
list = control_list_create(response, args->channel_count, args->channel);
|
|
|
|
if (!list) {
|
|
|
|
/* Response filled in by control_list_create() */
|
2013-06-10 13:07:11 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-08-23 17:19:02 +00:00
|
|
|
/* Make sure all of the channels are in this bridge */
|
2013-08-02 14:36:32 +00:00
|
|
|
for (i = 0; i < list->count; ++i) {
|
2013-08-23 17:19:02 +00:00
|
|
|
if (stasis_app_get_bridge(list->controls[i]) != bridge) {
|
|
|
|
ast_log(LOG_WARNING, "Channel %s not in bridge %s\n",
|
|
|
|
args->channel[i], args->bridge_id);
|
|
|
|
ast_ari_response_error(response, 422,
|
|
|
|
"Unprocessable Entity",
|
|
|
|
"Channel not in this bridge");
|
|
|
|
return;
|
|
|
|
}
|
2013-08-02 14:36:32 +00:00
|
|
|
}
|
|
|
|
|
2013-08-23 17:19:02 +00:00
|
|
|
/* Now actually remove it */
|
|
|
|
for (i = 0; i < list->count; ++i) {
|
|
|
|
stasis_app_control_remove_channel_from_bridge(list->controls[i],
|
|
|
|
bridge);
|
2013-06-10 13:07:11 +00:00
|
|
|
}
|
|
|
|
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_no_content(response);
|
2013-04-22 14:58:53 +00:00
|
|
|
}
|
2013-06-10 13:07:11 +00:00
|
|
|
|
2013-07-19 19:35:21 +00:00
|
|
|
struct bridge_channel_control_thread_data {
|
|
|
|
struct ast_channel *bridge_channel;
|
|
|
|
struct stasis_app_control *control;
|
2014-03-14 16:17:26 +00:00
|
|
|
struct stasis_forward *forward;
|
2016-06-13 22:40:07 +00:00
|
|
|
char bridge_id[0];
|
2013-07-19 19:35:21 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static void *bridge_channel_control_thread(void *data)
|
|
|
|
{
|
|
|
|
struct bridge_channel_control_thread_data *thread_data = data;
|
|
|
|
struct ast_channel *bridge_channel = thread_data->bridge_channel;
|
|
|
|
struct stasis_app_control *control = thread_data->control;
|
2014-03-14 16:17:26 +00:00
|
|
|
struct stasis_forward *forward = thread_data->forward;
|
2015-03-13 01:12:35 +00:00
|
|
|
ast_callid callid = ast_channel_callid(bridge_channel);
|
2016-06-13 22:40:07 +00:00
|
|
|
char *bridge_id = ast_strdupa(thread_data->bridge_id);
|
2013-07-19 19:35:21 +00:00
|
|
|
|
|
|
|
if (callid) {
|
|
|
|
ast_callid_threadassoc_add(callid);
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_free(thread_data);
|
|
|
|
thread_data = NULL;
|
|
|
|
|
|
|
|
stasis_app_control_execute_until_exhausted(bridge_channel, control);
|
2016-03-29 18:47:08 +00:00
|
|
|
stasis_app_control_flush_queue(control);
|
2013-07-19 19:35:21 +00:00
|
|
|
|
2016-06-13 22:40:07 +00:00
|
|
|
stasis_app_bridge_playback_channel_remove(bridge_id, control);
|
2014-03-14 16:17:26 +00:00
|
|
|
stasis_forward_cancel(forward);
|
2016-03-29 18:47:08 +00:00
|
|
|
ao2_cleanup(control);
|
|
|
|
ast_hangup(bridge_channel);
|
2013-07-19 19:35:21 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct ast_channel *prepare_bridge_media_channel(const char *type)
|
|
|
|
{
|
media formats: re-architect handling of media for performance improvements
In the old times media formats were represented using a bit field. This was
fast but had a few limitations.
1. Asterisk was limited in how many formats it could handle.
2. Formats, being a bit field, could not include any attribute information.
A format was strictly its type, e.g., "this is ulaw".
This was changed in Asterisk 10 (see
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal for
notes on that work) which led to the creation of the ast_format structure.
This structure allowed Asterisk to handle attributes and bundle information
with a format.
Additionally, ast_format_cap was created to act as a container for multiple
formats that, together, formed the capability of some entity. Another
mechanism was added to allow logic to be registered which performed format
attribute negotiation. Everywhere throughout the codebase Asterisk was
changed to use this strategy.
Unfortunately, in software, there is no free lunch. These new capabilities
came at a cost.
Performance analysis and profiling showed that we spend an inordinate
amount of time comparing, copying, and generally manipulating formats and
their related structures. Basic prototyping has shown that a reasonably
large performance improvement could be made in this area. This patch is the
result of that project, which overhauled the media format architecture
and its usage in Asterisk to improve performance.
Generally, the new philosophy for handling formats is as follows:
* The ast_format structure is reference counted. This removed a large amount
of the memory allocations and copying that was done in prior versions.
* In order to prevent race conditions while keeping things performant, the
ast_format structure is immutable by convention and lock-free. Violate this
tenet at your peril!
* Because formats are reference counted, codecs are also reference counted.
The Asterisk core generally provides built-in codecs and caches the
ast_format structures created to represent them. Generally, to prevent
inordinate amounts of module reference bumping, codecs and formats can be
added at run-time but cannot be removed.
* All compatibility with the bit field representation of codecs/formats has
been moved to a compatibility API. The primary user of this representation
is chan_iax2, which must continue to maintain its bit-field usage of formats
for interoperability concerns.
* When a format is negotiated with attributes, or when a format cannot be
represented by one of the cached formats, a new format object is created or
cloned from an existing format. That format may have the same codec
underlying it, but is a different format than a version of the format with
different attributes or without attributes.
* While formats are reference counted objects, the reference count maintained
on the format should be manipulated with care. Formats are generally cached
and will persist for the lifetime of Asterisk and do not explicitly need
to have their lifetime modified. An exception to this is when the user of a
format does not know where the format came from *and* the user may outlive
the provider of the format. This occurs, for example, when a format is read
from a channel: the channel may have a format with attributes (hence,
non-cached) and the user of the format may last longer than the channel (if
the reference to the channel is released prior to the format's reference).
For more information on this work, see the API design notes:
https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite
Finally, this work was the culmination of a large number of developer's
efforts. Extra thanks goes to Corey Farrell, who took on a large amount of the
work in the Asterisk core, chan_sip, and was an invaluable resource in peer
reviews throughout this project.
There were a substantial number of patches contributed during this work; the
following issues/patch names simply reflect some of the work (and will cause
the release scripts to give attribution to the individuals who work on them).
Reviews:
https://reviewboard.asterisk.org/r/3814
https://reviewboard.asterisk.org/r/3808
https://reviewboard.asterisk.org/r/3805
https://reviewboard.asterisk.org/r/3803
https://reviewboard.asterisk.org/r/3801
https://reviewboard.asterisk.org/r/3798
https://reviewboard.asterisk.org/r/3800
https://reviewboard.asterisk.org/r/3794
https://reviewboard.asterisk.org/r/3793
https://reviewboard.asterisk.org/r/3792
https://reviewboard.asterisk.org/r/3791
https://reviewboard.asterisk.org/r/3790
https://reviewboard.asterisk.org/r/3789
https://reviewboard.asterisk.org/r/3788
https://reviewboard.asterisk.org/r/3787
https://reviewboard.asterisk.org/r/3786
https://reviewboard.asterisk.org/r/3784
https://reviewboard.asterisk.org/r/3783
https://reviewboard.asterisk.org/r/3778
https://reviewboard.asterisk.org/r/3774
https://reviewboard.asterisk.org/r/3775
https://reviewboard.asterisk.org/r/3772
https://reviewboard.asterisk.org/r/3761
https://reviewboard.asterisk.org/r/3754
https://reviewboard.asterisk.org/r/3753
https://reviewboard.asterisk.org/r/3751
https://reviewboard.asterisk.org/r/3750
https://reviewboard.asterisk.org/r/3748
https://reviewboard.asterisk.org/r/3747
https://reviewboard.asterisk.org/r/3746
https://reviewboard.asterisk.org/r/3742
https://reviewboard.asterisk.org/r/3740
https://reviewboard.asterisk.org/r/3739
https://reviewboard.asterisk.org/r/3738
https://reviewboard.asterisk.org/r/3737
https://reviewboard.asterisk.org/r/3736
https://reviewboard.asterisk.org/r/3734
https://reviewboard.asterisk.org/r/3722
https://reviewboard.asterisk.org/r/3713
https://reviewboard.asterisk.org/r/3703
https://reviewboard.asterisk.org/r/3689
https://reviewboard.asterisk.org/r/3687
https://reviewboard.asterisk.org/r/3674
https://reviewboard.asterisk.org/r/3671
https://reviewboard.asterisk.org/r/3667
https://reviewboard.asterisk.org/r/3665
https://reviewboard.asterisk.org/r/3625
https://reviewboard.asterisk.org/r/3602
https://reviewboard.asterisk.org/r/3519
https://reviewboard.asterisk.org/r/3518
https://reviewboard.asterisk.org/r/3516
https://reviewboard.asterisk.org/r/3515
https://reviewboard.asterisk.org/r/3512
https://reviewboard.asterisk.org/r/3506
https://reviewboard.asterisk.org/r/3413
https://reviewboard.asterisk.org/r/3410
https://reviewboard.asterisk.org/r/3387
https://reviewboard.asterisk.org/r/3388
https://reviewboard.asterisk.org/r/3389
https://reviewboard.asterisk.org/r/3390
https://reviewboard.asterisk.org/r/3321
https://reviewboard.asterisk.org/r/3320
https://reviewboard.asterisk.org/r/3319
https://reviewboard.asterisk.org/r/3318
https://reviewboard.asterisk.org/r/3266
https://reviewboard.asterisk.org/r/3265
https://reviewboard.asterisk.org/r/3234
https://reviewboard.asterisk.org/r/3178
ASTERISK-23114 #close
Reported by: mjordan
media_formats_translation_core.diff uploaded by kharwell (License 6464)
rb3506.diff uploaded by mjordan (License 6283)
media_format_app_file.diff uploaded by kharwell (License 6464)
misc-2.diff uploaded by file (License 5000)
chan_mild-3.diff uploaded by file (License 5000)
chan_obscure.diff uploaded by file (License 5000)
jingle.diff uploaded by file (License 5000)
funcs.diff uploaded by file (License 5000)
formats.diff uploaded by file (License 5000)
core.diff uploaded by file (License 5000)
bridges.diff uploaded by file (License 5000)
mf-codecs-2.diff uploaded by file (License 5000)
mf-app_fax.diff uploaded by file (License 5000)
mf-apps-3.diff uploaded by file (License 5000)
media-formats-3.diff uploaded by file (License 5000)
ASTERISK-23715
rb3713.patch uploaded by coreyfarrell (License 5909)
rb3689.patch uploaded by mjordan (License 6283)
ASTERISK-23957
rb3722.patch uploaded by mjordan (License 6283)
mf-attributes-3.diff uploaded by file (License 5000)
ASTERISK-23958
Tested by: jrose
rb3822.patch uploaded by coreyfarrell (License 5909)
rb3800.patch uploaded by jrose (License 6182)
chan_sip.diff uploaded by mjordan (License 6283)
rb3747.patch uploaded by jrose (License 6182)
ASTERISK-23959 #close
Tested by: sgriepentrog, mjordan, coreyfarrell
sip_cleanup.diff uploaded by opticron (License 6273)
chan_sip_caps.diff uploaded by mjordan (License 6283)
rb3751.patch uploaded by coreyfarrell (License 5909)
chan_sip-3.diff uploaded by file (License 5000)
ASTERISK-23960 #close
Tested by: opticron
direct_media.diff uploaded by opticron (License 6273)
pjsip-direct-media.diff uploaded by file (License 5000)
format_cap_remove.diff uploaded by opticron (License 6273)
media_format_fixes.diff uploaded by opticron (License 6273)
chan_pjsip-2.diff uploaded by file (License 5000)
ASTERISK-23966 #close
Tested by: rmudgett
rb3803.patch uploaded by rmudgetti (License 5621)
chan_dahdi.diff uploaded by file (License 5000)
ASTERISK-24064 #close
Tested by: coreyfarrell, mjordan, opticron, file, rmudgett, sgriepentrog, jrose
rb3814.patch uploaded by rmudgett (License 5621)
moh_cleanup.diff uploaded by opticron (License 6273)
bridge_leak.diff uploaded by opticron (License 6273)
translate.diff uploaded by file (License 5000)
rb3795.patch uploaded by rmudgett (License 5621)
tls_fix.diff uploaded by mjordan (License 6283)
fax-mf-fix-2.diff uploaded by file (License 5000)
rtp_transfer_stuff uploaded by mjordan (License 6283)
rb3787.patch uploaded by rmudgett (License 5621)
media-formats-explicit-translate-format-3.diff uploaded by file (License 5000)
format_cache_case_fix.diff uploaded by opticron (License 6273)
rb3774.patch uploaded by rmudgett (License 5621)
rb3775.patch uploaded by rmudgett (License 5621)
rtp_engine_fix.diff uploaded by opticron (License 6273)
rtp_crash_fix.diff uploaded by opticron (License 6273)
rb3753.patch uploaded by mjordan (License 6283)
rb3750.patch uploaded by mjordan (License 6283)
rb3748.patch uploaded by rmudgett (License 5621)
media_format_fixes.diff uploaded by opticron (License 6273)
rb3740.patch uploaded by mjordan (License 6283)
rb3739.patch uploaded by mjordan (License 6283)
rb3734.patch uploaded by mjordan (License 6283)
rb3689.patch uploaded by mjordan (License 6283)
rb3674.patch uploaded by coreyfarrell (License 5909)
rb3671.patch uploaded by coreyfarrell (License 5909)
rb3667.patch uploaded by coreyfarrell (License 5909)
rb3665.patch uploaded by mjordan (License 6283)
rb3625.patch uploaded by coreyfarrell (License 5909)
rb3602.patch uploaded by coreyfarrell (License 5909)
format_compatibility-2.diff uploaded by file (License 5000)
core.diff uploaded by file (License 5000)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-20 22:06:33 +00:00
|
|
|
RAII_VAR(struct ast_format_cap *, cap, NULL, ao2_cleanup);
|
2014-08-11 18:38:15 +00:00
|
|
|
struct ast_channel *chan;
|
2013-07-19 19:35:21 +00:00
|
|
|
|
media formats: re-architect handling of media for performance improvements
In the old times media formats were represented using a bit field. This was
fast but had a few limitations.
1. Asterisk was limited in how many formats it could handle.
2. Formats, being a bit field, could not include any attribute information.
A format was strictly its type, e.g., "this is ulaw".
This was changed in Asterisk 10 (see
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal for
notes on that work) which led to the creation of the ast_format structure.
This structure allowed Asterisk to handle attributes and bundle information
with a format.
Additionally, ast_format_cap was created to act as a container for multiple
formats that, together, formed the capability of some entity. Another
mechanism was added to allow logic to be registered which performed format
attribute negotiation. Everywhere throughout the codebase Asterisk was
changed to use this strategy.
Unfortunately, in software, there is no free lunch. These new capabilities
came at a cost.
Performance analysis and profiling showed that we spend an inordinate
amount of time comparing, copying, and generally manipulating formats and
their related structures. Basic prototyping has shown that a reasonably
large performance improvement could be made in this area. This patch is the
result of that project, which overhauled the media format architecture
and its usage in Asterisk to improve performance.
Generally, the new philosophy for handling formats is as follows:
* The ast_format structure is reference counted. This removed a large amount
of the memory allocations and copying that was done in prior versions.
* In order to prevent race conditions while keeping things performant, the
ast_format structure is immutable by convention and lock-free. Violate this
tenet at your peril!
* Because formats are reference counted, codecs are also reference counted.
The Asterisk core generally provides built-in codecs and caches the
ast_format structures created to represent them. Generally, to prevent
inordinate amounts of module reference bumping, codecs and formats can be
added at run-time but cannot be removed.
* All compatibility with the bit field representation of codecs/formats has
been moved to a compatibility API. The primary user of this representation
is chan_iax2, which must continue to maintain its bit-field usage of formats
for interoperability concerns.
* When a format is negotiated with attributes, or when a format cannot be
represented by one of the cached formats, a new format object is created or
cloned from an existing format. That format may have the same codec
underlying it, but is a different format than a version of the format with
different attributes or without attributes.
* While formats are reference counted objects, the reference count maintained
on the format should be manipulated with care. Formats are generally cached
and will persist for the lifetime of Asterisk and do not explicitly need
to have their lifetime modified. An exception to this is when the user of a
format does not know where the format came from *and* the user may outlive
the provider of the format. This occurs, for example, when a format is read
from a channel: the channel may have a format with attributes (hence,
non-cached) and the user of the format may last longer than the channel (if
the reference to the channel is released prior to the format's reference).
For more information on this work, see the API design notes:
https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite
Finally, this work was the culmination of a large number of developer's
efforts. Extra thanks goes to Corey Farrell, who took on a large amount of the
work in the Asterisk core, chan_sip, and was an invaluable resource in peer
reviews throughout this project.
There were a substantial number of patches contributed during this work; the
following issues/patch names simply reflect some of the work (and will cause
the release scripts to give attribution to the individuals who work on them).
Reviews:
https://reviewboard.asterisk.org/r/3814
https://reviewboard.asterisk.org/r/3808
https://reviewboard.asterisk.org/r/3805
https://reviewboard.asterisk.org/r/3803
https://reviewboard.asterisk.org/r/3801
https://reviewboard.asterisk.org/r/3798
https://reviewboard.asterisk.org/r/3800
https://reviewboard.asterisk.org/r/3794
https://reviewboard.asterisk.org/r/3793
https://reviewboard.asterisk.org/r/3792
https://reviewboard.asterisk.org/r/3791
https://reviewboard.asterisk.org/r/3790
https://reviewboard.asterisk.org/r/3789
https://reviewboard.asterisk.org/r/3788
https://reviewboard.asterisk.org/r/3787
https://reviewboard.asterisk.org/r/3786
https://reviewboard.asterisk.org/r/3784
https://reviewboard.asterisk.org/r/3783
https://reviewboard.asterisk.org/r/3778
https://reviewboard.asterisk.org/r/3774
https://reviewboard.asterisk.org/r/3775
https://reviewboard.asterisk.org/r/3772
https://reviewboard.asterisk.org/r/3761
https://reviewboard.asterisk.org/r/3754
https://reviewboard.asterisk.org/r/3753
https://reviewboard.asterisk.org/r/3751
https://reviewboard.asterisk.org/r/3750
https://reviewboard.asterisk.org/r/3748
https://reviewboard.asterisk.org/r/3747
https://reviewboard.asterisk.org/r/3746
https://reviewboard.asterisk.org/r/3742
https://reviewboard.asterisk.org/r/3740
https://reviewboard.asterisk.org/r/3739
https://reviewboard.asterisk.org/r/3738
https://reviewboard.asterisk.org/r/3737
https://reviewboard.asterisk.org/r/3736
https://reviewboard.asterisk.org/r/3734
https://reviewboard.asterisk.org/r/3722
https://reviewboard.asterisk.org/r/3713
https://reviewboard.asterisk.org/r/3703
https://reviewboard.asterisk.org/r/3689
https://reviewboard.asterisk.org/r/3687
https://reviewboard.asterisk.org/r/3674
https://reviewboard.asterisk.org/r/3671
https://reviewboard.asterisk.org/r/3667
https://reviewboard.asterisk.org/r/3665
https://reviewboard.asterisk.org/r/3625
https://reviewboard.asterisk.org/r/3602
https://reviewboard.asterisk.org/r/3519
https://reviewboard.asterisk.org/r/3518
https://reviewboard.asterisk.org/r/3516
https://reviewboard.asterisk.org/r/3515
https://reviewboard.asterisk.org/r/3512
https://reviewboard.asterisk.org/r/3506
https://reviewboard.asterisk.org/r/3413
https://reviewboard.asterisk.org/r/3410
https://reviewboard.asterisk.org/r/3387
https://reviewboard.asterisk.org/r/3388
https://reviewboard.asterisk.org/r/3389
https://reviewboard.asterisk.org/r/3390
https://reviewboard.asterisk.org/r/3321
https://reviewboard.asterisk.org/r/3320
https://reviewboard.asterisk.org/r/3319
https://reviewboard.asterisk.org/r/3318
https://reviewboard.asterisk.org/r/3266
https://reviewboard.asterisk.org/r/3265
https://reviewboard.asterisk.org/r/3234
https://reviewboard.asterisk.org/r/3178
ASTERISK-23114 #close
Reported by: mjordan
media_formats_translation_core.diff uploaded by kharwell (License 6464)
rb3506.diff uploaded by mjordan (License 6283)
media_format_app_file.diff uploaded by kharwell (License 6464)
misc-2.diff uploaded by file (License 5000)
chan_mild-3.diff uploaded by file (License 5000)
chan_obscure.diff uploaded by file (License 5000)
jingle.diff uploaded by file (License 5000)
funcs.diff uploaded by file (License 5000)
formats.diff uploaded by file (License 5000)
core.diff uploaded by file (License 5000)
bridges.diff uploaded by file (License 5000)
mf-codecs-2.diff uploaded by file (License 5000)
mf-app_fax.diff uploaded by file (License 5000)
mf-apps-3.diff uploaded by file (License 5000)
media-formats-3.diff uploaded by file (License 5000)
ASTERISK-23715
rb3713.patch uploaded by coreyfarrell (License 5909)
rb3689.patch uploaded by mjordan (License 6283)
ASTERISK-23957
rb3722.patch uploaded by mjordan (License 6283)
mf-attributes-3.diff uploaded by file (License 5000)
ASTERISK-23958
Tested by: jrose
rb3822.patch uploaded by coreyfarrell (License 5909)
rb3800.patch uploaded by jrose (License 6182)
chan_sip.diff uploaded by mjordan (License 6283)
rb3747.patch uploaded by jrose (License 6182)
ASTERISK-23959 #close
Tested by: sgriepentrog, mjordan, coreyfarrell
sip_cleanup.diff uploaded by opticron (License 6273)
chan_sip_caps.diff uploaded by mjordan (License 6283)
rb3751.patch uploaded by coreyfarrell (License 5909)
chan_sip-3.diff uploaded by file (License 5000)
ASTERISK-23960 #close
Tested by: opticron
direct_media.diff uploaded by opticron (License 6273)
pjsip-direct-media.diff uploaded by file (License 5000)
format_cap_remove.diff uploaded by opticron (License 6273)
media_format_fixes.diff uploaded by opticron (License 6273)
chan_pjsip-2.diff uploaded by file (License 5000)
ASTERISK-23966 #close
Tested by: rmudgett
rb3803.patch uploaded by rmudgetti (License 5621)
chan_dahdi.diff uploaded by file (License 5000)
ASTERISK-24064 #close
Tested by: coreyfarrell, mjordan, opticron, file, rmudgett, sgriepentrog, jrose
rb3814.patch uploaded by rmudgett (License 5621)
moh_cleanup.diff uploaded by opticron (License 6273)
bridge_leak.diff uploaded by opticron (License 6273)
translate.diff uploaded by file (License 5000)
rb3795.patch uploaded by rmudgett (License 5621)
tls_fix.diff uploaded by mjordan (License 6283)
fax-mf-fix-2.diff uploaded by file (License 5000)
rtp_transfer_stuff uploaded by mjordan (License 6283)
rb3787.patch uploaded by rmudgett (License 5621)
media-formats-explicit-translate-format-3.diff uploaded by file (License 5000)
format_cache_case_fix.diff uploaded by opticron (License 6273)
rb3774.patch uploaded by rmudgett (License 5621)
rb3775.patch uploaded by rmudgett (License 5621)
rtp_engine_fix.diff uploaded by opticron (License 6273)
rtp_crash_fix.diff uploaded by opticron (License 6273)
rb3753.patch uploaded by mjordan (License 6283)
rb3750.patch uploaded by mjordan (License 6283)
rb3748.patch uploaded by rmudgett (License 5621)
media_format_fixes.diff uploaded by opticron (License 6273)
rb3740.patch uploaded by mjordan (License 6283)
rb3739.patch uploaded by mjordan (License 6283)
rb3734.patch uploaded by mjordan (License 6283)
rb3689.patch uploaded by mjordan (License 6283)
rb3674.patch uploaded by coreyfarrell (License 5909)
rb3671.patch uploaded by coreyfarrell (License 5909)
rb3667.patch uploaded by coreyfarrell (License 5909)
rb3665.patch uploaded by mjordan (License 6283)
rb3625.patch uploaded by coreyfarrell (License 5909)
rb3602.patch uploaded by coreyfarrell (License 5909)
format_compatibility-2.diff uploaded by file (License 5000)
core.diff uploaded by file (License 5000)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-20 22:06:33 +00:00
|
|
|
cap = ast_format_cap_alloc(AST_FORMAT_CAP_FLAG_DEFAULT);
|
2013-07-19 19:35:21 +00:00
|
|
|
if (!cap) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
media formats: re-architect handling of media for performance improvements
In the old times media formats were represented using a bit field. This was
fast but had a few limitations.
1. Asterisk was limited in how many formats it could handle.
2. Formats, being a bit field, could not include any attribute information.
A format was strictly its type, e.g., "this is ulaw".
This was changed in Asterisk 10 (see
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal for
notes on that work) which led to the creation of the ast_format structure.
This structure allowed Asterisk to handle attributes and bundle information
with a format.
Additionally, ast_format_cap was created to act as a container for multiple
formats that, together, formed the capability of some entity. Another
mechanism was added to allow logic to be registered which performed format
attribute negotiation. Everywhere throughout the codebase Asterisk was
changed to use this strategy.
Unfortunately, in software, there is no free lunch. These new capabilities
came at a cost.
Performance analysis and profiling showed that we spend an inordinate
amount of time comparing, copying, and generally manipulating formats and
their related structures. Basic prototyping has shown that a reasonably
large performance improvement could be made in this area. This patch is the
result of that project, which overhauled the media format architecture
and its usage in Asterisk to improve performance.
Generally, the new philosophy for handling formats is as follows:
* The ast_format structure is reference counted. This removed a large amount
of the memory allocations and copying that was done in prior versions.
* In order to prevent race conditions while keeping things performant, the
ast_format structure is immutable by convention and lock-free. Violate this
tenet at your peril!
* Because formats are reference counted, codecs are also reference counted.
The Asterisk core generally provides built-in codecs and caches the
ast_format structures created to represent them. Generally, to prevent
inordinate amounts of module reference bumping, codecs and formats can be
added at run-time but cannot be removed.
* All compatibility with the bit field representation of codecs/formats has
been moved to a compatibility API. The primary user of this representation
is chan_iax2, which must continue to maintain its bit-field usage of formats
for interoperability concerns.
* When a format is negotiated with attributes, or when a format cannot be
represented by one of the cached formats, a new format object is created or
cloned from an existing format. That format may have the same codec
underlying it, but is a different format than a version of the format with
different attributes or without attributes.
* While formats are reference counted objects, the reference count maintained
on the format should be manipulated with care. Formats are generally cached
and will persist for the lifetime of Asterisk and do not explicitly need
to have their lifetime modified. An exception to this is when the user of a
format does not know where the format came from *and* the user may outlive
the provider of the format. This occurs, for example, when a format is read
from a channel: the channel may have a format with attributes (hence,
non-cached) and the user of the format may last longer than the channel (if
the reference to the channel is released prior to the format's reference).
For more information on this work, see the API design notes:
https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite
Finally, this work was the culmination of a large number of developer's
efforts. Extra thanks goes to Corey Farrell, who took on a large amount of the
work in the Asterisk core, chan_sip, and was an invaluable resource in peer
reviews throughout this project.
There were a substantial number of patches contributed during this work; the
following issues/patch names simply reflect some of the work (and will cause
the release scripts to give attribution to the individuals who work on them).
Reviews:
https://reviewboard.asterisk.org/r/3814
https://reviewboard.asterisk.org/r/3808
https://reviewboard.asterisk.org/r/3805
https://reviewboard.asterisk.org/r/3803
https://reviewboard.asterisk.org/r/3801
https://reviewboard.asterisk.org/r/3798
https://reviewboard.asterisk.org/r/3800
https://reviewboard.asterisk.org/r/3794
https://reviewboard.asterisk.org/r/3793
https://reviewboard.asterisk.org/r/3792
https://reviewboard.asterisk.org/r/3791
https://reviewboard.asterisk.org/r/3790
https://reviewboard.asterisk.org/r/3789
https://reviewboard.asterisk.org/r/3788
https://reviewboard.asterisk.org/r/3787
https://reviewboard.asterisk.org/r/3786
https://reviewboard.asterisk.org/r/3784
https://reviewboard.asterisk.org/r/3783
https://reviewboard.asterisk.org/r/3778
https://reviewboard.asterisk.org/r/3774
https://reviewboard.asterisk.org/r/3775
https://reviewboard.asterisk.org/r/3772
https://reviewboard.asterisk.org/r/3761
https://reviewboard.asterisk.org/r/3754
https://reviewboard.asterisk.org/r/3753
https://reviewboard.asterisk.org/r/3751
https://reviewboard.asterisk.org/r/3750
https://reviewboard.asterisk.org/r/3748
https://reviewboard.asterisk.org/r/3747
https://reviewboard.asterisk.org/r/3746
https://reviewboard.asterisk.org/r/3742
https://reviewboard.asterisk.org/r/3740
https://reviewboard.asterisk.org/r/3739
https://reviewboard.asterisk.org/r/3738
https://reviewboard.asterisk.org/r/3737
https://reviewboard.asterisk.org/r/3736
https://reviewboard.asterisk.org/r/3734
https://reviewboard.asterisk.org/r/3722
https://reviewboard.asterisk.org/r/3713
https://reviewboard.asterisk.org/r/3703
https://reviewboard.asterisk.org/r/3689
https://reviewboard.asterisk.org/r/3687
https://reviewboard.asterisk.org/r/3674
https://reviewboard.asterisk.org/r/3671
https://reviewboard.asterisk.org/r/3667
https://reviewboard.asterisk.org/r/3665
https://reviewboard.asterisk.org/r/3625
https://reviewboard.asterisk.org/r/3602
https://reviewboard.asterisk.org/r/3519
https://reviewboard.asterisk.org/r/3518
https://reviewboard.asterisk.org/r/3516
https://reviewboard.asterisk.org/r/3515
https://reviewboard.asterisk.org/r/3512
https://reviewboard.asterisk.org/r/3506
https://reviewboard.asterisk.org/r/3413
https://reviewboard.asterisk.org/r/3410
https://reviewboard.asterisk.org/r/3387
https://reviewboard.asterisk.org/r/3388
https://reviewboard.asterisk.org/r/3389
https://reviewboard.asterisk.org/r/3390
https://reviewboard.asterisk.org/r/3321
https://reviewboard.asterisk.org/r/3320
https://reviewboard.asterisk.org/r/3319
https://reviewboard.asterisk.org/r/3318
https://reviewboard.asterisk.org/r/3266
https://reviewboard.asterisk.org/r/3265
https://reviewboard.asterisk.org/r/3234
https://reviewboard.asterisk.org/r/3178
ASTERISK-23114 #close
Reported by: mjordan
media_formats_translation_core.diff uploaded by kharwell (License 6464)
rb3506.diff uploaded by mjordan (License 6283)
media_format_app_file.diff uploaded by kharwell (License 6464)
misc-2.diff uploaded by file (License 5000)
chan_mild-3.diff uploaded by file (License 5000)
chan_obscure.diff uploaded by file (License 5000)
jingle.diff uploaded by file (License 5000)
funcs.diff uploaded by file (License 5000)
formats.diff uploaded by file (License 5000)
core.diff uploaded by file (License 5000)
bridges.diff uploaded by file (License 5000)
mf-codecs-2.diff uploaded by file (License 5000)
mf-app_fax.diff uploaded by file (License 5000)
mf-apps-3.diff uploaded by file (License 5000)
media-formats-3.diff uploaded by file (License 5000)
ASTERISK-23715
rb3713.patch uploaded by coreyfarrell (License 5909)
rb3689.patch uploaded by mjordan (License 6283)
ASTERISK-23957
rb3722.patch uploaded by mjordan (License 6283)
mf-attributes-3.diff uploaded by file (License 5000)
ASTERISK-23958
Tested by: jrose
rb3822.patch uploaded by coreyfarrell (License 5909)
rb3800.patch uploaded by jrose (License 6182)
chan_sip.diff uploaded by mjordan (License 6283)
rb3747.patch uploaded by jrose (License 6182)
ASTERISK-23959 #close
Tested by: sgriepentrog, mjordan, coreyfarrell
sip_cleanup.diff uploaded by opticron (License 6273)
chan_sip_caps.diff uploaded by mjordan (License 6283)
rb3751.patch uploaded by coreyfarrell (License 5909)
chan_sip-3.diff uploaded by file (License 5000)
ASTERISK-23960 #close
Tested by: opticron
direct_media.diff uploaded by opticron (License 6273)
pjsip-direct-media.diff uploaded by file (License 5000)
format_cap_remove.diff uploaded by opticron (License 6273)
media_format_fixes.diff uploaded by opticron (License 6273)
chan_pjsip-2.diff uploaded by file (License 5000)
ASTERISK-23966 #close
Tested by: rmudgett
rb3803.patch uploaded by rmudgetti (License 5621)
chan_dahdi.diff uploaded by file (License 5000)
ASTERISK-24064 #close
Tested by: coreyfarrell, mjordan, opticron, file, rmudgett, sgriepentrog, jrose
rb3814.patch uploaded by rmudgett (License 5621)
moh_cleanup.diff uploaded by opticron (License 6273)
bridge_leak.diff uploaded by opticron (License 6273)
translate.diff uploaded by file (License 5000)
rb3795.patch uploaded by rmudgett (License 5621)
tls_fix.diff uploaded by mjordan (License 6283)
fax-mf-fix-2.diff uploaded by file (License 5000)
rtp_transfer_stuff uploaded by mjordan (License 6283)
rb3787.patch uploaded by rmudgett (License 5621)
media-formats-explicit-translate-format-3.diff uploaded by file (License 5000)
format_cache_case_fix.diff uploaded by opticron (License 6273)
rb3774.patch uploaded by rmudgett (License 5621)
rb3775.patch uploaded by rmudgett (License 5621)
rtp_engine_fix.diff uploaded by opticron (License 6273)
rtp_crash_fix.diff uploaded by opticron (License 6273)
rb3753.patch uploaded by mjordan (License 6283)
rb3750.patch uploaded by mjordan (License 6283)
rb3748.patch uploaded by rmudgett (License 5621)
media_format_fixes.diff uploaded by opticron (License 6273)
rb3740.patch uploaded by mjordan (License 6283)
rb3739.patch uploaded by mjordan (License 6283)
rb3734.patch uploaded by mjordan (License 6283)
rb3689.patch uploaded by mjordan (License 6283)
rb3674.patch uploaded by coreyfarrell (License 5909)
rb3671.patch uploaded by coreyfarrell (License 5909)
rb3667.patch uploaded by coreyfarrell (License 5909)
rb3665.patch uploaded by mjordan (License 6283)
rb3625.patch uploaded by coreyfarrell (License 5909)
rb3602.patch uploaded by coreyfarrell (License 5909)
format_compatibility-2.diff uploaded by file (License 5000)
core.diff uploaded by file (License 5000)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-20 22:06:33 +00:00
|
|
|
ast_format_cap_append(cap, ast_format_slin, 0);
|
2013-07-19 19:35:21 +00:00
|
|
|
|
2014-08-11 18:38:15 +00:00
|
|
|
chan = ast_request(type, cap, NULL, NULL, "ARI", NULL);
|
|
|
|
if (!chan) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (stasis_app_channel_unreal_set_internal(chan)) {
|
|
|
|
ast_channel_cleanup(chan);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
return chan;
|
2013-07-19 19:35:21 +00:00
|
|
|
}
|
|
|
|
|
2014-04-18 20:09:24 +00:00
|
|
|
/*!
|
|
|
|
* \brief Performs common setup for a bridge playback operation
|
|
|
|
* with both new controls and when existing controls are found.
|
|
|
|
*
|
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 23:17:08 +00:00
|
|
|
* \param args_media medias to play
|
|
|
|
* \param args_media_count number of media items in \c media
|
2014-04-18 20:09:24 +00:00
|
|
|
* \param args_lang language string split from arguments
|
|
|
|
* \param args_offset_ms milliseconds offset split from arguments
|
|
|
|
* \param args_playback_id string to use for playback split from
|
|
|
|
* arguments (null valid)
|
|
|
|
* \param response ARI response being built
|
|
|
|
* \param bridge Bridge the playback is being peformed on
|
|
|
|
* \param control Control being used for the playback channel
|
|
|
|
* \param json contents of the response to ARI
|
|
|
|
* \param playback_url stores playback URL for use with response
|
|
|
|
*
|
|
|
|
* \retval -1 operation failed
|
|
|
|
* \retval operation was successful
|
|
|
|
*/
|
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 23:17:08 +00:00
|
|
|
static int ari_bridges_play_helper(const char **args_media,
|
|
|
|
size_t args_media_count,
|
2014-04-18 20:09:24 +00:00
|
|
|
const char *args_lang,
|
|
|
|
int args_offset_ms,
|
|
|
|
int args_skipms,
|
|
|
|
const char *args_playback_id,
|
|
|
|
struct ast_ari_response *response,
|
|
|
|
struct ast_bridge *bridge,
|
|
|
|
struct stasis_app_control *control,
|
|
|
|
struct ast_json **json,
|
|
|
|
char **playback_url)
|
2013-07-19 19:35:21 +00:00
|
|
|
{
|
|
|
|
RAII_VAR(struct ast_channel_snapshot *, snapshot, NULL, ao2_cleanup);
|
|
|
|
RAII_VAR(struct stasis_app_playback *, playback, NULL, ao2_cleanup);
|
2014-04-18 20:09:24 +00:00
|
|
|
|
|
|
|
const char *language;
|
|
|
|
|
|
|
|
snapshot = stasis_app_control_get_snapshot(control);
|
|
|
|
if (!snapshot) {
|
|
|
|
ast_ari_response_error(
|
|
|
|
response, 500, "Internal Error", "Failed to get control snapshot");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2018-11-07 17:18:34 +00:00
|
|
|
language = S_OR(args_lang, snapshot->base->language);
|
2014-04-18 20:09:24 +00:00
|
|
|
|
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 23:17:08 +00:00
|
|
|
playback = stasis_app_control_play_uri(control, args_media, args_media_count,
|
|
|
|
language, bridge->uniqueid, STASIS_PLAYBACK_TARGET_BRIDGE, args_skipms,
|
2014-04-18 20:09:24 +00:00
|
|
|
args_offset_ms, args_playback_id);
|
|
|
|
|
|
|
|
if (!playback) {
|
|
|
|
ast_ari_response_alloc_failed(response);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2016-05-14 17:29:09 +00:00
|
|
|
if (ast_asprintf(playback_url, "/playbacks/%s",
|
2014-04-18 20:09:24 +00:00
|
|
|
stasis_app_playback_get_id(playback)) == -1) {
|
|
|
|
ast_ari_response_alloc_failed(response);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
*json = stasis_app_playback_to_json(playback);
|
|
|
|
if (!*json) {
|
|
|
|
ast_ari_response_alloc_failed(response);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 23:17:08 +00:00
|
|
|
static void ari_bridges_play_new(const char **args_media,
|
|
|
|
size_t args_media_count,
|
2014-04-18 20:09:24 +00:00
|
|
|
const char *args_lang,
|
|
|
|
int args_offset_ms,
|
|
|
|
int args_skipms,
|
|
|
|
const char *args_playback_id,
|
|
|
|
struct ast_ari_response *response,
|
|
|
|
struct ast_bridge *bridge)
|
|
|
|
{
|
|
|
|
RAII_VAR(struct ast_channel *, play_channel, NULL, ast_hangup);
|
|
|
|
RAII_VAR(struct stasis_app_control *, control, NULL, ao2_cleanup);
|
2013-07-19 19:35:21 +00:00
|
|
|
RAII_VAR(struct ast_json *, json, NULL, ast_json_unref);
|
2014-03-14 16:17:26 +00:00
|
|
|
RAII_VAR(struct stasis_forward *, channel_forward, NULL, stasis_forward_cancel);
|
2014-04-18 20:09:24 +00:00
|
|
|
RAII_VAR(char *, playback_url, NULL, ast_free);
|
2013-07-19 19:35:21 +00:00
|
|
|
|
2014-03-14 16:17:26 +00:00
|
|
|
struct stasis_topic *channel_topic;
|
|
|
|
struct stasis_topic *bridge_topic;
|
2013-07-19 19:35:21 +00:00
|
|
|
struct bridge_channel_control_thread_data *thread_data;
|
|
|
|
pthread_t threadid;
|
|
|
|
|
|
|
|
if (!(play_channel = prepare_bridge_media_channel("Announcer"))) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(
|
2013-07-19 19:35:21 +00:00
|
|
|
response, 500, "Internal Error", "Could not create playback channel");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
ast_debug(1, "Created announcer channel '%s'\n", ast_channel_name(play_channel));
|
|
|
|
|
2014-03-14 16:17:26 +00:00
|
|
|
bridge_topic = ast_bridge_topic(bridge);
|
|
|
|
channel_topic = ast_channel_topic(play_channel);
|
|
|
|
|
|
|
|
/* Forward messages from the playback channel topic to the bridge topic so that anything listening for
|
|
|
|
* messages on the bridge topic will receive the playback start/stop messages. Other messages that would
|
|
|
|
* go to this channel will be suppressed since the channel is marked as internal.
|
|
|
|
*/
|
|
|
|
if (!bridge_topic || !channel_topic || !(channel_forward = stasis_forward_all(channel_topic, bridge_topic))) {
|
|
|
|
ast_ari_response_error(
|
|
|
|
response, 500, "Internal Error", "Could not forward playback channel stasis messages to bridge topic");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-08-09 17:22:28 +00:00
|
|
|
if (ast_unreal_channel_push_to_bridge(play_channel, bridge,
|
|
|
|
AST_BRIDGE_CHANNEL_FLAG_IMMOVABLE | AST_BRIDGE_CHANNEL_FLAG_LONELY)) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(
|
2013-07-19 19:35:21 +00:00
|
|
|
response, 500, "Internal Error", "Failed to put playback channel into the bridge");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
control = stasis_app_control_create(play_channel);
|
|
|
|
if (control == NULL) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-07-19 19:35:21 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-04-18 20:09:24 +00:00
|
|
|
ao2_lock(control);
|
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 23:17:08 +00:00
|
|
|
if (ari_bridges_play_helper(args_media, args_media_count, args_lang,
|
|
|
|
args_offset_ms, args_skipms, args_playback_id, response, bridge,
|
|
|
|
control, &json, &playback_url)) {
|
2014-04-18 20:09:24 +00:00
|
|
|
ao2_unlock(control);
|
2013-07-19 19:35:21 +00:00
|
|
|
return;
|
|
|
|
}
|
2014-04-18 20:09:24 +00:00
|
|
|
ao2_unlock(control);
|
2013-07-19 19:35:21 +00:00
|
|
|
|
2014-04-18 20:09:24 +00:00
|
|
|
if (stasis_app_bridge_playback_channel_add(bridge, play_channel, control)) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-07-19 19:35:21 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Give play_channel and control reference to the thread data */
|
2016-06-13 22:40:07 +00:00
|
|
|
thread_data = ast_malloc(sizeof(*thread_data) + strlen(bridge->uniqueid) + 1);
|
2013-07-19 19:35:21 +00:00
|
|
|
if (!thread_data) {
|
2016-06-13 22:40:07 +00:00
|
|
|
stasis_app_bridge_playback_channel_remove((char *)bridge->uniqueid, control);
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-07-19 19:35:21 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
thread_data->bridge_channel = play_channel;
|
|
|
|
thread_data->control = control;
|
2014-03-14 16:17:26 +00:00
|
|
|
thread_data->forward = channel_forward;
|
2016-06-13 22:40:07 +00:00
|
|
|
/* Safe */
|
|
|
|
strcpy(thread_data->bridge_id, bridge->uniqueid);
|
2013-07-19 19:35:21 +00:00
|
|
|
|
|
|
|
if (ast_pthread_create_detached(&threadid, NULL, bridge_channel_control_thread, thread_data)) {
|
2016-06-13 22:40:07 +00:00
|
|
|
stasis_app_bridge_playback_channel_remove((char *)bridge->uniqueid, control);
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-07-19 19:35:21 +00:00
|
|
|
ast_free(thread_data);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* These are owned by the other thread now, so we don't want RAII_VAR disposing of them. */
|
|
|
|
play_channel = NULL;
|
|
|
|
control = NULL;
|
2014-03-14 16:17:26 +00:00
|
|
|
channel_forward = NULL;
|
2013-07-19 19:35:21 +00:00
|
|
|
|
2014-01-12 22:24:27 +00:00
|
|
|
ast_ari_response_created(response, playback_url, ast_json_ref(json));
|
2013-07-19 19:35:21 +00:00
|
|
|
}
|
|
|
|
|
2014-04-18 20:09:24 +00:00
|
|
|
enum play_found_result {
|
|
|
|
PLAY_FOUND_SUCCESS,
|
|
|
|
PLAY_FOUND_FAILURE,
|
|
|
|
PLAY_FOUND_CHANNEL_UNAVAILABLE,
|
|
|
|
};
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \brief Performs common setup for a bridge playback operation
|
|
|
|
* with both new controls and when existing controls are found.
|
|
|
|
*
|
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 23:17:08 +00:00
|
|
|
* \param args_media medias to play
|
|
|
|
* \param args_media_count number of media items in \c media
|
2014-04-18 20:09:24 +00:00
|
|
|
* \param args_lang language string split from arguments
|
|
|
|
* \param args_offset_ms milliseconds offset split from arguments
|
|
|
|
* \param args_playback_id string to use for playback split from
|
|
|
|
* arguments (null valid)
|
|
|
|
* \param response ARI response being built
|
|
|
|
* \param bridge Bridge the playback is being peformed on
|
|
|
|
* \param found_channel The channel that was found controlling playback
|
|
|
|
*
|
|
|
|
* \retval PLAY_FOUND_SUCCESS The operation was successful
|
|
|
|
* \retval PLAY_FOUND_FAILURE The operation failed (terminal failure)
|
|
|
|
* \retval PLAY_FOUND_CHANNEL_UNAVAILABLE The operation failed because
|
|
|
|
* the channel requested to playback with is breaking down.
|
|
|
|
*/
|
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 23:17:08 +00:00
|
|
|
static enum play_found_result ari_bridges_play_found(const char **args_media,
|
|
|
|
size_t args_media_count,
|
2014-04-18 20:09:24 +00:00
|
|
|
const char *args_lang,
|
|
|
|
int args_offset_ms,
|
|
|
|
int args_skipms,
|
|
|
|
const char *args_playback_id,
|
|
|
|
struct ast_ari_response *response,
|
|
|
|
struct ast_bridge *bridge,
|
|
|
|
struct ast_channel *found_channel)
|
|
|
|
{
|
|
|
|
RAII_VAR(struct ast_channel *, play_channel, found_channel, ao2_cleanup);
|
|
|
|
RAII_VAR(struct stasis_app_control *, control, NULL, ao2_cleanup);
|
|
|
|
RAII_VAR(char *, playback_url, NULL, ast_free);
|
|
|
|
RAII_VAR(struct ast_json *, json, NULL, ast_json_unref);
|
|
|
|
|
|
|
|
control = stasis_app_control_find_by_channel(play_channel);
|
|
|
|
if (!control) {
|
2016-03-29 23:06:24 +00:00
|
|
|
return PLAY_FOUND_CHANNEL_UNAVAILABLE;
|
2014-04-18 20:09:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
ao2_lock(control);
|
|
|
|
if (stasis_app_control_is_done(control)) {
|
|
|
|
/* We failed to queue the action. Bailout and return that we aren't terminal. */
|
|
|
|
ao2_unlock(control);
|
|
|
|
return PLAY_FOUND_CHANNEL_UNAVAILABLE;
|
|
|
|
}
|
|
|
|
|
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 23:17:08 +00:00
|
|
|
if (ari_bridges_play_helper(args_media, args_media_count,
|
|
|
|
args_lang, args_offset_ms, args_skipms, args_playback_id,
|
|
|
|
response, bridge, control, &json, &playback_url)) {
|
2014-04-18 20:09:24 +00:00
|
|
|
ao2_unlock(control);
|
|
|
|
return PLAY_FOUND_FAILURE;
|
|
|
|
}
|
|
|
|
ao2_unlock(control);
|
|
|
|
|
|
|
|
ast_ari_response_created(response, playback_url, ast_json_ref(json));
|
|
|
|
return PLAY_FOUND_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ari_bridges_handle_play(
|
|
|
|
const char *args_bridge_id,
|
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 23:17:08 +00:00
|
|
|
const char **args_media,
|
|
|
|
size_t args_media_count,
|
2014-04-18 20:09:24 +00:00
|
|
|
const char *args_lang,
|
|
|
|
int args_offset_ms,
|
|
|
|
int args_skipms,
|
|
|
|
const char *args_playback_id,
|
|
|
|
struct ast_ari_response *response)
|
|
|
|
{
|
|
|
|
RAII_VAR(struct ast_bridge *, bridge, find_bridge(response, args_bridge_id), ao2_cleanup);
|
|
|
|
struct ast_channel *play_channel;
|
|
|
|
|
|
|
|
ast_assert(response != NULL);
|
|
|
|
|
|
|
|
if (!bridge) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
while ((play_channel = stasis_app_bridge_playback_channel_find(bridge))) {
|
|
|
|
/* If ari_bridges_play_found fails because the channel is unavailable for
|
|
|
|
* playback, The channel will be removed from the playback list soon. We
|
|
|
|
* can keep trying to get channels from the list until we either get one
|
|
|
|
* that will work or else there isn't a channel for this bridge anymore,
|
|
|
|
* in which case we'll revert to ari_bridges_play_new.
|
|
|
|
*/
|
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 23:17:08 +00:00
|
|
|
if (ari_bridges_play_found(args_media, args_media_count, args_lang,
|
|
|
|
args_offset_ms, args_skipms, args_playback_id, response,bridge,
|
2014-04-18 20:09:24 +00:00
|
|
|
play_channel) == PLAY_FOUND_CHANNEL_UNAVAILABLE) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 23:17:08 +00:00
|
|
|
ari_bridges_play_new(args_media, args_media_count, args_lang, args_offset_ms,
|
2014-04-18 20:09:24 +00:00
|
|
|
args_skipms, args_playback_id, response, bridge);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void ast_ari_bridges_play(struct ast_variable *headers,
|
|
|
|
struct ast_ari_bridges_play_args *args,
|
|
|
|
struct ast_ari_response *response)
|
|
|
|
{
|
|
|
|
ari_bridges_handle_play(args->bridge_id,
|
|
|
|
args->media,
|
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 23:17:08 +00:00
|
|
|
args->media_count,
|
2014-04-18 20:09:24 +00:00
|
|
|
args->lang,
|
|
|
|
args->offsetms,
|
|
|
|
args->skipms,
|
|
|
|
args->playback_id,
|
|
|
|
response);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ast_ari_bridges_play_with_id(struct ast_variable *headers,
|
|
|
|
struct ast_ari_bridges_play_with_id_args *args,
|
|
|
|
struct ast_ari_response *response)
|
|
|
|
{
|
|
|
|
ari_bridges_handle_play(args->bridge_id,
|
|
|
|
args->media,
|
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 23:17:08 +00:00
|
|
|
args->media_count,
|
2014-04-18 20:09:24 +00:00
|
|
|
args->lang,
|
|
|
|
args->offsetms,
|
|
|
|
args->skipms,
|
|
|
|
args->playback_id,
|
|
|
|
response);
|
|
|
|
}
|
|
|
|
|
2013-11-07 21:10:31 +00:00
|
|
|
void ast_ari_bridges_record(struct ast_variable *headers,
|
|
|
|
struct ast_ari_bridges_record_args *args,
|
|
|
|
struct ast_ari_response *response)
|
2013-04-22 14:58:53 +00:00
|
|
|
{
|
2013-07-19 19:35:21 +00:00
|
|
|
RAII_VAR(struct ast_bridge *, bridge, find_bridge(response, args->bridge_id), ao2_cleanup);
|
|
|
|
RAII_VAR(struct ast_channel *, record_channel, NULL, ast_hangup);
|
|
|
|
RAII_VAR(struct stasis_app_control *, control, NULL, ao2_cleanup);
|
|
|
|
RAII_VAR(struct stasis_app_recording *, recording, NULL, ao2_cleanup);
|
|
|
|
RAII_VAR(char *, recording_url, NULL, ast_free);
|
|
|
|
RAII_VAR(struct ast_json *, json, NULL, ast_json_unref);
|
|
|
|
RAII_VAR(struct stasis_app_recording_options *, options, NULL, ao2_cleanup);
|
|
|
|
RAII_VAR(char *, uri_encoded_name, NULL, ast_free);
|
2014-03-14 16:17:26 +00:00
|
|
|
RAII_VAR(struct stasis_forward *, channel_forward, NULL, stasis_forward_cancel);
|
2013-07-19 19:35:21 +00:00
|
|
|
|
2014-03-14 16:17:26 +00:00
|
|
|
struct stasis_topic *channel_topic;
|
|
|
|
struct stasis_topic *bridge_topic;
|
2013-07-19 19:35:21 +00:00
|
|
|
size_t uri_name_maxlen;
|
|
|
|
struct bridge_channel_control_thread_data *thread_data;
|
|
|
|
pthread_t threadid;
|
|
|
|
|
|
|
|
ast_assert(response != NULL);
|
|
|
|
|
|
|
|
if (bridge == NULL) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(record_channel = prepare_bridge_media_channel("Recorder"))) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(
|
2013-07-19 19:35:21 +00:00
|
|
|
response, 500, "Internal Server Error", "Failed to create recording channel");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-03-14 16:17:26 +00:00
|
|
|
bridge_topic = ast_bridge_topic(bridge);
|
|
|
|
channel_topic = ast_channel_topic(record_channel);
|
|
|
|
|
|
|
|
/* Forward messages from the recording channel topic to the bridge topic so that anything listening for
|
|
|
|
* messages on the bridge topic will receive the recording start/stop messages. Other messages that would
|
|
|
|
* go to this channel will be suppressed since the channel is marked as internal.
|
|
|
|
*/
|
|
|
|
if (!bridge_topic || !channel_topic || !(channel_forward = stasis_forward_all(channel_topic, bridge_topic))) {
|
|
|
|
ast_ari_response_error(
|
|
|
|
response, 500, "Internal Error", "Could not forward record channel stasis messages to bridge topic");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-08-09 17:22:28 +00:00
|
|
|
if (ast_unreal_channel_push_to_bridge(record_channel, bridge,
|
|
|
|
AST_BRIDGE_CHANNEL_FLAG_IMMOVABLE | AST_BRIDGE_CHANNEL_FLAG_LONELY)) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(
|
2013-07-19 19:35:21 +00:00
|
|
|
response, 500, "Internal Error", "Failed to put recording channel into the bridge");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
control = stasis_app_control_create(record_channel);
|
|
|
|
if (control == NULL) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-07-19 19:35:21 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
options = stasis_app_recording_options_create(args->name, args->format);
|
|
|
|
if (options == NULL) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-07-19 19:35:21 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-03-06 18:20:37 +00:00
|
|
|
ast_string_field_build(options, target, "bridge:%s", args->bridge_id);
|
2013-07-19 19:35:21 +00:00
|
|
|
options->max_silence_seconds = args->max_silence_seconds;
|
|
|
|
options->max_duration_seconds = args->max_duration_seconds;
|
|
|
|
options->terminate_on =
|
|
|
|
stasis_app_recording_termination_parse(args->terminate_on);
|
|
|
|
options->if_exists =
|
|
|
|
stasis_app_recording_if_exists_parse(args->if_exists);
|
|
|
|
options->beep = args->beep;
|
|
|
|
|
2013-10-25 22:01:43 +00:00
|
|
|
if (options->terminate_on == STASIS_APP_RECORDING_TERMINATE_INVALID) {
|
|
|
|
ast_ari_response_error(
|
|
|
|
response, 400, "Bad Request",
|
|
|
|
"terminateOn invalid");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-04-09 12:57:21 +00:00
|
|
|
if (options->if_exists == AST_RECORD_IF_EXISTS_ERROR) {
|
2013-10-25 22:01:43 +00:00
|
|
|
ast_ari_response_error(
|
|
|
|
response, 400, "Bad Request",
|
|
|
|
"ifExists invalid");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!ast_get_format_for_file_ext(options->format)) {
|
|
|
|
ast_ari_response_error(
|
|
|
|
response, 422, "Unprocessable Entity",
|
|
|
|
"specified format is unknown on this system");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-07-19 19:35:21 +00:00
|
|
|
recording = stasis_app_control_record(control, options);
|
|
|
|
if (recording == NULL) {
|
|
|
|
switch(errno) {
|
|
|
|
case EINVAL:
|
|
|
|
/* While the arguments are invalid, we should have
|
|
|
|
* caught them prior to calling record.
|
|
|
|
*/
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(
|
2013-07-19 19:35:21 +00:00
|
|
|
response, 500, "Internal Server Error",
|
|
|
|
"Error parsing request");
|
|
|
|
break;
|
|
|
|
case EEXIST:
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(response, 409, "Conflict",
|
2013-10-25 21:28:32 +00:00
|
|
|
"Recording '%s' already exists and can not be overwritten",
|
2013-07-19 19:35:21 +00:00
|
|
|
args->name);
|
|
|
|
break;
|
|
|
|
case ENOMEM:
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-07-19 19:35:21 +00:00
|
|
|
break;
|
|
|
|
case EPERM:
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(
|
2013-07-19 19:35:21 +00:00
|
|
|
response, 400, "Bad Request",
|
|
|
|
"Recording name invalid");
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Unrecognized recording error: %s\n",
|
|
|
|
strerror(errno));
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(
|
2013-07-19 19:35:21 +00:00
|
|
|
response, 500, "Internal Server Error",
|
|
|
|
"Internal Server Error");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
uri_name_maxlen = strlen(args->name) * 3;
|
|
|
|
uri_encoded_name = ast_malloc(uri_name_maxlen);
|
|
|
|
if (!uri_encoded_name) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-07-19 19:35:21 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
ast_uri_encode(args->name, uri_encoded_name, uri_name_maxlen, ast_uri_http);
|
|
|
|
|
2014-04-18 20:09:24 +00:00
|
|
|
if (ast_asprintf(&recording_url, "/recordings/live/%s",
|
|
|
|
uri_encoded_name) == -1) {
|
|
|
|
recording_url = NULL;
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-07-19 19:35:21 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
json = stasis_app_recording_to_json(recording);
|
|
|
|
if (!json) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-07-19 19:35:21 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
thread_data = ast_calloc(1, sizeof(*thread_data));
|
|
|
|
if (!thread_data) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-07-19 19:35:21 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
thread_data->bridge_channel = record_channel;
|
|
|
|
thread_data->control = control;
|
2014-03-14 16:17:26 +00:00
|
|
|
thread_data->forward = channel_forward;
|
2013-07-19 19:35:21 +00:00
|
|
|
|
|
|
|
if (ast_pthread_create_detached(&threadid, NULL, bridge_channel_control_thread, thread_data)) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-07-19 19:35:21 +00:00
|
|
|
ast_free(thread_data);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* These are owned by the other thread now, so we don't want RAII_VAR disposing of them. */
|
|
|
|
record_channel = NULL;
|
|
|
|
control = NULL;
|
2014-03-14 16:17:26 +00:00
|
|
|
channel_forward = NULL;
|
2013-07-19 19:35:21 +00:00
|
|
|
|
2014-01-12 22:24:27 +00:00
|
|
|
ast_ari_response_created(response, recording_url, ast_json_ref(json));
|
2013-04-22 14:58:53 +00:00
|
|
|
}
|
2013-06-10 13:07:11 +00:00
|
|
|
|
2013-11-07 21:10:31 +00:00
|
|
|
void ast_ari_bridges_start_moh(struct ast_variable *headers,
|
|
|
|
struct ast_ari_bridges_start_moh_args *args,
|
|
|
|
struct ast_ari_response *response)
|
2013-08-23 00:26:19 +00:00
|
|
|
{
|
|
|
|
RAII_VAR(struct ast_bridge *, bridge, find_bridge(response, args->bridge_id), ao2_cleanup);
|
|
|
|
struct ast_channel *moh_channel;
|
|
|
|
const char *moh_class = args->moh_class;
|
|
|
|
|
|
|
|
if (!bridge) {
|
|
|
|
/* The response is provided by find_bridge() */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
moh_channel = stasis_app_bridge_moh_channel(bridge);
|
|
|
|
if (!moh_channel) {
|
|
|
|
ast_ari_response_alloc_failed(response);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_moh_start(moh_channel, moh_class, NULL);
|
2018-06-26 14:17:37 +00:00
|
|
|
ast_channel_cleanup(moh_channel);
|
2013-08-23 00:26:19 +00:00
|
|
|
|
|
|
|
ast_ari_response_no_content(response);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2013-11-07 21:10:31 +00:00
|
|
|
void ast_ari_bridges_stop_moh(struct ast_variable *headers,
|
|
|
|
struct ast_ari_bridges_stop_moh_args *args,
|
|
|
|
struct ast_ari_response *response)
|
2013-08-23 00:26:19 +00:00
|
|
|
{
|
|
|
|
RAII_VAR(struct ast_bridge *, bridge, find_bridge(response, args->bridge_id), ao2_cleanup);
|
|
|
|
|
|
|
|
if (!bridge) {
|
|
|
|
/* the response is provided by find_bridge() */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (stasis_app_bridge_moh_stop(bridge)) {
|
|
|
|
ast_ari_response_error(
|
|
|
|
response, 409, "Conflict",
|
|
|
|
"Bridge isn't playing music");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_ari_response_no_content(response);
|
|
|
|
}
|
|
|
|
|
2013-11-07 21:10:31 +00:00
|
|
|
void ast_ari_bridges_get(struct ast_variable *headers,
|
|
|
|
struct ast_ari_bridges_get_args *args,
|
|
|
|
struct ast_ari_response *response)
|
2013-04-22 14:58:53 +00:00
|
|
|
{
|
2018-09-19 19:34:41 +00:00
|
|
|
RAII_VAR(struct ast_bridge_snapshot *, snapshot, ast_bridge_get_snapshot_by_uniqueid(args->bridge_id), ao2_cleanup);
|
2013-06-10 13:07:11 +00:00
|
|
|
if (!snapshot) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(
|
2013-06-10 13:07:11 +00:00
|
|
|
response, 404, "Not Found",
|
|
|
|
"Bridge not found");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_ok(response,
|
2013-11-22 20:10:46 +00:00
|
|
|
ast_bridge_snapshot_to_json(snapshot, stasis_app_get_sanitizer()));
|
2013-04-22 14:58:53 +00:00
|
|
|
}
|
2013-06-10 13:07:11 +00:00
|
|
|
|
2013-11-07 21:10:31 +00:00
|
|
|
void ast_ari_bridges_destroy(struct ast_variable *headers,
|
|
|
|
struct ast_ari_bridges_destroy_args *args,
|
|
|
|
struct ast_ari_response *response)
|
2013-04-22 14:58:53 +00:00
|
|
|
{
|
2013-06-10 13:07:11 +00:00
|
|
|
RAII_VAR(struct ast_bridge *, bridge, find_bridge(response, args->bridge_id), ao2_cleanup);
|
|
|
|
if (!bridge) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
stasis_app_bridge_destroy(args->bridge_id);
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_no_content(response);
|
2013-04-22 14:58:53 +00:00
|
|
|
}
|
2013-06-10 13:07:11 +00:00
|
|
|
|
2013-11-07 21:10:31 +00:00
|
|
|
void ast_ari_bridges_list(struct ast_variable *headers,
|
|
|
|
struct ast_ari_bridges_list_args *args,
|
|
|
|
struct ast_ari_response *response)
|
2013-04-22 14:58:53 +00:00
|
|
|
{
|
2018-09-19 19:34:41 +00:00
|
|
|
RAII_VAR(struct ao2_container *, bridges, NULL, ao2_cleanup);
|
2013-06-10 13:07:11 +00:00
|
|
|
RAII_VAR(struct ast_json *, json, NULL, ast_json_unref);
|
|
|
|
struct ao2_iterator i;
|
2018-09-19 19:34:41 +00:00
|
|
|
struct ast_bridge *bridge;
|
2013-06-10 13:07:11 +00:00
|
|
|
|
2018-09-19 19:34:41 +00:00
|
|
|
bridges = ast_bridges();
|
|
|
|
if (!bridges) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-06-10 13:07:11 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
json = ast_json_array_create();
|
|
|
|
if (!json) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-06-10 13:07:11 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-09-19 19:34:41 +00:00
|
|
|
i = ao2_iterator_init(bridges, 0);
|
|
|
|
while ((bridge = ao2_iterator_next(&i))) {
|
|
|
|
struct ast_bridge_snapshot *snapshot = ast_bridge_get_snapshot(bridge);
|
|
|
|
/* ast_bridge_snapshot_to_json will return NULL if snapshot is NULL */
|
2013-11-22 20:10:46 +00:00
|
|
|
struct ast_json *json_bridge = ast_bridge_snapshot_to_json(snapshot, stasis_app_get_sanitizer());
|
|
|
|
|
2018-09-19 19:34:41 +00:00
|
|
|
ao2_ref(bridge, -1);
|
|
|
|
ao2_cleanup(snapshot);
|
2013-11-22 20:10:46 +00:00
|
|
|
if (!json_bridge || ast_json_array_append(json, json_bridge)) {
|
2013-12-20 20:00:50 +00:00
|
|
|
ao2_iterator_destroy(&i);
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_alloc_failed(response);
|
2013-06-10 13:07:11 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
ao2_iterator_destroy(&i);
|
|
|
|
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_ok(response, ast_json_ref(json));
|
2013-04-22 14:58:53 +00:00
|
|
|
}
|
2013-06-10 13:07:11 +00:00
|
|
|
|
2013-11-07 21:10:31 +00:00
|
|
|
void ast_ari_bridges_create(struct ast_variable *headers,
|
|
|
|
struct ast_ari_bridges_create_args *args,
|
|
|
|
struct ast_ari_response *response)
|
2013-04-22 14:58:53 +00:00
|
|
|
{
|
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
|
|
|
RAII_VAR(struct ast_bridge *, bridge, stasis_app_bridge_create(args->type, args->name, args->bridge_id), ao2_cleanup);
|
2013-06-10 13:07:11 +00:00
|
|
|
RAII_VAR(struct ast_bridge_snapshot *, snapshot, NULL, ao2_cleanup);
|
|
|
|
|
|
|
|
if (!bridge) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(
|
2013-06-10 13:07:11 +00:00
|
|
|
response, 500, "Internal Error",
|
|
|
|
"Unable to create bridge");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-04-11 12:43:34 +00:00
|
|
|
ast_bridge_lock(bridge);
|
2013-06-10 13:07:11 +00:00
|
|
|
snapshot = ast_bridge_snapshot_create(bridge);
|
2014-04-11 12:43:34 +00:00
|
|
|
ast_bridge_unlock(bridge);
|
|
|
|
|
2013-06-10 13:07:11 +00:00
|
|
|
if (!snapshot) {
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_error(
|
2013-06-10 13:07:11 +00:00
|
|
|
response, 500, "Internal Error",
|
|
|
|
"Unable to create snapshot for new bridge");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-07-27 23:11:02 +00:00
|
|
|
ast_ari_response_ok(response,
|
2013-11-22 20:10:46 +00:00
|
|
|
ast_bridge_snapshot_to_json(snapshot, stasis_app_get_sanitizer()));
|
2013-04-22 14:58:53 +00:00
|
|
|
}
|
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
|
|
|
|
2015-01-27 17:21:03 +00:00
|
|
|
void ast_ari_bridges_create_with_id(struct ast_variable *headers,
|
|
|
|
struct ast_ari_bridges_create_with_id_args *args,
|
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
|
|
|
struct ast_ari_response *response)
|
|
|
|
{
|
|
|
|
RAII_VAR(struct ast_bridge *, bridge, find_bridge(response, args->bridge_id), ao2_cleanup);
|
|
|
|
RAII_VAR(struct ast_bridge_snapshot *, snapshot, NULL, ao2_cleanup);
|
|
|
|
|
|
|
|
if (bridge) {
|
|
|
|
/* update */
|
2017-11-26 15:44:51 +00:00
|
|
|
if (!ast_strlen_zero(args->name)
|
|
|
|
&& strcmp(args->name, bridge->name)) {
|
|
|
|
ast_ari_response_error(
|
|
|
|
response, 500, "Internal Error",
|
|
|
|
"Changing bridge name is not implemented");
|
|
|
|
return;
|
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
|
|
|
}
|
|
|
|
if (!ast_strlen_zero(args->type)) {
|
|
|
|
ast_ari_response_error(
|
|
|
|
response, 500, "Internal Error",
|
2015-01-20 17:15:54 +00:00
|
|
|
"Supplying a bridge type when updating a bridge is not allowed.");
|
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
ast_ari_response_ok(response,
|
|
|
|
ast_bridge_snapshot_to_json(snapshot, stasis_app_get_sanitizer()));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
bridge = stasis_app_bridge_create(args->type, args->name, args->bridge_id);
|
|
|
|
if (!bridge) {
|
|
|
|
ast_ari_response_error(
|
|
|
|
response, 500, "Internal Error",
|
|
|
|
"Unable to create bridge");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-04-11 12:43:34 +00:00
|
|
|
ast_bridge_lock(bridge);
|
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
|
|
|
snapshot = ast_bridge_snapshot_create(bridge);
|
2014-04-11 12:43:34 +00:00
|
|
|
ast_bridge_unlock(bridge);
|
|
|
|
|
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
|
|
|
if (!snapshot) {
|
|
|
|
ast_ari_response_error(
|
|
|
|
response, 500, "Internal Error",
|
|
|
|
"Unable to create snapshot for new bridge");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_ari_response_ok(response,
|
|
|
|
ast_bridge_snapshot_to_json(snapshot, stasis_app_get_sanitizer()));
|
|
|
|
}
|
2016-11-08 16:11:41 +00:00
|
|
|
|
|
|
|
static int bridge_set_video_source_cb(struct stasis_app_control *control,
|
|
|
|
struct ast_channel *chan, void *data)
|
|
|
|
{
|
|
|
|
struct ast_bridge *bridge = data;
|
|
|
|
|
|
|
|
ast_bridge_lock(bridge);
|
|
|
|
ast_bridge_set_single_src_video_mode(bridge, chan);
|
|
|
|
ast_bridge_unlock(bridge);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ast_ari_bridges_set_video_source(struct ast_variable *headers,
|
|
|
|
struct ast_ari_bridges_set_video_source_args *args, struct ast_ari_response *response)
|
|
|
|
{
|
|
|
|
struct ast_bridge *bridge;
|
|
|
|
struct stasis_app_control *control;
|
|
|
|
|
|
|
|
bridge = find_bridge(response, args->bridge_id);
|
|
|
|
if (!bridge) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
control = find_channel_control(response, args->channel_id);
|
|
|
|
if (!control) {
|
|
|
|
ao2_ref(bridge, -1);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (stasis_app_get_bridge(control) != bridge) {
|
|
|
|
ast_ari_response_error(response, 422,
|
|
|
|
"Unprocessable Entity",
|
|
|
|
"Channel not in this bridge");
|
|
|
|
ao2_ref(bridge, -1);
|
|
|
|
ao2_ref(control, -1);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
stasis_app_send_command(control, bridge_set_video_source_cb,
|
|
|
|
ao2_bump(bridge), __ao2_cleanup);
|
|
|
|
|
|
|
|
ao2_ref(bridge, -1);
|
|
|
|
ao2_ref(control, -1);
|
|
|
|
|
|
|
|
ast_ari_response_no_content(response);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ast_ari_bridges_clear_video_source(struct ast_variable *headers,
|
|
|
|
struct ast_ari_bridges_clear_video_source_args *args, struct ast_ari_response *response)
|
|
|
|
{
|
|
|
|
struct ast_bridge *bridge;
|
|
|
|
|
|
|
|
bridge = find_bridge(response, args->bridge_id);
|
|
|
|
if (!bridge) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_bridge_lock(bridge);
|
|
|
|
ast_bridge_set_talker_src_video_mode(bridge);
|
|
|
|
ast_bridge_unlock(bridge);
|
|
|
|
|
|
|
|
ao2_ref(bridge, -1);
|
|
|
|
ast_ari_response_no_content(response);
|
|
|
|
}
|