app_confbridge now has the ability to set the estimated bitrate on an
SFU bridge. To use it, set a bridge profile's remb_behavior to "force"
and set remb_estimated_bitrate to a rate in bits per second. The
remb_estimated_bitrate parameter is ignored if remb_behavior is something
other than "force".
Change-Id: Idce6464ff014a37ea3b82944452e56cc4d75ab0a
ConfBridge has the ability to move between different sample
rates for mixing the conference bridge. Up until now there has
only been the ability to set the conference bridge to mix at
a specific sample rate, or to let it move between sample rates
as necessary. This change adds the ability to configure a
conference bridge with a maximum sample rate so it can move
between sample rates but only up to the configured maximum.
ASTERISK-28658
Change-Id: Idff80896ccfb8a58a816e4ce9ac4ebde785963ee
After a bridge has been deleted the stasis control will depart
the channel and might attempt to re-add it to the dial bridge.
The later can fail and this can lead to a situation that the stasis
control is unlinked but the after_bridge_cb_failed cb is executed trying
to access a dangling control object.
Fix it by calling the after_cb's before bridge_channel_impart_signal.
ASTERISK-26718
Change-Id: Ib4e8f70d7a21bd54afe3cb51cc6717ef7c355496
When producing a combined REMB value the normal behavior
is to have a REMB value which is unique for each sender
based on all of their receivers. This can result in one
sender having low bitrate while all the rest are high.
This change adds "all" variants which produces a bridge
level REMB value instead. All REMB reports are combined
together into a single REMB value that is the same for
each sender.
ASTERISK-28401
Change-Id: I883e6cc26003b497c8180b346111c79a131ba88c
This small feature will help to checking the bridge's status to
figure out which bridge is in old/zombie or not. Also added
detail items for the 'bridge show *' cli to provide more detail
info. And added creation item to the ARI as well.
ASTERISK-28279
Change-Id: I460238c488eca4d216b9176576211cb03286e040
* The bridging core no longer uses the stasis cache for bridge
snapshots. The latest bridge snapshot is now stored on the
ast_bridge structure itself.
* The following APIs are no longer available since the stasis cache
is no longer used:
ast_bridge_topic_cached()
ast_bridge_topic_all_cached()
* A topic pool is now used for individual bridge topics.
* The ast_bridge_cache() function was removed since there's no
longer a separate container of snapshots.
* A new function "ast_bridges()" was created to retrieve the
container of all bridges. Users formerly calling
ast_bridge_cache() can use the new function to iterate over
bridges and retrieve the latest snapshot directly from the
bridge.
* The ast_bridge_snapshot_get_latest() function was renamed to
ast_bridge_get_snapshot_by_uniqueid().
* A new function "ast_bridge_get_snapshot()" was created to retrieve
the bridge snapshot directly from the bridge structure.
* The ast_bridge_topic_all() function now returns a normal topic
not a cached one so you can't use stasis cache functions on it
either.
* The ast_bridge_snapshot_type() stasis message now has the
ast_bridge_snapshot_update structure as it's data. It contains
the last snapshot and the new one.
* cdr, cel, manager and ari have been updated to use the new
arrangement.
Change-Id: I7049b80efa88676ce5c4666f818fa18ad1985369
Adding the "label" attribute used for participant info correlation
was previously done in app_confbridge but it wasn't working
correctly because it didn't have knowledge about which video
streams belonged to which channel. Only bridge_softmix has that
data so now it's set when the bridge topology is changed.
ASTERISK-28107
Change-Id: Ieddeca5799d710cad083af3fcc3e677fa2a2a499
This change adds the ability for multiple REMB reports in
bridge_softmix to be combined according to a configured
behavior into a single report. This single report is sent
back to the sender of video, which adjusts the encoding bitrate
to be at or below the bitrate of the report. The available
behaviors are: lowest, highest, and average. Lowest uses the
lowest received bitrate. Highest uses the highest received
bitrate. Average goes through the received bitrates adding
them to the previous average and creates a new average.
Other behaviors can be added in the future and the existing
average one may be adjusted, but this provides the foundation
to do so.
Support for configuring which behavior to use has been
added to app_confbridge.
ASTERISK-27804
Change-Id: I9eafe4e7c1f72d67074a8d6acb26bfcf19322b66
There is a problem when an INVITE-with-Replaces transfer targets a channel
in a ConfBridge. The transfer will unconditionally swap out the
ConfBridge channel. Unfortunately, the ConfBridge state will not be aware
of this change. Unexpected behavior will happen as a result since
ConfBridge channels currently can only be replaced by a masquerade and not
normal bridge channel moves.
* We just need to pretend that the channel isn't in a bridge (like other
transfer methods already do) so the transfer channel will masquerade into
the ConfBridge channel.
Change-Id: I209beb0e748fa4f4b92a576f36afa8f495ba4c82
This change adds a configuration option to app_confbridge which can be
used to set the interval at which we will send a combined REMB (remote
estimated maximum bitrate) frame to sources of video. The bridging API
has also been extended slightly to allow setting this so bridge_softmix
can use it.
ASTERISK-27786
Change-Id: I0e49eae60f369c86434414f3cb8278709c793c82
This change does a few things to improve packet loss and renegotiation:
1. On outgoing RTP streams we will now properly reflect out of order
packets and packet loss in the sequence number. This allows the
remote jitterbuffer to better reorder things.
2. Video updates can now be discarded for a period of time
after one has been sent to prevent flooding of clients.
3. For declined and removed streams we will now release any
media session resources associated with them. This was not
previously done and caused an issue where old state was being
used for a new stream.
4. RTP bundling was not actually removing bundled RTP instances
from the parent. This has been resolved by removing based on
the RTP instance itself and not the SSRC.
5. The code did not properly handle explicitly unbundling an
RTP instance from its parent. This now works as expected.
ASTERISK-27143
Change-Id: Ibd91362f0e4990b6129638e712bc8adf0899fd45
A previous commit added plumbing to bridge_softmix to allow for an SFU
experience with Asterisk. This commit adds an option to app_confbridge
that allows for a confbridge to actually make use of the SFU video mode.
SFU mode is implemented in a "set it and forget it" kind of way. That
is, when the bridge is created, if SFU mode is enabled, then the video
mode gets set to SFU and cannot be changed. Future improvements may
allow for a hybrid experience (e.g. forward multiple video streams,
specifically those of the most recent talkers), but for this addition,
no such capability is present.
Change-Id: I87bbcb63dec6dbbb42488f894871b86f112b2020
This sets up the "plumbing" in bridge_softmix to
be able to accommodate Asterisk asking as an SFU
(selective forwarding unit) for conferences.
The way this works is that whenever a channel enters or leaves a
conference, all participants in the bridge get sent a stream topology
change request. The topologies consist of the channels' original
topology, along with video destination streams corresponding to each
participants' source video streams. So for instance, if Alice, Bob, and
Carol are in the conference, and each supplies one video stream, then
the topologies for each would look like so:
Alice:
Audio,
Source video(Alice),
Destination Video(Bob),
Destination video (Carol)
Bob:
Audio,
Source video(Bob)
Destination Video(Alice),
Destination video (Carol)
Carol:
Audio,
Source video(Carol)
Destination Video(Alice),
Destination video (Bob)
This way, video that arrives from a source video stream can then be
copied out to the destination video streams on the other participants'
channels.
Once the bridge gets told that a topology on a channel has changed, the
bridge constructs a map in order to get the video frames routed to the
proper destination streams. This is done using the bridge channel's
stream_map.
This change is bare-bones with regards to SFU support. Some key features
are missing at this point:
* Stream limits. This commit makes no effort to limit the number of
streams on a specific channel. This means that if there were 50 video
callers in a conference, bridge_softmix will happily send out topology
change requests to every channel in the bridge, requesting 50+
streams.
* Configuration. The plumbing has been added to bridge_softmix, but
there has been nothing added as of yet to app_confbridge to enable SFU
video mode.
* Testing. Some functions included here have unit tests.
However, the functionality as a whole has only been verified by
hand-tracing the code.
* Selectivenss. For a "selective" forwarding unit, this does not
currently have any means of being selective.
* Features. Presumably, someone might wish to only receive video from
specific sources. There are no external-facing functions at the moment
that allow for users to select who they receive video from.
* Efficiency. The current scheme treats all video streams as being
unidirectional. We could be re-using a source video stream as a
desetnation, too. But to simplify things on this first round, I did it
this way.
Change-Id: I7c44a829cc63acf8b596a337b2dc3c13898a6c4d
This patch is the first cut at adding stream support to the bridging framework.
Changes were made to the framework that allows mapping of stream topologies to
a bridge's supported media types.
The first channel to enter a bridge initially defines the media types for a
bridge (i.e. a one to one mapping is created between the bridge and the first
channel). Subsequently added channels merge their media types into the bridge's
adding to it when necessary. This allows channels with different sized
topologies to map correctly to each other according to media type. The bridge
drops any frame that does not have a matching index into a given write stream.
For now though, bridge_simple will align its two channels according to size or
first to join. Once both channels join the bridge the one with the most streams
will indicate to the other channel to update its streams to be the same as that
of the other. If both channels have the same number of streams then the first
channel to join is chosen as the stream base.
A topology change source was also added to a channel when a stream toplogy
change request is made. This allows subsystems to know whether or not they
initiated a change request. Thus avoiding potential recursive situations.
ASTERISK-26966 #close
Change-Id: I1eb5987921dd80c3cdcf52accc136393ca2d4163
Adds binaural synthesis to bridge_softmix (via convolution using libfftw3).
Binaural synthesis is conducted at 48kHz.
For a conference, only one spatial representation is rendered.
The default rendering is applied for mono-capable channels.
ASTERISK-26292
Change-Id: Iecdb381b6adc17c961049658678f6219adae1ddf
In multi-party bridges, Asterisk currently supports two video modes:
* Follow the talker, in which the speaker with the most energy is shown
to all participants but the speaker, and the speaker sees the
previous video source
* Explicitly set video sources, in which all participants see a locked
video source
Prior to this patch, ARI had no ability to manipulate the video source.
This isn't important for two-party bridges, in which Asterisk merely
relays the video between the participants. However, in a multi-party
bridge, it can be advantageous to allow an external application to
manipulate the video source.
This patch provides two new routes to accomplish this:
(1) setVideoSource: POST /bridges/{bridgeId}/videoSource/{channelId}
Sets a video source to an explicit channel
(2) clearVideoSource: DELETE /bridges/{bridgeId}/videoSource
Removes any explicit video source, and sets the video mode to talk
detection
ASTERISK-26595 #close
Change-Id: I98e455d5bffc08ea5e8d6b84ccaf063c714e6621
Currently if a channel is transferred out of a bridge, the BRIDGEPEER
variable (also BRIDGEPVTCALLID) remain set even once the channel is
out of the bridge. This patch removes these variables when leaving
the bridge.
ASTERISK-25600 #close
Reported by: Mark Michelson
Change-Id: I753ead2fffbfc65427ed4e9244c7066610e546da
During an attended transfer a thread is started that handles imparting the
bridge channel. From the start of the thread to when the bridge channel is
ready exists a gap that can potentially cause problems (for instance, the
channel being swapped is hung up before the replacement channel enters the
bridge thus stopping the transfer). This patch adds a condition that waits
for the impart thread to get to a point of acceptable readiness before
allowing the initiating thread to continue.
ASTERISK-24782
Reported by: John Bigelow
Change-Id: I08fe33a2560da924e676df55b181e46fca604577
Switch logger callid's from AO2 objects to simple integers.
This helps in two ways. Copying integers is faster than
referencing AO2 objects, so this will result in a small
reduction in logger overhead. This also erases the possibility
of an infinate loop caused by an invalid callid in
threadstorage.
ASTERISK-24833 #comment Committed callid conversion to trunk.
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4466/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When swapping a Local channel in place of one already
in a bridge (to complete a bridge attended transfer),
the channel that was swapped out can actually be hung
up before the stasis bridge push callback executes on
the independant transfer thread. This results in the
stasis app loop dropping out and removing the control
that has the the app name which the local replacement
channel needs so it can re-enter stasis.
To avoid this race condition a new push_peek callback
has been added, and called from the ast_bridge_impart
thread before it launches the independant thread that
will complete the transfer. Now the stasis push_peek
callback can copy the stasis app name before the swap
channel can hang up.
ASTERISK-24649
Review: https://reviewboard.asterisk.org/r/4382/
........
Merged revisions 431450 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431451 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When code imparts a channel into a bridge to swap with another channel, a
ref needs to be held on the swap channel to ensure that it cannot
dissapear before finding it in the bridge.
* The ast_bridge_join() swap channel parameter now always steals a ref for
the swap channel. This is the only change to the bridge framework's
public API semantics.
* bridge_channel_internal_join() now requires the bridge_channel->swap
channel to pass in a ref.
ASTERISK-24649
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4354/
........
Merged revisions 430975 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
Bridges have two new optional properties, a creator and a name.
Certain consumers of bridges will automatically provide bridges that
they create with these properties. Examples include app_bridgewait,
res_parking, app_confbridge, and app_agent_pool. In addition, a name
may now be provided as an argument to the POST function for creating
new bridges via ARI.
(closes issue AFS-47)
Review: https://reviewboard.asterisk.org/r/3070/
........
Merged revisions 404042 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404043 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There were still a few cases in which ATTENDEDTRANSFER and BLINDTRANSFER
wouldn't be set on channels involved with blind and attended transfers.
This would happen with features that were initialized by channel driver
specific mechanisms in multiparty calls. This patch resolves those cases
while attempted to keep the behavior for setting those variables as
consistent as possible.
(closes issue AFS-24)
Review: https://reviewboard.asterisk.org/r/3040/
........
Merged revisions 403781 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds the following AMI events, closely following their CLI counterparts:
BridgeDestroy
BridgeKick
BridgeTechnologyList
BridgeTechnologySuspend
BridgeTechnologyUnsuspend
BridgeDestroy kicks an entire bridge, where BridgeKick kicks just one
channel off the bridge. When kicking a channel, specifying the bridge
also (optional) insures it is not removed from the wrong bridge. The
BridgeTechnology events allow viewing and changing suspension status,
which affects only subsequent not active bridging.
(closes ASTERISK-22356)
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/2973/
........
Merged revisions 402387 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402388 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Dial, Queue, and FollowMe applications need to inhibit the bridging
initial connected line exchange in order to support the 'I' option.
* Replaced the pass_reference flag on ast_bridge_join() with a flags
parameter to pass other flags defined by enum ast_bridge_join_flags.
* Replaced the independent flag on ast_bridge_impart() with a flags
parameter to pass other flags defined by enum ast_bridge_impart_flags.
* Since the Dial, Queue, and FollowMe applications are now the only
callers of ast_bridge_call() and ast_bridge_call_with_flags(), changed the
calling contract to require the initial COLP exchange to already have been
done by the caller.
* Made all callers of ast_bridge_impart() check the return value. It is
important. As a precaution, I also made the compiler complain now if it
is not checked.
* Did some cleanup in parking_tests.c as a result of checking the
ast_bridge_impart() return value.
An independent, but associated change is:
* Reduce stack usage in ast_indicate_data() and add a dropping redundant
connected line verbose message.
(closes issue ASTERISK-22072)
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/2845/
........
Merged revisions 399136 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The cause code needs to be passed from the disconnecting channel to the
bridge peers if the disconnecting channel dissolves the bridge.
* Made the call to an app_agent_pool agent disconnect with the busy cause
code if the agent does not ack the call in time or hangs up before acking
the call.
(closes issue ASTERISK-22042)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2772/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397472 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SIP/foo -- Local;1==Local;2 -- .... -- Local;1==Local;2 -- SIP/bar
Kick a ;1 channel and the chain toward SIP/foo goes away.
Kick a ;2 channel and the chain toward SIP/bar goes away.
This can leave a local channel chain between the kicked ;1 and ;2 channels
that are orphaned until you manually request one of those channels to
hangup or request the bridge to dissolve.
* Added ast_bridge_kick() as a companion to ast_bridge_remove(). The
functional difference is that ast_bridge_kick() may dissolve the bridge as
a result of the channel leaving the bridge.
* Made CLI "bridge kick <bridge> <channel>" use ast_bridge_kick() instead
of ast_bridge_remove() so the bridge can dissolve if needed.
* Renamed bridge_channel_handle_hangup() to ast_bridge_channel_kick() and
made it accessible to other files.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396877 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The lonely flag is an optional flag for bridge channels that will
make them leave a bridge when a channel leaves if only lonely
channels are in the bridge at that point. This is useful for things
like ending recording and playback channels when they cease to be
interacting with other channels in the bridge.
(closes issue ASTERISK-22117)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2721/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In working with res_stasis, I discovered a significant limitation to
the current structure of stasis_caching_topics: you cannot subscribe
to cache updates for a single channel/bridge/endpoint/etc.
To address this, this patch splits the cache away from the
stasis_caching_topic, making it a first class object. The stasis_cache
object is shared amongst individual stasis_caching_topics that are
created per channel/endpoint/etc. These are still forwarded to global
whatever_all_cached topics, so their use from most of the code does
not change.
In making these changes, I noticed that we frequently used a similar
pattern for bridges, endpoints and channels:
single_topic ----------------> all_topic
^
|
single_topic_cached ----+----> all_topic_cached
|
+----> cache
This pattern was extracted as the 'Stasis Caching Pattern', defined in
stasis_caching_pattern.h. This avoids a lot of duplicate code between
the different domain objects.
Since the cache is now disassociated from its upstream caching topics,
this also necessitated a change to how the 'guaranteed' flag worked
for retrieving from a cache. The code for handling the caching
guarantee was extracted into a 'stasis_topic_wait' function, which
works for any stasis_topic.
(closes issue ASTERISK-22002)
Review: https://reviewboard.asterisk.org/r/2672/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395954 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Changes arguments for BridgeWait from BridgeWait(role, options) to
BridgeWait(bridge_name, role, options). Now multiple holding bridges may
be created and referenced by this application.
(closes issue ASTERISK-21922)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2642/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch renames the bridging* files to bridge*. This may seem pedantic
and silly, but it fits better in line with current Asterisk naming conventions:
* channel is not "channeling"
* monitor is not "monitoring"
etc.
A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is
the act of using a bridge on a set of channels - and the API that fulfills that
role is more than just the action.
(closes issue ASTERISK-22130)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Alexander Traud
Josh Soref
George Joseph
Joshua C. Colp
Friendly Automation
Holger Hans Peter Freyther
Joshua Colp
sungtae kim
Richard Mudgett
Mark Michelson
Kevin Harwell
frahaase
Matt Jordan
Jonathan Rose
Corey Farrell
Scott Griepentrog
David M. Lee