> On Feb. 18, 2015, 1:57 p.m., Mark Michelson wrote:
> > /branches/11/channels/sip/sdp_crypto.c, line 304
> > <https://reviewboard.asterisk.org/r/4419/diff/1/?file=71388#file71388line304>
> >
> >     Since we're only concerned about an integer value here, would the 
> > following work:
> >     
> >     sdes_lifetime = 2UL << n_lifetime;
> >     
> >     ?
> >     
> >     pow() probably has a built-in optimization for raising 2 to integer 
> > powers, but the fact that it returns a double means that there is still the 
> > issue of type conversion when using it.
> >     
> >     Also I have a question here: since n_lifetime can be as large as 48, 
> > does this have the possibility of overflow on 32-bit architectures? The 
> > double returned by pow() can hold the value just fine, but when casting to 
> > unsigned long, what happens?
> 
> rmudgett wrote:
>     I think that would be:
>     sdes_lifetime = 1UL << n_lifetime;
>     :)
> 
> Mark Michelson wrote:
>     Ah yes, my mistake.

Unfortunately, the default recommended max lifetime for SRTP is 2^48, which 
means we probably should just use a double for storage and comparisons.

Tha also means using pow, and not using a bit shift.


- Matt


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


On Feb. 13, 2015, 9:26 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4419/
> -----------------------------------------------------------
> 
> (Updated Feb. 13, 2015, 9:26 p.m.)
> 
> 
> Review request for Asterisk Developers and Olle E Johansson.
> 
> 
> Bugs: ASTERISK-17721, ASTERISK-17899 and ASTERISK-22748
>     https://issues.asterisk.org/jira/browse/ASTERISK-17721
>     https://issues.asterisk.org/jira/browse/ASTERISK-17899
>     https://issues.asterisk.org/jira/browse/ASTERISK-22748
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Note that this patch is a forward port of oej's lingon-srtp-key-lifetime-1.8 
> branch, with a few small modifications to reduce block indentation and a few 
> improvements made to surrounding existing code.
> 
> To quote Olle from ASTERISK-17721:
> 
> {quote}
> The Lingon branch now handle lifetime and MKI parameters.
> 
> We only accept lifetimes up to max for the crypto and higher than 10 hours 
> for packetization of 20 ms (50 pps).
> 
> We only handle MKI with index 1.
> 
> We do not really bother with counting packets and reinviting at end of 
> lifetime, so the min of 10 hours kind of takes care of most calls. If there 
> are longer ones, we rely on the other side for re-invites.
> 
> It's still not perfect, but I personally think this is an improvement. A 
> configuration option for minimum lifetime accepted could be added.
> {quote}
> 
> I personally don't think the minimum lifetime option is needed, as in 
> practice, every instance of an SDP offer for SDES-SRTP with lifetime I've 
> seen offers a lifetime of 2^32 - but it could be added in the future if 
> necessary.
> 
> Note that since the sdp_crypto code was moved to the core in 12+, a separate 
> review (r4418) has been made for the Asterisk 13 variant. It is essentially 
> identical to this review.
> 
> 
> Diffs
> -----
> 
>   /branches/11/channels/sip/sdp_crypto.c 431750 
> 
> Diff: https://reviewboard.asterisk.org/r/4419/diff/
> 
> 
> Testing
> -------
> 
> Tests were added for chan_sip and updated for chan_pjsip - see 
> https://reviewboard.asterisk.org/r/4420 . This includes both nominal and 
> off-nominal offers negotiating SDES-SRTP.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

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