> On Jan. 27, 2015, 11:05 a.m., rmudgett wrote: > > I'm fine with the bridge core change.
Quoting from my statements on IRC: (11:27:55 AM) mjordan: file: I'd say go ahead and ship in https://reviewboard.asterisk.org/r/4378/ (11:28:03 AM) mjordan: file: if we have some testsuite blow ups, I'd rather catch them tonight I'd like to make sure we have time to correct any fall-out from this patch this week, as we're getting close to needing to put out an RC. - Matt ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4378/#review14316 ----------------------------------------------------------- On Jan. 27, 2015, 10:59 a.m., Joshua Colp wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4378/ > ----------------------------------------------------------- > > (Updated Jan. 27, 2015, 10:59 a.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > ------- > > Currently there exists two issues which prevent direct media from being > reinvited depending on the scenario: > > 1. During a swap operation for a brief period of time there will exist 3 > channels in a bridge. This is NOT handled by the bridge_native_rtp module and > causes it to not reinvite one of the channels that it should when it may be > leaving. As it's a reasonable expectation for a bridge technology which can > only handle 2 channels to only ever see 2 I've moved the operation which > causes the swap channel to leave to before the new channel is actually added > to the bridge. This means bridge_native_rtp only sees the two channels it saw > previously and reinvites occur as expected. > > 2. If the res_pjsip_sdp_rtp module received a re-invite *AFTER* the session > had been established it did not notify upstream that things such as the > bridge_native_rtp module should re-evaluate and potentially reinvite the > remote side. The res_pjsip_sdp_rtp module will now do this using the > UPDATE_RTP_PEER control frame if an offer is received after the session is > established. > > > Diffs > ----- > > /branches/13/res/res_pjsip_sdp_rtp.c 431113 > /branches/13/main/bridge_channel.c 431113 > > Diff: https://reviewboard.asterisk.org/r/4378/diff/ > > > Testing > ------- > > Tried various scenarios including attended transfers and multiple Asterisk > instances in the path. Previously media would go via the wrong route or not > at all. With patch reinvites occur as expected. > > > Thanks, > > Joshua Colp > >
-- _____________________________________________________________________ -- 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
