Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
updated by
Extracted elements (29)
The optional T_rr_interval parameter (minimum interval between Regular RTCP packets) was introduced to allow applications to reduce Regular RTCP overhead while still supporting more-frequent Early RTCP packets. Reducing overall RTCP bandwidth alone could not achieve this because it would also reduce the rate of Early feedback.
The random dithering delay T_dither_max before sending Early feedback was chosen specifically to prevent feedback implosion in multiparty sessions: multiple receivers detecting the same loss spread their reports randomly over the dither window, allowing the first to transmit to suppress the others. For point-to-point sessions, no dithering is needed (T_dither_max=0).
Three operational modes (Immediate Feedback, Early RTCP, Regular RTCP) are defined as soft, application-specific thresholds with no requirement that all participants agree on a common mode boundary. The algorithm scales smoothly across all modes; the mode labels are conceptual guidance for application designers rather than protocol state.
AVP and AVPF entities can coexist in the same RTP session without disrupting each other's core operation. If AVP entities may be present, T_rr_interval SHOULD be set to five seconds: if it is too large, AVPF entities may time out AVP members that legitimately follow the five-second rule; if T_rr is too small, AVPF entities may also time out AVP members prematurely.
AVPF receivers SHOULD send Early RTCP feedback packets only when all sending entities in the session support AVPF. In mixed AVP/AVPF sessions, receivers MAY include feedback in regularly scheduled RTCP packets following RFC 3550 timing but MUST NOT rely on the sender reacting to any feedback.
A minimal compound RTCP feedback packet (exactly one RR/SR, exactly one SDES with only CNAME, and the FB messages) SHOULD be used whenever an FB message is sent as an Early RTCP packet, to minimize packet size and maximize allowable feedback frequency within the RTCP bandwidth limit.
ACK mode (positive acknowledgement feedback) MUST only be used in sessions with exactly two members; the group MUST NOT be allowed to grow. Unicast addresses SHOULD be used in the session description for ACK mode sessions.
After transmitting an Early RTCP packet, a receiver MUST set allow_early=FALSE, MUST update tn=tp+2*T_rr (effectively skipping one regular interval to preserve average RTCP bandwidth), and MUST set tp to the previous tn. allow_early MUST be reset to TRUE when the new tn is reached.
An Early RTCP packet MUST be scheduled at te = t0 + RND * T_dither_max, where RND is uniform in [0,1]. For point-to-point sessions T_dither_max=0; for multiparty sessions T_dither_max is at minimum 0.5 * T_rr. A future document specifying an alternative T_dither_max calculation MUST ensure all receivers use the same mechanism.
Compound RTCP feedback packets MUST follow RFC 3550 ordering: optional encryption prefix, mandatory SR or RR, mandatory SDES containing at least the CNAME item, then one or more FB messages. FB messages MUST be placed after the RR/SR and SDES packets.
Feedback following AVPF timing rules MUST NOT be sent for a media session unless the session description indicates the 'AVPF' profile. The SDP 'rtcp-fb' attribute MUST only be used as a media-level attribute and MUST NOT appear at the session level.
If a receiver finds a pending FB message from another session member that is a superset of its own pending feedback, it MUST discard its own FB message and MUST reschedule the next Regular RTCP packet for tn. Receivers MUST store all received FB messages for at least T_retention to enable this suppression check.
In the offer/answer model, the answerer MUST remove 'rtcp-fb' attributes it does not understand or support and MUST NOT add or alter feedback parameters. Both offerer and answerer MUST use only the feedback mechanisms negotiated in this exchange.
T_retention, the retention window for stored FB messages used to enable feedback suppression, MUST be set to at least 2 seconds.
When 'rtcp-fb' attributes are present in a session description, receivers MUST ignore attributes whose semantics they do not fully understand and MUST NOT use FB message types not listed in the 'rtcp-fb' attribute lines. RTP senders MUST silently discard all received FB messages they do not understand.
When T_rr_interval is non-zero, the RTP entity timeout calculation (RFC 3550 Section 6.3.5) MUST use T_rr_interval instead of Tmin for computing Td and thus the M*Td timeout, to prevent premature timeout of entities that legitimately suppress Regular RTCP packets.
Application Layer Feedback (AFB) is PSFB FMT=15 and provides a transparent container for application-defined feedback data. The format only defines a common header; the content is interpreted solely by the application layer and is not acted upon at the RTP or codec layer.
Generic NACK is RTPFB FMT=1. It reports loss of one or more RTP packets by sequence number and bitmask, and SHOULD NOT be used when the underlying transport (e.g., DCCP) already provides equivalent loss feedback to the sender.
Picture Loss Indication (PLI) is PSFB FMT=1 with no FCI (length MUST be 2). It notifies the encoder that an unspecified amount of coded video data has been lost, potentially breaking inter-picture prediction; the encoder MAY respond with an intra-frame subject to congestion control.
Reference Picture Selection Indication (RPSI) is PSFB FMT=3. It carries codec-specific data referencing a prior correctly decoded picture, allowing the sender to choose that frame as a new prediction reference instead of sending a bandwidth-costly full intra-frame.
Slice Loss Indication (SLI) is PSFB FMT=2 and reports loss or corruption of consecutive macroblocks in raster-scan order. It MUST NOT be used with video codecs that have non-uniform, dynamically changeable macroblock sizes (e.g., H.263 Annex Q), where the encoder cannot identify the corrupted spatial region.
Two RTCP packet type values identify feedback classes: RTPFB (PT=205) for transport-layer feedback and PSFB (PT=206) for payload-specific feedback. Within each class, the 5-bit FMT field distinguishes specific message types; FMT=31 is reserved in both classes for future identifier-space expansion.
IANA registers the 'rtcp-fb' SDP attribute and a registry of RTCP feedback type names. Initial entries include 'ack' (positive acknowledgement), 'nack' (negative acknowledgement, with sub-parameters pli/sli/rpsi/app), and 'trr-int' (minimum Regular RTCP interval in ms). New feedback type names MUST be unique and registered with IANA along with their semantics and packet formats.
IANA registers two new RTCP packet types: RTPFB (205) for transport-layer feedback and PSFB (206) for payload-specific feedback. Separate 'FMT' value registries are created under each: Generic NACK is RTPFB FMT=1; PLI, SLI, and RPSI are PSFB FMT=1, 2, and 3 respectively; FMT=31 is reserved in both for future expansion.
The AVPF profile inherits all security properties of RTP (RFC 3550) and AVP (RFC 3551). Early RTCP feedback may be misused to send RTCP packets at higher-than-normal rates; the RTCP bandwidth constraints defined in this document are the primary safeguard, and implementations MUST enforce them even when processing or generating feedback.
The per-receiver Boolean allow_early controls Early RTCP eligibility. It is initialized to TRUE; set to FALSE immediately after transmitting an Early RTCP packet; and reset to TRUE when the next Regular RTCP transmission point (tn) is reached, regardless of whether that Regular packet is sent or suppressed due to T_rr_interval.
All RTCP FB messages share a common 12-octet header: V (2 bits), P (1 bit), FMT (5 bits identifying the specific FB type), PT (8 bits, RTPFB=205 or PSFB=206), Length (16 bits), SSRC of packet sender (32 bits), SSRC of media source (32 bits), followed by variable-length Feedback Control Information (FCI).
Generic NACK FCI consists of one or more 32-bit entries, each with Packet ID (PID, 16 bits) giving the lost RTP sequence number and a Bitmask of following Lost Packets (BLP, 16 bits) indicating loss of any of the 16 RTP packets immediately following PID. Packet length MUST be set to 2+n where n is the number of NACKs.
Slice Loss Indication (SLI) FCI uses 32-bit entries encoding First macroblock address (13 bits, raster-scan order from upper-left), Number of lost macroblocks (13 bits), and PictureID (6 least-significant bits of the codec-specific picture identifier). Packet length MUST be set to 2+n.