[asterisk-dev] [Code Review] Allow for reloading of crypto keys within same SIP dialog

[Joshua Colp]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1885/#review6068
-----------------------------------------------------------

Ship it!


I can think of no qualms to have with this.

- Joshua


On April 25, 2012, 9:52 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1885/
> -----------------------------------------------------------
> 
> (Updated April 25, 2012, 9:52 a.m.)
> 
> 
> Review request for Asterisk Developers, Mark Michelson and opticron.
> 
> 
> Summary
> -------
> 
> This is really a continuation of https://reviewboard.asterisk.org/r/1741/.
> 
> That patch allowed reloading of SRTP keys during transfer scenarios.  What was missed, however, was the more common case where a new key is requested within the context of a current SIP dialog.  This can occur with certain phones when said phone is put on hold.
> 
> Previously, once a dialog was associated with an SRTP object, any subsequent attempt to process crypto keys in any SDP offer - either the current one or a new offer in a new SIP request - were ignored.  This patch changes this behavior to only ignore subsequent crypto keys within the current SDP offer, but allows future SDP offers to change the keys.
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 363307 
> 
> Diff: https://reviewboard.asterisk.org/r/1885/diff
> 
> 
> Testing
> -------
> 
> Confirmed by the initial issue reporter that this resolved the issue with SNOM phones having protect/unprotect problems after issuing a hold.  Also confirmed that it did not break the behavior previously introduced by r1741.
> 
> Ran the patch through the SRTP tests in the Asterisk Test Suite; verified no loss of functionality.
> 
> 
> Thanks,
> 
> Matt
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120426/c18a3edc/attachment.htm>