SRTPAlso known as Secure Real-time Transport Protocol

How SRTP works

SRTP keeps the RTP header readable (so routers and jitter buffers still work) but encrypts the payload and appends an authentication tag. The default suite, AES_CM_128_HMAC_SHA1_80, uses a 128-bit AES key and an 80-bit tag; the _32 variant uses a shorter tag. A companion protocol, SRTCP, protects the RTCP statistics channel.

Both ends need the same keys, which SRTP itself does not provide. Three key-exchange methods are common:

• SDES (RFC 4568): keys are sent in the SDP body as a=crypto lines. Simple and widely supported, but only safe when signalling is encrypted with TLS.
• DTLS-SRTP (RFC 5763/5764): keys are negotiated in a DTLS handshake on the media path. Mandatory in WebRTC.
• ZRTP (RFC 6189): peer-to-peer key agreement with a short authentication string users can compare.

SRTP and TLS together

TLS encrypts SIP signalling (who is calling whom, and SDES keys); SRTP encrypts the audio. Using one without the other leaves a gap: SRTP with SDES over plain UDP exposes the keys, and TLS without SRTP leaves the voice in clear text. Our guide to SIP security with TLS and SRTP covers configuration on common PBXs.

Practical considerations

Every hop that needs to touch the audio, such as an SBC that transcodes or records, must decrypt and re-encrypt it, so SRTP is usually hop-by-hop rather than end-to-end. On a mobile gateway call, the radio leg is protected separately by the mobile network’s own air-interface encryption.