Every time you join a Google Meet, a Discord voice channel, a Zoom call (on its WebRTC path), or a FaceTime audio session, RFC 5763 is doing invisible work. It is the framework that explains how two endpoints, having signaled through some session protocol (SIP, Jingle, or modern SDP-over-HTTPS), can derive SRTP keys without ever trusting the signaling path with the key material itself.

The problem. SRTP (RFC 3711) encrypts and authenticates RTP packets, but it doesn't say how peers agree on keys. The earlier answer, SDES (RFC 4568), shoved a base64-encoded master key directly into the SDP offer/answer. That meant your SIP proxy, your STUN server operator, your call recording vendor, and anyone tapping the signaling plane could decrypt your media. For end-to-end media confidentiality, this was a non-starter.

The design. RFC 5763 punts the key agreement to DTLS (TLS over UDP, RFC 6347), but with two clever twists:

• The DTLS handshake runs over the same 5-tuple that will carry media, after ICE has finished punching holes. This means no extra ports, and the handshake itself confirms the path works.
• Endpoints use self-signed certificates. PKI is irrelevant here — the certs are just containers for ephemeral public keys. Identity binding is done out-of-band by carrying a SHA-256 a=fingerprint attribute in the signed SDP. If your signaling channel has integrity (e.g., SIP Identity, or HTTPS to a trusted server), an attacker swapping certs mid-handshake gets detected.

Once the DTLS handshake completes, RFC 5764 (the companion document, DTLS-SRTP extension) uses TLS's exporter mechanism to derive SRTP master keys from the DTLS session secret. The DTLS traffic then stops, and the same UDP flow carries SRTP-protected RTP. Both directions get keys; the offerer is always the DTLS client unless a=setup:passive says otherwise.

Why the split into 5763 + 5764? 5763 is the framework: how DTLS-SRTP fits into the SIP/SDP world, certificate handling, fingerprint comparison, the a=setup: active/passive/actpass dance borrowed from RFC 4145, and the security analysis. 5764 is the wire-level extension: the use_srtp TLS extension, the key derivation, and the SRTP profile negotiation. You need both, but 5763 is the one explaining the why.

Why it matters today. The W3C WebRTC spec mandates DTLS-SRTP and forbids SDES outright. Every browser, every RTCPeerConnection, every libwebrtc-based product (which is most of them) implements this. The a=fingerprint:sha-256 ... line in any modern SDP offer is the externally visible fingerprint of this protocol. When Chrome and Firefox interop on a video call, this RFC is what keeps the operator of your TURN relay from listening in.

A subtle history bit. Eric Rescorla, one of the authors, also wrote the TLS 1.3 spec and the DTLS 1.3 spec. The lineage of design — minimal trust in intermediaries, explicit identity binding via fingerprints, key derivation via exporters — runs straight through his RFCs. The fingerprint-in-signed-signaling pattern was later borrowed by other protocols, including some IoT pairing flows and the original SDP-based ZRTP fallback designs.

The framework also quietly answered a deployment question: how do you do end-to-end media security when one or both endpoints are behind NAT and you can't run a full PKI on every WebRTC client? Answer: don't try. Run DTLS over the media path, use throwaway certs, and lean on your signaling channel's integrity for the fingerprint. Eighteen years later, this is still the model.