What is exposed without encryption
Plain SIP is text over UDP. Anyone able to observe the traffic — on a shared network, at an ISP, on a compromised router — can read the signalling: who called whom, when, for how long, and the headers describing your infrastructure.
The audio is worse. Unencrypted RTP can be captured and reassembled into a playable audio file with freely available tools; Wireshark will do it from a packet capture in a few clicks. There is no obscurity protecting a VoIP call by default.
Two mechanisms fix this, and you need both, because they protect different things:
- SIP over TLS encrypts the signalling — the call setup, the headers, the identities.
- SRTP encrypts the media — the audio itself.
Encrypting only signalling is a common half-measure that feels secure and is not: the conversation remains fully recoverable. TLS also matters for a second reason — SRTP's keys are exchanged inside the SDP, so signalling encryption is what stops an eavesdropper simply reading the media keys in transit.
Configuring TLS in Asterisk
Add a TLS transport, conventionally on port 5061:
[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
cert_file=/etc/asterisk/keys/asterisk.crt
priv_key_file=/etc/asterisk/keys/asterisk.key
ca_list_file=/etc/asterisk/keys/ca.crt
method=tlsv1_2Then point endpoints at it:
[1001]
type=endpoint
transport=transport-tls
media_encryption=sdesA few things worth being deliberate about. Pin the method to a modern TLS version rather than accepting whatever negotiates — older versions have known weaknesses and there is no reason to permit them. Use a certificate from a real CA if your endpoints will validate it; self-signed certificates work but every device must be configured to trust them, which becomes tedious at scale and tempts people into disabling verification entirely.
And do not forget the firewall: TLS uses TCP 5061, not UDP 5060. Opening the wrong protocol here is a routine cause of "TLS just does not connect".
SRTP and its two key-exchange methods
media_encryption takes two meaningful values.
SDES exchanges the media keys in the SDP body of the SIP messages. It is simple and widely supported. Its weakness is structural: the keys travel in the signalling, so SDES is only secure if the signalling is encrypted. SDES over plain UDP SIP is security theatre — the keys are sitting in plaintext for anyone watching.
DTLS-SRTP negotiates keys directly between the media endpoints using a DTLS handshake, so the keys never appear in the signalling at all. This is what WebRTC mandates, and it is the stronger design. It requires more configuration — certificates and fingerprint verification on the endpoint — but it removes the dependency on signalling secrecy.
Use SDES with TLS for traditional SIP phones; use DTLS-SRTP for WebRTC, where it is not optional.
Strict vs optional encryption
A subtle and important setting is whether encryption is required or merely preferred. Many configurations allow a fallback to unencrypted media if the far end does not support SRTP — which means an attacker who can strip the offer downgrades your call to plaintext, and nothing visibly fails.
Where you genuinely need confidentiality, configure encryption as mandatory and accept that non-supporting endpoints will fail to connect. A call that fails loudly is better than one that silently succeeds without protection.
What encryption does not do
Two honest caveats, because encryption is often oversold.
First, it is hop-by-hop, not end-to-end. Your phone encrypts to your PBX; your PBX decrypts, processes, and re-encrypts to the carrier. The PBX sees everything in clear — it must, in order to bridge, record or transcode. And once a call reaches the PSTN it is unencrypted by definition. Encryption protects the legs you control, which is worthwhile, but it is not a private channel end to end.
Second, it costs CPU. Encrypting and decrypting every RTP packet on every call is real work, and on a busy server it is measurable. Size accordingly rather than discovering it under load.
Verifying it actually works
Do not assume from configuration. Check what Asterisk reports:
asterisk -rx "pjsip show endpoint 1001"
asterisk -rx "pjsip show transports"Then confirm on the wire — this is the test that matters. Capture during a call and try to play the audio back. With SRTP working, a capture tool cannot reassemble intelligible audio. If it can, your media is not encrypted regardless of what the config says:
tcpdump -i any -w /tmp/call.pcap udp portrange 10000-20000Open it in Wireshark and attempt RTP playback. Failure to produce audio is the success condition here.
Frequently asked questions
Do I need both TLS and SRTP?
Yes. TLS protects signalling, SRTP protects audio. TLS alone leaves the conversation recoverable; SRTP alone with SDES leaves the keys readable in the signalling.
What is the difference between SDES and DTLS-SRTP?
SDES carries the media keys in the SDP, so it depends on encrypted signalling. DTLS-SRTP negotiates keys directly between the media endpoints, so keys never appear in the signalling. WebRTC requires DTLS-SRTP.
Which port does SIP TLS use?
TCP 5061 by convention. Note it is TCP, not UDP — opening the wrong one is a common reason TLS fails to connect.
Is an encrypted VoIP call private end to end?
No. Encryption is hop-by-hop; the PBX decrypts in the middle, and any leg crossing the PSTN is unencrypted. It protects the segments you control, which is still worth doing.