SRTP (Secure Real-time Transport Protocol) is defined as the IETF profile of RTP, published as RFC 3711, that encrypts the payload of every voice and video packet, authenticates each packet, and rejects replayed ones. WebRTC requires it for all audio and video.
Every audio and video stream in a standards-compliant WebRTC call is encrypted with SRTP. You cannot turn it off, because the WebRTC security architecture forbids unencrypted media.
That makes SRTP the media encryption most developers rely on without ever configuring it. It is also widely misread. "Encrypted with SRTP" and "end-to-end encrypted" are different claims, and the difference decides who can see your users' video.
This guide covers what SRTP protects, how its keys are exchanged, and which ciphers and ports it uses in WebRTC, SIP, and VoIP. It ends with why a group call through a media server is encrypted hop by hop, not end to end.
What is SRTP?
SRTP (Secure Real-time Transport Protocol) is the encrypted form of RTP, the protocol that carries nearly every live voice and video packet on the internet.
SRTP is defined as a profile of the Real-time Transport Protocol (RTP, RFC 3550) that adds confidentiality, message authentication, and replay protection to RTP and to its control protocol, RTCP. The IETF published it as RFC 3711 in March 2004. SRTP works by encrypting each packet's payload with a session key, then appending an authentication tag computed over the header and the encrypted payload.
You will see it called secure RTP, the secure real time transport protocol, or the shorter secure real time protocol. All three names point to the same RFC 3711 profile. Its protected control channel is SRTCP.
SRTP does not set up calls or exchange keys. Signalling, such as SIP or a WebRTC app's own messaging, sets up the call, and a separate key exchange gives both ends the same master key. SRTP protects the media once that key exists. For the unencrypted base protocol, its packet layout, and RTCP, see what RTP is and how WebRTC uses it.
VideoSDK's HIPAA documentation lists SRTP for media encryption and TLS for network traffic. Its SOC 2 and GDPR pages describe data in transit as protected by TLS and SRTP.
How SRTP works
SRTP encrypts the payload of every RTP packet and authenticates the whole packet, so an attacker on the path can neither read the media nor alter it unnoticed.
The diagram below lays out a single SRTP packet the way RFC 3711 draws it, 32 bits per row. The header rows at the top are sent in the clear, and the payload and padding, shaded blue, are encrypted with AES in counter mode. The bracket on the right shows that HMAC-SHA1 authenticates everything from the first header bit to the pad count, and the optional MKI and the authentication tag follow at the end.
What SRTP encrypts and What it authenticates
An SRTP packet keeps the normal 12-byte RTP header readable. The header carries the sequence number, timestamp, and synchronisation source (SSRC) that receivers and network equipment need, and RFC 3711 leaves it in the clear so header compression still works.
| Part of the packet | Encrypted | Authenticated |
|---|---|---|
| RTP header, including CSRCs and header extensions | No | Yes |
| Payload (the audio or video data, plus padding) | Yes | Yes |
| Master key identifier (MKI), optional | No | No |
| Authentication tag, 80 bits by default | No | It is the tag |
RFC 3711 does not encrypt header extensions. RFC 6904 (April 2013) added selective encryption for them, and RFC 9335 (January 2023), known as Cryptex, encrypts header extensions and CSRC lists completely.
Session keys, the rollover counter, and replay protection
Both ends start from a shared master key, 128 bits by default, and a 112-bit master salt. SRTP runs a key derivation function over them to produce separate session keys for encryption, authentication, and salting.
Each packet gets a 48-bit index made from the 16-bit RTP sequence number and a 32-bit rollover counter (ROC) that counts how many times the sequence number has wrapped. The index feeds the cipher, so packets in a stream never reuse the same keystream.
The receiver keeps a replay list, a sliding window of at least 64 packets, and drops any packet whose index it has already accepted. An attacker who records packets cannot inject them again later.
SRTCP and the cost of encryption
RTCP carries the loss, jitter, and round-trip reports that adaptive bitrate depends on. SRTCP protects it the same way, with two differences. Authentication is mandatory for SRTCP, where RFC 3711 only recommends it for SRTP. Each SRTCP packet also carries a 31-bit index and an E flag that marks whether it is encrypted.
The overhead is small and fixed. With the default suite, SRTP adds a 10-byte authentication tag to each packet, and counter-mode encryption does not change the payload length. The 32-bit tag variant adds 4 bytes, and AES-GCM adds a 16-byte tag.
Key exchange: DTLS-SRTP vs SDES vs ZRTP
SRTP needs both ends to hold the same master key, and the three ways of delivering it differ mainly in who else can see that key.
| DTLS-SRTP | SDES | ZRTP | |
|---|---|---|---|
| Specification | RFC 5764 and RFC 5763, May 2010 | RFC 4568, July 2006 | RFC 6189, April 2011, Informational |
| Where the key travels | Derived from a DTLS handshake on the media path | Written into the SDP on the signalling path, in an a=crypto line | Diffie-Hellman exchange on the media path |
| Visible to the signalling server | No, signalling carries only a certificate fingerprint | Yes, any server that handles the SDP can read it | No |
| How the ends verify each other | The DTLS certificate must match the fingerprint in the SDP | Depends on the signalling channel being protected | Users compare a short authentication string (SAS) |
| Where you meet it | Mandatory in WebRTC | SIP phones, PBXs, and SIP trunks | Some secure SIP softphones |
WebRTC chose DTLS-SRTP. RFC 8827, the WebRTC security architecture, requires DTLS-SRTP for every media channel and forbids offering or accepting SDES. The companion document, RFC 8826, gives the reason: a calling service that holds the keying material, as it does with SDES, can decrypt the call.
With DTLS-SRTP, the DTLS handshake runs on the same port as the media. Both ends then export the SRTP keys from it, and the signalling server never sees them.
SDES is simpler and still common in SIP. RFC 4568 requires the signalling that carries the key to be protected for confidentiality and integrity. For SIP it prefers SIPS or S/MIME, and calls relying on transport TLS alone not recommended, because SIP proxies along the path can still read the key.
SRTP ciphers and key lengths
SRTP's default is AES-128 in counter mode with an 80-bit HMAC-SHA1 tag, and newer AES-GCM profiles replace the separate HMAC with authenticated encryption.
| Suite (SDES name, DTLS-SRTP name) | Cipher and key | Master salt | Authentication tag | Defined in, and where it applies |
|---|---|---|---|---|
| AES_CM_128_HMAC_SHA1_80, SRTP_AES128_CM_HMAC_SHA1_80 | AES-128, counter mode | 112 bits | HMAC-SHA1, 80 bits | RFC 3711 default; the one suite every WebRTC endpoint must support |
| AES_CM_128_HMAC_SHA1_32, SRTP_AES128_CM_HMAC_SHA1_32 | AES-128, counter mode | 112 bits | HMAC-SHA1, 32 bits on RTP, 80 on RTCP | RFC 5764; saves 6 bytes per packet with weaker integrity |
| AES_192_CM_HMAC_SHA1_80 and _32 | AES-192, counter mode | 112 bits | HMAC-SHA1, 80 or 32 bits | RFC 6188; SDES only |
| AES_256_CM_HMAC_SHA1_80 and _32 | AES-256, counter mode | 112 bits | HMAC-SHA1, 80 or 32 bits | RFC 6188; SDES only |
| SRTP_AEAD_AES_128_GCM | AES-128, GCM | 96 bits | 16 bytes, built into GCM | RFC 7714; DTLS-SRTP |
| SRTP_AEAD_AES_256_GCM | AES-256, GCM | 96 bits | 16 bytes, built into GCM | RFC 7714; DTLS-SRTP |
| SRTP_NULL_HMAC_SHA1_80 and _32 | None | None | HMAC-SHA1, 80 or 32 bits | RFC 5764; integrity only, forbidden in WebRTC |
The DTLS-SRTP names and values come from the IANA SRTP protection profile registry. RFC 3711 also defines AES in f8 mode as an optional alternative, but no DTLS-SRTP profile uses it.
In WebRTC you do not pick a suite by hand. The two ends negotiate one during the DTLS handshake, and RFC 8827 says they should favour the AEAD (GCM) profiles when both support them. On a SIP trunk, AES_CM_128_HMAC_SHA1_80 is the RFC 3711 default and the safest choice for interoperability.
Is SRTP end-to-end encryption?
No, not when media passes through a server that holds the keys, which is how most group calls and all server-side recording work.
SRTP protects each hop between two endpoints that share a key. In a one-to-one WebRTC call sent directly between two browsers, those endpoints are the two users, so the media is protected from end to end.
A group call is different. Each participant's SRTP session ends at a media server, usually a Selective Forwarding Unit (SFU). The server holds the keys for every leg, forwards the media, and re-encrypts it toward each receiver, so it can access the media in the clear.
That is not a defect. The server hop is what makes recording, transcription, and live streaming possible. It does mean that "encrypted with SRTP" describes encryption in transit, and the provider running the server sits inside your trust boundary.
What true end-to-end encryption needs
End-to-end encryption in a group call needs a second layer of encryption on the media frames, applied before SRTP, with keys the server never holds.
- SFrame, RFC 9605 (August 2024), encrypts each media frame so an SFU can forward it without access to the media.
- WebRTC Encoded Transform, a W3C Working Draft as of June 2026, lets a browser app process encoded frames before they are packetised. That is where a frame-level encryption layer runs.
- PERC, RFC 8723 (April 2020), defines double encryption: one hop-by-hop layer for the server and one end-to-end layer it cannot remove.
The trade-off is direct. Once the server cannot read the media, server-side recording, transcription, and AI processing stop working unless a client does that work instead.
What VideoSDK provides
VideoSDK encrypts media in transit with SRTP and signalling with TLS. Media passes through VideoSDK's servers, which is what lets VideoSDK record, transcribe, and stream a call. A standard VideoSDK call is therefore encrypted hop by hop, in transit, and should not be described as end-to-end encrypted.
Recordings get their own layer at rest. With recording encryption turned on, each recording is encrypted with its own AES-256 key (GCM recommended, CTR supported). That key is wrapped with an RSA public key you upload before the file reaches your cloud storage. VideoSDK stores only the public key, so only the holder of your private key can decrypt the recording.
For how this maps to healthcare rules, see HIPAA compliant video conferencing API requirements.
Building a call that needs this? VideoSDK applies SRTP and TLS to every room without configuration. Start with the React quickstart and the $20 free credit.
SRTP in SIP and VoIP
In SIP and VoIP, a secure call needs two layers: TLS for the SIP signalling and SRTP for the media.
RFC 3261 sets port 5061 as the default for SIP over TLS and 5060 for UDP and TCP. The SDP inside the SIP message marks encrypted media with the RTP/SAVP profile and, when SDES is used, carries the key in an a=crypto line. That is why SRTP VoIP deployments using SDES should always run SIP over TLS: without it, the media key crosses the network readable.
When a WebRTC user calls a phone number, a gateway sits between the two worlds. It ends the DTLS-SRTP leg on the WebRTC side and speaks SIP to the carrier, using SRTP if the trunk supports it. Any call that reaches the public phone network leaves SRTP at the carrier boundary.
VideoSDK's inbound and outbound telephony gateways have a Media Encryption setting. With it on, VideoSDK uses TLS for SIP signalling and SRTP for media and expects the carrier's signalling over TLS. The IP whitelisting page lists 5060 for TCP and UDP and 5061 for TLS. To connect a SIP trunk to a room, follow the SIP connect quickstart.
What port does SRTP use?
There is no fixed SRTP port number. SRTP uses whichever ports RTP would, and those are usually negotiated dynamically in the SDP. IANA registers 5004 and 5005 for RTP and RTCP, and RFC 3550 recommends an even port for RTP with RTCP on the next odd port.
WebRTC narrows this further. It multiplexes RTP and RTCP on one port (RFC 5761) and bundles audio, video, and data onto one transport (RFC 8843), so a call typically uses a single UDP port per connection.
SRTP does not change NAT traversal. ICE, STUN, and TURN find the network path, as explained in the WebRTC guide, and SRTP rides on whatever path they find. For VideoSDK firewall rules, the firewall setup guide lists UDP ports 40000 to 60000 for media, with TURN on port 3478 or TCP 443 as fallbacks.
SRTP cyber security: what it stops and what it leaves exposed
In an SRTP cyber security review, the useful question is which attacks SRTP blocks and which it leaves to other layers.
SRTP stops three things on every network hop:
- Eavesdropping. The audio and video content is unreadable without the session key.
- Tampering. A modified packet fails the authentication tag and is dropped.
- Replay. A recorded packet sent again is rejected by the replay list.
SRTP leaves these to something else:
- Headers and traffic patterns. Sequence numbers, timestamps, SSRCs, packet sizes, and timing stay visible, and so do header extensions unless RFC 6904 or Cryptex is in use.
- Signalling and chat. SRTP covers media only. Text in an SRTP chat or calling app travels over the signalling channel or a WebRTC data channel, protected by TLS or DTLS instead.
- The server hop. A media server that holds the keys can read the media, as explained above.
- The devices. Malware on a phone or laptop sees the media before it is encrypted.
Key takeaways
- SRTP encrypts RTP payloads with AES and authenticates each whole packet, blocking eavesdropping, tampering, and replay, while leaving headers readable.
- The key exchange decides who can see the key: DTLS-SRTP keeps it off the signalling path, while SDES puts it in the SDP.
- WebRTC mandates DTLS-SRTP and requires support for AES_CM_128_HMAC_SHA1_80, and should prefer AES-GCM when both ends support it.
- SRTP through a media server is encryption in transit, not end-to-end encryption. VideoSDK uses SRTP and TLS in transit and offers encrypted recordings with a key only you hold.
Conclusion
SRTP is the reason live audio and video on the web is encrypted by default. It is also why "encrypted" needs a second question: encrypted between whom? Most group calls are protected on every network hop and readable at the server, which is what makes recording and transcription possible.
VideoSDK applies SRTP and TLS to every call and lets you encrypt recordings with your own key. Try it with the $20 free credit at VideoSDK, or check pricing. What is your team's threat model for call media?
Frequently asked questions
What is SRTP protocol?
SRTP protocol is the Secure Real-time Transport Protocol, defined in RFC 3711, which adds encryption, message authentication, and replay protection to RTP media. It protects the audio and video in WebRTC calls and in secure SIP and VoIP calls. The keys come from a separate exchange such as DTLS-SRTP or SDES.
What is the difference between RTP and SRTP?
The difference is protection. RTP sends media payloads in the clear with no integrity check, while SRTP encrypts the payload and adds an authentication tag, 80 bits by default, over the header and payload. The RTP header stays readable in both.
What is DTLS-SRTP?
DTLS-SRTP is the key exchange defined in RFC 5764, in which the two endpoints run a DTLS handshake on the media path and derive SRTP keys from it. The signalling carries only a certificate fingerprint, so the signalling server never sees the key. WebRTC requires it.
Does SRTP encrypt chat messages?
No. SRTP encrypts only RTP audio and video. In WebRTC, chat usually travels over a data channel, which is encrypted with DTLS, or through the app's signalling server over TLS.
How much overhead does SRTP add?
SRTP adds a 10-byte authentication tag per packet with the default suite, 4 bytes with the 32-bit tag, and 16 bytes with AES-GCM. Counter-mode encryption does not change the payload size. An optional master key identifier, whose length the key management sets, adds to that when used.
Does VideoSDK use SRTP?
Yes. VideoSDK's compliance documentation lists SRTP for media and TLS for signalling, and its telephony gateways support TLS plus SRTP for SIP calls. Media passes through VideoSDK's servers, so calls are encrypted in transit rather than end to end, and recordings can be encrypted at rest with a key you hold.