summaryrefslogtreecommitdiff
path: root/include/asterisk/bridge_technology.h
AgeCommit message (Collapse)Author
2013-10-03Fix assumption in bridge_native_rtp.c regarding number of participants in a ↵Mark Michelson
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
2013-07-25A great big renaming patchMatthew Jordan
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