SIP over TLS vs SRTP: What Each One Protects

A SIP call has two separate traffic streams. Signaling, carried by SIP, sets the call up and tears it down. Media, carried by RTP, is the audio itself. TLS secures the first stream and SRTP secures the second. They work at different layers, protect different things and fail in different ways. Understanding the split explains why a "secure" setting in a softphone usually means two switches rather than one.

What travels in each stream?

Signaling is text. A SIP INVITE contains the caller's identity, the called number, routing headers, authentication headers and an SDP body that describes the media: codecs, IP addresses, ports and, in many setups, the encryption keys for the audio. A REGISTER request carries the digest response derived from your password.

Media is a sequence of small UDP packets, each holding a few milliseconds of encoded audio. RTP adds a header with timing and sequence information. RTCP, a companion protocol, carries quality statistics.

Someone who captures the signaling learns who called whom, when, and for how long. Someone who captures the media can listen to the conversation. Someone who captures both can do either, and can also take the SRTP keys out of the SDP if the signaling was not protected.

What does TLS protect?

TLS wraps the SIP connection in encryption and authentication. When a client connects to a server over TLS:

1. The server presents a certificate. The client checks that the certificate was issued by a trusted authority and that it matches the server name.
2. The two sides agree on session keys.
3. Every SIP message on that connection is encrypted and integrity-protected.

The result is that nobody on the network path can read the SIP headers, alter the SDP, or replay a digest response. The client also gains confidence that it is registering with the genuine server and not a device pretending to be it. RFC 3261 section 26 describes these threats and recommends TLS as the transport-layer answer.

TLS is hop by hop

A crucial limit: TLS protects one connection. Your client talks to your server over TLS. Your server then talks to the next server, perhaps a SIP trunk provider, over whatever transport they agreed on. That hop may or may not use TLS. Each server in the chain decrypts the message, reads it, and re-encrypts it for the next hop.

RFC 5630 explains how the sips URI scheme is meant to request secure transport on every hop, but in practice the client cannot verify what happens beyond the first server. When someone says "my SIP is encrypted", they usually mean the first hop only.

TLS requires a trustworthy certificate

TLS gives no protection against impersonation if the client accepts any certificate. That is why SIPdia requires a certificate from a public certificate authority and rejects self-signed ones. A PBX with a self-signed certificate can still be used securely over a VPN, where the VPN provides the encryption and the SIP transport can be plain UDP or TCP.

What does SRTP protect?

SRTP, defined in RFC 3711, encrypts the RTP payload and adds an authentication tag to each packet. It also protects RTCP. The RTP header stays in the clear so that routers and media servers can still handle the stream, but the audio inside is unreadable without the key.

Key properties:

• Confidentiality. The audio cannot be decoded by someone who captures the packets.
• Integrity. A modified or injected packet fails the authentication check and is dropped.
• Replay protection. Old packets cannot be re-sent to confuse the receiver.

SRTP says nothing about how the two endpoints agree on the key. That job belongs to a key exchange method, and the choice of method determines how much the signaling protection matters.

How are SRTP keys exchanged?

SDES: keys inside the SDP

The most widely deployed method is SDP Security Descriptions, or SDES, defined in RFC 4568. The caller puts a crypto attribute in the SDP of the INVITE, containing the cipher suite and a base64 key. The called party answers with its own crypto line. The two keys then protect the two directions of audio.

This is simple and widely supported, but it has an obvious consequence: the keys are written in the SIP message. If that message crosses the network without TLS, anyone who reads it can decrypt the audio. SDES only makes sense when the signaling is encrypted. This is why PBX guides, such as the Asterisk secure calling tutorial, set up TLS together with SRTP.

It also means SDES keys are visible to every server on the signaling path, because each hop decrypts the SIP message. The audio is confidential against outsiders but not against the servers that relay the call.

DTLS-SRTP: keys negotiated in the media path

RFC 5763 and RFC 5764 describe a different approach. The endpoints run a DTLS handshake directly over the media path and derive the SRTP keys from it. The SDP carries only a fingerprint of each side's certificate, not the key itself. An attacker who reads the SDP learns nothing useful, and a server that only relays the signaling cannot decrypt the audio. A PBX that handles the media itself, as a back-to-back user agent such as Asterisk does, terminates the DTLS session and can still hear the call.

DTLS-SRTP is the method used in WebRTC and is supported by some PBX systems for SIP as well. It still relies on protected signaling, usually TLS, because without it an attacker could swap the fingerprints in the SDP and insert themselves into the media path.

Why do you need both?

Put the pieces together:

Setup	Signaling exposed?	Audio exposed?
UDP or TCP, no SRTP	Yes	Yes
TLS, no SRTP	No	Yes
UDP or TCP with SDES SRTP	Yes, including the keys	Effectively yes
TLS with SRTP	No	No, on this hop

Only the last row keeps both the call details and the audio private on this hop. TLS alone hides who you are calling but not what you say. SRTP alone, with SDES, hands the key to anyone who can see the INVITE.

What does SIPdia offer?

SIPdia supports three SIP transports: UDP, TCP and TLS. Select TLS in the Transport field on the account page. The server must present a certificate from a public certificate authority. On iOS the trusted roots come from a bundled Mozilla certificate store.

For audio, the Advanced section has an Encrypt audio setting with three values:

• Off: plain RTP.
• Optional: offer SRTP and accept plain RTP if the server declines. Useful while you are testing server support.
• Required: the call fails unless SRTP is negotiated. Use this once you know the server supports it.

Pair TLS transport with Encrypt audio set to Required for the most complete protection the app can provide on its hop. Remember that neither setting controls what the server does on the next hop toward the other party.

Next steps

Set up both options in the app with the TLS and SRTP feature page. For background on transports, read SIP over UDP, TCP and TLS, and for the full account hardening list see how to secure a SIP account.