Visit Website →
← Back to blog

SIP TLS and SRTP for Engineers: PJSIP/OpenSIPS Configs & Fixes

September 1, 2026
SIP TLS and SRTP for Engineers: PJSIP/OpenSIPS Configs & Fixes

TLS secures SIP signaling; SRTP secures the voice media itself, and a genuinely secure VoIP deployment needs both running at the same time. Enable TLS 1.2 or higher on port 5061 with a CA-signed certificate matching your SIP hostname, turn on SRTP using SDES or DTLS-SRTP for key exchange, and open a defined RTP port range through your firewall. Skip either layer and you've left half the call exposed.

TL;DR:

  • Enabling TLS 1.2 or higher on port 5061 with a CA-signed certificate is essential to protect SIP signaling from eavesdropping and metadata leaks.
  • Running SDES for SRTP key exchange demands that signaling remains encrypted, or the session keys are exposed to possible interception.
  • DTLS-SRTP offers stronger security by negotiating media keys directly on the media path, but requires specific support and proper build configurations.
  • Certificate management, NAT traversal, and matching encryption suites are the most common points of failure in deploying secure VoIP systems.
  • Proper pre-deployment testing and configuration verification across all equipment minimize system outages and ensure encryption integrity.

Table of Contents

What SIP TLS and SRTP Actually Protect

A VoIP call runs on two separate planes, and encryption for one does nothing for the other. The signaling plane carries SIP messages like INVITE, REGISTER, and BYE — the handshake that sets up, modifies, and tears down a call. The media plane carries the actual RTP audio packets once the call connects. SIP over TLS protects the first; SRTP protects the second.

Unencrypted, both planes leak information an attacker can use. SIP signaling in plaintext exposes caller ID, extension numbers, and internal network topology to anyone sniffing the wire. Unencrypted RTP exposes the audio itself, which is trivial to reassemble into a playable file with common packet tools.

Ports and URI schemes matter here. sips: formally requires TLS on every hop to the destination, but RFC 5630 clarifies that most real deployments instead use sip: with a ;transport=tls parameter, applying TLS best effort to the next hop rather than end to end. In practice:

  • sips: and port 5061 signal mandatory TLS, per the SIP URI scheme.
  • sip:;transport=tls is the pragmatic, more common approach for trunk-to-PBX links.
  • SRTP has no dedicated port scheme; it rides the same RTP port range as plaintext RTP, just encrypted.

The threats this combination closes are specific: eavesdropping on call audio, signaling metadata leakage that maps out your PBX, and session hijacking where an attacker injects a BYE or re-INVITE into an unauthenticated stream.

How TLS and SRTP Interact During Call Setup

A call starts with a SIP INVITE carrying an SDP body that describes the media session, codecs, and, if SRTP is in use, the encryption keys. That last part is where things get interesting. If you're using SDES for key exchange, the actual SRTP master key travels inside an a=crypto attribute in that SDP payload. That means the SDP itself has to be protected, or the key is sitting in plaintext for anyone watching the signaling path.

That's the whole argument for running SDES over TLS: without transport encryption, SDES key exchange defeats its own purpose.

The call flow breaks down like this:

  1. The caller's endpoint sends INVITE over the TLS-encrypted signaling channel, with SDP describing supported codecs and crypto suites.
  2. The callee responds with 200 OK, negotiating a matching crypto suite (or DTLS fingerprint, if using DTLS-SRTP).
  3. Both endpoints derive or exchange SRTP session keys and begin exchanging encrypted RTP.
  4. Mid-call signaling (hold, transfer, BYE) continues over the same TLS session.

DTLS-SRTP handles step 3 differently and more safely: instead of putting a key inside the SDP, endpoints negotiate the key material directly on the media path using a DTLS handshake, referenced by a certificate fingerprint in the SDP rather than the key itself. That removes the dependency on signaling-layer confidentiality for key security, which is a large part of why WebRTC standardized on it.

You can confirm this is all working correctly by watching a packet capture. Encrypted SIP signaling shows up in Wireshark as TLS Application Data rather than readable SIP methods, and successfully negotiated media streams display as SRTP rather than plain RTP in the protocol column. The PJSIP project documents both mechanisms and notes that DTLS-SRTP support depends on build-time flags tied to your OpenSSL backend, which trips up more deployments than it should.

SDES vs. DTLS-SRTP vs. ZRTP: Picking the Right Key Exchange

Three methods dominate SRTP key negotiation, and they are not interchangeable in terms of security posture or provider support.

SDES puts the SRTP master key directly in the SDP a=crypto line, exchanged during the INVITE/200 OK handshake. It's simple to implement and widely supported by SIP trunk providers, which is why it's still the default in a lot of carrier-grade deployments. Its entire security model, though, depends on that signaling channel being encrypted with TLS. Run SDES over plain TCP or UDP and you've published your session key to anyone listening.

DTLS-SRTP negotiates keys on the media path itself using a DTLS handshake, with only a certificate fingerprint passed in the SDP. Because the key material never touches the signaling layer, it's considered stronger, and it's the mechanism WebRTC clients rely on by default, according to LiveKit's breakdown of SIP TLS. The tradeoff is build and library support: PJSIP's DTLS-SRTP path requires specific OpenSSL alignment at compile time, and older SBCs or budget carrier gear frequently don't support it at all.

ZRTP does peer-to-peer key agreement with a short authentication string users can verbally verify, which makes it attractive for genuine end-to-end privacy between two compatible endpoints. It sees almost no adoption in carrier SIP trunking and mostly shows up in specialized secure-communication apps.

  • SIP trunking to a carrier: SDES over TLS, because it's what most providers support.
  • Browser-based WebRTC clients: DTLS-SRTP, because it's the platform standard.
  • Internal desk phones on a controlled LAN: either works, but DTLS-SRTP is worth the setup effort if your phone firmware supports it.

Pro Tip: Before you commit to DTLS-SRTP across a fleet of desk phones, check firmware support first. A surprising number of otherwise modern SIP phones only implement SDES, and you'll find that out mid-rollout instead of during planning.

Configuring PJSIP, OpenSIPS, and SBCs for TLS and SRTP

Getting TLS and SRTP running in production comes down to a short list of settings that have to match on both ends of every leg.

For PJSIP (Asterisk), the transport and endpoint sections need to align:

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
cert_file=/etc/asterisk/keys/cert.pem
priv_key_file=/etc/asterisk/keys/key.pem
method=tlsv1_2

[endpoint-secure]
type=endpoint
transport=transport-tls
media_encryption=sdes

Set media_encryption=dtls instead of sdes if you're targeting WebRTC clients, and confirm your PJSIP build has DTLS-SRTP compiled in, since the PJSIP documentation notes this depends on OpenSSL backend flags rather than being available by default everywhere.

For OpenSIPS, TLS lives in the tls_mgm module tied to a proto_tls listener:

loadmodule "tls_mgm.so"
loadmodule "proto_tls.so"
listen=tls:0.0.0.0:5061

modparam("tls_mgm", "server_domain", "[server_dom]")
modparam("tls_mgm", "verify_cert", "[server_dom]", 1)
modparam("tls_mgm", "certificate", "[server_dom]", "/etc/opensips/tls/cert.pem")

The OpenSIPS TLS tutorial is explicit that lab examples often set verify_cert=0 to simplify testing, and that production deployments should flip that back to enforce certificate validation.

For SBCs, decide early whether TLS and SRTP terminate at the SBC (re-encrypting toward the PBX, or dropping to plaintext internally) or pass through untouched end to end. Termination simplifies call recording since the SBC holds the decryption keys; full passthrough with DTLS-SRTP means the SBC can't see media content at all, which breaks recording unless you build in a legal intercept point.

Checklist itemTarget value
TLS version1.2 or higher
CertificateCA-signed, SAN matches SIP hostname
Signaling port5061
RTP port rangeDefined RTP port range, opened in firewall
Certificate verificationEnabled in production

Fixing the Usual TLS and SRTP Failures

Most post-deployment problems trace back to one of four categories, and they're fast to isolate once you know where to look.

  1. Certificate mismatch. If the certificate's SAN or CN doesn't match the SIP hostname the client dials, the TLS handshake fails silently on many phones. Check Asterisk or OpenSIPS logs for handshake errors and confirm the cert chain with openssl s_client -connect host:5061.
  2. One-way or no audio. This almost always means the two endpoints negotiated different SRTP crypto suites, or one side offered SRTP and the other rejected it silently. Confirm both legs list a matching a=crypto suite (for SDES) or compatible DTLS fingerprints.
  3. NAT and ALG interference. Session border gateways and consumer routers with SIP ALG enabled often rewrite SDP in ways that break encrypted signaling, since they can't parse a TLS-wrapped payload the way they parse plaintext SIP. Disable SIP ALG on the firewall and configure symmetric RTP with a static, documented port range instead.
  4. Codec or suite negotiation failures. Mismatched SRTP suite lists between an SBC and a downstream PBX will negotiate a call that connects but never carries audio.

Pro Tip: If a call capture shows encrypted RTP you need to inspect for troubleshooting, import the session's private key into Wireshark's RTP/SRTP preferences. That decrypts the stream for analysis without weakening the deployment itself.

Run asterisk -rx "rtp set debug on" for a live view of negotiation on Asterisk systems, and watch for the SRTP suite both sides settle on before assuming the problem is elsewhere.

Real-World TLS and SRTP Deployment Experience

Getting TLS 1.2 and SRTP running correctly on a lab PBX is one thing. Getting it right across forty desk phones, three remote offices, and a carrier trunk without a service interruption is a different problem entirely. Businessvoip has been installing and configuring on-site VoIP systems for Ontario businesses since 2005, which means encrypted signaling and media aren't an add-on step, they're baked into how every system gets provisioned from day one.

A typical on-site rollout includes:

  • Certificate provisioning matched to the client's actual SIP hostname before any phone is racked
  • TLS transport and SRTP settings configured on every extension during on-site setup, not left to default
  • Firewall and RTP port range configuration verified against the client's existing network before cutover
  • Post-install verification that signaling and media both show encrypted in a live test call

That last step catches the certificate and NAT issues described above before they become a support ticket, which is the difference between a secure deployment on paper and one that actually holds up.

Where to Verify These Standards Yourself

Every configuration detail here traces back to a public specification. RFC 3711 defines SRTP itself. RFC 5630 settles the sips: versus sip:;transport=tls question. The PJSIP security documentation and the OpenSIPS TLS tutorial both carry working configuration examples worth bookmarking before your next deployment.

The Part of This Stack Everyone Underrates

The technical conversation around SIP TLS and SRTP almost always centers on which key-exchange method wins. That's the wrong fight. SDES over properly enforced TLS is perfectly adequate for the overwhelming majority of business deployments, and chasing DTLS-SRTP purely because it's theoretically stronger, while your PJSIP build doesn't actually support it cleanly, creates more outages than it prevents.

The failure mode nobody talks about enough is certificate lifecycle management. Teams enable TLS once, get it working, and then let the certificate expire eighteen months later during a Friday afternoon, taking every trunk down with it. Encryption that isn't renewed isn't encryption, it's a countdown timer. If you're deploying this stack, put certificate expiry monitoring in place before you worry about which SRTP suite is marginally more elegant.

Prioritize what actually breaks in production: certificate validity, matching SAN entries, and firewall rules for your RTP range. Get those right first. The key-exchange debate matters far less than most engineers treat it.

— James

Get TLS and SRTP Configured Right the First Time

Everything above is achievable with a PJSIP config file and a weekend, assuming your certificates, firewall rules, and phone firmware all cooperate on the first try. They usually don't. Businessvoip installs and configures these encrypted VoIP systems on-site across Ontario, which means the certificate provisioning, TLS transport settings, and SRTP negotiation get verified on your actual network before your team ever picks up a handset.

Businessvoip

That matters most for multi-site operations and businesses running remote extensions where NAT and firewall mismatches are the most common source of the one-way audio problems covered above. Businessvoip's team handles the design, cabling, programming, and installation directly, backed by carrier-grade infrastructure and a lifetime warranty on rented phones, so encrypted signaling and media are working correctly before the system goes live rather than something your IT staff debugs after the fact.

If your organization runs a technology company or ISP with specific security requirements, or you're planning a custom phone system deployment that needs TLS and SRTP configured correctly from installation day, reach out to Businessvoip to scope the project.