Google

Kungsbron 2 Stockholm 11122 Sweden harald@alvestrand.no

This document proposes an RTCP message for use in experimentally-deployed congestion control algorithms for RTP-based media flows. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

This document proposes an RTCP feedback message signalling the estimated total available bandwidth for a session. If this function is available, it is possible to implement the algorithm in , or other algorithms with the same kind of feedback messaging need, in a fashion that covers multiple RTP streams at once.

This feedback message is used to notify a sender of multiple media streams over the same RTP session of the total estimated available bit rate on the path to the receiving side of this RTP session. Within the common packet header for feedback messages (as defined in section 6.1 of ), the "SSRC of packet sender" field indicates the source of the notification. The "SSRC of media source" is not used and SHALL be set to 0. This usage of the value zero is also done The reception of a REMB message by a media sender conforming to this specification SHALL result in the total bit rate sent on the RTP session this message applies to being equal to or lower than the bit rate in this message. The new bit rate constraint should be applied as fast as reasonable. The sender is free to apply additional bandwidth restrictions based on its own restrictions and estimates.

This document describes a message using the application specific payload type. This is suitable for experimentation; upon standardization, a specific type can be assigned for the purpose. The message is an RTCP message with payload type 206. RFC 3550 defines the range, RFC 4585 defines the specific PT value 206 and the FMT value 15.

The fields V, P, SSRC, and length are defined in the RTP specification [2], the respective meaning being summarized below: This field identifies the RTP version. The current version is 2. If set, the padding bit indicates that the packet contains additional padding octets at the end that are not part of the control information but are included in the length field. Always 0. This field identifies the type of the FB message and is interpreted relative to the type (transport layer, payload- specific, or application layer feedback). Always 15, application layer feedback message. RFC 4585 section 6.4. This is the RTCP packet type that identifies the packet as being an RTCP FB message. Always PSFB (206), Payload-specific FB message. RFC 4585 section 6.4. The length of this packet in 32-bit words minus one, including the header and any padding. This is in line with the definition of the length field used in RTCP sender and receiver reports [3]. RFC 4585 section 6.4. The synchronization source identifier for the originator of this packet. RFC 4585 section 6.4. Always 0; this is the same convention as in section 4.2.2.2 (TMMBN). Always ‘R’ ‘E’ ‘M’ ‘B’ (4 ASCII characters). Number of SSRCs in this message. The exponential scaling of the mantissa for the maximum total media bit rate value, ignoring all packet overhead. The value is an unsigned integer [0..63], as in RFC 5104 section 4.2.2.1. The mantissa of the maximum total media bit rate (ignoring all packet overhead) that the sender of the REMB estimates. The BR is the estimate of the traveled path for the SSRCs reported in this message. The value is an unsigned integer in number of bits per second. Consists of one or more SSRC entries which this feedback message applies to.

Either end of an RTP session can send this message. There is no signalling to indicate that the message can be understood. OPEN ISSUE: Do we need signalling, and if so, how should it be done? It does not seem harmful to send it when recipient does not understand it, but negotiating it may give better behaviour when it is not available (by falling back to per-RTP-session TMMBR messages).

This document requests no action of IANA. This section can be removed upon publication as an RFC.

If the RTCP packet is not protected, it is possible to inject fake RTCP packets that can increase or decrease bandwidth. This is not different from security considerations for any other RTCP message.

This proposal has emerged from discussions between, among others, Justin Uberti, Magnus Flodman, Patrik Westin, Stefan Holmer and Henrik Lundin.

The timestamp option was removed. Discussion concluded that the RFC 5450 "transmission time offset" header likely gives accurate enough send-time information for our purposes.