Opportunistic SRTP Support in VoIP Devices

The widely used VoIP signalling protocol SIP has a bad reputation. In my opinion it's mostly unwarranted. If you don't stray too far off piste and have a decent NAT traversal behaviour things will generally work fine.

In the ideal world everything would be encrypted, but there's a plethora of end of life and unsupported devices out there, and devices which may support encryption are often configured by end users that may not enable it.

Enter Opportunistic SRTP - a method of encrypting the audio stream if it's supported by the other end, and it's not supported just fall back to plain old RTP

Photo by Markus Spiske on Unsplash

There's two methods for supporting opportunistic RTP, the first covered indirectly in RFC3264 and the second explicitly in RFC8643 

RFC3264

RFC3264 states we can include multiple streams within the SDP offer, and the callee can reject a stream by answering with the port for that stream set to 0. So in theory we could offer two streams, one with encryption and one without, and let the called end point select which one it accepts. In the event it accepts both, the caller could then send a RE-INVITE to select it's preferred encrypted stream.

Here's an example offer containing two streams, one with encryption and the other without, compatible with RFC3264:

v=0
o=blah-3745B801 1251125182 1300868845 IN IP4 93.184.216.34
s=-
c=IN IP4 93.184.216.34
t=0 0
m=audio 22244 RTP/AVP 0 8 102
c=IN IP4 93.184.216.34
a=rtpmap:102 telephone-event/8000
a=fmtp:102 0-15
a=ptime:20
m=audio 22244 UDP/TLS/RTP/SAVP 0 8 102
c=IN IP4 93.184.216.34
a=rtpmap:102 telephone-event/8000
a=fmtp:102 0-15
a=ptime:20
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:81zD9gP+bDybfZ18fGSIOF0H7c67IvYZJ6MK8EAJ|2^31

And here's the corresponding answer, accepting the encrypted stream and rejecting the unencrypted stream by setting the port to 0:

v=0
o=foo-3745B3234 1251125333 1300868888 IN IP4 198.51.100.22
s=-
c=IN IP4 198.51.100.22
t=0 0
m=audio 0 RTP/AVP 0 8 102
c=IN IP4 198.51.100.22
a=rtpmap:102 telephone-event/8000
a=fmtp:102 0-15
a=ptime:20
m=audio 11111 UDP/TLS/RTP/SAVP 0 8 102
c=IN IP4 198.51.100.22
a=rtpmap:102 telephone-event/8000
a=fmtp:102 0-15
a=ptime:20
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:81zD9gP+bDybfZ18fGSIOF0H7c67IvYZJ6MK8EAJ|2^31

RFC8643

RFC8643 states we can offer a single stream with the RTP/AVP profile, but include the SRTP key information in the attributes so if the endpoint supports SRTP it will use it, if not, it will be ignored.

Here's an example offer containing a single stream, with the profile set to RTP/AVP and a SDES key in the attributes:

v=0
o=blah-3745B801 1251125182 1300868845 IN IP4 93.184.216.34
s=-
c=IN IP4 93.184.216.34
t=0 0
m=audio 22244 RTP/AVP 0 8 102
c=IN IP4 93.184.216.34
a=rtpmap:102 telephone-event/8000
a=fmtp:102 0-15
a=ptime:20
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:81zD9gP+bDybfZ18fGSIOF0H7c67IvYZJ6MK8EAJ|2^31

And here's the corresponding answer which also includes an SDES key, indicating support for SRTP:

v=0
o=foo-3745B3234 1251125333 1300868888 IN IP4 198.51.100.22
s=-
c=IN IP4 198.51.100.22
t=0 0
m=audio 11111 RTP/AVP 0 8 102
c=IN IP4 198.51.100.22
a=rtpmap:102 telephone-event/8000
a=fmtp:102 0-15
a=ptime:20
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:81zD9gP+bDybfZ18fGSIOF0H7c67IvYZJ6MK8EAJ|2^31

End Point Support

At the time of writing I can only test the RFC3264 method with two streams in the offer. When I get around to writing some SIPp scenarios to emulate the RFC8643 method, I'll update the blog.

All devices were configured to require encrypted SRTP.

Device	RFC3264 opportunistic SRTP support?	Notes
Yealink T42G	YES	Responds with a single RTP/AVP Profile with an SDES key, as per RFC8643
Groundwire (Android)	NO	Buggy. With SRTP set to required it accepts the unencrypted profile. With DTLS set to required it accepts the encrypted profile - but no audio.
Bria (Android)	NO	Rejected with a 488
Polycom VVX 450	YES	Responds with a single RTP/AVP Profile with an SDES key, as per RFC8643
Cisco SPA504G	NO	Accepts the RTP/AVP profile without an SDES key.

What about a late offer?

This is a "ninja-edit" if you will. Whilst looking into something unrelated, I recalled what's called a later offer - where the initial INVITE to an endpoint doesn't contain an SDP body, and the SDP is included with the ACK after a 200 has been received. This inverses the offer / answer and means the caller is aware of what's supported before negotiating the stream.

This could be a better way of implementing Opportunistic SRTP, assuming end points properly support a later offer. Unfortunately I don't believe many SIP servers expose this level of control. Asterisk certainly doesn't, and whilst Freeswitch supports late negotiation to avoid transcoding, it's not clear if it can be utilised to select different profiles based on AVP vs SAVP profiles.