TLS and SRTP: what is protected in a telephone call?

Short answer: assess TLS for SIP signaling and SRTP for media separately. An encrypted control connection does not establish that the whole call’s audio is protected. A useful review explains what each boundary protects, how identity is checked and which party can process the media. Start with a scope map covering the conversation from entry to termination rather than one security checkbox.

Separate signaling from media

SIP uses TLS to protect signaling transport; SIPS semantics should not be presented as a general security guarantee for the entire session. [1] Call-control messages and audio packets may follow different paths. Mark their respective boundaries separately. Evidence about one path does not replace documentation about the other.

A practical review form asks who connects to whom, which protection that connection uses and what the observation demonstrates. Complete the same form for a new connection after transfer. This prevents a scope statement verified at the beginning of a call from being carried forward automatically into a different stage.

Inspect the protection behind the SRTP label

SRTP provides a framework for confidentiality, message authentication and replay protection of RTP and RTCP traffic. Its security services include independent options. [2] Therefore, seeing “SRTP” in a tool is not the end of the review. Check whether the negotiated protection profile meets your acceptance conditions. Record the protocol name, actual protection scope and acceptance decision separately so that the conclusion remains specific.

Separate key establishment from media protection

In DTLS-SRTP, the DTLS handshake establishes keying material and parameters, while SRTP protects the media. [3] Handshake completion and receiving the intended media are different checkpoints. Do not treat exporting secret keys as a prerequisite for examining key establishment. Aim for sufficient, limited evidence about protocol state and expected authentication, without turning the review into a new store of sensitive material.

The remote party’s identity is a different question from network reachability. The WebRTC security architecture addresses the relationship between signaling and media identity information. [4] Ask which mechanism establishes identity and which party makes the authorization decision. The explanation shown to users should match the scope that has actually been verified, particularly when a connection continues through another processing boundary.

Fill the scope table with specific review questions

The table does not produce an automatic pass. Give every row an evidence item and owner. If information is missing, record the unresolved question instead of overstating the conclusion. A connection owner can then answer a concrete question about profile acceptance or the new media boundary after transfer. This makes the review actionable without publishing the operational details behind its answer.

Follow trust boundaries through the complete path

If a media processor decodes audio for transformation, its incoming and outgoing protections have separate scopes. DTLS-SRTP describes a mixer decrypting and protecting separate flows again. [3] Make such boundaries visible in design reviews. Do not expand “encrypted during transport” into a claim that an authorized processor never sees audio. Define processing access and retention decisions separately and connect them to the applicable boundary.

Hypothetical scenario: a support call transfer

Imagine a call moving from automated reception to a human representative. The reviewing team records signaling and media protection in the initial stage. After transfer, it checks the new endpoints and negotiation rather than copying the earlier result. Acceptance rules also specify what happens when a required protection condition is not met. The user-facing state should be consistent with the outcome of that rule.

Start an investigation by sharing the boundary map and necessary state fields rather than an example conversation. If a packet trace is needed, consider access scope, embedded identifiers and retention separately. The useful result is a record explaining which condition was verified at which stage. A broad label such as “secure call” gives a later reviewer much less information about what must be reassessed after a change.

Checklist

• Show signaling and media connections separately.
• Name each connection’s endpoints and trust boundary.
• Match the negotiated protection profile to acceptance conditions.
• Check identity verification and the outcome of key establishment.
• Reassess scope after transfer, reconnection or bridging.
• Keep unnecessary keys and personal conversation data out of diagnostic records.
• Review recording access and retention separately from transport protection.

Frequently asked questions

Does TLS mean the audio is encrypted? Examine the audio path separately. An observation about a control connection does not apply directly to a media connection. Specify where protection begins and ends.

Does SRTP mean end-to-end encryption? Establish which endpoints it connects before making that claim. When an intermediate party processes media, explain each protected segment and its processing boundary.

Does encryption settle the recording policy? Transport protection, recording access, retention and deletion are separate decisions. Review them together if helpful, but verifying one does not establish the others.