[asterisk-dev] SRTP configuration and behavior in Asterisk18
bob.beers at gmail.com
Mon Feb 7 16:31:32 CST 2011
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 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, 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.
More information about the asterisk-dev