RTCP message for Receiver Estimated Maximum
BitrateGoogleKungsbron 2Stockholm11122Swedenharald@alvestrand.noThis document proposes an RTCP message for use in
experimentally-deployed congestion control algorithms for RTP-based
media flows.It also describes an absolute-value timestamp option for use in
bandwidth estimatoin.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 in other RFCs.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.We negotiate use of the message in SDP using a header extension
according to RFC 4585 section 4.2, with the value "goog-remb":a=rtcp-fb:<payload type> goog-rembGoogle has found that there are issues with relative send time offset
when packets are relayed at nodes that are not the source of the RTP
clock; it is hard to generate accurate offsets when you have to
regenerate the base clock from the incoming packets before you can
figure out what time to match; also, using signals from multiple flows
becomes impossible unless the timestamps come from a common clock.The Absolute Send Time extension is used to stamp RTP packets with a
timestamp showing the departure time from the system that put this
packet on the wire (or as close to this as we can manage).Name: "Absolute Sender Time" ; "RTP Header Extension for Absolute
Sender Time".Formal name:
"http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time".Wire format: 1-byte extension, 3 bytes of data. total 4 bytes
extra per packet (plus shared 4 bytes for all extensions present: 2
byte magic word 0xBEDE, 2 byte # of extensions). Encoding: Timestamp is in seconds, 24 bit 6.18 fixed point,
yielding 64s wraparound and 3.8us resolution (one increment for each
477 bytes going out on a 1Gbps interface).Relation to NTP timestamps: abs_send_time_24 = (ntp_timestamp_64
>> 14) & 0x00ffffff ; NTP timestamp is the number of
seconds since the epoch, in 32.32 bit fixed point format.Notes: Packets are time stamped when going out, preferably close
to metal. Intermediate RTP relays (RTP entities possibly altering
the relative timing of packets in the stream) should remove the
extension or overwrite its value with its own timestamp.When signalled in SDP, the standard mechanism for RTCP
extensions is used:a=extmap:3
http://www.webrtc.org/experiments/rtp-hdrext/abs-send-timeUpon publication of this document as an RFC (if it is decided to
publish it), IANA is requested to register the string "goog-remb" in its
registry of "rtcp-fb" values in the SDP attribute registry group.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.No changes. These are "keepalive" publications.Added information on the absolute-timestamp extension and on SDP
negotiation of REMB.