----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3992/#review13454 -----------------------------------------------------------
Just as a note to this, we tested this patch a *lot* at SIPit 31. A few things to state about it: * There is an outstanding issue in this patch where we will respond with crypto keys to an RTP/AVP offer that did not contain crypto keys. If we aren't offered crypto keys, we shouldn't respond to it. * Other than that, the patch worked great. While opportunistic (optimistic?) encryption is not a 'standard', it is used by the vast majority of endpoints out there. The industry accepted practice is "encrypt everything whenever possible". You don't have to call it 'secure', but it's better than nothing. - Matt Jordan On Sept. 13, 2014, 7:25 p.m., Joshua Colp wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3992/ > ----------------------------------------------------------- > > (Updated Sept. 13, 2014, 7:25 p.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > ------- > > When enabling SRTP support in PJSIP it is either forced on or disabled. This > means that if you specify SRTP but the client does not support it the session > will fail. For situations where this guarantee is not required this new > functionality can be used to optimistically use SRTP if possible. This has > the added benefit of encrypting the media when possible but does not > guarantee it. This also fixes an issue where a client may offer SRTP using > the normal transport but we reject it. > > > Diffs > ----- > > /trunk/res/res_pjsip_sdp_rtp.c 423064 > /trunk/res/res_pjsip/pjsip_configuration.c 423064 > /trunk/res/res_pjsip.c 423064 > /trunk/include/asterisk/res_pjsip.h 423064 > /trunk/configs/samples/pjsip.conf.sample 423064 > > Diff: https://reviewboard.asterisk.org/r/3992/diff/ > > > Testing > ------- > > Used Blink to place calls with optimistic enabled and disabled on the PJSIP > side. > In Blink I alternated between disabled/mandatory/optional. > Confirmed that for each scenario the expected outcome occurred. > > Blink Asterisk Result > Disabled Optimistic Off Failed > Disabled Optimistic On Success (Not encrypted) > Mandatory Optimistic Off Success (Encrypted) > Mandatory Optimistic On Success (Encrypted) > Optional Optimistic Off Success (Encrypted) > Optional Optimistic On Success (Encrypted) > > > 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