The Secure Real-time Transport Protocol (SRTP, RFC 3711) provides confidentiality, message authentication, and replay protection for real-time audio and video communications. In the WebRTC specification (RFC 8826/8827), unencrypted RTP is strictly forbidden: all audio/video streams and RTCP control telemetry must be encrypted with SRTP. SRTP encrypts the RTP payload (e.g. Opus audio samples or VP8/VP9/AV1 video frames) while leaving the 12-byte RTP header in the clear so intermediate routers and Selective Forwarding Units (SFUs) can inspect sequence numbers, timestamps, payload types, and Synchronization Source (SSRC) identifiers for routing and jitter buffer synchronization without needing to decrypt the media.

In legacy VoIP protocols (SDES-SRTP, RFC 4568), symmetric SRTP master keys were transmitted as base64 plain text directly inside Session Description Protocol (SDP) signaling messages, exposing communications to any SIP proxy or signaling server. WebRTC completely eliminated SDES in favor of DTLS-SRTP (RFC 5764). Endpoints establish a direct Datagram Transport Layer Security (DTLS) handshake over the peer-to-peer UDP connection negotiated via ICE. During the handshake, endpoints advertise supported SRTP protection profiles via the "use_srtp" extension (e.g. SRTP_AEAD_AES_256_GCM or SRTP_AES128_CM_HMAC_SHA1_80). Once the DTLS handshake finishes, both peers invoke the TLS-Exporter function (RFC 5705) using the label "EXTRACTOR-dtls_srtp" to derive client and server SRTP master keys and salts directly from the ephemeral Diffie-Hellman secret, completely bypassing signaling servers.

The standard RTP sequence number is only 16 bits wide, meaning it rolls over back to 0 every 65,536 packets. In a 60 FPS HD video stream transmitting 200 packets per second, a sequence rollover occurs every ~5.5 minutes! In counter-mode ciphers (AES-CTR or AES-GCM), reusing the same Initialization Vector (IV) with the same key catastrophically destroys encryption security (enabling keystream XOR recovery). To prevent IV collision across rollovers, SRTP maintains a 32-bit Rollover Counter (ROC) in sender and receiver state. The 48-bit extended packet index is calculated as: Index = (ROC * 2^16) + SEQ. The receiver uses a sliding window (typically 64 or 128 packets) to detect rollovers and out-of-order packets. The full 48-bit index is XORed into the master salt to generate a unique IV for every single packet, ensuring cryptographic uniqueness for years of continuous streaming.

In a multi-party video conference, endpoints do not establish direct mesh P2P links; instead, all participants connect to a Selective Forwarding Unit (SFU, such as Mediasoup, LiveKit, or Janus). Under standard DTLS-SRTP, encryption is hop-by-hop: Peer A establishes a DTLS-SRTP session with the SFU server, and the SFU establishes separate DTLS-SRTP sessions with Peer B and Peer C. Consequently, the SFU server must decrypt every packet from Peer A, inspect it, and re-encrypt it for Peer B. If the SFU cloud provider or infrastructure is compromised, attackers can tap, record, or transcribe private video and audio calls in the clear.

SFrame (Secure Frame, RFC 9605) and WebRTC Insertable Streams (RTCRtpScriptTransform) decouple media payload encryption from network packet encryption: (1) Frame Cryptor in Web Worker: Immediately after the browser video encoder produces a raw compressed frame (VP9 or AV1), and before RTP packetization, a Web Worker intercepts the frame via Insertable Streams and encrypts the frame bytes using SFrame (HKDF + AES-GCM with a shared conference ratchet key); (2) Hop-by-Hop SRTP: The browser packetizes the already-encrypted frame into RTP packets and applies standard DTLS-SRTP for the hop to the SFU; (3) SFU Media Routing: The SFU decrypts SRTP, reads the RTP header, selectively routes the packets to subscribers, and re-encrypts the RTP hop; (4) Client Decryption: The receiving client decrypts the outer SRTP hop, reassembles the video frame, and passes it to the SFrame Insertable Stream decryptor before feeding it to the hardware video decoder. The SFU never possesses the SFrame key and sees only ciphertext.

Modern browsers optimize Insertable Streams through zero-copy transferable ArrayBuffers and Web Workers. When using AES-GCM or ChaCha20-Poly1305 hardware instructions (via WebCrypto or compiled WebAssembly SIMD), frame encryption adds approximately 0.1ms to 0.3ms of latency per 1080p video frame and less than 0.05ms for Opus audio packets. Because encryption occurs inside a dedicated Web Worker (RTCRtpScriptTransform), the main browser UI thread experiences 0% stutter or frame drops, ensuring solid 60 FPS video playback.