SRTP explained: a production guide to secure voice media

What is SRTP?

Secure Real-time Transport Protocol (SRTP) is a security profile for Real-time Transport Protocol (RTP), which carries real-time audio and video. SRTP can provide payload confidentiality, packet authentication and integrity, and replay protection. Its companion, Secure RTCP (SRTCP), protects RTP Control Protocol (RTCP) traffic, including reception reports used to understand media quality.

These are distinct services:

• Confidentiality prevents parties without the decryption keys from reading protected media.
• Authentication and integrity let the receiver detect packets that fail authentication, including altered packets.
• Replay protection rejects packets already received or outside the accepted replay window.

The base SRTP specification makes services independently selectable, with mandatory authentication for SRTCP. Encryption alone does not authenticate packets, and secure replay protection requires integrity protection. A production requirement therefore needs to name the protection profile and enforcement policy, rather than stopping at “SRTP enabled.”

SRTP vs RTP, TLS, and DTLS

Voice systems separate call control from media. Session Initiation Protocol (SIP) establishes, changes, and ends calls. Its Session Description Protocol (SDP) bodies describe media parameters. The audio takes a separate path.

Two security protocols appear alongside SRTP: Transport Layer Security (TLS) for connections and Datagram Transport Layer Security (DTLS) for datagram-based communication.

TLS applied to SIP is hop-by-hop. A TLS connection to a SIP proxy says nothing about whether the audio uses SRTP or what happens on later signaling hops. The SIP security model explicitly separates these concerns.

With DTLS-SRTP, the handshake establishes media keys; ongoing RTP audio is protected by SRTP rather than carried inside DTLS application-data records. The DTLS-SRTP extension defines that division.

For carrier connectivity, our SIP trunking guide explains the wider signaling and media architecture.

How SRTP protects media packets

With encryption and authentication enabled, a media stack uses a codec to encode audio, places it in RTP packets, and applies SRTP protection before transmission. The receiver authenticates and decrypts accepted packets before the codec decodes their payloads.

An implementation maintains a cryptographic context, the keys, algorithms, and stream state needed to protect or accept packets. Cisco’s libSRTP exposes separate packet-protection and unprotection operations, with per-stream state that includes keys and anti-replay data. That state belongs to a stream, rather than to arbitrary packets sharing a network port.

SRTP extends RTP’s 16-bit sequence number with a locally maintained rollover counter to form its packet index. Sequence-number wrap is normal; losing agreement about that state can break packet processing. This is why a media-server restart or failover needs explicit handling of stream and cryptographic state.

What remains visible

Payload encryption does not hide the whole packet. The fixed RTP header remains readable, including sequence numbers, timestamps, payload type, and the synchronization source identifier (SSRC). Packet timing, size, and network addresses also remain observable.

Header extensions may expose additional metadata. Optional Cryptex protection encrypts header extensions and contributing-source identifiers when supported and negotiated; it does not make the fixed header disappear. Treat traffic analysis and media-content confidentiality as separate concerns.

Cipher suites and overhead

Advanced Encryption Standard (AES) appears in several SRTP profiles. A suite name defines more than key length. For example, AES_CM_128_HMAC_SHA1_80 combines AES counter-mode encryption with a separate 80-bit authentication tag. Authenticated encryption with associated data (AEAD) combines confidentiality and authentication in one construction.

The AES-GCM SRTP profiles define AEAD_AES_128_GCM and AEAD_AES_256_GCM, each with a 16-byte authentication tag. GCM means Galois/Counter Mode. The DTLS handshake cipher and the negotiated SRTP protection profile are separate selections.

Plan bandwidth from the complete packet. As an arithmetic example, a 16-byte tag on 50 audio packets per second adds 800 bytes per second, or 6.4 kbit/s, in each direction. That excludes network headers, SRTCP, and any other added fields. Packetization, profile, and call volume determine the actual budget. Handshake time and steady-state packet processing also belong in separate latency budgets.

How endpoints establish SRTP keys

SRTP packet protection depends on a separate mechanism supplying the keys. Two common approaches in SIP-connected systems are DTLS-SRTP and SDP Security Descriptions (SDES). They place different demands on the signaling path.

DTLS-SRTP: keys established on the media path

Endpoints exchange DTLS handshake messages and derive the material used for SRTP and SRTCP. The media master keys do not travel as inline SDP values.

SDP carries a certificate fingerprint that binds the certificate presented during the handshake to the negotiated session. The certificate must match that fingerprint. A successful cryptographic handshake with an unexpected peer is insufficient: the fingerprint’s association with the intended peer depends on trustworthy signaling or another identity mechanism. The DTLS-SRTP framework requires the media session to end when the fingerprint does not match.

SDES: keys carried in SDP

SDES uses the SDP a=crypto attribute to carry a crypto suite and keying parameters. With the inline method, the SDP contains media keying material. Anyone with access to that material may be able to decrypt the protected stream.

The SDES security requirements require confidentiality and integrity protection for the key-bearing signaling. Hop encryption still leaves trusted intermediaries able to read SDP where they terminate that protection. SIP traces, support exports, and debug logs containing inline keys therefore need secret-handling controls.

SDES can fit a controlled SIP environment with an explicit signaling trust model. It expands the set of systems that can see media keys to include the relevant signaling intermediaries.

WebRTC has stricter requirements

Web Real-Time Communication (WebRTC) requires SRTP/SRTCP for media and DTLS-SRTP for keying. It prohibits plain RTP/RTCP, NULL encryption modes, and offering or selecting SDES. These are WebRTC security requirements, not a description of every SIP trunk or telephone network.

A browser-to-server WebRTC connection and a server-to-carrier SIP connection can consequently use different keying mechanisms and terminate at different endpoints. Our WebRTC and WebSocket comparison explains where those transports fit in a voice application.

Read negotiation without mistaking an offer for protection

SDP reveals what an endpoint proposes or accepts. Runtime evidence establishes whether key installation and protected media processing actually succeeded.

Useful negotiation indicators include:

• RTP/SAVP identifies the secure RTP audio/video profile.
• RTP/SAVPF adds the feedback profile to secure RTP; the final F does not mean stronger encryption.
• UDP/TLS/RTP/SAVP identifies DTLS-SRTP over User Datagram Protocol (UDP). Feedback-enabled variants also exist.
• a=crypto carries SDES security descriptions.
• a=fingerprint and a=setup participate in DTLS certificate binding and handshake-role negotiation.

The secure feedback profile explains SAVPF. Profile labels alone do not identify the accepted crypto suite, establish that both directions have installed keys, or describe another call leg.

For engineering acceptance, retain three distinct facts: offered, negotiated, and active. A configuration flag records intent. An accepted offer/answer records agreement. Successful protected send/receive processing records operational state.

Enforcement is a separate decision. Some SIP stacks allow optional SRTP and can accept unencrypted media under that policy. A confidentiality requirement needs required encryption and rejection of incompatible peers. A call that falls back to plain RTP is a security-policy failure even if the audio sounds correct.

There is no universal SRTP port

SRTP uses the media transport addresses and ports established for the session. In SDP, the m= media description supplies the media port and protocol, while the c= connection information supplies the address. Opening a SIP signaling port does not establish media reachability.

RTP and RTCP may use separate ports or share one port when multiplexing is negotiated. Encryption and port sharing solve different problems; our media multiplexing guide covers that distinction.

Map the security boundary through a voice AI call

The useful unit of analysis is a protected media leg. A leg ends at a system that holds its keys and decrypts its media. A forwarding relay that passes encrypted packets without those keys plays a different role from a media processor.

Consider a browser conversation that an AI service later bridges to a telephone:

The DTLS-SRTP framework treats a transcoder that needs media keys as an endpoint. It also allows SRTP security to terminate at a gateway to the public switched telephone network (PSTN). That termination does not provide caller-to-caller end-to-end security.

The architectural consequence for voice AI is straightforward: a service that processes decoded audio is inside the trust boundary for that audio. Two encrypted connections joined by such a service do not make the service unable to access the conversation.

For each leg, record both endpoints, who controls the keys, which system can access plaintext, and what changes during transfer or failover. A session border controller (SBC), recorder, transcoder, and transfer target each need an explicit role. The phrase “encrypted call” is too broad to carry that inventory.

SRTP also says nothing about transcript authorization, recording retention, webhook destinations, or application logs. Those controls remain necessary even when every intended network media leg is encrypted.

Production acceptance and troubleshooting

Treat media security as an enforced contract with observable failure states. For each route and call direction, the deployment record should include:

1. Accepted protection: keying method, allowed SRTP profiles, payload encryption, authentication, and SRTCP policy.
2. Peer trust: how signaling is authenticated and protected, and how DTLS certificate fingerprints are bound to the intended endpoint when used.
3. Rejection behavior: incompatible profiles, fingerprint mismatch, and forbidden plaintext media cannot silently become an unencrypted call.
4. Lifecycle behavior: initial connection, hold/resume, transfers, media-server restart, and failover preserve the intended boundary or fail closed.
5. Operational evidence: negotiated profile, key-establishment outcome, protected packet counters, rejection reasons, and a call/leg correlation identifier.

These acceptance criteria follow from the separate negotiation, keying, and media-processing boundaries. A signaling-success event alone cannot satisfy them.

Diagnose the stage that failed

These are diagnostic branches, not one-to-one explanations. Authentication failures can have several causes. Removing authentication or allowing plaintext to make a call work destroys the required security property.

Keep key material out of ordinary telemetry. PJSIP’s latest development guide documents level-5 logs that print per-direction SRTP keys. Prefer profile names, state transitions, and counters in routine logs. Restrict and redact any key-bearing captures or support bundles.

Packet captures still help explain routing, timing, packet size, and visible headers. An undecodable payload alone is weak evidence of encryption: the decoder may lack the codec or session context. Strong acceptance evidence combines negotiated parameters with endpoint protection state and authenticated packet-processing results.

Use an established media stack or maintained SRTP library rather than implementing cryptography and replay handling inside application code. The application’s job is to enforce policy, preserve the intended trust boundary, and surface failures without leaking secrets.

Where Dasha fits

We help technical teams build and run production voice AI agents through a managed runtime, REST APIs, and a web application. Our SIP configuration connects the agent application to telephony infrastructure.

The transport field in our SIP configuration guide selects SIP signaling transport: udp, tcp, or tls. Selecting tls describes that signaling connection. It does not specify the media’s negotiated SRTP profile, keying method, or decryption endpoints.

A Dasha integration belongs in the same leg-by-leg security design as the carrier, SBC, browser peer, and recording pipeline. Keep the agent-runtime decision and the media-security contract explicit, with no inferred end-to-end guarantee from a signaling setting.

For a managed runtime behind your production voice application, start building with Dasha.