Summary

  • RFC 5124 combined the feedback behavior of AVPF with the security processing of SAVP under the profile name SAVPF.
  • The AVPF scheduler does not disappear inside the secure profile; it still works from RTCP bandwidth, group size and average packet size.
  • SRTCP adds fields to every RTCP packet. RFC 5124 describes roughly 10 to 20 extra bytes and a 14-byte default case.
  • The implementation must include those bytes in avg_rtcp_size, because a larger average packet permits fewer reports within the same control-bandwidth budget.
  • RFC 4585's rough Immediate Feedback relation, N <= B*T/R, makes the trade explicit: increasing packet size R reduces the number of events N reportable inside interval T at bandwidth B.
  • A secure profile choice is not evidence that signaling itself was protected from a bidding-down attack.
  • It is not a key-establishment receipt, an SRTCP authentication result, a timely-arrival measurement or a media-recovery result.
  • SAVPF inherits SAVP's security properties; it does not invent a new cipher, key-management system or end-to-end identity layer.
  • SRTCP integrity is mandatory, but confidentiality is not universal: RFC 3711 permits NULL encryption, and group-key integrity need not identify one unique source.
  • Negotiation is scoped per media description. One rejected video line need not erase a successful audio line, and one secure line cannot certify the whole call.
  • Secure and insecure profile families must not be mixed in one RTP session, even though SAVP and SAVPF endpoints may coexist within the secure family.
  • Operations should record capability, offer, protected selection, keys, packet acceptance, budget, timing, sender action and rendered outcome as separate receipts.

One report, fourteen more bytes

Imagine a receiver detecting a lost video packet. Under the feedback profile defined by RFC 4585, it may try to send a negative acknowledgement before the next regular RTCP report. The value of that report is perishable. A retransmission requested after the decoder's useful window has closed may be cryptographically impeccable and operationally worthless.

RFC 5124 does not replace that feedback mechanism. It places the AVPF layer above the SAVP security layer. AVPF decides when an RTCP feedback packet may be scheduled and what feedback format it carries. SAVP then applies SRTCP processing and appends security fields. Every RTCP packet in SAVPF must use the SRTCP encapsulation defined by RFC 3711.

That composition matters because RTCP is budgeted. RFC 5124 says the SRTCP fields are probably at least 10 to 20 bytes in the configurations it discusses, with 14 bytes as the default example. The number is not a universal constant: master-key identifiers, authentication-tag choices and later transforms can change it. The invariant is that the protected packet size, not the unprotected packet size, belongs in the scheduler's evidence.

The standard therefore requires avg_rtcp_size to reflect SRTCP packets. This is unusually valuable specification language because it prevents a seductive category error. Security is not free metadata attached outside the transport economy. It consumes bytes. Those bytes alter the feedback interval even when every cryptographic operation works exactly as designed.

The equation is a governance boundary

RFC 4585 gives a rough expression for Immediate Feedback: N <= B*T/R. N is the average number of reportable events in interval T; B is the RTCP bandwidth available to the receiver; R is average RTCP packet size. Hold bandwidth and the application deadline constant, enlarge the packet, and fewer events fit.

The expression is an estimate rather than a service-level guarantee. Loss distribution, codec behavior, packet rate, group size and suppression rules also matter. Yet it establishes the correct direction of accountability. A dashboard that says “feedback enabled” has omitted the variable that decides whether the feedback remains timely. A dashboard that says “secure feedback enabled” can be worse if it treats the security layer as proof that no timing consequence exists.

AVPF names three operating regions. In Immediate Feedback mode, there is enough bandwidth for a receiver to report each relevant event almost immediately. In Early RTCP mode, the system cannot report everything but can still deliver selected feedback often enough to influence media transmission. In Regular RTCP mode, the group and time scale make event-by-event feedback ineffective. The boundaries are not fixed group-size constants. A larger protected average packet can move the same session closer to another region.

RFC 4585 also names T_max_fb_delay, the application-specific maximum delay within which feedback is useful. RFC 5124 does not promise that SRTCP stays below it. A conforming implementation can protect a packet that arrives too late for the codec, playout buffer or sender strategy. The security receipt and timing receipt answer different questions.

The profile token is only one receipt

RTP/SAVPF in an SDP media description expresses a profile choice. It says that the media line uses the combined secure-feedback behavior if the exchange succeeds. It does not contain the complete state of the session.

First comes capability: can each endpoint implement the profile and an acceptable keying arrangement? Then comes an offer with profile order, feedback attributes, codecs, addresses and per-media scope. Then comes signaling protection. Then selection or rejection. Only after that can key establishment produce a usable cryptographic context. Only an actual SRTCP packet can be authenticated against that context and checked for replay. Only observed timestamps can show whether the accepted report arrived before T_max_fb_delay. The sender may still decide not to retransmit or adapt. The decoder may still fail to recover. The rendered picture may still remain damaged.

