-----------------------------------------------------------
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

Reply via email to