Unencrypted VoIP is a liability. Carriers are already mandating SRTP on trunk connections, regulators are tightening requirements for healthcare and finance, and the trajectory is clear — all VoIP traffic will eventually be encrypted end-to-end. Here's everything you need to implement it correctly.
For most of its history, VoIP ran unencrypted. SIP signaling over UDP in plaintext, RTP media in plaintext — anyone on the network path could intercept call content, harvest credentials from REGISTER messages, or inject forged SIP packets. The industry accepted this risk because encryption added complexity and the threat model seemed theoretical.
That calculus has changed. Several forces are converging:
The question for most VoIP engineers is no longer whether to implement encryption but how — and how to do it without breaking existing infrastructure.
VoIP encryption requires securing two completely independent channels. Confusing them is the most common source of misconfiguration:
TLS without SRTP means your credentials and call setup are protected but the actual voice conversation is unencrypted. Anyone who can tap the RTP stream can listen to the call.
SRTP without TLS means the audio is encrypted but the key exchange (which happens in the SDP) is unprotected. An attacker who intercepts the SIP signaling gets the SRTP keys and can decrypt the audio anyway.
Both layers must be implemented together for meaningful call security.
SIP over TLS (SIPS) uses TCP port 5061 instead of the standard UDP/TCP port 5060. The TLS handshake occurs before any SIP messages are exchanged, establishing an encrypted channel for all subsequent signaling.
Each SIP server needs a valid TLS certificate with the server's hostname in the Subject Alternative Name (SAN). For internal infrastructure, you can use your own CA. For external trunk connections with carriers, use a publicly trusted CA (Let's Encrypt, DigiCert, etc.) — carriers will typically reject self-signed certificates.
Require TLS 1.2 minimum. TLS 1.3 is preferred. SSLv3, TLS 1.0, and TLS 1.1 are deprecated and should be explicitly disabled. Many carriers and enterprise SBCs now reject connections on deprecated TLS versions.
A SIPS URI (sips:alice@example.com vs sip:alice@example.com) signals that TLS must be used for the entire path. If any hop in the path can't support TLS, the request fails rather than falling back to plaintext. Use SIPS URIs when you want to enforce end-to-end signaling security.
Configure DNS SRV records for TLS transport so endpoints can discover the TLS endpoint automatically:
SRTP encrypts the RTP media stream using AES. The key question is how the encryption keys are exchanged — and there are two main approaches:
SDES exchanges SRTP keys inline in the SDP body using a=crypto: lines. It's simple, widely supported, and works with any SIP transport.
Critical limitation: SDES keys are in the SDP, which means if your SIP signaling isn't encrypted (TLS), your SRTP keys are in plaintext. SDES only provides real security when combined with TLS. Without TLS, SDES-encrypted media is trivially decryptable by anyone who can see the SIP signaling.
DTLS-SRTP uses a separate DTLS handshake on the media channel itself to exchange keys, independent of the SIP signaling. This is the method used by WebRTC and is defined in RFC 5764.
Advantage: Because keys are exchanged on the media channel via DTLS, SRTP security doesn't depend on the SIP signaling being encrypted. Even if the SDP is intercepted, the keys aren't in it — they're negotiated separately.
Disadvantage: DTLS-SRTP requires ICE, which means it's incompatible with many traditional SIP endpoints and requires an SBC or media gateway to bridge WebRTC to legacy SIP.
For traditional SIP infrastructure: use SDES + TLS. For WebRTC or modern unified communications: use DTLS-SRTP. For mixed environments: your SBC handles the translation between the two at the boundary.
DTLS-SRTP is increasingly important as WebRTC usage grows and as enterprises adopt UCaaS platforms. Understanding it is essential for engineers managing hybrid SIP/WebRTC environments.
The a=setup: attribute in the SDP controls which endpoint acts as the DTLS client (active) and which acts as the server (passive):
a=setup:active — this endpoint initiates the DTLS handshakea=setup:passive — this endpoint waits for the DTLS handshakea=setup:actpass — this endpoint can do either (offer phase)a=setup:holdconn — hold, no DTLS connectionA common failure: both endpoints set a=setup:active or both set a=setup:passive. The DTLS handshake never completes and there's no audio. If you see a=setup:active on both sides of an SDP exchange, that's your problem.
The a=fingerprint: line contains a hash of the DTLS certificate that will be used for key exchange. Both sides compare the fingerprint they receive in the SDP against the actual certificate presented during the DTLS handshake. A mismatch causes the DTLS handshake to fail with a certificate verification error.
DTLS-SRTP depends on ICE to establish the media path before DTLS can run. ICE selects the best candidate pair (direct, STUN-reflexive, or TURN relay) and DTLS runs on top of the established ICE connection. If ICE fails, DTLS never starts and there's no audio — not even unencrypted audio.
Via headers show which transport was used: SIP/2.0/UDP, SIP/2.0/TCP, or SIP/2.0/TLS. If you're expecting TLS and see UDP or TCP, the call isn't using encrypted signaling.
In the SDP, the m= line transport tells you what's negotiated for media:
m=audio 49172 RTP/AVP 0 — unencrypted RTPm=audio 49172 RTP/SAVP 0 — SRTP with SDES key exchangem=audio 49172 UDP/TLS/RTP/SAVPF 111 — DTLS-SRTP (WebRTC style)For SDES, check that the INVITE SDP and 200 OK SDP both contain a=crypto: lines and that the cipher suite in the answer is one of the ones offered. A 200 OK without any crypto line when the INVITE had crypto lines means the remote end rejected SRTP and the call will proceed unencrypted (or fail if SRTP is required).
Both sides of a DTLS-SRTP exchange must have a=fingerprint: lines. Verify the hash algorithm matches (sha-256 is standard). A fingerprint mismatch between what's in the SDP and what's presented in the DTLS handshake will cause a certificate verification failure.
_sips._tcp DNS SRV recordsopenssl s_client -connect sip.example.com:5061 before deployingPaste your SIP trace into SIPSymposium. The analyzer checks TLS transport indicators in Via headers, validates SRTP crypto line negotiation, detects mixed encrypted/unencrypted legs, identifies DTLS setup conflicts, and flags calls where encryption was offered but not honored.
The Teams tier includes a compliance report that maps your encryption findings directly to SOC 2, PCI-DSS, and HIPAA controls — useful if you need to demonstrate encryption compliance to auditors.
Paste your SIP trace into SIPSymposium. The analyzer identifies exactly what encryption is — and isn't — in use on your calls, and tells you what to fix to get to full TLS + SRTP coverage.