[asterisk-dev] [Code Review] Add ability to reload SRTP policies

[Matt Jordan]

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

Review request for Asterisk Developers, Joshua Colp and Mark Michelson.


Summary
-------

Currently, when using res_srtp, once the SRTP policy has been added to the current session the policy is locked into place.  Any attempt to add a new policy, which would replace an existing policy, is instead rejected in res_srtp.

This patch adds a new configurable option to rtp.conf.sample "srtpallowpolicyrenew" that instructs res_srtp to allow policies to be renewed.  Thus, if a SIP re-INVITE is sent to Asterisk with a new cryptographic key, and the SDP parsing contructs a new local/remote policy for the SRTP session, the policy will be re-added to the underlying library and the new key used for further SIP messages.

Since res_srtp didn't actually use a configuration object, or have 'reload' implemented for its module, I went ahead and added that as well.

This patch was written against 1.8; however, it could be argued that its a new behavior (hence the configurable parameter turning it on), I'm open to debate on whether or not this should go into trunk.  As a defense for it going into 1.8, there are phones that need this setting to function properly (as they send a re-INVITE in certain situations that have a new key)


Diffs
-----

  /branches/1.8/configs/rtp.conf.sample 354547 
  /branches/1.8/res/res_srtp.c 354547 
  /branches/1.8/CHANGES 354547 
  /branches/1.8/channels/sip/sdp_crypto.c 354547 

Diff: https://reviewboard.asterisk.org/r/1741/diff


Testing
-------

Made sure that the initial patch didn't break the SRTP test in the TestSuite.  Made sure that the module could be loaded, unloaded, and reloaded and that the configuration value was read.

More testing is needed to make sure that the key is actually re-generated properly and that the SRTP stream is removed from the underlying SRTP library.


Thanks,

Matt

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