2. SAVPF Rules
SAVP is defined as an intermediate layer between RTP (following the regular RTP profile AVP) and the transport layer (usually UDP). This yields a two-layer hierarchy within the Real-time Transport Protocol. In SAVPF, the upper (AVP) layer is replaced by the extended RTP profile for feedback (AVPF).
AVPF modifies timing rules for transmitting RTCP packets and adds extra RTCP packet formats specific to feedback. These functions are independent of whether or not RTCP packets are subsequently encrypted and/or integrity protected. The functioning of the AVPF layer remains unchanged in SAVPF.
The AVPF profile derives from RFC 3550 [1] the (optional) use of the encryption prefix for RTCP. The encryption prefix MUST NOT be used within the SAVPF profile (it is not used in SAVP, as it is only applicable to the encryption method specified in [1]).
The SAVP part uses extra fields added to the end of RTP and RTCP packets and executes cryptographic transforms on (some of) the RTP/RTCP packet contents. This behavior remains unchanged in SAVPF. The average RTCP packet size calculation done by the AVPF layer for timing purposes MUST take into account the fields added by the SAVP layer.
The SRTP part becomes active only when the RTP or RTCP was scheduled by the "higher" AVPF layer or received from the transport protocol, irrespective of its timing and contents.
2.1. Packet Formats
AVPF defines extra packet formats to provide feedback information. Those extra packet formats defined in RFC 4585 [3] (and further ones defined elsewhere for use with AVPF) MAY be used with SAVPF.
SAVP defines a modified packet format for SRTP and SRTCP packets that essentially consists of the RTP/RTCP packet formats plus some trailing protocol fields for security purposes. For SAVPF, all RTCP packets MUST be encapsulated as defined in Section 3.4 of RFC 3711 [4].
2.2. Extensions
Extensions to AVPF RTCP feedback packets defined elsewhere MAY be used with the SAVPF profile provided that those extensions are in conformance with the extension rules of RFC 4585 [3].
Additional extensions (e.g., transforms) defined for SAVP following the rules of Section 6 of RFC 3711 [4] MAY also be used with the SAVPF profile. The overhead per RTCP packet depends on the extensions and transforms chosen. New extensions and transforms added in the future MAY introduce yet unknown further per-packet overhead.
Finally, further extensions specifically to SAVPF MAY be defined elsewhere.
2.3. Implications from Combining AVPF and SAVP
The AVPF profile aims at -- statistically -- allowing receivers to provide timely feedback to senders. The frequency at which receivers are, on average, allowed to send feedback information depends on the RTCP bandwidth, the group size, and the average size of an RTCP packet. SRTCP (see Section 3.4 of RFC 3711 [4]) adds extra fields (some of which are of configurable length) at the end of each RTCP packet that are probably at least some 10 to 20 bytes in size (14 bytes as default). Note that extensions and transforms defined in the future, as well as the configuration of each field length, MAY add greater overhead. By using SRTP, the average size of an RTCP packet will increase and thus reduce the frequency at which (timely) feedback can be provided. Application designers need to be aware of this, and take precautions so that the RTCP bandwidth shares are maintained. This MUST be done by adjusting the RTCP variable "avg_rtcp_size" to reflect the size of the SRTCP packets.