SIP TLS and SRTP: what each protects

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

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.