| Age | Commit message (Collapse) | Author |
|---|
|
softmix_bridge_join() failed because of an allocation failure. To address
this, the softmix bridge technology now checks if the channel failed to
join softmix successfully. In addition, the bridge now begins the process
of kicking the channel out of the bridge so we don't have channels
partially in the bridge for very long.
* Fix the test_channel_feature_hooks.c unit tests. The test channel must
have a valid codec to join the simple_bridge technology. This patch makes
joining a bridge more strict by not allowing partially joined channels to
remain in the bridge.
Change-Id: I97e2ade6a2bcd1214f24fb839fda948825b61a2b
|
|
operation.
When a channel enters the bridging system it is first made compatible with
the bridge and then the bridge technology makes the channel compatible
with the technology. For all but the DAHDI native and softmix bridge
technologies the make channel compatible with the bridge step is an
effective noop because the other technologies allow all audio formats.
For the DAHDI native bridge technology it doesn't matter because it is not
an initial bridge technology and chan_dahdi allows only one native format
per channel. For the softmix bridge technology, it is a noop at best and
harmful at worst because the wrong translation path could be setup if the
channel's native formats allow more than one audio format.
This is an intermediate patch for a series of patches aimed at improving
translation path choices.
* Removed code dealing with the unnecessary step of making the channel
compatible with the bridge.
ASTERISK-24841
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4600/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434424 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
bridge.
When a party leaves a bridge, there may be more participants in the bridge than expected.
As such, it is important not to make assumptions regarding the list of channels in a
bridge.
This change makes it so that when a party leaves a native RTP bridge, we unbridge it and
the party it was bridged with. Previously, the first and last channels in the list were
unbridged since it was assumed that these were the two channels that had been bridged. As
previously stated, a new party had been inserted into the bridge, so this logic did not
work properly.
(closes issue ASTERISK-22615)
reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2899
........
Merged revisions 400403 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400452 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
|
