Summary:	ASTERISK-24327: bridge_native_rtp: Smart bridge operation to softmix sometimes fails to properly re-INVITE remotely bridged participants
Reporter:	Matt Jordan (mjordan)	Labels:
Date Opened:	2014-09-15 16:06:44	Date Closed:	2014-10-16 20:58:23
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Bridges/bridge_native_rtp
Versions:	12.5.0 13.0.0-beta1	Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When a native RTP bridge that is remotely bridging its participants switches to a softmix bridge, it may not properly re-INVITE the media for one or both participants back to Asterisk. This is due to two factors: # The current {{bridge_native_rtp}} code only re-INVITEs if it believes the channel will survive the bridge operation. Currently, that code is failing, as it expects the channels to have a soft hangup flag set on it indicating that a redirect has occurred or that the channel is going to leave the bridge. (The code did not take into account a smart bridge operation). # When the bridge layer performs a smart bridge, it passes a dummy bridge down into the old mixing technology when it is stopped. That breaks the native RTP bridge, as it looks to {{bridge->channels}} to know which channels to re-INVITE back. That list has no entries, as the dummy bridge does not populate that value. Given how tricky this code is - both smart bridging and native RTP bridging - the native RTP bridge should probably just keep track of its channels itself. That would keep it from having to trust what the bridge layer passes to it implicitly, as it has become very difficult to know what the bridging layer is going to give you when it calls a callback (other than a bridge pointer with (hopefully) your tech pvt).
Comments: