VoIP.info Protocol reference

SIP TLS and SRTP: what each protects

Distinguish adjacent-hop signaling protection, SRTP media protection, SDES and DTLS-SRTP keying, and the actual termination points on every call leg.

Reviewed 2026-10-29RFC 3261 SIP, RFC 3711 SRTP, RFC 4568 SDP Security Descriptions, RFCs 5763 and 5764 DTLS-SRTP, and current Asterisk PJSIP documentation reviewed October 6, 2026; deployed endpoints, intermediaries, certificates and calls require direct verificationFoundationalDocumentation based · not lab tested

Map protection by traffic type and adjacent hop

TLS can protect one SIP signaling connection. SRTP and SRTCP protect media and media control under a negotiated cryptographic context. Enabling either one does not enable or prove the other. A phone, PBX, SBC and provider can terminate and originate separate signaling and media legs, each with its own trust, certificate, keying and packet path.

Document every termination point and avoid the phrase end-to-end encryption unless the actual participants, keys and intermediary access support it. A browser padlock, SIP TLS registration or endpoint security icon is not evidence for the full call path.

TLS and SRTP protect different traffic
TLS protects SIP signaling on the configured transport hop. SRTP protects the audio media stream on its configured path. Each requires separate negotiation and validation.

Encryption on one leg is not proof of end-to-end encryption. Review the provider boundary, certificates and media keying method.

Distinguish SDES from DTLS-SRTP key establishment

SRTP does not define its own key-management exchange. RFC 4568 SDES carries crypto suite and inline key parameters in SDP and therefore requires confidentiality and integrity protection for that signaling content. DTLS-SRTP instead uses a DTLS handshake on the media path to derive SRTP keys; SDP fingerprints and setup roles bind the expected certificate and handshake roles.

These modes are not interchangeable labels. Record the offered and selected mechanism, every signaling intermediary that can read or rewrite SDP, the certificate or fingerprint evidence, selected SRTP profile and downgrade policy. Do not expose SDP crypto values or private keys in shared diagnostics.

Verify negotiation, protected packets and decoded media separately

Preserve the offer and answer for each media stream, including transport profile, crypto or fingerprint attributes, setup role, address, port and payload mapping. Then locate the DTLS handshake or SDES selection, subsequent SRTP and SRTCP packets, authentication or replay errors, and bidirectional decoded audio. A completed SIP dialog, one encrypted packet or an unreadable payload cannot stand in for the full sequence.

Repeat the check after hold, transfer, ICE change or direct-media re-INVITE because the media peer or keys can change. Use bounded, authorized captures and retain metadata whenever payload collection is unnecessary.

Keep authorization, recording and maintenance in scope

Encryption does not grant permission to call. Preserve identity, authentication, dialplan authorization, emergency behavior and toll controls independently. If a PBX records, transcodes or mixes media, state where it decrypts and which administrators or services can access media and keys.

Inventory signaling and DTLS certificate consumers separately, test renewal and restart behavior, and record rollback. For an Asterisk deployment, use the PJSIP media-encryption guide to map endpoint policy, call legs, direct media and loaded runtime evidence. No endpoint, PBX, certificate, protected packet path or call was inspected or tested for this guide.

Bind Genesys BYOC TLS evidence to its Voice platform

The Genesys Cloud BYOC record preserves different legacy and Dynamic Cloud Voice certificate roots, addresses and URI suffixes. It also retains the outbound-only transport-setting boundary and Dynamic platform's lack of mutual TLS.

Preserve the Azure-facing certificate and media boundary

The ACS Direct Routing record binds TLS 1.2, public-CA trust, SBC FQDN and the published SRTP suite to the Azure-facing leg without projecting them onto the carrier leg or treating encryption as a completed call.

Apply the signaling-versus-media boundary to Linphone

Linphone exposes SRTP, ZRTP and DTLS media choices independently of signaling transport. The Linphone encryption guide follows configured policy into the selected call state and keeps ZRTP SAS verification separate from encrypted media and SIP TLS.

Trace a LoopUp mutual-TLS and SRTP failure by stage

Use the LoopUp secure-trunk diagnostic to separate DNS, TCP, customer certificate, LoopUp trust, mutual TLS, SIP, SDP security descriptions and SRTP packets.

Protect the intercom call without confusing transport and door authorization

The GDS3712 guide treats SIP signaling, media protection and remote-unlock authorization as separate policies. A protected call does not by itself authorize a relay action or secure the management plane.

Resolve SignalWire profile and credential encryption on the call

The SignalWire guide separates stored project defaults, credential settings, TLS registration, INVITE transport, certificate validation, SRTP negotiation and media outcome.

Keep Telnyx route selection separate from protected media

A Telnyx route or response-code failure is not repaired by weakening certificate, SRTP or codec policy. The Telnyx diagnostic moves to transport and media evidence only after signaling reaches the intended PBX route.

Verify Amazon Chime encryption on the actual selected path

An encryption-enabled Voice Connector uses TLS on 5061 and SRTP, but the selected connector, certificate trust, cipher and SDP still need evidence. The diagnostic keeps routing and negotiation together.

Do not infer PhonerLite protection from a restored profile

After recovering PhonerLite state, verify the selected profile, TLS handshake and media protection on the actual call. A copied sipper.ini or successful REGISTER proves none of those together.

Simwood TLS and SRTP remain separate negotiations

The Simwood guide requires evidence for certificate validation, signaling transport, SDP crypto and each media direction.

Sinch SRTP is coupled to TLS signaling

The Sinch diagnostic requires hostname trust, TLS negotiation, SDP crypto and media evidence separately.

Scope 8x8 trunk protection to the account SOW

The 8x8 provider guide separates current SOW-scoped SIPS and SRTP guidance from endpoint ports and historical interface details.

Bound Flowroute TLS to the documented signaling route

The Flowroute guide keeps URI-route transport, certificate validation and Direct Media as separate evidence.

Verify AireSpring TLS and SRTP on the actual carrier leg

The AireSpring guide keeps ordered options, certificate validation, signaling protection, media keying and decoded audio separate.

Keep JsSIP WSS protection scoped to its hop

The JsSIP guide does not treat a valid WebSocket TLS session as proof of downstream SIP or media protection.

Keep DIDWW TLS and SRTP as separate leg protections

The DIDWW guide treats signaling and media protection independently and does not claim end-to-end encryption.

Verify Exotel TLS and SRTP separately

The Exotel diagnostic checks certificate validation, signaling transport, SDP protection and both media directions independently.

Verify Voximplant signaling and media protection per leg

The Voximplant guide keeps transport, SDP, media endpoints and scenario-created leg boundaries explicit.

Check Colt SDES and MKI behavior separately from TLS

The Colt failover and media diagnostic verifies certificate-authenticated signaling and both media directions.

Do not infer Gamma encryption from private access

The Gamma provider record separates access isolation, CallGuard, SIP transport and media protection.

Bind Bandwidth transport evidence to the selected product

The Bandwidth provider record does not import one product path’s transport or media profile into another.

Treat legacy Jitsi protection claims as session questions

The Jitsi Desktop guide requires certificate, signaling and negotiated media evidence instead of relying on an old feature list or lock icon.

Separate three protected Sipnetic paths

For Sipnetic, DNS over TLS, SIP signaling over TLS and SRTP or ZRTP media are independent negotiations with different peers and evidence. None establishes the others.

Do not infer Allstream encryption from port support

The Allstream guide treats TCP 5061 and RTP or SRTP range documentation as capability evidence, not proof of TLS identity, SRTP negotiation or protected end-to-end media.

Separate Orange TLS signaling from SRTP media

The Orange Business Talk guide records DNS, time, certificate, TLS and SDP security as separate acceptance checkpoints.

Treat Vodafone encryption as an ordered option

The Vodafone Evolved Voice diagnostic separates TLS identity, negotiated SDP, SRTP profile, packet delivery and decoded media.

Keep trusted access separate from negotiated protection

The Swisscom Enterprise SIP diagnostic separates MPLS or IP access, SBC trust, signaling transport, SDP, media protection and decoded audio.

Do not infer Proximus protection from service reachability

The Proximus Business Trunking diagnostic separates access, signaling transport, negotiated media protection and decoded audio.

Do not transfer Crazytel Hybrid SRTP to standard trunks

The Crazytel SIP Trunking guide separates TLS signaling, standard-trunk media and Hybrid or CrazyPBX SRTP.

Do not infer MaxoTel encryption from SIP registration

The MaxoTel SIP Trunking guide records its reviewed UDP transport boundary without inventing TLS or SRTP support.

Leave Aussie Broadband protection unverified without the handoff

The Aussie Broadband SIP Trunks guide does not convert absent public TLS or SRTP details into either support or non-support claims.

Scope Wave protection to the observed legs

The Grandstream Wave diagnostic does not convert TLS, SRTP, HTTPS, RemoteConnect or a lock icon into end-to-end protection proof.

Bind Symbio TLS and SRTP to the order

The Symbio Enterprise SIP Trunking guide treats published TLS and SRTP as optional voice-termination features, not universal enterprise entitlement.

Verify NUSO TLS and SRTP independently

The NUSO guide separates ordered protection, TLS peer validation, SDP selection, SRTP packets and audible media.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.