skip to content

In SDP, what do the RTP/AVP, RTP/SAVP, RTP/SAVPF and UDP/TLS/RTP/SAVPF transport profiles signal, and what happens when two endpoints' profiles do not match?

level: middleimportance: should knowfreq 20%

answer

  1. the third token on the m= line
  2. S for secure, F for feedback
  3. who keys the SRTP
  4. secure and plain never mix
  5. port zero means rejected

basics

~20 s

The m= line's proto token says how media is carried: plain RTP (RTP/AVP), SRTP (RTP/SAVP), SRTP with RTCP feedback (RTP/SAVPF), or SRTP keyed by DTLS over UDP (UDP/TLS/RTP/SAVPF). Secure and plain profiles cannot mix, so a mismatch rejects that stream.

solid answer

~40 s

SDP's media line is `m=<media> <port> <proto> <fmt>`, and `<proto>` names the transport profile. RFC 8866 defines `RTP/AVP` (plain RTP), `RTP/SAVP` (SRTP) and `RTP/SAVPF` (SRTP with the RFC 4585 feedback rules); RFC 5764 adds `UDP/TLS/RTP/SAVP` and `UDP/TLS/RTP/SAVPF` when the SRTP is keyed by DTLS over UDP. The `F` adds feedback timing, not security. RFC 5124 makes AVP, AVPF, SAVP and SAVPF mutually exclusive for one media description: an answerer that cannot do the offered secure profile MUST reject the stream, which offer/answer does by answering with port zero (RFC 3264). WebRTC endpoints offer only DTLS-SRTP and never SDP security descriptions (RFC 8827), so a carrier that answers only `RTP/AVP` cannot meet them directly; a border controller has to re-originate. Offering secure and plain alternatives together invites bidding down unless the signalling is protected.

go deeper

for a junior

Recall that the m= line's third token says whether media is plain RTP or SRTP, and that the secure profiles carry an S.

for a middle

Explain what S, F and the UDP/TLS prefix each add, and walk through how an answerer rejects a profile it cannot meet with port zero.

for a senior

Spot a profile that lies on one leg of a call, and explain why WebRTC and a plain-RTP carrier can only meet through an element that re-originates media.

for a principal

Decide whether a platform should ever offer plain fallback, weighing reach to legacy peers against the bidding-down risk RFC 5124 describes.

## Where the profile lives The **Session Description Protocol** (SDP, RFC 8866) describes each media stream with an `m=` line: `m=<media> <port> <proto> <fmt> ...` Here `<proto>` is the **transport protocol**, and for RTP media it names an **RTP profile**: the rules for how RTP and RTCP are used, including whether they are protected. The same codec can run under any profile, so the profile, not the codec list, tells the far end whether to expect plain RTP or SRTP. | `<proto>` token | Media protection | Keying normally paired with it | Specification | |---|---|---|---| | `RTP/AVP` | none, plain RTP | none | RFC 3551 | | `RTP/AVPF` | none, plus RTCP feedback | none | RFC 4585 | | `RTP/SAVP` | SRTP and SRTCP | SDP security descriptions (`a=crypto`, RFC 4568) | RFC 3711 | | `RTP/SAVPF` | SRTP plus RTCP feedback | `a=crypto` | RFC 5124 | | `UDP/TLS/RTP/SAVP` | SRTP keyed by DTLS over UDP | DTLS-SRTP, `a=fingerprint` | RFC 5764 | | `UDP/TLS/RTP/SAVPF` | as above, plus feedback | DTLS-SRTP, `a=fingerprint` | RFC 5764 | ## What the letters mean - **S** means the stream uses **SRTP** (RFC 3711) instead of plain RTP. - **F** means the **AVPF** feedback profile (RFC 4585): earlier RTCP feedback such as loss indications. RFC 5124 says SAVPF "does not add or take away any security services" compared with SAVP. - **AVP** is the base profile of RFC 3551, which assigns the static payload types and the default RTCP behaviour every other profile here builds on. - **UDP/TLS/** in front means the SRTP keys come from a DTLS handshake on the media path (RFC 5764), not from keys written into the SDP. ## Mismatch rules RFC 5124 sets the negotiation rules for these profiles: 1. For one media description, AVP, AVPF, SAVP and SAVPF are **mutually exclusive**; AVP or AVPF entities on one side and SAVP or SAVPF on the other **MUST NOT be mixed** in one RTP session. 2. If an offer uses SAVPF and the answerer does not support it, the media stream **MUST be rejected**. 3. If an offer does not use SAVPF but the answerer wants it, the answerer **MUST reject** the stream and MAY send a new offer of its own. 4. In offer/answer (RFC 3264), rejecting a stream means answering its `m=` line with **port zero**; if every stream is rejected, the whole session fails. Negotiation is per media description, so audio may succeed while video is rejected. ## Bidding down and best-effort SRTP An offerer that wants to reach both secure and plain peers is tempted to offer both. RFC 5124 warns that an offer SHOULD NOT include a secure and an insecure alternative together, because an attacker who can alter signalling can strip the secure choice and force plain media; if both are offered, the signalling MUST be protected. RFC 5763 section 6.11 describes best-effort encryption through SDP capability negotiation, where the actual line is `RTP/AVP` and an attribute such as `a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP` advertises the secure alternative to peers that understand it. ## Assembling it at a border controller The reserved scenario for this topic is a border controller between WebRTC clients and a SIP carrier: - RFC 8827 requires WebRTC endpoints to offer DTLS-SRTP for every media channel, to send no plain RTP, and never to offer or accept SDP security descriptions. The browser leg is therefore `UDP/TLS/RTP/SAVPF`. - A carrier interconnect commonly accepts `RTP/AVP`, or `RTP/SAVP` with `a=crypto` keys over protected signalling. - Forwarding the browser's offer unchanged to such a carrier gets the stream rejected with port zero. The border has to answer the browser itself and send the carrier a fresh offer in the carrier's profile. The failure that looks strangest in production is a profile that lies. If an intermediary rewrites `RTP/SAVP` to `RTP/AVP` in the SDP but leaves the media encrypted, or the reverse, the receiving stack either reads the last bytes of a plain packet as a tag that fails, or hands ciphertext to the decoder. The call is "up" and nobody hears anything, so compare the `<proto>` token on each leg with what is actually on the wire.

  • Does choosing RTP/SAVPF instead of RTP/SAVP make a call more secure?
    No. RFC 5124 says SAVPF adds no security services over SAVP; it adds the AVPF feedback timing rules, such as earlier RTCP feedback. Both protect media with SRTP and SRTCP, and both use the same crypto attributes. The choice matters for feedback-dependent behaviour, such as video loss recovery, not for confidentiality or integrity.
  • How does an SDP answer reject one media stream while accepting the rest?
    Under the offer/answer model of RFC 3264, the answerer keeps an m= line for every offered stream, in the same order, and sets the port of the one it rejects to zero. The other streams proceed normally. Only when every stream is rejected does the whole offered session fail.

saying these in an interview costs you the question

  • RTP/SAVPF is more secure than RTP/SAVP.
  • An answerer can accept an RTP/SAVP offer and simply send plain RTP back.
  • Offering RTP/SAVP and RTP/AVP side by side is harmless graceful fallback.
  • UDP/TLS/RTP/SAVPF means the media is carried inside DTLS records.
  • A WebRTC endpoint can fall back to a=crypto keys when a carrier asks for them.