> On Jan. 27, 2015, 3:57 p.m., rmudgett wrote: > > /branches/13/main/bridge_channel.c, lines 1998-2001 > > <https://reviewboard.asterisk.org/r/4378/diff/1/?file=71097#file71097line1998> > > > > The reason a swap channel is pulled after the new channel is pushed is > > because pulling the last channel out of a bridge may dissolve it! This is > > not good. If the AST_BRIDGE_FLAG_DISSOLVE_EMPTY flag is set the bridge > > will dissolve. Most mixing bridges are going to have this flag set. > > > > The bridge technology must deal only with the channels that the bridge > > core has told it about with the technology join/leave callbacks. > > Otherwise, what is the point of the join/leave technology callbacks if the > > technology is going to look at the bridge channel member list at > > inappropriate times? > > Joshua Colp wrote: > That flag can be unset and reset appropriately. The bridge is locked > during this operation. > > I firmly disagree with your statement about the bridge technology only > dealing with channels it has been told about. That means each bridge > technology has to DUPLICATE information that the core already has. And the > point of the join/leave callbacks is so the bridge technology can react to > the act of a channel joining or leaving a bridge. In case of > bridge_native_rtp that means setting up local bridging or doing reinvites.
Additionally: During testing there was always one other channel in the bridge so the dissolve check never kicked in. - Joshua ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4378/#review14308 ----------------------------------------------------------- On Jan. 27, 2015, 12:06 p.m., Joshua Colp wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4378/ > ----------------------------------------------------------- > > (Updated Jan. 27, 2015, 12:06 p.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 431112 > /branches/13/main/bridge_channel.c 431112 > > 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
