SRTP and media encryption for VoIP, explained

Signalling is not the same as media

A VoIP call has two parts: the signalling that sets it up and tears it down, and the media that carries the audio. Protecting one does not protect the other. It is common to find signalling secured with TLS while the audio still travels as plain Real-time Transport Protocol, which can be captured and replayed by anyone on the media path.

The control for the media is the Secure Real-time Transport Protocol, defined by the IETF in RFC 3711, which adds encryption and integrity so a captured stream is not intelligible.

How SRTP is keyed

SRTP protects the media, but it needs keys, and those keys must be exchanged safely. In practice media encryption is tied to secure signalling, so if signalling is protected the keys can be exchanged under that protection. In browser-based WebRTC, media is protected with DTLS-SRTP.

This is why the two layers are assessed together. SRTP with keys exchanged over unprotected signalling is weaker than it looks, and signalling protected without SRTP leaves the conversation exposed.

Verifying that calls are actually protected

• Confirm that media uses SRTP for the calls that matter, not only that signalling uses TLS.
• Check that media does not silently fall back to unencrypted RTP when a device or path does not support SRTP.
• Confirm that key exchange is tied to protected signalling rather than sent in the clear.
• For browser-based calling, confirm DTLS-SRTP is in use.

Where an assessment fits

Whether media is genuinely protected is a question about the live service, not the documentation. An authorised VoIP security assessment checks that signalling and media are both protected, that there is no silent fallback, and that keys are exchanged safely, then reports what it finds with evidence. It is carried out only against systems you own or are authorised to test.