Collapsing those stages into a single green “secure” indicator converts a coordination label into symbolic power. The label begins to answer questions the protocol never asked it to answer. RFC 5124 is more disciplined: its security considerations say the new profile inherits SAVP's security properties and neither adds nor removes security services.

Secure does not mean every security service

RFC 3711 describes SRTP as able to provide confidentiality, integrity or message authentication, and replay protection. The details matter. Encryption and authentication are independently configurable, while SRTCP integrity protection is mandatory because altered control messages can disrupt the media stream. The specification also defines a NULL encryption transform. Consequently, a valid SRTCP report can have strong integrity and replay evidence without proving that its control contents were confidential.

The word “authentication” also needs scope. RFC 3711 warns that in some group communication settings the service may amount to integrity protection rather than data-origin authentication of one unique sender. A shared group key can prove that a packet came from someone holding the group secret without proving which member produced it. Operations must report the trust model actually deployed, not the strongest everyday meaning of a protocol term.

Keys, algorithms, packet index, replay window, master-key identifier and context lifetime belong to the packet-security receipt. An SDP profile token contains none of those runtime outcomes. A peer can accept SAVPF in signaling while later rejecting an SRTCP packet because the context is absent, stale, mismatched or outside its replay window.

Protect the decision before protecting the report

RFC 5124 identifies a failure that happens even earlier. An offerer may have both secure and insecure profile alternatives. Listing them together can enable bidding-down and related attacks. If both kinds are offered, the negotiation signaling must be protected appropriately. Otherwise an attacker can manipulate the choice before SRTP or SRTCP begins protecting media and control packets.

This is not merely “prefer secure.” Preference is a local ordering rule. Downgrade resistance requires evidence that the offer, its order, its attributes and the answer were integrity protected against the adversary in scope. A final SAVPF selection is strong evidence of the selected profile, but it cannot retrospectively prove that a rejected or deleted alternative was never manipulated.

For one media description, AVP, AVPF, SAVP and SAVPF are mutually exclusive. If the answerer does not support an offered SAVPF line, it must reject that media session. If it wants SAVPF when the offer did not use it, it must reject and may initiate a later counter-offer. It cannot silently rewrite the offer in its answer.

Negotiation is per media line. Audio can succeed while video fails. Different profiles can be used across different RTP sessions. A call-wide security badge therefore destroys useful fault isolation. The minimum honest display is a matrix keyed by media description, RTP session and profile epoch.

Compatibility has an exact seam

RFC 5124 permits SAVP and SAVPF entities in the same RTP session because both belong to the secure family; RFC 4585 supplies the feedback interworking rules. It similarly permits AVP and AVPF within an insecure session. It forbids mixing secure and insecure families in the same RTP session because RTP and SRTP are not wire-compatible substitutes.

That seam is narrower than “supports old and new clients.” It says which packet families can coexist in one session and which require separate sessions or alternatives. When operators generalize it into an application-level compatibility promise, they lose the evidence needed to explain why one participant receives media but cannot provide early feedback, why another media line was rejected, or why a fallback opened a downgrade surface.

The RTSP procedure in RFC 5124 makes state transition explicit. A client selects exactly one profile per desired stream in SETUP; the server confirms or refuses it. Under the procedure described there, changing a profile requires tearing down and re-establishing the media stream. That is not a trivial label update. It is a continuity event with old-state retirement, new keying and new transport evidence.

Non-interactive announcements expose a different boundary. SAP, email or a web page can distribute a session description without an answer. The initiator must provide usable alternatives and protect access to sensitive keying information. RFC 4568's inline security descriptions are especially clear: if the channel carrying the description lacks confidentiality, the key can be exposed before the media begins. SRTCP cannot repair a compromised key-distribution path after the fact.

What the record can and cannot prove

The IANA registry can prove that names and values were allocated. RFC Editor metadata can prove that RFC 5124 remains listed as a Proposed Standard without an updating or obsoleting document. The later publication of RFC 8866 for SDP, RFC 7826 for RTSP, and RFC 5763/5764 for DTLS-SRTP can prove standards evolution. None of those records proves that a named endpoint implements SAVPF today.

The captured evidence contains no present deployment census, vendor interoperability result, packet trace, incident, adoption percentage or measured user outcome. This article therefore makes no claim that a particular product uses SAVPF or that the 14-byte example describes every modern cryptographic suite. It analyzes the control boundary defined by the standards.

That restraint is not a weakness. It is the operational value. The evidence chain tells leaders exactly what to collect before a profile badge is allowed to become a service claim.

Sources