[asterisk-dev] SRTP configuration and behavior in Asterisk18

[Bob Beers]

Hi list,

IMO, the current situation (trunk) includes these short-comings wrt SRTP
(not necessarily in order of importance):
a - Asterisk can only offer one crypto-suite in outgoing INVITEs,
b - The only crypto-suite Asterisk will offer is "AES_CM_128_HMAC_SHA1_80",
c - Asterisk will accept the first crypto-suite offered in incoming INVITEs --
     no way to accept alternate (2nd/3rd) offered crypto-suite if preferred,
d - Asterisk has no means to specify use of the NULL cipher for SRTP stream,
e - Asterisk does not have any way to use different crypto suites or keys
     for audio/video/text streams in the same offer/answer,
f - Asterisk does not understand lifetime or MKI:length parameter,
     and rejects INVITE if either is present,

I have an opened this issue[1] upon which I have spent some effort.
So far my efforts/patches only attempt to address letter b above.

I have been encouraged to "keep it simple, seriously" and only add
 new  values for the encryption=... param.
But upon reading (again) from a relevant RFC document[2], and
 spending some non-negligable time in the code, I think a more
 intrusive correction is called for.
Since, in the offer/answer model, the crypto-suite is a negotiated
 parameter, much like codec is, I suggest Asterisk should have a
 more codec-like behavior in both configuration and negotiation of
 the SRTP crypto settings.  (allow_encryption|deny_encryption perhaps?)
Doing so may resolve issues a, b and c in a single effort.
Issues d, e, and f will require more thought.

So, I humbly solicit opinions from Asterisk developers and potential
 SRTP implementors about how to best resolve these issues.

I also welcome any ideas about correcting any other issues related to
 Asterisk18 SRTP capability.

respectfully,
-Bob Beers

[1]: <https://issues.asterisk.org/view.php?id=18674>
[2]: <http://tools.ietf.org/html//rfc4568>