[Home]

Summary:ASTERISK-22104: Bridge API Enhancements - update the Native RTP bridge to better manage channels
Reporter:Matt Jordan (mjordan)Labels:Asterisk12
Date Opened:2013-07-18 13:24:07Date Closed:2013-07-31 09:30:04
Priority:MajorRegression?
Status:Closed/CompleteComponents:Core/Bridging
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:The Native RTP bridge could be subject to some nasty behavior when channels enter or leave a bridge, or when the bridge is updated via a smart bridge operation.

It currently relies on the {{bridge_pvt}} pointer in the {{bridge_channel}} structure to store the {{native_rtp_bridge_data}} for that channel. Doing this during a join or leave is apparently safe; however, performing it during a frame hook operation may not be.

{noformat}
/*
* BUGBUG The RTP native bridge technology should use tech_pvt not bridge_pvt.
*
* This technology needs to be reworked to not change the
* tech_pvt of channels other than the one that is currently
* entering/leaving before it can actually use the correct
* pointer.
*/
bridge_channel->bridge_pvt = data;

return 0;
}
{noformat}

Additionally, it should use the start/stop bridge callbacks to start/stop native RTP bridging. The start/stop callbacks are used during smartbridge operations - if the bridge mixing technology changes a number of operations will be done to the bridge mixing technology as well as to the channels in the bridge. The start/stop callbacks provide a safe way to prevent frames and other data from attempting to access the channels/bridge during that period of time.
Comments: