If you've ever wondered why your VoIP call is encrypted on some hops and plaintext on others, RFC 8643 is the pragmatic compromise that explains it. Opportunistic SRTP (OSRTP) is a tiny but consequential trick: use encrypted media when the other side supports it, but don't fail the call if they don't. It is the same philosophy as opportunistic TLS for SMTP (STARTTLS) — better than nothing, worse than mandatory.

The problem. SRTP (RFC 3711) gives you encrypted, authenticated RTP. The keys are negotiated out-of-band, typically through SDP using either SDES (keys carried in SIP, RFC 4568) or DTLS-SRTP (keys negotiated in-band, RFC 5763/5764). The catch: SDP uses different media transport identifiers for secured (RTP/SAVP, UDP/TLS/RTP/SAVP) versus unsecured (RTP/AVP) sessions. If an endpoint offers UDP/TLS/RTP/SAVP and the far end doesn't speak DTLS-SRTP, the offer is rejected outright. The call fails. So in a world of mixed legacy PBXs, SIP trunks, and gateways, operators were forced to choose: offer plaintext and always interop, or offer secure and break half your calls.

The trick. OSRTP works at the SDP offer/answer layer (RFC 3264). The offerer advertises RTP/AVP — the plaintext profile — but also includes the cryptographic attributes for SRTP (a=crypto for SDES, or a=fingerprint and a=setup for DTLS-SRTP). A legacy endpoint sees the familiar RTP/AVP, ignores the attributes it doesn't understand, and answers in plaintext. A modern endpoint sees the keying material, recognizes the opportunistic intent, and answers with the same security attributes — upgrading the session to SRTP. No new SIP headers, no new option tags, no flag day.

Key design decisions:

• No fallback negotiation — there's no "try secure, then retry plaintext" round trip. One offer, one answer. Latency-sensitive.
• No active downgrade detection — the spec is honest that a MITM can strip the crypto attributes. OSRTP explicitly does not protect against active attackers. It defends against passive wiretapping only.
• User indication is mandatory — endpoints SHOULD signal to the user whether the session ended up encrypted. Without this, users get a false sense of security.
• Works with both keying mechanisms — SDES and DTLS-SRTP. The RFC carefully specifies the SDP shape for each.

Why it matters today. Almost every enterprise SIP deployment lives in this messy interop zone. Carrier SBCs, conference bridges, and analog gateways still don't all speak SRTP. OSRTP is what lets a Webex or Teams gateway negotiate encryption with a peer that supports it while still completing calls to the PSTN. WebRTC, by contrast, mandates SRTP — but the moment WebRTC media crosses a SIP gateway, you're back in OSRTP territory. The RFC also documents a real ecosystem behavior: vendors were already doing this informally, and IETF standardized the existing practice rather than inventing something new. That's classic IETF — pave the cowpath.

The philosophical backstory. OSRTP is part of a broader IETF push after the Snowden disclosures (see RFC 7258, "Pervasive Monitoring Is an Attack") to make encryption the default, even when it can't be perfect. The argument: encrypting some traffic raises the cost of bulk passive surveillance, even if targeted attacks remain feasible. It's the same logic as DNS-over-TLS opportunistic mode and SMTP STARTTLS. Imperfect crypto, deployed broadly, beats perfect crypto deployed narrowly.