----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3997/#review13518 -----------------------------------------------------------
/branches/12/bridges/bridge_native_rtp.c <https://reviewboard.asterisk.org/r/3997/#comment24038> No, AST_LIST_FIRST and AST_LIST_LAST would return the same thing since it's a linked list containing one channel. - Joshua Colp On Oct. 13, 2014, 5:32 p.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3997/ > ----------------------------------------------------------- > > (Updated Oct. 13, 2014, 5:32 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24327 > https://issues.asterisk.org/jira/browse/ASTERISK-24327 > > > Repository: Asterisk > > > 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: > > (1) 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). > (2) 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. > > This patch modifies bridge_native_rtp such that it keeps track of the > channels itself. Given how tricky this code is - both smart bridging and > native RTP bridging - this keeps the mixing technology insulated from changes > in the core, which is probably a good thing. > > > Diffs > ----- > > /branches/12/bridges/bridge_native_rtp.c 425404 > > Diff: https://reviewboard.asterisk.org/r/3997/diff/ > > > Testing > ------- > > The tests that extercised this code the most are the PJSIP blind transfer > tests, as they change the bridge mixing technology from native_rtp to simple > and back in various tests. Shocking the callee_with_hold/caller_with_hold > tests worked right off the bat. The direct media tests still fail, but this > is not surprising as the messages from Asterisk arrive interleaved, which is > not something SIPp handles well (at all). > > > Thanks, > > Matt Jordan > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
