[SR-Users] Dealing with optional SRTP

Mark Boyce mark at darkorigins.com
Sat Aug 24 12:07:55 CEST 2019


Hi all

(Using Kamailio + RTPEngine, both current stable versions)

Just wondering what current best practice is for dealing with “optional SRTP” such as those generated by Yealink devices. (I know this breaks the RFC but lots of things seem to use this method.) Where the device SDP message looks like;

m=audio 50004 RTP/AVP 8 97 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:uhJOWOXPuzMeBmrbx2wAKohuveAvZeMEJTzfE7GT
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:yF+EhR3RtxSDCGtLCnEAl3Zrdut4b8cfFQP+hFqf

An unencrypted RTP/AVP media line but with crypto lines showing that the device will support SRTP encryption but it is not mandatory.

The system of offer SRTP and try and catch on not supported/acceptable here fail feels a little clumsy and relies on how gracefully the device sends “not acceptable here”.

I’m wondering if I just short cut it and say that if a device offers a acceptable crypto line then Kamailio sends back a SAVP response. 


Naturally this question is then closely followed by how to do optional SRTP invites originating from Kamailio without just directly manipulating lines?

Feels like there should be an RTPEngine setting for Optional?  RTP/AVP+SAVP ?

Thoughts?

Mark




More information about the sr-users mailing list