----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3982/#review13299 -----------------------------------------------------------
Ship it! /branches/13/res/res_rtp_asterisk.c <https://reviewboard.asterisk.org/r/3982/#comment23775> Blob cleanup /branches/13/res/res_rtp_asterisk.c <https://reviewboard.asterisk.org/r/3982/#comment23776> Slap an assert here, as something has gone wrong if we get a transport type that we don't support passed to this function /branches/13/res/res_rtp_asterisk.c <https://reviewboard.asterisk.org/r/3982/#comment23777> This probably needs a WARNING message, as PJPROJECT not creating something won't get caught by our allocation routines - Matt Jordan On Sept. 10, 2014, 6:24 a.m., Joshua Colp wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3982/ > ----------------------------------------------------------- > > (Updated Sept. 10, 2014, 6:24 a.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-23577 and ASTERISK-23634 > https://issues.asterisk.org/jira/browse/ASTERISK-23577 > https://issues.asterisk.org/jira/browse/ASTERISK-23634 > > > Repository: Asterisk > > > Description > ------- > > The TURN support in res_rtp_asterisk has been exercised by only a few, which > has uncovered a slew of issues. > > 1. The number of file descriptors that an ioqueue instance in pjlib can > support is a fixed number. Exceeding this causes an assertion. The code will > now dynamically create/terminate threads as needed to ensure that this limit > is not exceeded on ioqueue instances. > 2. The API did not allow users of the TURN code to explicitly request a TURN > session with details. This has been added. > 3. The ICE code has a fixed size array of 4 for transports. As our transport > identifiers started at 1 we were exceeding this causing an assertion. Our > identifiers now start at 0. > 4. The TURN client did not set up client binding causing needless bandwidth > usage. Upon ICE completion if TURN is used channel binding is now established. > 5. The code will no longer update address information on every sent packet. > The remote address is now updated only once upon ICE completion to the target > address. > 6. When relaying was in use STUN traffic was getting looped back to > res_rtp_asterisk due to it being handled on the normal socket. It is now > handled in the TURN session callback instead. > 7. Logging when a TURN relay is in use now uses the IP address that the TURN > relay is sending/receiving to/from on our behalf. > 8. Synchronization between the TURN session and the RTP instance now ensures > that the session has been fully created or fully destroyed before continuing. > 9. Some cleanup has occurred when tearing down the pj environment. > > > Diffs > ----- > > /branches/13/res/res_rtp_asterisk.c 422898 > /branches/13/include/asterisk/rtp_engine.h 422898 > > Diff: https://reviewboard.asterisk.org/r/3982/diff/ > > > Testing > ------- > > Sabotaged the code so the only candidates I sent were of the relay type. > Confirmed bidirectional media flow using the TURN relay. > > > 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
