draft-ietf-avt-avpf-ccm-04.txt   draft-ietf-avt-avpf-ccm-05.txt 
Network Working Group Stephan Wenger Network Working Group Stephan Wenger
INTERNET-DRAFT Umesh Chandra INTERNET-DRAFT Umesh Chandra
Expires: May 2007 Nokia Expires: October 2007 Nokia
Magnus Westerlund Magnus Westerlund
Bo Burman Bo Burman
Ericsson Ericsson
March 5, 2007 May 14, 2007
Codec Control Messages in the Codec Control Messages in the
RTP Audio-Visual Profile with Feedback (AVPF) RTP Audio-Visual Profile with Feedback (AVPF)
draft-ietf-avt-avpf-ccm-04.txt> draft-ietf-avt-avpf-ccm-05.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 5 skipping to change at page 2, line 5
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies a few extensions to the messages defined in This document specifies a few extensions to the messages defined in
the Audio-Visual Profile with Feedback (AVPF). They are helpful the Audio-Visual Profile with Feedback (AVPF). They are helpful
primarily in conversational multimedia scenarios where centralized primarily in conversational multimedia scenarios where centralized
multipoint functionalities are in use. However some are also usable multipoint functionalities are in use. However some are also usable
in smaller multicast environments and point-to-point calls. The in smaller multicast environments and point-to-point calls. The
extensions discussed are messages related to the ITU-T H.271 Video extensions discussed are messages related to the ITU-T H.271 Video
Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit- Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit
rate and Temporal Spatial Trade-off. Rate and Temporal Spatial Trade-off.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction....................................................5 1. Introduction....................................................5
2. Definitions.....................................................7 2. Definitions.....................................................6
2.1. Glossary...................................................7 2.1. Glossary...................................................6
2.2. Terminology................................................8 2.2. Terminology................................................6
2.3. Topologies.................................................9 2.3. Topologies.................................................9
3. Motivation (Informative).......................................10 3. Motivation (Informative).......................................10
3.1. Use Cases.................................................10 3.1. Use Cases.................................................10
3.2. Using the Media Path......................................12 3.2. Using the Media Path......................................12
3.3. Using AVPF................................................13 3.3. Using AVPF................................................13
3.3.1. Reliability..........................................13 3.3.1. Reliability..........................................13
3.4. Multicast.................................................13 3.4. Multicast.................................................13
3.5. Feedback Messages.........................................13 3.5. Feedback Messages.........................................13
3.5.1. Full Intra Request Command...........................13 3.5.1. Full Intra Request Command...........................13
3.5.1.1. Reliability.....................................14 3.5.1.1. Reliability.....................................14
3.5.2. Temporal Spatial Trade-off Request and Announcement..15 3.5.2. Temporal Spatial Trade-off Request and Notification..15
3.5.2.1. Point-to-point..................................16 3.5.2.1. Point-to-Point..................................16
3.5.2.2. Point-to-Multipoint using Multicast or Translators16 3.5.2.2. Point-to-Multipoint Using Multicast or
3.5.2.3. Point-to-Multipoint using RTP Mixer.............17 Translators.....................................16
3.5.2.3. Point-to-Multipoint Using RTP Mixer.............17
3.5.2.4. Reliability.....................................17 3.5.2.4. Reliability.....................................17
3.5.3. H.271 Video Back Channel Message conforming to ITU-T Rec. 3.5.3. H.271 Video Back Channel Message.....................17
H.271.......................................................17
3.5.3.1. Reliability.....................................20 3.5.3.1. Reliability.....................................20
3.5.4. Temporary Maximum Media Bit-rate Request.............20 3.5.4. Temporary Maximum Media Stream Bit Rate Request and
3.5.4.1. MCU based Multi-point operation.................25 Notification................................................20
3.5.4.2. Point-to-Multipoint using Multicast or Translators27 3.5.4.1. Behavior for media receivers using TMMBR........22
3.5.4.3. Point-to-point operation........................27 3.5.4.2. Algorithm for establishing current limitations..24
3.5.4.4. Reliability.....................................28 3.5.4.3. Use of TMMBR in a Mixer Based Multipoint
4. RTCP Receiver Report Extensions................................29 Operation.......................................30
4.1. Design Principles of the Extension Mechanism..............29 3.5.4.4. Use of TMMBR in Point-to-Multipoint Using
4.2. Transport Layer Feedback Messages.........................30 Multicast or Translators........................32
4.2.1. Temporary Maximum Media Bit-rate Request (TMMBR).....30 3.5.4.5. Use of TMMBR in Point-to-point operation........32
4.2.1.1. Semantics.......................................31 3.5.4.6. Reliability.....................................32
4.2.1.2. Message Format..................................33 4. RTCP Receiver Report Extensions................................34
4.2.1.3. Timing Rules....................................34 4.1. Design Principles of the Extension Mechanism..............34
4.2.2. Temporary Maximum Media Bit-rate Notification (TMMBN) 35 4.2. Transport Layer Feedback Messages.........................35
4.2.2.1. Semantics.......................................35 4.2.1. Temporary Maximum Media Stream Bit Rate Request
4.2.2.2. Message Format..................................36 (TMMBR)..............................................36
4.2.2.3. Timing Rules....................................36 4.2.1.1. Message Format..................................36
4.3. Payload Specific Feedback Messages........................37 4.2.1.2. Semantics.......................................37
4.3.1. Full Intra Request (FIR) command.....................37 4.2.1.3. Timing Rules....................................40
4.3.1.1. Semantics.......................................37 4.2.1.4. Handling in Translator and Mixers...............40
4.3.1.2. Message Format..................................39 4.2.2. Temporary Maximum Media Stream Bit Rate Notification
4.3.1.3. Timing Rules....................................40 (TMMBN)..............................................41
4.3.1.4. Remarks.........................................40 4.2.2.1. Message Format..................................41
4.3.2. Temporal-Spatial Trade-off Request (TSTR)............41 4.2.2.2. Semantics.......................................41
4.3.2.1. Semantics.......................................41 4.2.2.3. Timing Rules....................................43
4.3.2.2. Message Format..................................41 4.2.2.4. Handling by Translators and Mixers..............43
4.3.2.3. Timing Rules....................................42 4.3. Payload Specific Feedback Messages........................43
4.3.2.4. Remarks.........................................42 4.3.1. Full Intra Request (FIR).............................44
4.3.3. Temporal-Spatial Trade-off Announcement (TSTA).......43 4.3.1.1. Message Format..................................44
4.3.3.1. Semantics.......................................43 4.3.1.2. Semantics.......................................45
4.3.3.2. Message Format..................................44 4.3.1.3. Timing Rules....................................47
4.3.3.3. Timing Rules....................................44 4.3.1.4. Handling of FIR Message in Mixer and
4.3.3.4. Remarks.........................................45 Translators.................................... 47
4.3.4. H.271 VideoBackChannelMessage (VBCM).................45 4.3.1.5. Remarks.........................................47
5. Congestion Control.............................................48 4.3.2. Temporal-Spatial Trade-off Request (TSTR)............47
6. Security Considerations........................................48 4.3.2.1. Message Format..................................47
7. SDP Definitions................................................49 4.3.2.2. Semantics.......................................48
7.1. Extension of rtcp-fb attribute............................49 4.3.2.3. Timing Rules....................................49
7.2. Offer-Answer..............................................51 4.3.2.4. Handling of message in Mixers and Translators...49
7.3. Examples..................................................51 4.3.2.5. Remarks.........................................49
8. IANA Considerations............................................54 4.3.3. Temporal-Spatial Trade-off Notification (TSTN).......50
9. Acknowledgements...............................................54 4.3.3.1. Message Format..................................50
10. References....................................................56 4.3.3.2. Semantics.......................................50
10.1. Normative references.....................................56 4.3.3.3. Timing Rules....................................51
10.2. Informative references...................................56 4.3.3.4. Handling of TSTN in Mixer and Translators.......51
11. Authors' Addresses............................................57 4.3.3.5. Remarks.........................................51
12. List of Changes relative to previous draftsError! Bookmark not defined. 4.3.4. H.271 Video Back Channel Message (VBCM)..............51
4.3.4.1. Message Format..................................52
4.3.4.2. Semantics.......................................52
4.3.4.3. Timing Rules....................................54
4.3.4.4. Handling of message in Mixer or Translator......54
4.3.4.5. Remarks.........................................54
5. Congestion Control.............................................54
6. Security Considerations........................................55
7. SDP Definitions................................................56
7.1. Extension of the rtcp-fb Attribute........................56
7.2. Offer-Answer..............................................58
7.3. Examples..................................................58
8. IANA Considerations............................................61
9. Acknowledgements...............................................62
10. References....................................................63
10.1. Normative references.....................................63
10.2. Informative references...................................63
11. Authors' Addresses............................................64
1. Introduction 1.1. Introduction
When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was
developed, the main emphasis lay in the efficient support of point- developed, the main emphasis lay in the efficient support of point-
to-point and small multipoint scenarios without centralized to-point and small multipoint scenarios without centralized
multipoint control. However, in practice, many small multipoint multipoint control. However, in practice, many small multipoint
conferences operate utilizing devices known as Multipoint Control conferences operate utilizing devices known as Multipoint Control
Units (MCUs). Long standing experience of the conversational video Units (MCUs). Long-standing experience of the conversational video
conferencing industry suggests that there is a need for a few conferencing industry suggests that there is a need for a few
additional feedback messages, to efficiently support centralized additional feedback messages, to support centralized multipoint
multipoint conferencing. Some of the messages have applications conferencing efficiently. Some of the messages have applications
beyond centralized multipoint, and this is indicated in the beyond centralized multipoint, and this is indicated in the
description of the message. This is especially true for the message description of the message. This is especially true for the message
intended to carry ITU-T Rec. H.271 [H.271] bitstrings for Video Back intended to carry ITU-T Rec. H.271 [H.271] bitstrings for Video Back
Channel messages. Channel messages.
In RTP [RFC3550] terminology, MCUs comprise mixers and translators. In Real-time Transport Protocol (RTP) [RFC3550] terminology, MCUs
Most MCUs also include signaling support. During the development of comprise mixers and translators. Most MCUs also include signaling
this memo, it was noticed that there is considerable confusion in the support. During the development of this memo, it was noticed that
community related to the use of terms such as mixer, translator, and there is considerable confusion in the community related to the use
MCU. In response to these concerns, a number of topologies have been of terms such as mixer, translator, and MCU. In response to these
identified that are of practical relevance to the industry, but not concerns, a number of topologies have been identified that are of
documented in sufficient detail in RTP. These topologies are practical relevance to the industry, but are not documented in
documented in [Topologies], and understanding this memo requires sufficient detail in [RFC3550]. These topologies are documented in
previous or parallel study of [Topologies]. [Topologies], and understanding this memo requires previous or
parallel study of [Topologies].
Some of the messages defined here are forward only, in that they do Some of the messages defined here are forward only, in that they do
not require an explicit notification to the message emitter not require an explicit notification to the message emitter that they
indicating their reception and/or the message receiver's actions. have been received and/or indicating the message receiver's actions.
Other messages require notification, leading to a two way Other messages require a response, leading to a two way communication
communication model that could suggest to some to be useful for model that one could view as useful for control purposes. However,
control purposes. It is not the intention of this memo to open up it is not the intention of this memo to open up RTP Control Protocol
RTCP to a generalized control protocol. All mentioned messages have (RTCP) to a generalized control protocol. All mentioned messages
relatively strict real-time constraints -- in the sense that their have relatively strict real-time constraints, in the sense that their
value diminishes with increased delay. This makes the use of more value diminishes with increased delay. This makes the use of more
traditional control protocol means, such as SIP re-invites [RFC3261], traditional control protocol means, such as Session Initiation
undesirable. Furthermore, all messages are of a very simple format Protocol (SIP) re-INVITEs [RFC3261], undesirable when used for the
same purpose. Furthermore, all messages are of a very simple format
that can be easily processed by an RTP/RTCP sender/receiver. that can be easily processed by an RTP/RTCP sender/receiver.
Finally, all messages infer only to the RTP stream they are related Finally, all messages relate only to the RTP stream with which they
to, and not to any other property of a communication system. are associated, and not to any other property of a communication
system. In particular, none of them relate to the properties of the
The Full Intra Request (FIR) requires the receiver of the message access links traversed by the session.
(and sender of the stream) to immediately insert a decoder refresh
point. In video coding, one commonly used form of a decoder refresh
point is an IDR or Intra picture, depending on the video compression
technology in use. Other codecs may have other forms of decoder
refresh points. In order to fulfill congestion control constraints,
sending a decoder refresh point may imply a significant drop in frame
rate, as they are commonly much larger than regular predicted
content. The use of this message is restricted to cases where no
other means of decoder refresh can be employed, e.g. during the join-
phase of a new participant in a multipoint conference. It is
explicitly disallowed to use the FIR command for error resilience
purposes, and instead it is referred to AVPF's [RFC4585] PLI message,
which reports lost pictures and has been included in AVPF for
precisely that purpose. The message does not require a reception
notification, as the presence of a decoder refresh point can be
easily derived from the media bit stream. Today, the FIR message
appears to be useful primarily with video streams, but in the future
it may also prove helpful in conjunction with other media codecs that
support prediction across RTP packets.
The Temporary Maximum Media Stream Bitrate Request (TMMBR) allows to
signal, from media receiver to media sender, the current maximum
media stream bit-rate for a given media stream. The maximum media
stream bit-rate is defined as a tuple. The first value is the bit-
rate available for the packet stream at the layer reported on. The
second value is the measured header sizes between the start of the
header for the layer reported on and the beginning of the RTP
payload. Once, the media sender has received the TMMBR request on
the bitrate limitation, it notifies the initiator of the request, and
all other session participants, by sending a Temporal Maximum Media
Stream Bitrate Notification (TMMBN). The TMMBN contains a list of
the current applicable restrictions to help the participants to
suppress TMMBR requests that wouldn't result in further restrictions
for the sender. One usage scenario can be seen as limiting media
senders in multiparty conferencing to the slowest receiver's Maximum
Media Stream bitrate reception/handling capability. Such a use is
helpful, for example, because the receiver's situation may have
changed due to computational load, or because the receiver has just
joined the conference, and considers it helpful to inform media
sender(s) about its constraints, without waiting for congestion
induced bitrate reduction. Another application involves graceful
bitrate adaptation in scenarios where the upper limit connection
bitrate to a receiver changes, but is known in the interval between
these dynamic changes. The TMMBR/TMMBN messages are useful for all
media types that are not inherently of constant bit rate. However,
TMMBR is not a congestion control mechanism and can't replace the
need to implement one.
The Video Back Channel Message (VBCM) allows conveying bit streams
conforming to ITU-T Rec. H.271 [H.271], from a video receiver to
video sender. This ITU-T Recommendation defines codepoints for a
number of video-specific feedback messages. Examples include
messages to signal:
- the corruption of reference pictures or parts thereof,
- the corruption of decoder state information, e.g. parameter sets,
- the suggestion of using a reference picture other than the one
typically used, e.g. to support the NEWPRED algorithm [NEWPRED].
The ITU-T has the authority to add codepoints to H.271 every time a
need arises, e.g. with the introduction of new video codecs or new
tools into existing video codecs.
There exists some overlap between VBCM messages and native messages
specified in this memo and in AVPF. Examples include the PLI message
of [RFC4585] and the FIR message specified herein. As a general
rule, the native messages should be preferred over the sending of
VBCM messages when all senders and receivers implement this memo.
However, if gateways are in the picture, it may be more advisable to
utilize VBCM. Similarly, for feedback message types that exist in
H.271 but do not exist in this memo or AVPF, there is no other choice
but using VBCM.
Video Back Channel Messages according to H.271 do not require a
notification on a protocol level, because the appropriate reaction of
the video encoder and sender can be derived from the forward video
bit stream.
Finally, the Temporal-Spatial Trade-off Request (TSTR) enables a
video receiver to signal to the video sender its preference for
spatial quality or high temporal resolution (frame rate). Typically,
the receiver of the video stream generates this signal based on input
from its user interface, in reaction to explicit requests of the
user. However, some implicit use forms are also known. For example,
the trade-offs commonly used for live video and document camera
content are different. Obviously, this indication is relevant only
with respect to video transmission. The message is acknowledged by a
notification message indicating the newly chosen tradeoff, so to
allow immediate user feedback.
2. Definitions 2. Definitions
2.1. Glossary 2.1. Glossary
AMID - Additive Increase Multiplicative Decrease AMID - Additive Increase Multiplicative Decrease
ASM - Asynchronous Multicast AVPF - The extended RTP profile for RTCP-based feedback
AVPF - The Extended RTP Profile for RTCP-based Feedback
FEC - Forward Error Correction FEC - Forward Error Correction
FCI - Feedback Control Information [RFC4585]
FIR - Full Intra Request FIR - Full Intra Request
MCU - Multipoint Control Unit MCU - Multipoint Control Unit
MPEG - Moving Picture Experts Group MPEG - Moving Picture Experts Group
PtM - Point to Multipoint TMMBN - Temporary Maximum Media Stream Bit Rate Notification
PtP - Point to Point TMMBR - Temporary Maximum Media Stream Bit Rate Request
TMMBN - Temporary Maximum Media Stream Bitrate Notification
TMMBR - Temporary Maximum Media Stream Bitrate Request
PLI - Picture Loss Indication PLI - Picture Loss Indication
PR - Packet rate
QP - Quantizer Parameter
RTT - Round trip time
SSRC - Synchronization Source
TSTN - Temporal Spatial Trade-off Notification TSTN - Temporal Spatial Trade-off Notification
TSTR - Temporal Spatial Trade-off Request TSTR - Temporal Spatial Trade-off Request
VBCM - Video Back Channel Message indication. VBCM - Video Back Channel Message indication.
2.2. Terminology 2.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Message: Message:
Codepoint defined by this specification, of one of the An RTCP feedback message [RFC4585] defined by this
following types: specification, of one of the following types:
Request: Request:
Message that requires Acknowledgement Message that requires acknowledgement
Command: Command:
Message that forces the receiver to an action Message that forces the receiver to an action
Indication: Indication:
Message that reports a situation Message that reports a situation
Notification: Notification:
See Indication.
Note that, with the exception of ''Notification'', this Message that provides a notification that an event has
terminology is in alignment with ITU-T Rec. H.245. occurred. Notifications are commonly generated in response
to a Request.
Note that, with the exception of "Notification", this
terminology is in alignment with ITU-T Rec. H.245 [H245].
Decoder Refresh Point: Decoder Refresh Point:
A bit string, packetised in one or more RTP packets, which A bit string, packetized in one or more RTP packets, which
completely resets the decoder to a known state. Typical completely resets the decoder to a known state.
examples of Decoder Refresh Points are H.261 Intra pictures
and H.264 IDR pictures. However, there are also much more
complex decoder refresh points, as discussed below.
Examples for "hard" decoder refresh points are Intra pictures Examples for "hard" decoder refresh points are Intra pictures
in H.261, H.263, MPEG 1, MPEG 2, and MPEG-4 part 2, and IDR in H.261, H.263, MPEG-1, MPEG-2, and MPEG-4 part 2, and
pictures in H.264. "Gradual" decoder refresh points may also Instantaneous Decoder Refresh (IDR) pictures in H.264.
be used; see for example [AVC]. While both "hard" and "Gradual" decoder refresh points may also be used; see for
"gradual" decoder refresh points are acceptable in the scope example [AVC]. While both "hard" and "gradual" decoder
of this specification, in most cases the user experience will refresh points are acceptable in the scope of this
benefit from using a "hard" decoder refresh point. specification, in most cases the user experience will benefit
from using a "hard" decoder refresh point.
A decoder refresh point also contains all header information A decoder refresh point also contains all header information
above the picture layer (or equivalent, depending on the above the picture layer (or equivalent, depending on the video
video compression standard) that is conveyed in-band. In compression standard) that is conveyed in-band. In H.264, for
H.264, for example, a decoder refresh point contains example, a decoder refresh point contains parameter set
parameter set NAL units that generate parameter sets Network Adaptation Layer (NAL) units that generate parameter
necessary for the decoding of the following slice/data sets necessary for the decoding of the following slice/data
partition NAL units (and that are not conveyed out of band). partition NAL units (and that are not conveyed out of band).
Decoding: Decoding:
The operation of reconstructing the media stream. The operation of reconstructing the media stream.
Rendering: Rendering:
The operation of presenting (parts of) the reconstructed The operation of presenting (parts of) the reconstructed media
media stream to the user. stream to the user.
Stream thinning: Stream thinning:
The operation of removing some of the packets from a media The operation of removing some of the packets from a media
stream. Stream thinning, preferably, is media-aware, stream. Stream thinning, preferably, is media-aware, implying
implying that media packets are removed in the order of their that media packets are removed in the order of increasing
relevance to the reproductive quality. However even when relevance to the reproductive quality. However even when
employing media-aware stream thinning, most media streams employing media-aware stream thinning, most media streams
quickly lose quality when subject to increasing levels of quickly lose quality when subject to increasing levels of
thinning. Media-unaware stream thinning leads to even worse thinning. Media-unaware stream thinning leads to even worse
quality degradation. In contrast to transcoding, stream quality degradation. In contrast to transcoding, stream
thinning is typically seen as a computationally lightweight thinning is typically seen as a computationally lightweight
operation operation.
Media: Often used (sometimes in conjunction with terms like Media:
bitrate, stream, sender, ...) to identify the content of the
forward RTP packet stream carrying the codec data to which
the codec control message applies to.
Media Stream: The stream of packets carrying the media (and in some Often used (sometimes in conjunction with terms like bit rate,
case also repair information such as retransmission or stream, sender ...) to identify the content of the forward RTP
Forward Error Correction (FEC) information). We further packet stream (carrying the codec data), to which the codec
include within this specification the RTP packetization and control message applies.
the usage of additional protocol headers on these packets to
carry them from sender to receiver. Media Stream:
The stream of RTP packets labeled with a single
Synchronization Source (SSRC) carrying the media (and also in
some cases repair information such as retransmission or
Forward Error Correction (FEC) information).
Total media bit rate:
The total bits per second transferred in a media stream,
measured at an observer-selected protocol layer and averaged
over a reasonable timescale, the length of which depends on
the application. In general, a media sender and a media
receiver will observe different total media bit rates for the
same stream, first because they may have selected different
reference protocol layers, and second, because of changes in
per-packet overhead along the transmission path. The goal
with bit rate averaging is to be able to ignore any burstiness
on very short timescales, below for example 100 ms, introduced
by scheduling or link layer packetization effects.
Maximum total media bit rate:
The upper limit on total media bit rate for a given media
stream at a particular receiver and for its selected protocol
layer. Note that this value cannot be measured on the received
media stream, instead it needs to be calculated or determined
through other means, such as QoS negotiations or local
resource limitations. Also note that this value is an average
(on a timescale that is reasonable for the application) and
that it may be different from the instantaneous bit-rate seen
by packets in the media stream.
Overhead:
All protocol header information required to convey a packet
with media data from sender to receiver, from the application
layer down to a pre-defined protocol level (for example down
to, and including, the IP header). Overhead may include, for
example, IP, UDP, and RTP headers, any layer 2 headers, any
Contributing Sources (CSRCs), RTP-Padding, and RTP header
extensions. Overhead excludes any RTP payload headers and the
payload itself.
Net media bit rate:
The bit rate carried by a media stream, net of overhead. That
is, the bits per second accounted for by encoded media, any
applicable payload headers, and any directly associated meta
payload information placed in the RTP packet. A typical
example of the latter is redundancy data provided by the use
of RFC 2198 [RFC2198]. Note that, unlike the total media bit
rate, the net media bit rate will have the same value at the
media sender and at the media receiver unless any mixing or
translating of the media has occurred.
For a given observer, the total media bit rate for a media
stream is equal to the sum of the net media bit rate and the
per-packet overhead as defined above multiplied by the packet
rate.
Feasible region:
The set of all combinations of packet rate and net media bit
rate that do not exceed the restrictions in maximum media bit
rate placed on a given media sender by the Temporary Maximum
Media Stream Bit-rate Request (TMMBR) messages it has
received. The feasible region will change as new TMMBR
messages are received.
Bounding set:
The set of TMMBR tuples, selected from all those received at a
given media sender, that define the feasible region for that
media sender. The media sender uses an algorithm such as that
in section 3.5.4.2 to determine or iteratively approximate the
current bounding set, and reports that set back to the media
receivers in a Temporary Maximum Media Stream Bit-rate
Notification (TMMBN) message.
2.3. Topologies 2.3. Topologies
Please refer to [Topologies] for an in depth discussion. the
topologies referred to throughout this memo are labeled (consistent Please refer to [Topologies] for an in depth discussion. The
with [Topologies] as follows: topologies referred to throughout this memo are labeled (consistently
with [Topologies]) as follows:
Topo-Point-to-Point . . . . . point-to-point communication Topo-Point-to-Point . . . . . point-to-point communication
Topo-Multicast . . . . . . . multicast communication as in RFC 3550 Topo-Multicast . . . . . . . multicast communication as in RFC 3550
Topo-Translator . . . . . . . translator based as in RFC 3550 Topo-Translator . . . . . . . translator based as in RFC 3550
Topo-Mixer . . . . . . . . . mixer based as in RFC 3550 Topo-Mixer . . . . . . . . . mixer based as in RFC 3550
Topo-Video-switch-MCU . . . . video switching MCU, Topo-Video-switch-MCU . . . . video switching MCU,
Topo-RTCP-terminating-MCU . . mixer but terminating RTCP Topo-RTCP-terminating-MCU . . mixer but terminating RTCP
3. Motivation (Informative) 3. Motivation (Informative)
This section discusses the motivation and usage of the different This section discusses the motivation and usage of the different
video and media control messages. The video control messages have video and media control messages. The video control messages have
been under discussion for a long time, and a requirement draft was been under discussion for a long time, and a requirement draft was
drawn up [Basso]. This draft has expired; however we do quote drawn up [Basso]. This draft has expired; however we quote relevant
relevant sections of it to provide motivation and requirements. sections of it to provide motivation and requirements.
3.1. Use Cases 3.1. Use Cases
There are a number of possible usages for the proposed feedback There are a number of possible usages for the proposed feedback
messages. Let's begin with looking through the use cases Basso et al. messages. Let us begin by looking through the use cases Basso et al.
[Basso] proposed. Some of the use cases have been reformulated and [Basso] proposed. Some of the use cases have been reformulated and
commented: comments have been added.
1. An RTP video mixer composes multiple encoded video sources into a 1. An RTP video mixer composes multiple encoded video sources into a
single encoded video stream. Each time a video source is added, single encoded video stream. Each time a video source is added,
the RTP mixer needs to request a decoder refresh point from the the RTP mixer needs to request a decoder refresh point from the
video source, so as to start an uncorrupted prediction chain on video source, so as to start an uncorrupted prediction chain on
the spatial area of the mixed picture occupied by the data from the spatial area of the mixed picture occupied by the data from
the new video source. the new video source.
2. An RTP video mixer that receives multiple encoded RTP video 2. An RTP video mixer receives multiple encoded RTP video streams
streams from conference participants, and dynamically selects one from conference participants, and dynamically selects one of the
of the streams to be included in its output RTP stream. At the streams to be included in its output RTP stream. At the time of a
time of a bit stream change (determined through means such as bit stream change (determined through means such as voice
voice activation or the user interface), the mixer requests a activation or the user interface), the mixer requests a decoder
decoder refresh point from the remote source, in order to avoid refresh point from the remote source, in order to avoid using
using unrelated content as reference data for inter picture unrelated content as reference data for inter picture prediction.
prediction. After requesting the decoder refresh point, the video After requesting the decoder refresh point, the video mixer stops
mixer stops the delivery of the current RTP stream and monitors the delivery of the current RTP stream and monitors the RTP stream
the RTP stream from the new source until it detects data belonging from the new source until it detects data belonging to the decoder
to the decoder refresh point. At that time, the RTP mixer starts refresh point. At that time, the RTP mixer starts forwarding the
forwarding the newly selected stream to the receiver(s). newly selected stream to the receiver(s).
3. An application needs to signal to the remote encoder a request of 3. An application needs to signal to the remote encoder that the
change of the desired trade-off in temporal/spatial resolution. desired trade-off between temporal and spatial resolution has
For example, one user may prefer a higher frame rate and a lower changed. For example, one user may prefer a higher frame rate and
spatial quality, and another user may prefer the opposite. This a lower spatial quality, and another user may prefer the opposite.
choice is also highly content dependent. Many current video This choice is also highly content dependent. Many current video
conferencing systems offer in the user interface a mechanism to conferencing systems offer in the user interface a mechanism to
make this selection, usually in the form of a slider. The make this selection, usually in the form of a slider. The
mechanism is helpful in point-to-point, centralized multipoint and mechanism is helpful in point-to-point, centralized multipoint and
non-centralized multipoint uses. non-centralized multipoint uses.
4. Use case 4 of the Basso draft applies only to AVPF's PLI [RFC4585] 4. Use case 4 of the Basso draft applies only to Picture Loss
and is not reproduced here. Indication (PLI) as defined in AVPF [RFC4585] and is not
reproduced here.
5. Use case 5 of the Basso draft relates to a mechanism known as 5. Use case 5 of the Basso draft relates to a mechanism known as
"freeze picture request". Sending freeze picture requests "freeze picture request". Sending freeze picture requests
over a non-reliable forward RTCP channel has been identified as over a non-reliable forward RTCP channel has been identified as
problematic. Therefore, no freeze picture request has been problematic. Therefore, no freeze picture request has been
included in this memo, and the use case discussion is not included in this memo, and the use case discussion is not
reproduced here. reproduced here.
6. A video mixer dynamically selects one of the received video 6. A video mixer dynamically selects one of the received video
streams to be sent out to participants and tries to provide the streams to be sent out to participants and tries to provide the
highest bit rate possible to all participants, while minimizing highest bit rate possible to all participants, while minimizing
stream transrating. One way of achieving this is to setup sessions stream trans-rating. One way of achieving this is to set up
with endpoints using the maximum bit rate accepted by that sessions with endpoints using the maximum bit rate accepted by
endpoint, and by the call admission method used by the mixer. By each endpoint, and accepted by the call admission method used by
means of commands that allow reducing the Maximum Media Stream the mixer. By means of commands that reduce the maximum media
bitrate beyond what has been negotiated during session setup, the stream bit rate below what has been negotiated during session set
mixer can then reduce the maximum bit rate sent by endpoints to up, the mixer can reduce the maximum bit rate sent by endpoints to
the lowest common denominator of all received streams. As the the lowest of all the accepted bit rates. As the lowest accepted
lowest common denominator changes due to endpoints joining, bit rate changes due to endpoints joining and leaving or due to
leaving, or network congestion, the mixer can adjust the limits to network congestion, the mixer can adjust the limits at which
which endpoints can send their streams to match the new limit. The endpoints can send their streams to match the new value. The
mixer then would request a new maximum bit rate, which is equal or mixer then requests a new maximum bit rate, which is equal to or
less than the maximum bit-rate negotiated at session setup, for a less than the maximum bit rate negotiated at session setup for a
specific media stream, and the remote endpoint can respond with specific media stream, and the remote endpoint can respond with
the actual bit-rate that it can support. the actual bit rate that it can support.
The picture Basso, et al draws up covers most applications we The picture Basso, et al draws up covers most applications we
foresee. However we would like to extend the list with two additional foresee. However we would like to extend the list with two
use cases: additional use cases:
7. The used congestion control algorithms (AMID and TFRC [RFC3448]) 7. Currently deployed congestion control algorithms (AMID and TFRC
probe for more available capacity as long as there is something to [RFC3448]) probe for additional available capacity as long as
send. With congestion control using packet-loss as the indication there is something to send. With congestion control algorithms
for congestion, this probing does generally result in reduced using packet loss as the indication for congestion, this probing
media quality (often to a point where the distortion is large does generally result in reduced media quality (often to a point
enough to make the media unusable), due to packet loss and where the distortion is large enough to make the media unusable),
increased delay. In a number of deployment scenarios, especially due to packet loss and increased delay.
cellular ones, the bottleneck link is often the last hop link.
That cellular link also commonly has some type of QoS negotiation In a number of deployment scenarios, especially cellular ones, the
enabling the cellular device to learn the maximal bit-rate bottleneck link is often the last hop link. That cellular link
available over this last hop. Thus, indicating the maximum also commonly has some type of QoS negotiation enabling the
available bit-rate to the transmitting part can be beneficial to cellular device to learn the maximal bit rate available over this
prevent it from even trying to exceed the known hard limit that last hop. A media receiver behind this link can, in most (if not
exists. For cellular or other mobile devices the available known all) cases, calculate at least an upper bound for the bit rate
bit-rate can also quickly change due to handover to another available for each media stream it presently receives. How this
is done is an implementation detail and not discussed herein.
Indicating the maximum available bit rate to the transmitting
party for the various media streams can be beneficial to prevent
that party from probing for bandwidth for this stream in excess of
a known hard limit. For cellular or other mobile devices, the
known available bit rate for each stream (deduced from the link
bit rate) can change quickly, due to handover to another
transmission technology, QoS renegotiation due to congestion, etc. transmission technology, QoS renegotiation due to congestion, etc.
To enable minimal disruption of service quick convergence is To enable minimal disruption of service, quick convergence is
necessary, and therefore media path signaling is desirable. necessary, and therefore media path signaling is desirable.
8. The use of reference picture selection (RPS) as an error 8. The use of reference picture selection (RPS) as an error
resilience tool has been introduced in 1997 as NEWPRED [NEWPRED], resilience tool has been introduced in 1997 as NEWPRED [NEWPRED],
and is now widely deployed. When RPS is in use, simplisticly put, and is now widely deployed. When RPS is in use, simplistically
the receiver can send a feedback message to the sender, indicating put, the receiver can send a feedback message to the sender,
a reference picture that should be used for future prediction. indicating a reference picture that should be used for future
([NEWPRED] mentions other forms of feedback as well.) AVPF prediction. ([NEWPRED] mentions other forms of feedback as well.)
contains a mechanism for conveying such a message, but did not AVPF contains a mechanism for conveying such a message, but did
specify for which codec and according to which syntax the message not specify for which codec and according to which syntax the
conforms to. Recently, the ITU-T finalized Rec. H.271 which message should conform. Recently, the ITU-T finalized Rec. H.271
(among other message types) also includes a feedback message. It which (among other message types) also includes a feedback
is expected that this feedback message will enjoy wide support and message. It is expected that this feedback message will fairly
fairly quickly. Therefore, a mechanism to convey feedback quickly enjoy wide support. Therefore, a mechanism to convey
messages according to H.271 appears to be desirable. feedback messages according to H.271 appears to be desirable.
3.2. Using the Media Path 3.2. Using the Media Path
There are multiple reasons why we use the media path for the codec There are multiple reasons why we use the media path for the codec
control messages. control messages.
First, systems employing MCUs are often separating the control and First, systems employing MCUs often separate the control and media
media processing parts. As these messages are intended or generated processing parts. As these messages are intended for or generated by
by the media part rather than the signaling part of the MCU, having the media part rather than the signaling part of the MCU, having them
them on the media path avoids interfaces and unnecessary control on the media path avoids transmission across interfaces and
traffic between signaling and processing. If the MCU is physically unnecessary control traffic between signaling and processing. If the
decomposite, the use of the media path avoids the need for media MCU is physically decomposed, the use of the media path avoids the
control protocol extensions (e.g. in MEGACO [RFC3525]). need for media control protocol extensions (e.g. in MEGACO
[RFC3525]).
Secondly, the signaling path quite commonly contains several Secondly, the signaling path quite commonly contains several
signaling entities, e.g. SIP-proxies and application servers. signaling entities, e.g. SIP proxies and application servers.
Avoiding going through signaling entities avoids delay for several Avoiding going through signaling entities avoids delay for several
reasons. Proxies have less stringent delay requirements than media reasons. Proxies have less stringent delay requirements than media
processing and due to their complex and more generic nature may processing and due to their complex and more generic nature may
result in significant processing delay. The topological locations of result in significant processing delay. The topological locations of
the signaling entities are also commonly not optimized for minimal the signaling entities are also commonly not optimized for minimal
delay, but rather towards other architectural goals. Thus the delay, but rather towards other architectural goals. Thus the
signaling path can be significantly longer in both geographical and signaling path can be significantly longer in both geographical and
delay sense. delay sense.
3.3. Using AVPF 3.3. Using AVPF
The AVPF feedback message framework [RFC4585] provides a simple way The AVPF feedback message framework [RFC4585] provides the
of implementing the new messages. Furthermore, AVPF implements rules appropriate framework to implement the new messages. AVPF implements
controlling the timing of feedback messages so to avoid congestion rules controlling the timing of feedback messages to avoid congestion
through network flooding by RTCP traffic. We re-use these rules by through network flooding by RTCP traffic. We re-use these rules by
referencing AVPF. referencing AVPF.
The signaling setup for AVPF allows each individual type of function The signaling setup for AVPF allows each individual type of function
to be configured or negotiated on a RTP session basis. to be configured or negotiated on an RTP session basis.
3.3.1. Reliability 3.3.1. Reliability
The use of RTCP messages implies that each message transfer is The use of RTCP messages implies that each message transfer is
unreliable, unless the lower layer transport provides reliability. unreliable, unless the lower layer transport provides reliability.
The different messages proposed in this specification have different The different messages proposed in this specification have different
requirements in terms of reliability. However, in all cases, the requirements in terms of reliability. However, in all cases, the
reaction to an (occasional) loss of a feedback message is specified. reaction to an (occasional) loss of a feedback message is specified.
3.4. Multicast 3.4. Multicast
skipping to change at page 14, line 7 skipping to change at page 14, line 5
messages and how they apply to the different use cases. messages and how they apply to the different use cases.
3.5.1. Full Intra Request Command 3.5.1. Full Intra Request Command
A Full Intra Request (FIR) Command, when received by the designated A Full Intra Request (FIR) Command, when received by the designated
media sender, requires that the media sender sends a Decoder Refresh media sender, requires that the media sender sends a Decoder Refresh
Point (see 2.2) at the earliest opportunity. The evaluation of such Point (see 2.2) at the earliest opportunity. The evaluation of such
opportunity includes the current encoder coding strategy and the opportunity includes the current encoder coding strategy and the
current available network resources. current available network resources.
FIR is also known as an ''instantaneous decoder refresh request'' FIR is also known as an "instantaneous decoder refresh request" or
or ''video fast update request''. "video fast update request".
Using a decoder refresh point implies refraining from using any Using a decoder refresh point implies refraining from using any
picture sent prior to that point as a reference for the encoding picture sent prior to that point as a reference for the encoding
process of any subsequent picture sent in the stream. For predictive process of any subsequent picture sent in the stream. For predictive
media types that are not video, the analogue applies. For example, media types that are not video, the analogue applies. For example,
if in MPEG-4 systems scene updates are used, the decoder refresh if in MPEG-4 systems scene updates are used, the decoder refresh
point consists of the full representation of the scene and is not point consists of the full representation of the scene and is not
delta-coded relative to previous updates. delta-coded relative to previous updates.
Decoder Refresh Points, especially Intra or IDR pictures, are in Decoder refresh points, especially Intra or IDR pictures, are in
general several times larger in size than predicted pictures. Thus, general several times larger in size than predicted pictures. Thus,
in scenarios in which the available bit-rate is small, the use of a in scenarios in which the available bit rate is small, the use of a
Decoder Refresh Point implies a delay that is significantly longer decoder refresh point implies a delay that is significantly longer
than the typical picture duration. than the typical picture duration.
Usage in multicast is possible; however aggregation of the commands Usage in multicast is possible; however aggregation of the commands
is recommended. A receiver that receives a request closely (within 2 is recommended. A receiver that receives a request closely (within 2
times the longest Round Trip Time (RTT) known) after sending a times the longest Round Trip Time (RTT) known, plus any AVPF-induced
Decoder Refresh Point should await a second request message to ensure RTCP packet sending delays, if those are known) after sending a
that the media receiver has not been served by the previously decoder refresh point, should await a second request message to
delivered Decoder Refresh Point. The reason for delaying 2 times the ensure that the media receiver has not been served by the previously
longest known RTT is to avoid sending unnecessary Decoder Refresh delivered decoder refresh point. The reason for the specified delay
Points. A session participant may have sent its own request while is to avoid sending unnecessary decoder refresh points. A session
another participant's request was in-flight to them. Suppressing participant may have sent its own request while another participant's
those requests that may have been sent without knowledge about the request was in-flight to them. Suppressing those requests that may
other request avoids this issue. have been sent without knowledge about the other request avoids this
issue.
Full Intra Request is applicable in use-case 1, 2, and 5. Using the FIR command to recover from errors is explicitly
disallowed, and instead the PLI message defined in AVPF [RFC4585]
should be used. The PLI message reports lost pictures and has been
included in AVPF for precisely that purpose.
Full Intra Request is applicable in use-cases 1 and 2.
3.5.1.1. Reliability 3.5.1.1. Reliability
The FIR message results in the delivery of a Decoder Refresh Point, The FIR message results in the delivery of a decoder refresh point,
unless the message is lost. Decoder Refresh Points are easily unless the message is lost. Decoder refresh points are easily
identifiable from the bit stream. Therefore, there is no need for identifiable from the bit stream. Therefore, there is no need for
protocol-level notification, and a simple command repetition protocol-level notification, and a simple command repetition
mechanism is sufficient for ensuring the level of reliability mechanism is sufficient for ensuring the level of reliability
required. However, the potential use of repetition does require a required. However, the potential use of repetition does require a
mechanism to prevent the recipient from responding to messages mechanism to prevent the recipient from responding to messages
already received and responded to. already received and responded to.
To ensure the best possible reliability, a sender of FIR may repeat To ensure the best possible reliability, a sender of FIR may repeat
the FIR request until a response has been received. The repetition the FIR request until the desired content has been received. The
interval is determined by the RTCP timing rules applicable to the repetition interval is determined by the RTCP timing rules applicable
session. Upon reception of a complete Decoder Refresh Point or the to the session. Upon reception of a complete decoder refresh point
detection of an attempt to send a Decoder Refresh Point (which got or the detection of an attempt to send a decoder refresh point (which
damaged due to a packet loss), the repetition of the FIR must stop. got damaged due to a packet loss), the repetition of the FIR must
If another FIR is necessary, the request sequence number must be stop. If another FIR is necessary, the request sequence number must
increased. To combat loss of the Decoder Refresh Points sent, the be increased. A FIR sender shall not have more than one FIR request
sender that receives repetitions of the FIR 2*RTT after the (different request sequence number) outstanding at any time per media
transmission of the Decoder Refresh Point shall send a new Decoder sender in the session.
Refresh Point. Two round trip times allow time for the request to
arrive at the media sender and the Decoder Refresh Point to arrive
back to the requestor. A FIR sender shall not have more than one FIR
request (different request sequence number) outstanding at any time
per media sender in the session.
An RTP Mixer that receives an FIR from a media receiver is The receiver of FIR (i.e. the media sender) behaves in complementary
responsible to ensure that a Decoder Refresh Point is delivered to fashion to ensure delivery of a decoder refresh point. If it
receives repetitions of the FIR more than 2*RTT after it has sent a
decoder refresh point, it shall send a new decoder refresh point.
Two round trip times allow time for the decoder refresh point to
arrive back to the requestor and for the end of repetitions of FIR to
reach and be detected by the media sender.
An RTP mixer that receives an FIR from a media receiver is
responsible to ensure that a decoder refresh point is delivered to
the requesting receiver. It may be necessary for the mixer to the requesting receiver. It may be necessary for the mixer to
generate FIR commands. The two legs (FIR-requesting endpoint to generate FIR commands. From a reliability perspective, the two legs
mixer, and mixer to Decoder Refresh Point generating endpoint) are (FIR-requesting endpoint to mixer, and mixer to decoder refresh point
handled independently from each other from a reliability perspective. generating endpoint) are handled independently from each other.
3.5.2. Temporal Spatial Trade-off Request and Notification 3.5.2. Temporal Spatial Trade-off Request and Notification
The Temporal Spatial Trade-off Request (TSTR) instructs the video The Temporal Spatial Trade-off Request (TSTR) instructs the video
encoder to change its trade-off between temporal and spatial encoder to change its trade-off between temporal and spatial
resolution. Index values from 0 to 31 indicate monotonically a resolution. Index values from 0 to 31 indicate monotonically a
desire for higher frame rate. That is, a requester asking for an desire for higher frame rate. That is, a requester asking for an
index of 0 prefers a high quality and is willing to accept a low index of 0 prefers a high quality and is willing to accept a low
frame rate, whereas a requester asking for 31 wishes a high frame frame rate, whereas a requester asking for 31 wishes a high frame
rate, potentially at the cost of low spatial quality. rate, potentially at the cost of low spatial quality.
In general the encoder reaction time may be significantly longer than In general the encoder reaction time may be significantly longer than
the typical picture duration. See use case 3 for an example. The the typical picture duration. See use case 3 for an example. The
encoder decides if the request results in a change of the trade off. encoder decides whether and to what extent the request results in a
The Temporal Spatial Trade-Off Notification message (TSTN) has been change of the trade-off. It returns a Temporal Spatial Trade-Off
defined to provide feedback of the trade-off that is used henceforth. Notification (TSTN) message to indicate the trade-off that it will
use henceforth.
Informative note: TSTR and TSTN have been introduced primarily TSTR and TSTN have been introduced primarily because it is believed
because it is believed that control protocol mechanisms, e.g. a SIP that control protocol mechanisms, e.g. a SIP re-invite, are too
re-invite, are too heavyweight, and too slow to allow for a heavyweight and too slow to allow for a reasonable user experience.
reasonable user experience. Consider, for example, a user
interface where the remote user selects the temporal/spatial trade- Consider, for example, a user interface where the remote user selects
off with a slider (as it is common in state-of-the-art video the temporal/spatial trade-off with a slider (as it is common in
conferencing systems). An immediate feedback to any slider state-of-the-art video conferencing systems). An immediate feedback
movement is required for a reasonable user experience. A SIP re- to any slider movement is required for a reasonable user experience.
invite [RFC3261] would require at least 2 round-trips more A SIP re-INVITE [RFC3261] would require at least two round-trips more
(compared to the TSTR/TSTN mechanism) and may involve proxies and (compared to the TSTR/TSTN mechanism) and may involve proxies and
other complex mechanisms. Even in a well-designed system, it may other complex mechanisms. Even in a well-designed system, it could
take a second or so until finally the new trade-off is selected. take a second or so until finally the new trade-off is selected.
Furthermore the use of RTCP solves very efficiently the multicast Furthermore the use of RTCP solves the multicast use case very
use case. efficiently.
The use of TSTR and TSTN in multipoint scenarios is a non-trivial The use of TSTR and TSTN in multipoint scenarios is a non-trivial
subject, and can be solved in many implementation-specific ways. subject, and can be achieved in many implementation-specific ways.
Problems are stemming from the fact that TSTRs will typically arrive Problems stem from the fact that TSTRs will typically arrive
unsynchronized, and may request different trade-off values for the unsynchronized, and may request different trade-off values for the
same stream and/or endpoint encoder. This memo does not specify a same stream and/or endpoint encoder. This memo does not specify a
translator, mixer or endpoint's reaction to the reception of a translator, mixer or endpoint's reaction to the reception of a
suggested trade-off as conveyed in the TSTR -- we only require the suggested trade-off as conveyed in the TSTR. We only require the
receiver of a TSTR message to reply to it by sending a TSTN, carrying receiver of a TSTR message to reply to it by sending a TSTN, carrying
the new trade-off chosen by its own criteria (which may or may not be the new trade-off chosen by its own criteria (which may or may not be
based on the trade-off conveyed by TSTR). In other words, the trade- based on the trade-off conveyed by the TSTR). In other words, the
off sent in TSTR is a non-binding recommendation; nothing more. trade-off sent in TSTR is a non-binding recommendation, nothing more.
With respect to TSTR/TSTN, four scenarios based on the topologies Four TSTR/TSTN scenarios need to be distinguished, based on the
described in [Topologies] need to be distinguished. The scenarios are topologies described in [Topologies]. The scenarios are described in
described in the following sub-clauses. the following sub-clauses.
3.5.2.1. Point-to-point 3.5.2.1. Point-to-Point
In this most trivial case (Topo-Point-to-Point), the media sender In this most trivial case (Topo-Point-to-Point), the media sender
typically adjusts its temporal/spatial trade-off based on the typically adjusts its temporal/spatial trade-off based on the
requested value in TSTR, and within its capabilities. The TSTN requested value in TSTR, subject to its own capabilities. The TSTN
message conveys back the new trade-off value (which may be identical message conveys back the new trade-off value (which may be identical
to the old one if, for example, the sender is not capable of to the old one if, for example, the sender is not capable of
adjusting its trade-off). adjusting its trade-off).
3.5.2.2. Point-to-Multipoint using Multicast or Translators 3.5.2.2. Point-to-Multipoint Using Multicast or Translators
RTCP Multicast is used either with media multicast according to Topo- RTCP Multicast is used either with media multicast according to Topo-
Multicast, or following RFC 3550's translator model according to Multicast, or following RFC 3550's translator model according to
Topo-Translator. In these cases, TSTR messages from different Topo-Translator. In these cases, unsynchronized TSTR messages from
receivers may be received unsynchronized, and possibly with different different receivers may be received, possibly with different
requested trade-offs (because of different user preferences). This requested trade-offs (because of different user preferences). This
memo does not specify how the media sender tunes its trade-off. memo does not specify how the media sender tunes its trade-off.
Possible strategies include selecting the mean, or median, of all Possible strategies include selecting the mean or median of all
trade-off requests received, prioritize certain participants, or trade-off requests received, giving priority to certain participants,
continue using the previously selected trade-off (e.g. when the or continuing to use the previously selected trade-off (e.g. when the
sender is not capable of adjusting it). Again, all TSTR messages sender is not capable of adjusting it). Again, all TSTR messages
need to be acknowledged by TSTN, and the value conveyed back has to need to be acknowledged by TSTN, and the value conveyed back has to
reflect the decision made. reflect the decision made.
3.5.2.3. Point-to-Multipoint using RTP Mixer 3.5.2.3. Point-to-Multipoint Using RTP Mixer
In this scenario (Topo-Mixer) the RTP Mixer receives all TSTR In this scenario (Topo-Mixer) the RTP mixer receives all TSTR
messages, and has the opportunity to act on them based on its own messages, and has the opportunity to act on them based on its own
criteria. In most cases, the Mixer should form a ''consensus'' of criteria. In most cases, the mixer should form a "consensus" of
potentially conflicting TSTR messages arriving from different potentially conflicting TSTR messages arriving from different
participants, and initiate its own TSTR message(s) to the media participants, and initiate its own TSTR message(s) to the media
sender(s). The strategy of forming this ''consensus'' is open for sender(s). As in the previous scenario, the strategy for forming
the implementation, and can, for example, encompass averaging the this "consensus" is up to the implementation, and can, for example,
participants request values, prioritizing certain participants, or encompass averaging the participants' request values, giving priority
use session default values. If the Mixer changes its trade-off, it to certain participants, or using session default values.
needs to request from the media sender(s) the use of the new value,
by creating a TSTR of its own. Upon reaching a decision on the used
trade-off it includes that value in the acknowledgement.
Even if a Mixer or Translator performs transcoding, it is very Even if a mixer or translator performs transcoding, it is very
difficult to deliver media with the requested trade-off, unless the difficult to deliver media with the requested trade-off, unless the
content the Mixer or Translator receives is already close to that content the mixer or translator receives is already close to that
trade-off. Only in cases where the original source has substantially trade-off. Thus if the mixer changes its trade-off, it needs to
higher quality (and bit-rate), it is likely that transcoding can request the media sender(s) to use the new value, by creating a TSTR
result in the requested trade-off. of its own. Upon reaching a decision on the used trade-off it
includes that value in the acknowledgement to the downstream
requestors. Only in cases where the original source has
substantially higher quality (and bit rate), is it likely that
transcoding alone can result in the requested trade-off.
3.5.2.4. Reliability 3.5.2.4. Reliability
A request and reception acknowledgement mechanism is specified. The A request and reception acknowledgement mechanism is specified. The
Temporal Spatial Trade-off Notification (TSTN) message informs the Temporal Spatial Trade-off Notification (TSTN) message informs the
request-sender that its request has been received, and what trade-off request-sender that its request has been received, and what trade-off
is used henceforth. This acknowledgment mechanism is desirable for at is used henceforth. This acknowledgment mechanism is desirable for
least the following reasons: at least the following reasons:
o A change in the trade-off cannot be directly identified from the o A change in the trade-off cannot be directly identified from the
media bit stream, media bit stream.
o User feedback cannot be implemented without information of the o User feedback cannot be implemented without knowing the chosen
chosen trade-off value, according to the media sender's trade-off value, according to the media sender's constraints.
constraints,
o Repetitive sending of messages requesting an unimplementable trade- o Repetitive sending of messages requesting an unimplementable trade-
off can be avoided. off can be avoided.
3.5.3. H.271 Video Back Channel Message 3.5.3. H.271 Video Back Channel Message
ITU-T Rec. H.271 defines syntax, semantics, and suggested encoder ITU-T Rec. H.271 defines syntax, semantics, and suggested encoder
reaction to a video back channel message. The codepoint defined in reaction to a video back channel message. The structure defined in
this memo is used to transparently convey such a message from media this memo is used to transparently convey such a message from media
receiver to media sender. In this memo, we refrain from an in-depth receiver to media sender. In this memo, we refrain from an in-depth
discussion of the available codepoints within H.271 and refer to the discussion of the available codepoints within H.271 and refer to the
specification text instead [H.271]. specification text [H.271] instead.
However, we note that some H.271 messages bear similarities with However, we note that some H.271 messages bear similarities with
native messages of AVPF and this memo. Furthermore, we note that native messages of AVPF and this memo. Furthermore, we note that
some H.271 message are known to require caution in multicast some H.271 message are known to require caution in multicast
environments -- or are plainly not usable in multicast or multipoint environments -- or are plainly not usable in multicast or multipoint
scenarios. Table 1 provides a brief, oversimplifying overview of the scenarios. Table 1 provides a brief, oversimplifying overview of the
messages currently defined in H.271, their similar AVPF or CCM messages currently defined in H.271, their roughly corresponding AVPF
messages (the latter as specified in this memo), and an indication of or CCM messages (the latter as specified in this memo), and an
our current knowledge of their multicast safety. indication of our current knowledge of their multicast safety.
H.271 msg type AVPF/CCM msg type multicast-safe H.271 msg type AVPF/CCM msg type multicast-safe
--------------------------------------------------------------------- ---------------------------------------------------------------------
0 (when used for 0 (when used for
reference picture reference picture
selection) AVPF RPSI No (positive ACK of pictures) selection) AVPF RPSI No (positive ACK of pictures)
1 AVPF PLI Yes 1 picture loss AVPF PLI Yes
2 AVPF SLI Yes 2 partial loss AVPF SLI Yes
3 N/A Yes (no required sender action) 3 one parameter CRC N/A Yes (no required sender action)
4 N/A Yes (no required sender action) 4 all parameter CRC N/A Yes (no required sender action)
5 refresh point CCM FIR Yes
Table 1: H.271 messages and their AVPF/CCM equivalents Table 1: H.271 messages and their AVPF/CCM equivalents
Note: H.271 message type 0 is not a strict equivalent to Note: H.271 message type 0 is not a strict equivalent to
AVPF's RPSI; it is an indication of known-as-correct reference AVPF's Reference Picture Selection Indication (RPSI); it is an
picture(s) at the decoder. It does not command an encoder to indication of known-as-correct reference picture(s) at the
use a defined reference picture (the form of control decoder. It does not command an encoder to use a defined
information envisioned to be carried in RPSI). However, it is reference picture (the form of control information envisioned
believed and intended that H.271 message type 0 will be used to be carried in RPSI). However, it is believed and intended
for the same purpose as AVPF's RPSI -- although other use that H.271 message type 0 will be used for the same purpose as
forms are also possible. AVPF's RPSI -- although other use forms are also possible.
In response to the opaqueness of the H.271 messages especially with In response to the opaqueness of the H.271 messages especially with
respect to the multicast safety, the following guidelines MUST be respect to the multicast safety, the following guidelines MUST be
followed when an implementation wishes to employ the H.271 video back followed when an implementation wishes to employ the H.271 video back
channel message: channel message:
1. Implementations utilizing the H.271 feedback message MUST stay in 1. Implementations utilizing the H.271 feedback message MUST stay in
compliance with congestion control principles, as outlined in compliance with congestion control principles, as outlined in
section 5 .. section 5.
2. An implementation SHOULD utilize the native messages as defined in
[RFC4585] and in this memo instead of similar messages defined in 2. An implementation SHOULD utilize the IETF-native messages as
[H.271]. Our current understanding of similar messages is defined in [RFC4585] and in this memo instead of similar messages
documented in Table 1 above. One good reason to divert from the defined in [H.271]. Our current understanding of similar messages
SHOULD statement above would be if it is clearly understood that, is documented in Table 1 above. One good reason to divert from
for a given application and video compression standard, the the SHOULD statement above would be if it is clearly understood
aforementioned ''similarity'' is not given, in contrast to what that, for a given application and video compression standard, the
aforementioned "similarity" is not given, in contrast to what
the table indicates. the table indicates.
3. It has been observed that some of the H.271 codepoints currently 3. It has been observed that some of the H.271 codepoints currently
in existence are not multicast-safe. Therefore, the sensible in existence are not multicast-safe. Therefore, the sensible
thing to do is not to use the H.271 feedback message type in thing to do is not to use the H.271 feedback message type in
multicast environments. It MAY be used only when all the issues multicast environments. It MAY be used only when all the issues
mentioned later are fully understood by the implementer, and mentioned later are fully understood by the implementer, and
properly taken into account by all endpoints. In all other cases, properly taken into account by all endpoints. In all other cases,
the H.271 message type MUST NOT be used in conjunction with the H.271 message type MUST NOT be used in conjunction with
multicast. multicast.
skipping to change at page 19, line 13 skipping to change at page 19, line 22
the table indicates. the table indicates.
3. It has been observed that some of the H.271 codepoints currently 3. It has been observed that some of the H.271 codepoints currently
in existence are not multicast-safe. Therefore, the sensible in existence are not multicast-safe. Therefore, the sensible
thing to do is not to use the H.271 feedback message type in thing to do is not to use the H.271 feedback message type in
multicast environments. It MAY be used only when all the issues multicast environments. It MAY be used only when all the issues
mentioned later are fully understood by the implementer, and mentioned later are fully understood by the implementer, and
properly taken into account by all endpoints. In all other cases, properly taken into account by all endpoints. In all other cases,
the H.271 message type MUST NOT be used in conjunction with the H.271 message type MUST NOT be used in conjunction with
multicast. multicast.
4. It has been observed that even in centralized multipoint 4. It has been observed that even in centralized multipoint
environments, where the mixer should theoretically be able to environments, where the mixer should theoretically be able to
resolve issues as documented below, the implementation of such a resolve issues as documented below, the implementation of such a
mixer and cooperative endpoints is a very difficult and tedious mixer and cooperative endpoints is a very difficult and tedious
task. Therefore, H.271 message MUST NOT be used in centralized task. Therefore, H.271 messages MUST NOT be used in centralized
multipoint scenarios, unless all the issues mentioned below are multipoint scenarios, unless all the issues mentioned below are
fully understood by the implementer, and properly taken into fully understood by the implementer, and properly taken into
account by both mixer and endpoints. account by both mixer and endpoints.
Issues to be taken into account when considering the use of H.271 in Issues to be taken into account when considering the use of H.271 in
multipoint environments: multipoint environments:
1. Different state on different receivers. In many environments it 1. Different state on different receivers. In many environments it
cannot be guarantied that the decoder state of all media receivers cannot be guaranteed that the decoder state of all media receivers
is identical at any given point in time. The most obvious reason is identical at any given point in time. The most obvious reason
for such a possible misalignment of state is a loss that occurs on for such a possible misalignment of state is a loss that occurs on
the link to only one of many media receivers. However, there are the path to only one of many media receivers. However, there are
other not so obvious reasons, such as recent joins to the other not so obvious reasons, such as recent joins to the
multipoint conference (be it by joining the multicast group or multipoint conference (be it by joining the multicast group or
through additional mixer output). Different states can lead the through additional mixer output). Different states can lead the
media receivers to issue potentially contradicting H.271 messages media receivers to issue potentially contradicting H.271 messages
(or one media receiver issuing an H.271 message that, when (or one media receiver issuing an H.271 message that, when
observed by the media sender, is not helpful for the other media observed by the media sender, is not helpful for the other media
receivers). A naive reaction of the media sender to these receivers). A naive reaction of the media sender to these
contradicting messages can lead to unpredictable and annoying contradicting messages can lead to unpredictable and annoying
results. results.
2. Combining messages from different media receivers in a media 2. Combining messages from different media receivers in a media
sender is a non-trivial task. As reasons, we note that these sender is a non-trivial task. As reasons, we note that these
messages may be contradicting each other, and that their transport messages may be contradicting each other, and that their transport
is unreliable (there may well be other reasons). In case of many is unreliable (there may well be other reasons). In case of many
H.271 messages (i.e. types 0, 2, 3, and 4), the algorithm for H.271 messages (i.e. types 0, 2, 3, and 4), the algorithm for
combining must be both aware of the network/protocol environment combining must be aware both of the network/protocol environment
(i.e. with respect to congestion) and of the media codec employed, (i.e. with respect to congestion) and of the media codec employed,
as H.271 messages of a given type can have different semantics for as H.271 messages of a given type can have different semantics for
different media codecs. different media codecs.
3. The suppression of requests may need to go beyond the basic 3. The suppression of requests may need to go beyond the basic
mechanism described in AVPF (which are driven exclusively by mechanisms described in AVPF (which are driven exclusively by
timing and transport considerations on the protocol level). For timing and transport considerations on the protocol level). For
example, a receiver is often required to refrain from (or delay) example, a receiver is often required to refrain from (or delay)
generating requests, based on information it receives from the generating requests, based on information it receives from the
media stream. For instance, it makes no sense for a receiver to media stream. For instance, it makes no sense for a receiver to
issue a FIR when a transmission of an Intra/IDR picture is issue a FIR when a transmission of an Intra/IDR picture is
ongoing. ongoing.
4. When using the non-multicast-safe messages (e.g. H.271 type 0 4. When using the non-multicast-safe messages (e.g. H.271 type 0
positive ACK of received pictures/slices) in larger multicast positive ACK of received pictures/slices) in larger multicast
groups, the media receiver will likely be forced to delay or even groups, the media receiver will likely be forced to delay or even
omit sending these messages. For the media sender this looks like omit sending these messages. For the media sender this looks like
data has not been properly received (although it was received data has not been properly received (although it was received
properly), and a naively implemented media sender reacts to these properly), and a naively implemented media sender reacts to these
perceived problems where it shouldn't. perceived problems where it should not.
3.5.3.1. Reliability 3.5.3.1. Reliability
H.271 Video Back Channel messages do not require reliable H.271 Video Back Channel messages do not require reliable
transmission, and the reception of a message can be derived from the transmission, and confirmation of the reception of a message can be
forward video bit stream. Therefore, no specific reception derived from the forward video bit stream. Therefore, no specific
acknowledgement is specified. reception acknowledgement is specified.
With respect to re-sending rules, clause 3.5.1.1. applies. With respect to re-sending rules, clause 3.5.1.1. applies.
3.5.4. Temporary Maximum Media Stream Bit-rate Request and Notification 3.5.4. Temporary Maximum Media Stream Bit Rate Request and Notification
A receiver, translator or mixer uses the Temporary Maximum Media A receiver, translator or mixer uses the Temporary Maximum Media
Stream Bit-rate Request (TMMBR, "timber") to request a sender to Stream Bit Rate Request (TMMBR, "timber") to request a sender to
limit the maximum bit-rate for a media stream to, or below, the limit the maximum bit rate for a media stream (see 2.2) to, or below,
provided value. The Temporary Maximum Media Stream Bit-rate the provided value. The Temporary Maximum Media Stream Bit Rate
Notification (TMMBN) advises the media receiver(s) of the changed Notification (TMMBN) contains the media sender's current view of the
bitrate it is not going to exceed henceforth. The primary usage for most limiting subset of the TMMBR-defined limits it has received, to
this is a scenario with a MCU or Mixer (use case 6), corresponding to help the participants to suppress TMMBR requests that would not
Topo-Translator or Topo-Mixer, but also Topo-Point-to-Point. further restrict the media sender. The primary usage for the
TMMBR/TMMBN messages is in a scenario with an MCU or mixer (use case
6), corresponding to Topo-Translator or Topo-Mixer, but also to Topo-
Point-to-Point.
The temporary limitation on the media stream is expressed as a tuple; Each temporary limitation on the media stream is expressed as a
one value limiting the bit-rate at the layer for which the overhead tuple. The first component of the tuple is the maximum total media
is calculated to. A second value provides the per packet header bit rate (as defined in section 2.2) that the media receiver is
overhead between the layer for which bit-rate is reported and the currently prepared to accept for this media stream. The second
start of the RTP payload. By having both values the media stream component is the per-packet overhead that the media receiver has
sender can determine the effect of changing the packet rate for the observed for this media stream at its chosen reference protocol
media stream in an environment which contains translators or mixers layer.
that affect the amount of per packet overhead. For example a gateway
that convert between IPv4 and IPv6 would affect the per packet
overhead commonly with 20 bytes. There exist also other mechanisms,
like tunnels, that change the amount of headers that are present at a
particular bottleneck for which the TMMBR sending entity has
knowledge about. The problem with varying overhead is also discussed
in [RFC3890].
The above way of measuring allows for one to provide bit-rate and As indicated in section 2.2, the overhead as observed by the sender
overhead values for different protocol layers, for example on IP of the TMMBR (i.e. the media receiver) may differ from the overhead
level, out part of a tunnel protocol, or the link layer. The level a observed at the receiver of the TMMBR (i.e. the media sender) due to
peer report on, is fully dependent on the level of integration the use of a different reference protocol layer at the other end or due
peer has, as it needs to be able to extract the information from that to the intervention of translators or mixers that affect the amount
level. It is expected that peers will be able to report values at of per packet overhead. For example, a gateway in between the two
least for the IP layer, but in certain implementations link layer may that converts between IPv4 and IPv6 affects the per-packet overhead
be available to allow for more precise information. by 20 bytes. Other mechanisms that change the overhead include
tunnels. The problem with varying overhead is also discussed in
[RFC3890]. As will be seen in the description of the algorithm for
use of TMMBR, the difference in perceived overhead between the
sending and receiving ends presents no difficulty because
calculations are carried out in terms of variables (packet rate, net
media bit rate) that have the same value at the sender as at the
receiver.
The temporary maximum media stream bit-rate messages are generic Reporting both maximum total media bit rate and per-packet overhead
allows different receivers to provide bit rate and overhead values
for different protocol layers, for example at the IP level, at the
outer part of a tunnel protocol, or at the link layer. The protocol
level a peer reports on depends on the level of integration the peer
has, as it needs to be able to extract the information from that
protocol level. For example, an application with no knowledge of the
IP version it is running over can not meaningfully determine the
overhead of the IP header, and hence will not want to include IP
overhead in the overhead or maximum total media bit rate calculation.
It is expected that most peers will be able to report values at least
for the IP layer. In certain implementations it may be advantageous
to also include information pertaining to the link layer, which in
turn allows for a more precise overhead calculation and a better
optimization of connectivity resources.
The Temporary Maximum Media Stream Bit Rate messages are generic
messages that can be applied to any RTP packet stream. This messages that can be applied to any RTP packet stream. This
separates it a bit from the other codec control messages defined in separates them from the other codec control messages defined in this
this specification that applies only to specific media types or specification, which apply only to specific media types or payload
payload formats. The TMMBR functionality applies to the transport and formats. The TMMBR functionality applies to the transport, and the
the requirements it places on the media encoding. requirements the transport places on the media encoding.
The reasoning below assumes that the participants have negotiated a The reasoning below assumes that the participants have negotiated a
session maximum bit-rate, using a signaling protocol. This value can session maximum bit rate, using a signaling protocol. This value can
be global, for example in case of point-to-point, multicast, or be global, for example in case of point-to-point, multicast, or
translators. It may also be local between the participant and the translators. It may also be local between the participant and the
peer or mixer. In both cases, the bit-rate negotiated in signaling is peer or mixer. In either case, the bit rate negotiated in signaling
the one that the participant guarantees to be able to handle (encode is the one that the participant guarantees to be able to handle
and decode). In practice, the connectivity of the participant also (depacketize and decode). In practice, the connectivity of the
bears an influence to the negotiated value -- it does not necessarily participant also influences the negotiated value -- it does not make
make much sense to negotiate a media bit rate that one's network much sense to negotiate a total media bit rate that one's network
interface does not support. interface does not support.
It is also beneficial to have negotiated a maximum packet rate for It is also beneficial to have negotiated a maximum packet rate for
the session or sender. RFC 3890 provides such a SDP [RFC4566] the session or sender. RFC 3890 provides an SDP [RFC4566] attribute
attribute, however that is not usable in RTP sessions established that can be used for this purpose; however, that attribute is not
using offer/answer [RFC3264]. Therefore a max packet rate signaling usable in RTP sessions established using offer/answer [RFC3264].
parameter is specified. Therefore an optional maximum packet rate signaling parameter is
specified in this memo.
An already established temporary limit may be changed at any time An already established maximum total media bit rate may be changed at
(subject to the timing rules of the feedback message sending), and to any time, subject to the timing rules governing the sending of
any values between zero and the session maximum, as negotiated during feedback messages. The limit may change to any value between zero and
session establishment signaling. Even if a sender has received a the session maximum, as negotiated during session establishment
TMMBR message allowing an increase in the bit-rate, all increases signaling. However, even if a sender has received a TMMBR message
must be governed by a congestion control mechanism. TMMBR only allowing an increase in the bit rate, all increases must be governed
indicates known limitations, usually in the local environment, and by a congestion control mechanism. TMMBR indicates known limitations
does not provide any guarantees about the full path. only, usually in the local environment, and does not provide any
guarantees about the full path. Furthermore, any increases in TMMBR-
established bit rate limits are to be executed only after a certain
delay from the sending of the TMMBN message that notifies the world
about the increase in limit. The delay is specified as at least
twice the longest RTT as known by the media sender, plus the media
sender's calculation of the required wait time for the sending of
another TMMBR message for this session based on AVPF timing rules.
This delay is introduced to allow other session participants to make
known their bit rate limit requirements, which may be lower.
If it is likely that the new value indicated by TMMBR will be valid If it is likely that the new value indicated by TMMBR will be valid
for the remainder of the session, the TMMBR sender can perform a for the remainder of the session, the TMMBR sender is expected to
renegotiation of the session upper limit using the session signaling perform a renegotiation of the session upper limit using the session
protocol. signaling protocol.
3.5.4.1. Behavior for media receivers using TMMBR 3.5.4.1. Behavior for media receivers using TMMBR
In multipart scenarios, different receivers likely have different This section is an informal description of behaviour described more
limits for receiving bitrate. Therefore, an algorithm to identify precisely in section 4.2.
the most restrictive TMMBR requests is specified in section 4 ..2.2.1.
The general behavior is explaind in this section and the gist of the
algorithm to determine the most restrictive values are explained
informally in the next section.
Immediately after session setup, the bitrate limit is set to the A media sender begins the session limited by the maximum media bit
session limit as established by the session setup signaling (or rate and maximum packet rate negotiated in session signaling, if any.
equivalent). The overhead value is set to 0. When the session setup
signaling does not specify a limit, then unlimited bitrate is
assumed. Note that many codecs specify their own limits, e.g.
through H.264's level concept.
At any given time, a media receiver can send a TMMBR with a limit Note that this value may be negotiated for another protocol layer
that is lower than the current limit. The media receiver use the than the one the participant uses in its TMMBR messages. Each media
algorithm outlined in the below Section 3.5.4.2 to determine if its receiver selects a reference protocol layer, forms an estimate of the
limit is stricter than already existing ones. The media sender upon overhead it is observing (or estimating it if no packets has been
receiving the TMMBR request will also excersie the algorithm to seen yet) at that reference level, and determines the maximum total
determine the set of most restrictive limitations and then send a media bit rate it can accept, taking into account its own limitations
TMMBN containg that set. Once the media sender has sent the TMMBN and any transport path limitations of which it may be aware. In case
message, the receivers indicated in that message becomes ''owners'' the current limitations are more restricting then what was agreed on
of the limitations. Most likely, the owner is the original sender of in the session signaling, the media receiver reports its initial
the TMMBR -- for the handling of corner-cases (i.e. concurrent TMMBRs estimate of these two quantities to the media sender using a TMMBR
from different receivers, lost TMMBRs and sender side optimisations) message. Overall message traffic is reduced by the possibility of
please see the formal specification. ''Owners'' and limits are including tuples for multiple media senders in the same TMMBR
usually known session wide, as both TMMBR and TMMBN are forwarded to message.
all in the session unless a Mixer or Translator separate the session
from RTCP handling point of view.
Only a ''owner'' is allowed to raise the bitrate limit to a value The media sender applies an algorithm such as that specified in
higher than the session has been notified of, but not higher than the section 3.5.4.2 to select which of the tuples it has received are
session limit negotiated by the session setup signaling (see above). most limiting (i.e. the bounding set as defined in section 2.2). It
A ''owner'' does not need to take into account TMMBR messages sent by modifies its operation to stay within the feasible region (as defined
anyone else (although that may well be a desirable optimization). If in section 2.2), and also sends out a TMMBN notification to the media
a ''owner'' sets a new session limit that is too high for someone receivers indicating the selected bounding set.
else's liking, other media receivers can react to the situation by
emmitting their own TMMBR message (and, in the process, become a
''owner''). Limitations belonging to ''owners'' timing out from the
session are removed by the media sender who notifies the session
about the event by sending a TMMBN.
Obviously, when there is only one media receiver, this receiver If a media receiver does not own one of the tuples in the bounding
becomes ''owner'' once it receives the first TMMBN in response to its set reported by the TMMBN, it applies the same algorithm as the media
own TMMBR, and stays ''owner'' for the rest of the session. sender to determine if its current estimated (maximum total media bit
Therefore, when it is known that there will always be only a single rate, overhead) tuple would enter the bounding set if known to the
media receiver, the above algorithm is not required. Media receivers media sender. If so, it issues a TMMBR request reporting the tuple
that are aware they are the only ones in a session can send TMMBR value to the sender. Otherwise it takes no action for the moment.
messages with bitrate limits both higher and lower than the Periodically, its estimated tuple values may change or it may receive
previously notified limit at any time (subject to AVPF's RTCP RR send a new TMMBN. If so, it reapplies the algorithm to decide whether it
timing rules). However, it may be difficult for a session needs to issue a TMMBR request.
participant to determine if it is the only receiver in the session.
Due to that any one implementing TMMBR are required to implement this
algorithm.
3.5.4.2. Algorithm for exstablishing current limitations If, alternatively, a media receiver owns one of the tuples in the
reported bounding set, it takes no action until such time as its
estimate of its own tuple values changes. At that time it sends a
TMMBR request to the media sender to report the changed values.
A media receiver may change status between owner and non-owner of a
bounding tuple between one TMMBN message and the next. Thus it must
check the contents of each TMMBN to determine its subsequent actions.
Implementations may use other algorithms of their choosing, as long
as the bit rate limitations resulting from the exchange of TMMBR and
TMMBN messages are at least as strict (at least as low, in the bit
rate dimension) as the ones resulting from the use of the
aforementioned algorithm.
Obviously, in point-to-point cases, when there is only one media
receiver, this receiver becomes "owner" once it receives the first
TMMBN in response to its own TMMBR, and stays "owner" for the rest of
the session. Therefore, when it is known that there will always be
only a single media receiver, the above algorithm is not required.
Media receivers that are aware they are the only ones in a session
can send TMMBR messages with bit rate limits both higher and lower
than the previously notified limit, at any time (subject to the AVPF
[RFC4585] RTCP RR send timing rules). However, it may be difficult
for a session participant to determine if it is the only receiver in
the session. Because of this any implementation of TMMBR is required
to include the algorithm described in the next section or a stricter
equivalent.
3.5.4.2. Algorithm for establishing current limitations
This section introduces an example algorithm for the calculation of a
session limit. Other algorithms can be employed, as long as the
result of the calculation is at least as restrictive as the result
that is obtained by this algorithm.
First it is important to consider the implications of using a tuple First it is important to consider the implications of using a tuple
for limiting the media sender's behavior. The bit-rate and the for limiting the media sender's behavior. The bit rate and the
overhead value results in a 2-dimensional solution space for possible overhead value result in a two-dimensional solution space for the
media streams. Fortunately the two variables are linked. The bit-rate calculation of the bit rate of media streams. Fortunately the two
available for RTP payloads will be equal to the TMMBR reported bit- variables are linked. Specifically, the bit rate available for RTP
rate minus the packet rate used times the TMMBR reported overhead. payloads is equal to the TMMBR reported bit rate minus the packet
This has the result in a session with two different participants rate used, multiplied by the TMMBR reported overhead converted to
having set limitations, the used packet rate will determine which of bits. As a result, when different bit rate/overhead combinations
the two that applies. need to be considered, the packet rate determines the correct
limitation. This is perhaps best explained by an example:
Example: Example:
Receiver A: TMMBR_BR = 35 kbps, TMMBR_OH = 40 Receiver A: TMMBR_max total BR = 35 kbps, TMMBR_OH = 40 bytes
Receiver B: TMMBR_BR = 40 kbps, TMMBR_OH = 60 Receiver B: TMMBR_max total BR = 40 kbps, TMMBR_OH = 60 bytes
For a given packet rate (PR) the bit-rate available for media For a given packet rate (PR) the bit rate available for media
payloads in RTP will be: payloads in RTP will be:
Max_media_BR_A = TMMBR_BR_A - PR * TMMBR_OH_A * 8 Max_net media_BR_A = TMMBR_max total BR_A - PR * TMMBR_OH_A * 8 ...
Max_media_BR_B = TMMBR_BR_B - PR * TMMBR_OH_B * 8 (1)
Max_net media_BR_B = TMMBR_max total BR_B - PR * TMMBR_OH_B * 8 ...
(2)
For a PR = 20 these calculations will yield a Max_media_BR_A = 28600 For a PR = 20 these calculations will yield a Max_net media_BR_A =
bps and Max_media_BR_B = 30400 bps, which shows that receiver A is 28600 bps and Max_net media_BR_B = 30400 bps, which suggests that
the limiting one for this packet rate. However there will be a PR receiver A is the limiting one for this packet rate. However at a
when the difference in bit-rate restriction will be equal to the certain PR there is a switchover point at which receiver B becomes
difference in packet overheads. This can be found by setting the limiting one. The switchover point can be identified by setting
Max_media_BR_A equal to Max_media_BR_B and breaking out PR: Max_media_BR_A equal to Max_media_BR_B and breaking out PR:
TMMBR_BR_A - TMMBR_BR_B TMMBR_max total BR_A - TMMBR_max total BR_B
PR = --------------------------- PR = ------------------------------------------- ... (3)
8*(TMMBR_OH_A - TMMBR_OH_B) 8*(TMMBR_OH_A - TMMBR_OH_B)
Which, for the numbers above yields 31.25 as the intersection point which, for the numbers above yields 31.25 as the switchover point
between the two limits. The implications of this have to be between the two limits. That is, for packet rates below 31.25 per
considered by application implementors that are going to control second, receiver A is the limiting receiver, and for higher packet
media encoding and its packetization. Because, as exemplified above, rates, receiver B is more limiting. The implications of this
there might be multiple TMMBR limits that applies to the trade-off behavior have to be considered by implementations that are going to
between media bit-rate and packet rate. Which limitation that applies control media encoding and its packetization. As exemplified above,
depends on the packet rate considered to be used. multiple TMMBR limits may apply to the trade-off between net media
bit rate and packet rate. Which limitation applies depends on the
packet rate being considered.
This also has implications for how the TMMBR mechanism needs to work. This also has implications for how the TMMBR mechanism needs to work.
First, there is the possibility that multiple TMMBR tuples are First, there is the possibility that multiple TMMBR tuples are
providing limitations on the media sender. Secondly there is a need providing limitations on the media sender. Secondly there is a need
for any session participant (meda sender and receivers) to be able to for any session participant (media sender and receivers) to be able
determine if a given tuple will become a limitation upon the media to determine if a given tuple will become a limitation upon the media
sender, or if the set of already given limitations are stricter than sender, or if the set of already given limitations is stricter than
the given values. Otherwise the suppression of TMMBR requests would the given values. In the absence of the ability to make this
not work. determination the suppression of TMMBR requests would not work.
Thus any session participant needs to be able from a given set X of The basic idea of the algorithm is as follows. Each TMMBR tuple can
tuples determine which is the minimal set need to express the be viewed as the equation of a straight line (cf. equations (1) and
limitations for all packet rates from 0 to highest possible. Where (2)) in a space where packet rate lies along the X-axis and maximum
the highest possible either is application limited and indicated bit rate lies along the Y-axis. The lower envelope of the set of
trough session setup signaling or as a result of the given lines corresponding to the complete set of TMMBR tuples defines a
limitations when the available bit-rate is fully consumed by headers. polygon. Points lying along or below this polygon are combinations of
packet rate and bit rate that meet all of the TMMBR constraints. The
highest feasible packet rate within this region is the minimum of the
rate at which the bounding polygon meets the X-axis or the session
maximum packet rate (SMAXPR) provided by signaling, if any. Typically
a media sender will prefer to operate at a lower rate than this
theoretical maximum, so as to increase the rate at which actual media
content reaches the receivers. The purpose of the algorithm is to
distinguish the TMMBR tuples constituting the bounding set and thus
delineate the feasible region, so that the media sender can select
its preferred operating point within that region
First determine what the highest possible bit-rate given all the Figure 1 below shows a bounding polygon formed by TMMBR tuples A and
limitations is. If there is provided a session maximum packet rate B. A third tuple C lies outside the bounding polygon and is therefore
(SMAXPR) then this can be used. In addition one needs to calculate irrelevant in determining feasible tradeoffs between media rate and
for each tuple in the set what its maximum is by calculating bit-rate packet rate. The line labeled ss..s represents the limit on packet
(BR) divided by overhead (OH) per packet converted to bits. rate imposed by the session maximum packet rate (SMAXPR) obtained by
signaling during session setup. In Figure 1 the limit determined by
tuple B happens to be more restrictive than SMAXPR. The situation
could easily be the reverse, meaning that the bounding polygon is
terminated on the right by the vertical line representing the SMAXPR
constraint.
MaxPR = SMAXPR ^
For i=1 to size(X) { |a c b s
tmp_pr = X(i).BR / 8*X(i).OH; Bit | a c b s
If (tmp_pr < MaxPR) then MaxPR = tmp_pr Rate | a c b s
} | a cb s
| a c s
| a bc s
| a b c s
| ab c s
| Feasible b c s
| region ba s
| b a s c
| b s c
| b s a
|_____________________bs________
+------------------------------>____________
For a zero packet rate the TMMBR signaled bit-rate will be the only Packet rate
limiting factor, thus the tuple with the smallest available bit-rate
is a limitation at this point of the range and function as a start
value in the algorithm.
Start by finding the element X(l) in X with the lowest bit-rate value Figure 1 - Geometric Interpretation of TMMBR Tuples
and the highest overhead if there are multiple on the same bit-rate.
The set Y that is the minimal set of tuples that provide restrictions
initially contain only X(l). Then for each other tuple X(i) calculate
if there exist an intersection between the currently selected tuple
X(s) (initially s=l) and which of the tuples within the set that has
this intersection at the lowest packet rate. Having found the lowest
packet rate, compare it with the sessions maximum packet rate. If
lower than that limit this tuple provide a session limit and the
tuple is added to Y. Update the value of s to the found tuple and
repeat search for the tuple that has the intersection at the lowest
packet rate, but still higher than the previous intersection.
Algorithm has finished when it can't find any new tuple with an
intersection at a packet rate lower than the session maximum.
// Find the element with the lowest bit-rate in X Note that the slopes of the lines making up the bounding polygon are
l=0; increasingly negative as one moves in the direction of increasing
for (i=1:size(X)){ packet rate. Note also that with slight rearrangement, equations (1)
if (X(i).BR <= X(l).BR) & (X(i).OH > X(l).OH) then and (2) have the canonical form:
l=I;
}
tuple_index = l; // The lowest bit-rate tuple y = mx + b
Y = X(l); // Initilize Y to X(l)
start_pr = 0; // Start from zero bit-rate
do {
current_low = MaxPr; //Reset packet-rate
current_index = tuple_index; // To allow for no intersection
For i=each element in X
pr = (X(i).BR - X(tuple_index).BR) /
(X(i).OH - X(tuple_index).OH)
// Calculate packet rate compared to element i
If (pr < current_low && pr > start_pr) then {
// Update lowest intersection packet rate
current_low = pr;
current_index = i;
}
}
If (current_index != tuple_index) {
// A tuple intersecting below maxpacket rate
Y(size(Y)+1) = X(current_index) // Add to Y
tuple_index = current_index; // Update which to compare with
start_pr = current_low; // Update packet rate to seek from.
}
} while (current_low < MaxPr)
The above algorithm yields the set of applicable restriction Y. where
m is the slope and has value equal to the negative of the tuple
overhead (in bits),
and
b is the y-intercept and has value equal to the tuple maximum total
media bit rate.
3.5.4.3. Use of TMMBR in a Mixer based Multi-point operation These observations lead to the conclusion that when processing the
TMMBR tuples to select the initial bounding set, one should sort and
process the tuples by order of increasing overhead. Once a particular
tuple has been added to the bounding set, all tuples not already
selected and having lower overhead can be eliminated, because the
next side of the bounding polygon has to be steeper (i.e. the
corresponding TMMBR must have higher overhead) than the latest added
tuple.
Line cc..c in Figure 1 illustrates another principle. This line is
parallel to line aa..a, but has a higher Y-intercept. That is, the
corresponding TMMBR tuple contains a higher maximum total media bit
rate value. Since line cc..c is outside the bounding polygon, it
illustrates the conclusion that if two TMMBR tuples have the same
overhead value, the one with higher maximum total media bit rate
value cannot be part of the bounding set and can be set aside.
Two further observations complete the algorithm. Obviously, moving
from the left, the successive corners of the bounding polygon (i.e.
the intersection points between successive pairs of sides) lie at
successively higher packet rates. On the other hand, again moving
from the left, each successive line making up the bounding set
crosses the X-axis at a lower packet rate.
The complete algorithm can now be specified. The algorithm works
with two lists of TMMBR tuples, the candidate list X and the selected
list Y, both ordered by increasing overhead value. The algorithm
terminates when all members of X have been discarded or removed for
processing. Membership of the selected list Y is probationary until
the algorithm is complete. Each member of the selected list is
associated with an intersection value, which is the packet rate at
which the line corresponding to that TMMBR tuple intersects with the
line corresponding to the previous TMMBR tuple in the selected list.
Each member of the selected list is also associated with a maximum
packet rate value, which is the lesser of the session maximum packet
rate SMAXPR (if any) and the packet rate at which the line
corresponding to that tuple crosses the X-axis.
When the algorithm terminates, the selected list is equal to the
bounding set as defined in section 2.2.
Initial Algorithm
This algorithm is used by the media sender when it has received one
or more TMMBR requests and before it has determined a bounding set
for the first time.
1. Sort the TMMBR tuples by order of increasing overhead. This is
the initial candidate list X.
2. When multiple tuples in the candidate list have the same
overhead value, discard all but the one with the lowest maximum
total media bit rate value.
3. Select and remove from the candidate list the TMMBR tuple with the
lowest maximum total media bit rate value. If there is more than
one tuple with that value, choose the one with the highest
overhead value. This is the first member of the selected list Y.
Set its intersection value equal to zero. Calculate its maximum
packet rate as the minimum of SMAXPR (if available) and the value
obtained from the following formula, which is the packet rate at
which the corresponding line crosses the X-axis.
Max PR = TMMBR max total BR / (8 * TMMBR OH) ... (4)
4. Discard from the candidate list all tuples with a lower overhead
value than the selected tuple.
5. Remove the first remaining tuple from the candidate list for
processing. Call this the current candidate.
6. Calculate the packet rate PR at the intersection of the line
generated by the current candidate with the line generated by the
last tuple in the selected list Y, using equation (3).
7. If the calculated value PR is equal to or lower than the
intersection value stored for the last tuple of the selected list,
discard the last tuple of the selected list and go back to step 6
(retaining the same current candidate).
Note that the choice of the initial member of the selected list Y
in step 3 guarantees that the selected list will never be emptied
by this process, meaning that the algorithm must eventually (if
not immediately) fall through to the step 8.
8. (This step is reached when the calculated PR value of the current
candidate is greater than the intersection value of the current
last member of the selected list Y.) If the calculated value PR
of the current candidate is lower than the maximum packet rate
associated with the last tuple in the selected list, add the
current candidate tuple to the end of the selected list. Store
PR as its intersection value. Calculate its maximum packet rate
as the lesser of SMAXPR (if available) and the maximum packet
rate calculated using equation (4).
9. If any tuples remain in the candidate list, go back to step 5.
Incremental Algorithm
The previous algorithm covered the initial case, where no selected
list had previously been created. It also applied only to the media
sender. When a previously-created selected list is available at
either the media sender or media receiver, two other cases can be
considered:
o when a TMMBR tuple not currently in the selected list is a
candidate for addition;
o when the values change in a TMMBR tuple currently in the
selected list.
At the media receiver these cases correspond respectively to those
of the non-owner and owner of a tuple in the TMMBN-reported bounding
set.
In either case, the process of updating the selected list to take
account of the new/changed tuple can use the basic algorithm
described above, with the modification that the initial candidate
set consists only of the existing selected list and the new or
changed tuple. Some further optimization is possible (beyond
starting with a reduced candidate set) by taking advantage of the
following observations.
The first observation is that if the new/changed candidate becomes
part of the new selected list, the result may be to cause zero or
more other tuples to be dropped from the list. However, if more than
one other tuple is dropped, the dropped tuples will be consecutive.
This can be confirmed geometrically by visualizing a new line that
cuts off a series of segments from the previously-existing bounding
polygon. The cut-off segments are connected one to the next, the
geometric equivalent of consecutive tuples in a list ordered by
overhead value. Beyond the dropped set in either direction all of
the tuples that were in the earlier selected list will be in the
updated one. The second observation is that, leaving aside the new
candidate, the order of tuples remaining in the updated selected list
is unchanged because their overhead values have not changed.
The consequence of these two observations is that, once the placement
of the new candidate and the extent of the dropped set of tuples (if
any) has been determined, the remaining tuples can be copied directly
from the candidate list into the selected list, preserving their
order. This conclusion suggests the following modified algorithm:
o Run steps 1-4 of the basic algorithm.
o If the new candidate has survived steps 2 and 4 and has become
the new first member of the selected list, run steps 5-9 on
subsequent candidates until another candidate is added to the
selected list. Then move all remaining candidates to the
selected list, preserving their order.
o If the new candidate has survived steps 2 and 4 and has not
become the new first member of the selected list, start by
moving all tuples in the candidate list with lower overhead
values than that of the new candidate to the selected list,
preserving their order. Run steps 5 through 9 for the new
candidate, with the modification that the intersection values
and maximum packet rates for the tuples on the selected list
have to be calculated on the fly because they were not
previously stored. Continue processing only until a
subsequent tuple has been added to the selected list, then
move all remaining candidates to the selected list, preserving
their order.
Note that the new candidate could be added to the selected
list only to be dropped again when the next tuple is
processed. It can easily be seen that in this case the new
candidate does not displace any of the earlier tuples in the
selected list. The limitations of ASCII art make this
difficult to show in a figure. Line cc..c in Figure 1 would
be an example if it had a steeper slope (tuple C had a higher
overhead value), but still intersected line aa..a beyond where
line aa..a intersects line bb..b.
The algorithm just described is approximate, because it does not take
account of tuples outside the selected list. To see how such tuples
can become relevant, consider Figure 1 and suppose that the maximum
total media bit rate in tuple A increases to the point that line
aa..a moves outside line cc..c. Tuple A will remain in the bounding
set calculated by the media sender. However, once it issues a new
TMMBN, media receiver C will apply the algorithm and discover that
its tuple C should now enter the bounding set. It will issue a TMMBR
request to the media sender, which will repeat its calculation and
come to the appropriate conclusion.
The rules of section 4.2 require that the media sender refrain from
raising its sending rate until media receivers have had a chance to
respond to the TMMBN. In the example just given, this delay ensures
that the relaxation of tuple A does not actually result in an attempt
to send media at a rate exceeding the capacity at C.
3.5.4.3. Use of TMMBR in a Mixer Based Multipoint Operation
Assume a small mixer-based multiparty conference is ongoing, as Assume a small mixer-based multiparty conference is ongoing, as
depicted in Topo-Mixer of [Topologies]. All participants have depicted in Topo-Mixer of [Topologies]. All participants have
negotiated a common maximum bit-rate that this session can use. The negotiated a common maximum bit rate that this session can use. The
conference operates over a number of unicast paths between the conference operates over a number of unicast paths between the
participants and the mixer. The congestion situation on each of participants and the mixer. The congestion situation on each of
these paths can be monitored by the participant in question and by these paths can be monitored by the participant in question and by
the mixer, utilizing, for example, RTCP Receiver Reports or the the mixer, utilizing, for example, RTCP receiver reports (RR) or the
transport protocol, e.g. DCCP [RFC4340]. However, any given transport protocol, e.g. DCCP [RFC4340]. However, any given
participant has no knowledge of the congestion situation of the participant has no knowledge of the congestion situation of the
connections to the other participants. Worse, without mechanisms connections to the other participants. Worse, without mechanisms
similar to the ones discussed in this draft, the mixer (who is aware similar to the ones discussed in this draft, the mixer (which is
of the congestion situation on all connections it manages) has no aware of the congestion situation on all connections it manages) has
standardized means to inform media senders to slow down, short of no standardized means to inform media senders to slow down, short of
forging its own receiver reports (which is undesirable). In forging its own receiver reports (which is undesirable). In
principle, a mixer confronted with such a situation is obliged to principle, a mixer confronted with such a situation is obliged to
thin or transcode streams intended for connections that detected thin or transcode streams intended for connections that detected
congestion. congestion.
In practice, media-aware stream thinning is unfortunately a very In practice, media-aware stream thinning is unfortunately a very
difficult and cumbersome operation and adds undesirable delay. If difficult and cumbersome operation and adds undesirable delay. If
media-unaware, it leads very quickly to unacceptable reproduced media media-unaware, it leads very quickly to unacceptable reproduced media
quality. Hence, means to slow down senders even in the absence of quality. Hence, a means to slow down senders even in the absence of
congestion on their connections to the mixer are desirable. congestion on their connections to the mixer is desirable.
To allow the mixer to perform congestion control on the individual To allow the mixer to throttle traffic on the individual links,
links, without performing transcoding, there is a need for a without performing transcoding, there is a need for a mechanism that
mechanism that enables the mixer to request the participant's media enables the mixer to ask a participant's media encoders to limit the
encoders to limit their Maximum Media Stream bit-rate currently used. media stream bit rate they are currently generating. TMMBR provides
The mixer handles the detection of a congestion state between itself the required mechanism. When the mixer detects congestion between
and a participant as follows: itself and a given participant, it executes the following procedure:
1. Start thinning the media traffic to the supported bit-rate.
2. Use the TMMBR to request the media sender(s) to reduce the media
bit-rate sent by them to the mixer, to a value that is in
compliance with congestion control principles for the slowest
link. Slow refers here to the available
bandwidth/bitrate/capacity and packet rate after congestion
control.
3. As soon as the bit-rate has been reduced by the sending part, the
mixer stops stream thinning implicitly, because there is no need
for it any more as the stream is in compliance with congestion
control.
Above algorithms may suggest to some that there is no need for the 1. It starts thinning the media traffic to the congested participant
TMMBR - it should be sufficient to solely rely on stream thinning. to the supported bit rate.
As much as this is desirable from a network protocol designer's
viewpoint, it has the disadvantage that it doesn't work very
well - the reproduced media quality quickly becomes unusable.
It appears to be a reasonable compromise to rely on stream thinning 2. It uses TMMBR to request the media sender(s) to reduce the total
as an immediate reaction tool to combat congestions, and have a quick media bit rate sent by them to the mixer, to a value that is in
control mechanism that instructs the original sender to reduce its compliance with congestion control principles for the slowest
bitrate. link. Slow refers here to the available bandwidth / bit rate /
capacity and packet rate after congestion control.
Note also that the standard RTCP receiver report cannot serve for the 3. As soon as the bit rate has been reduced by the sending part, the
purpose mentioned. In an environment with RTP mixers, the RTCP RR is mixer stops stream thinning implicitly, because there is no need
being sent between the RTP receiver in the endpoint and the RTP for it once the stream is in compliance with congestion control.
sender in the mixer only - as there is no multicast transmission.
The stream that needs to be bitrate-reduced, however, is the one
between the original sending endpoint and the mixer. This endpoint
doesn't see the aforementioned RTCP RRs, and hence needs to be
explicitly informed about desired bitrate adjustments.
In this topology it is the mixer's responsibility to collect, and This use of stream thinning as an immediate reaction tool followed up
consider jointly, the different bit-rates which the different links by a quick control mechanism appears to be a reasonable compromise
may support, into the bit rate requested. This aggregation may also between media quality and the need to combat congestion.
take into account that the mixer may contain certain transcoding
capabilities (as discussed in under Topo-Mixer in [Topologies]),
which can be employed for those few of the session participants that
have the lowest available bit-rates.
3.5.4.4. Use of TMMBR in Point-to-Multipoint using Multicast or 3.5.4.4. Use of TMMBR in Point-to-Multipoint Using Multicast or
Translators Translators
In these topologies, corresponding to Topo-Multicast or Topo- In these topologies, corresponding to Topo-Multicast or Topo-
Translator RTCP RRs are transmitted globally which allows for the Translator, RTCP RRs are transmitted globally. This allows all
detection of transmission problems such as congestion, on a medium participants to detect transmission problems such as congestion, on a
timescale. As all media senders are aware of the congestion medium timescale. As all media senders are aware of the congestion
situation of all media receivers, the rationale of the use of TMMBR situation of all media receivers, the rationale for the use of TMMBR
of section 3.5.4.3 does not apply. However, even in this case the in the previous section does not apply. However, even in this case
congestion control response can be improved when the unicast links the congestion control response can be improved when the unicast
are employing congestion controlled transport protocols (such as TCP links are using congestion controlled transport protocols (such as
or DCCP). A peer may also report local limitation to the media TCP or DCCP). A peer may also report local limitations to the media
sender. sender.
3.5.4.5. Use of TMMBR in Point-to-point operation 3.5.4.5. Use of TMMBR in Point-to-point operation
In use case 7 it is possible to use TMMBR to improve the performance In use case 7 it is possible to use TMMBR to improve the performance
at times of changes in the known upper limit of the bit-rate. In when the known upper limit of the bit rate changes. In this use case
this use case the signaling protocol has established an upper limit the signaling protocol has established an upper limit for the session
for the session and media bit-rates. However, at the time of and total media bit rates. However, at the time of transport link
transport link bit-rate reduction, a receiver could avoid serious bit rate reduction, a receiver can avoid serious congestion by
congestion by sending a TMMBR to the sending side. Thus TMMBR is sending a TMMBR to the sending side. Thus TMMBR is useful for
useful for putting restrictions on the application and thus placing putting restrictions on the application and thus placing the
the congestion control mechanism in the right ballpark. However TMMBR congestion control mechanism in the right ballpark. However TMMBR is
is usually unable to have continuously quick feedback loop required usually unable to provide the continuously quick feedback loop
for real congestion control. Its semantics is also not a match for required for real congestion control. Nor do its semantics match
congestion control due to its different purpose. Because of these those of congestion control given its different purpose. For these
reasons TMMBR SHALL NOT be used for congestion control. reasons TMMBR SHALL NOT be used as a substitute for congestion
control.
3.5.4.6. Reliability 3.5.4.6. Reliability
The reaction of a media sender to the reception of a TMMBR message is The reaction of a media sender to the reception of a TMMBR message is
not immediately identifiable through inspection of the media stream. not immediately identifiable through inspection of the media stream.
Therefore, a more explicit mechanism is needed to avoid unnecessary Therefore, a more explicit mechanism is needed to avoid unnecessary
re-sending of TMMBR messages. Using a statistically based re-sending of TMMBR messages. Using a statistically based
retransmission scheme would only provide statistical guarantees of retransmission scheme would only provide statistical guarantees of
the request being received. It would also not avoid the the request being received. It would also not avoid the
retransmission of already received messages. In addition, it does not retransmission of already received messages. In addition, it would
allow for easy suppression of other participants requests. For the not allow for easy suppression of other participants' requests. For
reasons mentioned, a mechanism based on explicit notification is these reasons, a mechanism based on explicit notification is used.
used, as discussed already in section 3.5.4.1.
Upon the reception of a request a media sender sends a notification Upon the reception of a request a media sender sends a TMMBN
containing the current applicable limitation of the bit-rate, and notification containing the current bounding set, and indicating
which session participants that own that limit. In multicast which session participants own that limit. In multicast scenarios,
scenarios, that allows all other participants to suppress any request that allows all other participants to suppress any request they may
they may have, with limitation values less strict than the current have, if their limitations are less strict than the current ones
ones. The identity of the owners allows for small message sizes and (i.e. define lines lying outside the feasible region as defined in
media sender states. A media sender only keeps state for the SSRCs of section 2.2). Keeping and notifying only the bounding set of tuples
the current owners of the limitations; all other requests and their allows for small message sizes and media sender states. A media
sources are not saved. Only the owners are allowed to remove or sender only keeps state for the SSRCs of the current owners of the
change its limitation. Otherwise, anyone that ever set a limitation bounding set of tuples; all other requests and their sources are not
would need to remove it to allow the maximum bit-rate to be raised saved. Once the bounding set has been established, new TMMBR
beyond that value. messages should be generated only by owners of the bounding tuples
and by other entities that determine (by applying the algorithm of
section 3.5.4.2 or its equivalent) that their limitations should now
be part of the bounding set.
4. RTCP Receiver Report Extensions 4. RTCP Receiver Report Extensions
This memo specifies six new feedback messages. The Full Intra Request This memo specifies six new feedback messages. The Full Intra
(FIR), Temporal-Spatial Trade-off Request (TSTR), Temporal-Spatial Request (FIR), Temporal-Spatial Trade-off Request (TSTR), Temporal-
Trade-off Notification (TSTN), and Video Back Channel Message (VBCM) Spatial Trade-off Notification (TSTN), and Video Back Channel Message
are "Payload Specific Feedback Messages" as defined in Section 6.3 of (VBCM) are "Payload Specific Feedback Messages" as defined in Section
AVPF [RFC4585]. The Temporary Maximum Media Stream Bit-rate Request 6.3 of AVPF [RFC4585]. The Temporary Maximum Media Stream Bit Rate
(TMMBR) and Temporary Maximum Media Stream Bit-rate Notification Request (TMMBR) and Temporary Maximum Media Stream Bit Rate
(TMMBN) are "Transport Layer Feedback Messages" as defined in Section Notification (TMMBN) are "Transport Layer Feedback Messages" as
6.2 of AVPF. defined in Section 6.2 of AVPF.
In the following subsections, the new feedback messages are defined, The new feedback messages are defined in the following subsections,
following a similar structure as in the AVPF specification's sections following a similar structure to that in sections 6.2 and 6.3 of the
6.2 and 6.3, respectively. AVPF specification [RFC4585].
4.1. Design Principles of the Extension Mechanism 4.1. Design Principles of the Extension Mechanism
RTCP was originally introduced as a channel to convey presence, RTCP was originally introduced as a channel to convey presence,
reception quality statistics and hints on the desired media coding. reception quality statistics and hints on the desired media coding.
A limited set of media control mechanisms have been introduced in A limited set of media control mechanisms were introduced in early
early RTP payload formats for video formats, for example in RFC 2032 RTP payload formats for video formats, for example in RFC 4587
[RFC2032]. However, this specification, for the first time, suggests [RFC4587]. However, this specification, for the first time, suggests
a two-way handshake for some of its messages. There is danger that a two-way handshake for some of its messages. There is danger that
this introduction could be misunderstood as the precedence for the this introduction could be misunderstood as a precedent for the use
use of RTCP as an RTP session control protocol. In order to prevent of RTCP as an RTP session control protocol. To prevent such a
these misunderstandings, this subsection attempts to clarify the misunderstanding, this subsection attempts to clarify the scope of
scope of the extensions specified in this memo, and strongly suggests the extensions specified in this memo, and strongly suggests that
that future extensions follow the rationale spelled out here, or future extensions follow the rationale spelled out here, or
compellingly explain why they divert from the rationale. compellingly explain why they divert from the rationale.
In this memo, and in AVPF [RFC4585], only such messages have been In this memo, and in AVPF [RFC4585], only such messages have been
included which included as:
a) have comparatively strict real-time constraints, which prevent the a) have comparatively strict real-time constraints, which prevent the
use of mechanisms such as a SIP re-invite in most application use of mechanisms such as a SIP re-invite in most application
scenarios. The real-time constraints are explained separately for scenarios. The real-time constraints are explained separately for
each message where necessary each message where necessary.
b) are multicast-safe in that the reaction to potentially b) are multicast-safe in that the reaction to potentially
contradicting feedback messages is specified, as necessary for contradicting feedback messages is specified, as necessary for
each message each message; and
c) are directly related to activities of a certain media codec, class c) are directly related to activities of a certain media codec, class
of media codecs (e.g. video codecs), or a given RTP packet stream. of media codecs (e.g. video codecs), or a given RTP packet stream.
In this memo, a two-way handshake is only introduced for such In this memo, a two-way handshake is introduced only for messages for
messages that which:
a) require a notification or acknowledgement due to their nature,
which is motivated separately for each message a) a notification or acknowledgement is required due to their nature.
An analysis to determine whether this requirement exists has been
performed separately for each message.
b) the notification or acknowledgement cannot be easily derived from b) the notification or acknowledgement cannot be easily derived from
the media bit stream. the media bit stream.
All messages in AVPF [RFC4585] and in this memo implement their All messages in AVPF [RFC4585] and in this memo present their
codepoints in a simple, fixed binary format. The reason behind this contents in a simple, fixed binary format. This accommodates media
design principle lies in that media receivers do not always implement receivers which have not implemented higher control protocol
higher control protocol functionalities (SDP, XML parsers and such) functionalities (SDP, XML parsers and such) in their media path.
in their media path. Therefore, simple binary representations are
used in the feedback messages and not an (otherwise desirable)
flexible format such as, for example, XML.
4.2. Transport Layer Feedback Messages 4.2. Transport Layer Feedback Messages
Transport Layer FB messages are identified by the value RTPFB (205) As specified in section 6.1 of RFC 4585 [RFC4585], Transport Layer
as RTCP packet type (see section 6.1 of RFC 4585 [RFC4585]. Feedback messages are identified by the RTCP packet type value RTPFB
(205).
In AVPF, one message of this category had been defined. This memo In AVPF, one message of this category had been defined. This memo
specifies two more messages, for a total of three messages of this specifies two more such messages. They are identified by means of
type. They are identified by means of the FMT parameter as follows: the FMT parameter as follows:
0: unassigned Assigned in AVPF [RFC4585]:
1: Generic NACK (as per AVPF)
2: reserved (see note below) 1: Generic NACK
3: Temporary Maximum Media Stream Bit-rate Request (TMMBR)
4: Temporary Maximum Media Stream Bit-rate Notification (TMMBN)
5-30: unassigned
31: reserved for future expansion of the identifier number space 31: reserved for future expansion of the identifier number space
Note: early drafts of AVPF [RFC4585] reserved FMT=2 for a Assigned in this memo:
codepoint that has later been removed. It has been pointed
out that there may be implementations in the field using this 2: reserved (see note below)
value for according to the expired draft. As there is 3: Temporary Maximum Media Stream Bit Rate Request (TMMBR)
4: Temporary Maximum Media Stream Bit Rate Notification (TMMBN)
Note: early drafts of AVPF [RFC4585] reserved FMT=2 for a code
point that has later been removed. It has been pointed out
that there may be implementations in the field using this
value in accordance with the expired draft. As there is
sufficient numbering space available, we mark FMT=2 as sufficient numbering space available, we mark FMT=2 as
reserved so to avoid possible interoperability problems with reserved so to avoid possible interoperability problems with
implementations that are standard-incompliant with respect to any such early implementations.
RFC 4585 in this very point.
The following subsection defines the formats of the FCI field for Available for assignment:
this type of FB message.
4.2.1. Temporary Maximum Media Stream Bit-rate Request and Notification 0: unassigned
5-30: unassigned
The following subsection defines the formats of the FCI entries for
the TMMBR and TMMBN messages respectively and specify the associated
behaviour at the media sender and receiver.
4.2.1. Temporary Maximum Media Stream Bit Rate Request (TMMBR)
The FCI field of a Temporary Maximum Media Stream Bit-Rate Request The FCI field of a Temporary Maximum Media Stream Bit-Rate Request
(TMMBR) message SHALL contain one or more FCI entries. (TMMBR) message SHALL contain one or more FCI entries.
4.2.1.1. Semantics 4.2.1.1. Message Format
TMMBR is used to indicate the transport related limitation in the The Feedback Control Information (FCI) consists of one or more TMMBR
form of a tuple. The first value is the highest bit-rate per sender FCI entries with the following syntax:
of a media, which the receiver currently supports in this RTP session
observed at a particular protocol layer. The second value is the
measured header overhead in bytes on the packets received for the
stream. Counting from the start of the header on the protocol layer
for which the bit-rate is reported until the RTP payload's start.
The measurement of the overhead is a running averaging that is
updated for each packet received for this particular media source
(SSRC). For each packet received the overhead is calculated (pckt_OH)
and then added to the average overhead (avg_OH) by calculating:
avg_OH = 15/16*avg_OH + 1/16*pckt_OH.
The bit-rate values used in this formats are averaged out over a 0 1 2 3
reasonable timescale. What reasonable timescales are, depends on the 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
application. However the goal is be able to ignore any burstiness on +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
very short timescales, below for example 100 ms, introduced by | SSRC |
scheduling or link layer packetization effects. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The media sender MAY use any combination of packet rate and RTP Figure 2 - Syntax of an FCI entry in the TMMBR message
payload bit-rate to produce a lower media stream bit-rate, as it may
need to address a congestion situation or other limiting factors.
See section 5 . (congestion control) for more discussion.
The ''SSRC of the packet sender'' field indicates the source of the SSRC (32 bits): The SSRC value of the media sender that is
request, and the ''SSRC of media source'' is not used and SHALL be requested to obey the new maximum bit rate.
set to 0. The SSRC of media sender in the FCI field denotes the media
sender the message applies to. This is useful in the multicast or
translator topologies where each media sender may be addressed in a
single TMMBR message using multiple FCIs.
A TMMBR FCI MAY be repeated in subsequent TMMBR messages if no MxTBR Exp (6 bits): The exponential scaling of the mantissa for the
applicable Temporal Maximum Media Stream Bit-Rate Notification maximum total media bit rate value. The value is an
(TMMBN) FCI has been received at the time of transmission of the next unsigned integer [0..63].
RTCP packet. A TMMBN is applicable if it either indicate the sender
of the TMMBR as an owner, or contains limitations that are stricter
than one sent in the TMMBR message. The bit-rate value of a TMMBR
FCI MAY be changed from a previous TMMBR message and the next,
regardless of the eventual reception of an applicable TMMBN FCI. The
overhead measurement SHALL be updated to the current value of avg_OH.
A TMMBN message SHALL be sent by the media sender at the earliest MxTBR Mantissa (17 bits): The mantissa of the maximum total media
possible point in time, as a result of any TMMBR messages received bit rate value as an unsigned integer.
since the last sending of TMMBN. The TMMBN message indicates the
limits and the owners of those limits at the time of the transmission
of the message. The limits SHALL be set to the set of the stricts
limits of the previous limits and all limits received in TMMBR FCI's
since the last TMMBN was transmitted.
A media receiver considering sending a TMMBR, who is not a ''owner'' Measured Overhead (9 bits): The measured average packet overhead
of a limitation, SHOULD request a limitation stricter than their value in bytes. The measurement SHALL be done according
knowledge of the currently established limits for this media sender, to description in section 4.2.1.2. The value is an
or suppress their transmission of the TMMBR. The exception to the unsigned integer [0..512].
above rule is when a receiver either doesn't know the limit or is
certain that their local representation of the set of limitations are
in error. All received requests for limits equally or less strict
compared to the ones currently established MUST BE ignored, with the
exception of them resulting in the transmission of a TMMBN containg
the current set of limitations. A media receiver who is the owner of
a current limitation MAY lower the value further, raise the value or
remove the restriction completely by setting the bit-rate part of the
limit equal to the session bit-rate limit.
A limitation tuple LT can be determined to be stricter or not The maximum total media bit rate (MxTBR) value in bits per second is
compared to the current set of limitations if LT is part of the set Y calculated from the MxTBR exponent (exp) and mantissa in the
produced by the algorithm described in Section 3.5.4.2. following way:
Once a session participant receives the TMMBN in response to its MxTBR = mantissa * 2^exp
TMMBR, with its own SSRC, it knows that it "owns" the bitrate
limitation. Only the "owner" of a bitrate limitation can raise it or
reset it to the session limit.
Note that, due to the unreliable nature of transport of TMMBR and This allows for 17 bits of resolution in the range 0 to 131072*2^63
TMMBN, the above rules may lead to the sending of TMMBR messages (approximately 1.2*10^24).
disobeying the rules above. Furthermore, in multicast scenarios it
can happen that more than one session participants believes it "owns"
the current bitrate limitation. This is not critical for a number of
reasons:
a) If a TMMBR message is lost in transmission, the media sender does
not learn about the restrictions imposed on it. However, it also
does not send a TMMBN message notifying reception of a request it
has never received. Therefore, no new limit is established, the
media receiver sending a more restrictive TMMBR is not the owner.
Since this media receiver has not seen a notification
corresponding to its request, it is free to re-send it.
b) Similarly, if a TMMBN message gets lost, the media receiver that
has sent the corresponding TMMBR request does not receive the
Notification. In that case, it is also not the "owner" of the
restriction and is free to re-send the request.
c) If multiple competing TMMBR messages are sent by different session
participants, then the resulting TMMBN indicates the most
restrictive limits requested including its owners.
d) If more than one session participant incidently send TMMBR The length of the TMMBR feedback message SHALL be set to 2+2*N where
messages at the same time and with the same limit, the media N is the number of TMMBR FCI entries.
sender selects one of them and addresses it as the ''owner''.
Session-wide, the correct limit is thereby established.
It is also important to consider the security risks involved with 4.2.1.2. Semantics
faked TMMBRs. See security considerations in Section 6.
The feedback messages may be used in both multicast and unicast Behaviour at the Media Receiver (Sender of the TMMBR)
sessions of any of the specified topologies.
For sessions with a large number of participants using the lowest TMMBR is used to indicate a transport related limitation at the
common denominator, as required by this mechanism, may not be the reporting entity acting as a media receiver. TMMBR has the form of a
most suitable course of action. Large session may need to consider tuple containing two components. The first value is the highest bit
other ways to support adapted bit-rate to participants, such as rate per sender of a media stream, observed at a receiver-chosen
partitioning the session in different quality tiers, or use some protocol layer, which the receiver currently supports in this RTP
other method of achieving bit-rate scalability. session. The second value is the measured header overhead in bytes
as defined in section 2.2 and measured at the chosen protocol layer
in the packets received for the stream. The measurement of the
overhead is a running average that is updated for each packet
received for this particular media source (SSRC), using the following
formula:
avg_OH (new) = 15/16*avg_OH (old) + 1/16*pckt_OH,
where avg_OH is the running (exponentially smoothed) average and
pckt_OH is the overhead observed in the latest packet.
If a maximum bit rate has been negotiated through signaling, the
maximum total media bit rate that the receiver reports in a TMMBR
message MUST NOT exceed the negotiated value converted to a common
basis (i.e. with overheads adjusted to bring it to the same reference
protocol layer).
Within the common packet header for feedback messages (as defined in
section 6.1 of [RFC4585]), the "SSRC of the packet sender" field
indicates the source of the request, and the "SSRC of media source"
is not used and SHALL be set to 0. Within a particular TMMBR FCI
entry, the "SSRC of media sender" in the FCI field denotes the media
sender the tuple applies to. This is useful in the multicast or
translator topologies where the reporting entity may address all of
the media senders in a single TMMBR message using multiple FCI
entries.
The media receiver SHALL save the contents of the latest TMMBN
message received from each media sender.
The media receiver MAY send a TMMBR FCI entry to a particular media
sender under the following circumstances:
o before any TMMBN message has been received from that media
sender;
o when the media receiver has been identified as the source of a
bounding tuple within the latest TMMBN message received from
that media sender, and the value of the maximum total media
bit rate or the overhead relating to that media sender has
changed;
o when the media receiver has not been identified as the source
of a bounding tuple within the latest TMMBN message received
from that media sender, and, after the media receiver applies
the incremental algorithm from section 3.5.4.2 or a stricter
equivalent, the media receiver's tuple relating to that media
sender is determined to belong to the bounding set.
A TMMBR FCI entry MAY be repeated in subsequent TMMBR messages if no
Temporary Maximum Media Stream Bit-Rate Notification (TMMBN) FCI has
been received from the media sender at the time of transmission of
the next RTCP packet. The bit rate value of a TMMBR FCI entry MAY be
changed from one TMMBR message to the next. The overhead measurement
SHALL be updated to the current value of avg_OH each time the entry
is sent.
If the value set by a TMMBR message is expected to be permanent, the If the value set by a TMMBR message is expected to be permanent, the
TMMBR setting party is RECOMMENDED to renegotiate the session TMMBR setting party SHOULD renegotiate the session parameters to
parameters to reflect that using session setup signaling, e.g. a SIP reflect that using session setup signaling, e.g. a SIP re-invite.
re-invite.
An SSRC may time out according to the default rules for RTP session Behaviour at the Media Sender (Receiver of the TMMBR)
participants, i.e. the media sender has not received any RTCP packet
from the owner for the last five regular reporting intervals. An SSRC
may also leave the session, indicating this through the transmission
of an RTCP BYE packet or an external signaling channel. In all of
these cases the entity is considered to have left the session. In the
case the "owner" leaves the session, the limit SHALL be removed and
the transmission of a TMMBN is scheduled indicating the remaining
limitations.
4.2.1.2. Message Format When it receives a TMMBR message containing an FCI entry relating to
it, the media sender SHALL use an initial or incremental algorithm as
applicable to determine the bounding set of tuples based on the new
information. The algorithm used SHALL be at least as strict as the
corresponding algorithm defined in section 3.5.4.2. The media sender
MAY accumulate TMMBR requests over a small interval (relative to the
RTCP sending interval) before making this calculation.
The Feedback Control Information (FCI) consists of one or more TMMBR Once it has determined the bounding set of tuples, the media sender
FCI entries with the following syntax: MAY use any combination of packet rate and net media bit rate within
the feasible region that these tuples describe to produce a lower
total media stream bit rate, as it may need to address a congestion
situation or other limiting factors. See section 5 (congestion
control) for more discussion.
0 1 2 3 If the media sender concludes that it can increase the maximum total
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 media bit rate value, it SHALL wait before actually doing so, for a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ period long enough to allow a media receiver to respond to the TMMBN
| SSRC | if it determines that its tuple belongs in the bounding set. This
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ delay period is estimated by the formula:
| MMBR Exp | MMBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Syntax for the TMMBR message 2 * RTT + T_Dither_Max,
SSRC: The SSRC value of the media sender that is requested to
obey the new maximum bit-rate).
MMBR Exp (6 bits): The exponential scaling of the mantissa for the
Maximum Media Stream bit-rate value. The value is non
signed integer [0..63].
MMBR Mantissa (17 bits): The mantissa of the Maximum Media Stream where RTT is the longest round trip time known to the media sender
Bit-rate value as a non-signed integer. and T_Dither_Max is defined in section 3.4 of [RFC4585].
Measured Overhead (9 bits): The measured average packet overhead A TMMBN message SHALL be sent by the media sender at the earliest
value in bytes. The measurement SHALL be done according to possible point in time, in response to any TMMBR messages received
above description in Section 4.2.1.1. since the last sending of TMMBN. The TMMBN message indicates the
calculated set of bounding tuples and the owners of those tuples at
the time of the transmission of the message.
The maximum media stream bit-rate (MMBR) value in bits per second is An SSRC may time out according to the default rules for RTP session
calculated from the MMBR exponent (exp) and mantissa in the following participants, i.e. the media sender has not received any RTP or RTCP
way: packets from the owner for the last five regular reporting intervals.
An SSRC may also explicitly leave the session, with the participant
indicating this through the transmission of an RTCP BYE packet or
using an external signaling channel. If the media sender determines
that the owner of a tuple in the bounding set has left the session,
the media sender shall transmit a new TMMBN containing the
previously-determined set of bounding tuples but with the tuple
belonging to the departed owner removed.
MMBR = mantissa * 2^exp Discussion
This allows for 17 bits of resolution in the range 0 to 131072*2^63 Due to the unreliable nature of transport of TMMBR and TMMBN, the
(approximately 1.2*10^24). above rules may lead to the sending of TMMBR messages which appear to
disobey those rules. Furthermore, in multicast scenarios it can
happen that more than one "non-owning" session participant may
determine, rightly or wrongly, that its tuple belongs in the bounding
set. This is not critical for a number of reasons:
The length of the FB message is be set to 2+2*N where N is the number a) If a TMMBR message is lost in transmission, either the media
of TMMBR FCI entries. sender sends a new TMMBN message in response to some other media
receiver or it does not send a new TMMBN message at all. In the
first case, the media receiver applies the incremental algorithm
and, if it determines that its tuple should be part of the
bounding set, sends out another TMMBR. In the second case, it
repeats the sending of a TMMBR unconditionally. Either way, the
media sender eventually gets the information it needs.
b) Similarly, if a TMMBN message gets lost, the media receiver that
has sent the corresponding TMMBR request does not receive the
notification and is expected to re-send the request and trigger
the transmission of another TMMBN.
c) If multiple competing TMMBR messages are sent by different session
participants, then the algorithm can be applied taking all of
these messages into account, and the resulting TMMBN provides the
participants with an updated view of how their tuples compare with
the bounded set.
d) If more than one session participant happens to send TMMBR
messages at the same time and with the same tuple component
values, it does not matter which if either tuple is taken into the
bounding set. The losing session participant will determine after
applying the algorithm that its tuple does not enter the bounding
set, and will therefore stop sending its TMMBR request.
It is important to consider the security risks involved with faked
TMMBRs. See the security considerations in Section 6.
As indicated already, the feedback messages may be used in both
multicast and unicast sessions in any of the specified topologies.
However, for sessions with a large number of participants, using the
lowest common denominator, as required by this mechanism, may not be
the most suitable course of action. Large sessions may need to
consider other ways to adapt the bit rate to participants'
capabilities, such as partitioning the session into different quality
tiers, or using some other method of achieving bit rate scalability.
4.2.1.3. Timing Rules 4.2.1.3. Timing Rules
The first transmission of the request message MAY use early or The first transmission of the TMMBR request message MAY use early or
immediate feedback in cases when timeliness is desirable. Any immediate feedback in cases when timeliness is desirable. Any
repetition of a request message SHOULD use regular RTCP mode for its repetition of a request message SHOULD use regular RTCP mode for its
transmission timing. transmission timing.
4.2.1.4. Handling in Translator and Mixers 4.2.1.4. Handling in Translator and Mixers
Media Translators and Mixers will need to receive and respond to Media translators and mixers will need to receive and respond to
TMMBR messages as they are part of the chain that provides a certain TMMBR messages as they are part of the chain that provides a certain
media stream to the receiver. The mixer or translator may act locally media stream to the receiver. The mixer or translator may act
on the TMMBR request and thus generate a TMMBN to indicate that it locally on the TMMBR request and thus generate a TMMBN to indicate
has done so. Alternatively it can forward the request in the case of that it has done so. Alternatively, in the case of a media
a media translator, or generate one of itself in the case of the translator it can forward the request, or in the case of a mixer
mixer. In case it generates a TMMBR, it will need to send a TMMBN generate one of its own and pass it forward. In the latter case, the
back to the original requestor to indicate that it is handling the mixer will need to send a TMMBN back to the original requestor to
request. indicate that it is handling the request.
4.2.2. Temporary Maximum Media Stream Bit-rate Notification (TMMBN) 4.2.2. Temporary Maximum Media Stream Bit Rate Notification (TMMBN)
The FCI field of the TMMBN Feedback message may contain zero, one or The FCI field of the TMMBN Feedback message may contain zero, one or
more TMMBN FCI entry. more TMMBN FCI entries.
4.2.2.1. Semantics
This feedback message is used to notify the senders of any TMMBR
message that one or more TMMBR messages have been received or that a
owner has left the session. It indicates to all participants the set
of currently employed limitations and the ''owners'' of those.
The ''SSRC of the packet sender'' field indicates the source of the
notification. The ''SSRC of media source'' is not used and SHALL be
set to 0.
A TMMBN message SHALL be scheduled for transmission after the
reception of a TMMBR message with a FCI identifying this media
sender. Only a single TMMBN SHALL be sent, even if more than one
TMMBR messages are received between the scheduling of the
transmission and the actual transmission of the TMMBN message. The
TMMBN message indicates the limits and their owners at the time of
transmitting the message. The limits included SHALL be the set of
most restrictive values in the previously established set and
received TMMBR messages since the last TMMBN was transmitted.
The reception of a TMMBR message with a transmission limit equally or
less restrictive than the set of current limits SHALL still result in
the transmission of a TMMBN message. However the limits and their
owners are not changed, unless it was from an owner of a limit within
the current set of limitations. This procedure allows session
participants that haven't seen the last TMMBN message to get a
correct view of this media sender's state.
When a media sender determines an ''owner'' of a limitation has left
the session, then that limitation is removed, and the media sender
SHALL send a TMMBN message indicating the remaining limitations. In
case there are no remaining limitations a TMMBN without any FCI SHALL
be sent to indicate this.
In unicast scenarios (i.e. where a single sender talks to a single
receiver), the aforementioned algorithm to determine ownership
degenerates to the media receiver becoming the ''owner'' as soon as
the media receiver has issued the first TMMBR message.
4.2.2.2. Message Format 4.2.2.1. Message Format
The Feedback Control Information (FCI) consists of zero, one or more The Feedback Control Information (FCI) consists of zero, one or more
TMMBN FCI entries with the following syntax: TMMBN FCI entries with the following syntax:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC | | SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MMBR Exp | MMBR Mantissa |Measured Overhead| | MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Syntax for the TMMBR message Figure 3 - Syntax of an FCI entry in the TMMBN message
SSRC: The SSRC value of the ''owner'' of this limitation. SSRC (32 bits): The SSRC value of the "owner" of this tuple.
MMBR Exp (6 bits): The exponential scaling of the mantissa for the MxTBR Exp (6 bits): The exponential scaling of the mantissa for the
Maximum Media Stream bit-rate value. The value is non- maximum total media bit rate value. The value is an
signed integer [0..63]. unsigned integer [0..63].
MMBR Mantissa (17 bits): The mantissa of the Maximum Media Stream MxTBR Mantissa (17 bits): The mantissa of the maximum total media
Bit-rate value as non-signed integer. bit rate value as an unsigned integer.
Measured Overhead (9 bits): The measured average packet overhead Measured Overhead (9 bits): The measured average packet overhead
value in bytes represented as non-signed integer. value in bytes represented as an unsigned integer.
Thus the FCI contains blocks indicating the applicable limitations as Thus the FCI within the TMMBN message contains entries indicating the
the owner followed by the applicable maximum media stream bit-rate bounding tuples. For each tuple, the entry gives the owner by the
and overhead value. SSRC, followed by the applicable maximum total media bit rate and
overhead value.
The length of the FB message is be set to 2+2*N where N is the number The length of the TMMBN message SHALL be set to 2+2*N where N is the
of TMMBR FCI entries. number of TMMBN FCI entries.
4.2.2.2. Semantics
This feedback message is used to notify the senders of any TMMBR
message that one or more TMMBR messages have been received or that an
owner has left the session. It indicates to all participants the
current set of bounding tuples and the "owners" of those tuples.
Within the common packet header for feedback messages (as defined in
section 6.1 of [RFC4585]), the "SSRC of the packet sender" field
indicates the source of the notification. The "SSRC of media source"
is not used and SHALL be set to 0.
A TMMBN message SHALL be scheduled for transmission after the
reception of a TMMBR message with an FCI entry identifying this media
sender. Only a single TMMBN SHALL be sent, even if more than one
TMMBR message is received between the scheduling of the transmission
and the actual transmission of the TMMBN message. The TMMBN message
indicates the bounding tuples and their owners at the time of
transmitting the message. The bounding tuples included SHALL be the
set arrived at through application of the applicable algorithm of
section 3.5.4.2 or an equivalent, applied to the previous bounding
set if any and tuples received in TMMBR messages since the last TMMBN
was transmitted.
The reception of a TMMBR message SHALL still result in the
transmission of a TMMBN message even if, after application of the
algorithm, the newly reported TMMBR tuple is not accepted into the
bounding set. In such a case the bounding tuples and their owners
are not changed, unless the TMMBR was from an owner of a tuple within
the previously calculated bounding set. This procedure allows
session participants that did not see the last TMMBN message to get a
correct view of this media sender's state.
As indicated in section Error! Reference source not found., when a
media sender determines that an "owner" of a bounding tuple has left
the session, then that tuple is removed from the bounding set, and
the media sender SHALL send a TMMBN message indicating the remaining
bounding tuples. If there are no remaining bounding tuples a TMMBN
without any FCI SHALL be sent to indicate this.
Note: if any media receivers remain in the session, this last will
be a temporary situation. The empty TMMBN will cause every
remaining media receiver to determine that its limitation belongs
in the bounding set and send a TMMBR in consequence.
In unicast scenarios (i.e. where a single sender talks to a single
receiver), the aforementioned algorithm to determine ownership
degenerates to the media receiver becoming the "owner" of the one
bounding tuple as soon as the media receiver has issued the first
TMMBR message.
4.2.2.3. Timing Rules 4.2.2.3. Timing Rules
The acknowledgement SHOULD be sent as soon as allowed by the applied The TMMBN acknowledgement SHOULD be sent as soon as allowed by the
timing rules for the session. Immediate or early feedback mode SHOULD applied timing rules for the session. Immediate or early feedback
be used for these messages. mode SHOULD be used for these messages.
4.2.2.4. Handling by Translators and Mixers 4.2.2.4. Handling by Translators and Mixers
As discussed in Section 4.2.1.4 mixer or translators may need to As discussed in Section 4.2.1.4 mixers or translators may need to
issue TMMBN messages as response to TMMBR messages handled by the issue TMMBN messages as responses to TMMBR messages for SSRC's
mixer or translator. handled by them.
4.3. Payload Specific Feedback Messages 4.3. Payload Specific Feedback Messages
Payload-Specific FB messages are identified by the value PT=PSFB As specified by section 6.1 of RFC 4585 [RFC4585], Payload-Specific
(206) as RTCP packet type (see section 6.1 of RFC 4585 [RFC4585]). FB messages are identified by the RTCP packet type value PT=PSFB
(206).
AVPF defines three payload-specific FB messages and one application AVPF [RFC4585] defines three payload-specific feedback messages and
layer FB message. This memo specifies four additional payload- one application layer feedback message. This memo specifies four
specific feedback messages. All are identified by means of the FMT additional payload-specific feedback messages. All are identified by
parameter as follows: means of the FMT parameter as follows:
Assigned in [RFC4585]:
0: unassigned
1: Picture Loss Indication (PLI) 1: Picture Loss Indication (PLI)
2: Slice Lost Indication (SLI) 2: Slice Lost Indication (SLI)
3: Reference Picture Selection Indication (RPSI) 3: Reference Picture Selection Indication (RPSI)
15: Application layer FB message
31: reserved for future expansion of the number space
Assigned in this memo:
4: Full Intra Request Command (FIR) 4: Full Intra Request Command (FIR)
5: Temporal-Spatial Trade-off Request (TSTR) 5: Temporal-Spatial Trade-off Request (TSTR)
6: Temporal-Spatial Trade-off Notification (TSTN) 6: Temporal-Spatial Trade-off Notification (TSTN)
7: Video Back Channel Message (VBCM) 7: Video Back Channel Message (VBCM)
Unassigned:
0: unassigned
8-14: unassigned 8-14: unassigned
15: Application layer FB message
16-30: unassigned 16-30: unassigned
31: reserved for future expansion of the number space
The following subsections define the new FCI formats for the payload- The following subsections define the new FCI formats for the payload-
specific FB messages. specific feedback messages.
4.3.1. Full Intra Request (FIR) 4.3.1. Full Intra Request (FIR)
The FIR message is identified by PT=PSFB and FMT=4. The FIR message is identified by RTCP packet type value PT=PSFB and
FMT=4.
There MUST be one or more FIR entry contained in the FCI field. The FCI field MUST contain one or more FIR entries. Each entry
applies to a different media sender, identified by its SSRC.
4.3.1.1. Semantics 4.3.1.1. Message Format
Upon reception of FIR, the encoder MUST send a Decoder Refresh Point The Feedback Control Information (FCI) for the Full Intra Request
(see Section 2 ..2) as soon as possible. consists of one or more FCI entries, the content of which is depicted
in Figure 4. The length of the FIR feedback message MUST be set to
2+2*N, where N is the number of FCI entries.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq. nr | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - Syntax of an FCI entry in the FIR message
SSRC (32 bits): The SSRC value of the media sender which is
requested to send a decoder refresh point.
Seq. nr (8 bits): Command sequence number. The sequence number
space is unique for each pairing of the SSRC of command
source and the SSRC of the command target. The sequence
number SHALL be increased by 1 modulo 256 for each new
command. A repetition SHALL NOT increase the sequence
number. The initial value is arbitrary.
Reserved (24 bits): All bits SHALL be set to 0 by the sender and
SHALL be ignored on reception.
The semantics of this feedback message is independent of the RTP
payload type.
4.3.1.2. Semantics
Upon reception of FIR, the encoder MUST send a decoder refresh point
(see section 2.2) as soon as possible.
Note: Currently, video appears to be the only useful application Note: Currently, video appears to be the only useful application
for FIR, as it appears to be the only RTP payloads widely deployed for FIR, as it appears to be the only RTP payload widely deployed
that relies heavily on media prediction across RTP packet that relies heavily on media prediction across RTP packet
boundaries. However, use of FIR could also reasonably be boundaries. However, use of FIR could also reasonably be
envisioned for other media types that share essential properties envisioned for other media types that share essential properties
with compressed video, namely cross-frame prediction (whatever a with compressed video, namely cross-frame prediction (whatever a
frame may be for that media type). One possible example may be the frame may be for that media type). One possible example may be the
dynamic updates of MPEG-4 scene descriptions. It is suggested that dynamic updates of MPEG-4 scene descriptions. It is suggested that
payload formats for such media types refer to FIR and other message payload formats for such media types refer to FIR and other message
types defined in this specification and in AVPF, instead of types defined in this specification and in AVPF [RFC4585], instead
creating similar mechanisms in the payload specifications. The of creating similar mechanisms in the payload specifications. The
payload specifications may have to explain how the payload-specific payload specifications may have to explain how the payload-specific
terminologies map to the video-centric terminology used herein. terminologies map to the video-centric terminology used herein.
Note: In environments where the sender has no control over the Note: In environments where the sender has no control over the
codec (e.g. when streaming pre-recorded and pre-coded content), the codec (e.g. when streaming pre-recorded and pre-coded content), the
reaction to this command cannot be specified. One suitable reaction to this command cannot be specified. One suitable
reaction of a sender would be to skip forward in the video bit reaction of a sender would be to skip forward in the video bit
stream to the next decoder refresh point. In other scenarios, it stream to the next decoder refresh point. In other scenarios, it
may be preferable not to react to the command at all, e.g. when may be preferable not to react to the command at all, e.g. when
streaming to a large multicast group. Other reactions may also be streaming to a large multicast group. Other reactions may also be
possible. When deciding on a strategy, a sender could take into possible. When deciding on a strategy, a sender could take into
account factors such as the size of the receiving group, the account factors such as the size of the receiving group, the
''importance'' of the sender of the FIR message (however "importance" of the sender of the FIR message (however "importance"
''importance'' may be defined in this specific application), the may be defined in this specific application), the frequency of
frequency of Decoder Refresh Points in the content, and others. decoder refresh points in the content, and so on. However a
However a session which predominately handles pre-coded content is session which predominately handles pre-coded content is not
not expected to use FIR at all. expected to use FIR at all.
The sender MUST consider congestion control as outlined in section 5 ., The sender MUST consider congestion control as outlined in
which MAY restrict its ability to send a decoder refresh point section 5., which MAY restrict its ability to send a decoder refresh
quickly. point quickly.
Note: The relationship between the Picture Loss Indication and FIR Note: The relationship between the Picture Loss Indication and FIR
is as follows. As discussed in section 6.3.1 of AVPF, a Picture is as follows. As discussed in section 6.3.1 of AVPF [RFC4585], a
Loss Indication informs the decoder about the loss of a picture and Picture Loss Indication informs the decoder about the loss of a
hence the likeliness of misalignment of the reference pictures in picture and hence the likelihood of misalignment of the reference
the encoder and decoder. Such a scenario is normally related to pictures between the encoder and decoder. Such a scenario is
losses in an ongoing connection. In point-to-point scenarios, and normally related to losses in an ongoing connection. In point-to-
without the presence of advanced error resilience tools, one point scenarios, and without the presence of advanced error
possible option of an encoder consists in sending a Decoder Refresh resilience tools, one possible option for an encoder consists in
Point. However, there are other options. One example is that the sending a decoder refresh point. However, there are other options.
media sender ignores the PLI, because the embedded stream One example is that the media sender ignores the PLI, because the
redundancy is likely to clean up the reproduced picture within a embedded stream redundancy is likely to clean up the reproduced
reasonable amount of time. The FIR, in contrast, leaves a (real- picture within a reasonable amount of time. The FIR, in contrast,
time) encoder no choice but to send a Decoder Refresh Point. It leaves a (real-time) encoder no choice but to send a decoder
disallows the encoder to take into account any considerations such refresh point. It does not allow the encoder to take into account
as the ones mentioned above. any considerations such as the ones mentioned above.
Note: Mandating a maximum delay for completing the sending of a Note: Mandating a maximum delay for completing the sending of a
Decoder Refresh Point would be desirable from an application decoder refresh point would be desirable from an application
viewpoint, but may be problematic from a congestion control point viewpoint, but is problematic from a congestion control point of
of view. ''As soon as possible'' as mentioned above appears to be view. "As soon as possible" as mentioned above appears to be a
a reasonable compromise. reasonable compromise.
FIR SHALL NOT be sent as a reaction to picture losses -- it is FIR SHALL NOT be sent as a reaction to picture losses -- it is
RECOMMENDED to use PLI instead. FIR SHOULD be used only in such RECOMMENDED to use PLI instead. FIR SHOULD be used only in
situations where not sending a decoder refresh point would render the situations where not sending a decoder refresh point would render the
video unusable for the users. video unusable for the users.
Note: A typical example where sending FIR is appropriate is when, Note: A typical example where sending FIR is appropriate is when,
in a multipoint conference, a new user joins the session and no in a multipoint conference, a new user joins the session and no
regular Decoder Refresh Point interval is established. Another regular decoder refresh point interval is established. Another
example would be a video switching MCU that changes streams. Here, example would be a video switching MCU that changes streams. Here,
normally, the MCU issues a FIR to the new sender so to force it to normally, the MCU issues a FIR to the new sender so to force it to
emit a Decoder Refresh Point. The Decoder Refresh Point includes emit a decoder refresh point. The decoder refresh point normally
normally a Freeze Picture Release (defined outside this includes a Freeze Picture Release (defined outside this
specification), which re-starts the rendering process of the specification), which re-starts the rendering process of the
receivers. Both techniques mentioned are commonly used in MCU- receivers. Both techniques mentioned are commonly used in MCU-
based multipoint conferences. based multipoint conferences.
Other RTP payload specifications such as RFC 2032 [RFC2032] already Other RTP payload specifications such as RFC 4587 [RFC4587] already
define a feedback mechanism for certain codecs. An application define a feedback mechanism for certain codecs. An application
supporting both schemes MUST use the feedback mechanism defined in supporting both schemes MUST use the feedback mechanism defined in
this specification when sending feedback. For backward compatibility this specification when sending feedback. For backward compatibility
reasons, such an application SHOULD also be capable to receive and reasons, such an application SHOULD also be capable to receive and
react to the feedback scheme defined in the respective RTP payload react to the feedback scheme defined in the respective RTP payload
format, if this is required by that payload format. format, if this is required by that payload format.
The ''SSRC of the packet sender'' field indicates the source of the Within the common packet header for feedback messages (as defined in
request, and the ''SSRC of media source'' is not used and SHALL be section 6.1 of [RFC4585]), the "SSRC of the packet sender" field
set to 0. The SSRC of media sender to which the FIR command applies indicates the source of the request, and the "SSRC of media source"
to is in the FCI. is not used and SHALL be set to 0. The SSRCs of the media senders to
which the FIR command applies are in the corresponding FCI entries.
4.3.1.2. Message Format A TSTR message MAY contain requests to multiple media senders, using
one FCI entry per target media sender.
Full Intra Request uses one additional FCI field, the content of
which is depicted in Figure 3 The length of the FB message MUST be
set to 2+2*N, where N is the number of FCI entries.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq. nr | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Syntax for the FIR message
SSRC: The SSRC value of the media sender which is requested to
send a Decoder Refresh Point.
Seq. nr: Command sequence number. The sequence number space is
unique for each tuple consisting of the SSRC of command
source and the SSRC of the command target. The sequence
number SHALL be increased by 1 modulo 256 for each new
command. A repetition SHALL NOT increase the sequence
number. Initial value is arbitrary.
Reserved: All bits SHALL be set to 0 and SHALL be ignored on
reception.
The semantics of this FB message is independent of the RTP payload
type.
4.3.1.3. Timing Rules 4.3.1.3. Timing Rules
The timing follows the rules outlined in section 3 of [RFC4585]. FIR The timing follows the rules outlined in section 3 of [RFC4585]. FIR
commands MAY be used with early or immediate feedback. The FIR commands MAY be used with early or immediate feedback. The FIR
feedback message MAY be repeated. If using immediate feedback mode feedback message MAY be repeated. If using immediate feedback mode
the repetition SHOULD wait at least one RTT before being sent. In the repetition SHOULD wait at least one RTT before being sent. In
early or regular RTCP mode the repetition is sent in the next regular early or regular RTCP mode the repetition is sent in the next regular
RTCP packet. RTCP packet.
4.3.1.4. Handling of message in Mixer and Translators 4.3.1.4. Handling of FIR Message in Mixer and Translators
A media translator or a mixer performing media encoding of the A media translator or a mixer performing media encoding of the
content for which the session participant has issued a FIR is content for which the session participant has issued a FIR is
responsible for acting upon it. A mixer acting upon a FIR SHOULD NOT responsible for acting upon it. A mixer acting upon a FIR SHOULD NOT
forward the message unaltered, instead it SHOULD issue a FIR itself. forward the message unaltered; instead it SHOULD issue a FIR itself.
4.3.1.5. Remarks 4.3.1.5. Remarks
In conjunction with video codecs, FIR messages typically trigger the In conjunction with video codecs, FIR messages typically trigger the
sending of full intra or IDR pictures. Both are several times larger sending of full intra or IDR pictures. Both are several times larger
then predicted (inter) pictures. Their size is independent of the then predicted (inter) pictures. Their size is independent of the
time they are generated. In most environments, especially when time they are generated. In most environments, especially when
employing bandwidth-limited links, the use of an intra picture employing bandwidth-limited links, the use of an intra picture
implies an allowed delay that is a significant multitude of the implies an allowed delay that is a significant multiple of the
typical frame duration. An example: If the sending frame rate is 10 typical frame duration. An example: if the sending frame rate is 10
fps, and an intra picture is assumed to be 10 times as big as an fps, and an intra picture is assumed to be 10 times as big as an
inter picture, then a full second of latency has to be accepted. In inter picture, then a full second of latency has to be accepted. In
such an environment there is no need for a particularly short delay such an environment there is no need for a particularly short delay
in sending the FIR message. Hence waiting for the next possible time in sending the FIR message. Hence waiting for the next possible time
slot allowed by RTCP timing rules as per [RFC4585] may not have an slot allowed by RTCP timing rules as per [RFC4585] should not have an
overly negative impact on the system performance. overly negative impact on the system performance.
4.3.2. Temporal-Spatial Trade-off Request (TSTR) 4.3.2. Temporal-Spatial Trade-off Request (TSTR)
The TSTR FB message is identified by PT=PSFB and FMT=5. The TSTR feedback message is identified by RTCP packet type value
PT=PSFB and FMT=5.
There MUST be one or more TSTR entry contained in the FCI field.
4.3.2.1. Semantics
A decoder can suggest the use of a temporal-spatial trade-off by
sending a TSTR message to an encoder. If the encoder is capable of
adjusting its temporal-spatial trade-off, it SHOULD take into account
the received TSTR message for future coding of pictures. A value of
0 suggests a high spatial quality and a value of 31 suggests a high
frame rate. The values from 0 to 31 indicate monotonically a desire
for higher frame rate. Actual values do not correspond to precise
values of spatial quality or frame rate.
The reaction to the reception of more than one TSTR message by a
media sender from different media receivers is left open to the
implementation. The selected trade-off SHALL be communicated to the
media receivers by the means of the TSTN message.
The ''SSRC of the packet sender'' field indicates the source of the
request, and the ''SSRC of media source'' is not used and SHALL be
set to 0. The SSRC of media sender to which the TSTR applies to is in
the FCI entries.
A TSTR message may contain multiple requests to different media The FCI field MUST contain one or more TSTR FCI entries.
senders, using multiple FCI entries.
4.3.2.2. Message Format 4.3.2.1. Message Format
The Temporal-Spatial Trade-off Request uses one FCI field, the The content of the FCI entry for the Temporal-Spatial Trade-off
content of which is depicted in Figure 4. The length of the FB Request is depicted in Figure 5. The length of the feedback message
message MUST be set to 2+2*N, where N is the number of FCI entries MUST be set to 2+2*N, where N is the number of FCI entries included.
included.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC | | SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved | Index | | Seq nr. | Reserved | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - Syntax of the TSTR Figure 5 - Syntax of an FCI Entry in the TSTR Message
SSRC: The SSRC of the media sender which is requested to apply SSRC (32 bits): The SSRC of the media sender which is requested to
the tradeoff value in Index. apply the tradeoff value given in Index.
Seq. nr: Request sequence number. The sequence number space is Seq. nr (8 bits): Request sequence number. The sequence number
unique for each tuple consisting of the SSRC of request space is unique for pairing of the SSRC of request source
source and the SSRC of the request target. The sequence and the SSRC of the request target. The sequence number
number SHALL be increased by 1 modulo 256 for each new SHALL be increased by 1 modulo 256 for each new command.
command. A repetition SHALL NOT increase the sequence A repetition SHALL NOT increase the sequence number. The
number. Initial value is arbitrary. initial value is arbitrary.
Index: An integer value between 0 and 31 that indicates the Reserved (19 bits): All bits SHALL be set to 0 by the sender and
relative trade off that is requested. An index value of 0 SHALL be ignored on reception.
index highest possible spatial quality, while 31 indicates
highest possible temporal resolution.
Reserved: All bits SHALL be set to 0 and SHALL be ignored on Index (5 bits): An integer value between 0 and 31 that indicates
reception. the relative trade off that is requested. An index value
of 0 index highest possible spatial quality, while 31
indicates highest possible temporal resolution.
4.3.2.2. Semantics
A decoder can suggest a temporal-spatial trade-off level by sending a
TSTR message to an encoder. If the encoder is capable of adjusting
its temporal-spatial trade-off, it SHOULD take into account the
received TSTR message for future coding of pictures. A value of 0
suggests a high spatial quality and a value of 31 suggests a high
frame rate. The progression of values from 0 to 31 indicate
monotonically a desire for higher frame rate. The index values do
not correspond to precise values of spatial quality or frame rate.
The reaction to the reception of more than one TSTR message by a
media sender from different media receivers is left open to the
implementation. The selected trade-off SHALL be communicated to the
media receivers by the means of the TSTN message.
Within the common packet header for feedback messages (as defined in
section 6.1 of [RFC4585]), the "SSRC of the packet sender" field
indicates the source of the request, and the "SSRC of media source"
is not used and SHALL be set to 0. The SSRCs of the media senders to
which the TSTR applies to are in the corresponding FCI entries.
A TSTR message MAY contain requests to multiple media senders, using
one FCI entry per target media sender.
4.3.2.3. Timing Rules 4.3.2.3. Timing Rules
The timing follows the rules outlined in section 3 of [RFC4585]. The timing follows the rules outlined in section 3 of [RFC4585].
This request message is not time critical and SHOULD be sent using This request message is not time critical and SHOULD be sent using
regular RTCP timing. Only if it is known that the user interface regular RTCP timing. Only if it is known that the user interface
requires a quick feedback, the message MAY be sent with early or requires a quick feedback, the message MAY be sent with early or
immediate feedback timing. immediate feedback timing.
4.3.2.4. Handling of message in Mixers and Translators 4.3.2.4. Handling of message in Mixers and Translators
Mixer or Media translators that encodes content sent to the session A mixer or media translator that encodes content sent to the session
participant issuing the TSTR SHALL consider the request to determine participant issuing the TSTR SHALL consider the request to determine
if it can fulfill it by changing its own encoding parameters. A media if it can fulfill it by changing its own encoding parameters. A
translator unable to fulfill the request MAY forward the request media translator unable to fulfill the request MAY forward the
unaltered towards the media sender. A Mixer encoding for multiple request unaltered towards the media sender. A mixer encoding for
session participants will need to consider the joint needs before multiple session participants will need to consider the joint needs
generating a TSTR for itself towards the media sender. See also of these participants before generating a TSTR on its own behalf
discussion in Section . 3.5.2. towards the media sender. See also the discussion in Section 3.5.2.
4.3.2.5. Remarks 4.3.2.5. Remarks
The term "spatial quality" does not necessarily refer to the The term "spatial quality" does not necessarily refer to the
resolution, measured by the number of pixels the reconstructed video resolution, measured by the number of pixels the reconstructed video
is using. In fact, in most scenarios the video resolution stays is using. In fact, in most scenarios the video resolution stays
constant during the lifetime of a session. However, all video constant during the lifetime of a session. However, all video
compression standards have means to adjust the spatial quality at a compression standards have means to adjust the spatial quality at a
given resolution, often influenced by the Quantizer Parameter or QP. given resolution, often influenced by the Quantizer Parameter or QP.
A numerically low QP results in a good reconstructed picture quality, A numerically low QP results in a good reconstructed picture quality,
whereas a numerically high QP yields a coarse picture. The typical whereas a numerically high QP yields a coarse picture. The typical
reaction of an encoder to this request is to change its rate control reaction of an encoder to this request is to change its rate control
parameters to use a lower frame rate and a numerically lower (on parameters to use a lower frame rate and a numerically lower (on
average) QP, or vice versa. The precise mapping of Index, frame average) QP, or vice versa. The precise mapping of Index value to
rate, and QP is intentionally left open here, as it depends on frame rate and QP is intentionally left open here, as it depends on
factors such as compression standard employed, spatial resolution, factors such as the compression standard employed, spatial
content, bit rate, and many more. resolution, content, bit rate, and so on.
4.3.3. Temporal-Spatial Trade-off Notification (TSTN) 4.3.3. Temporal-Spatial Trade-off Notification (TSTN)
The TSTN message is identified by PT=PSFB and FMT=6. The TSTN message is identified by RTCP packet type value PT=PSFB and
FMT=6.
There SHALL be one or more TSTN contained in the FCI field.
4.3.3.1. Semantics
This feedback message is used to acknowledge the reception of a TSTR.
A TSTN entry in a TSTN feedback message SHALL be sent for each TSTR
entry targeted to this session participant, i.e. each TSTR received
that in the SSRC field in the entry has the receiving entities SSRC.
A single TSTN message MAY acknowledge multiple requests using
multiple FCI entries. The index value included SHALL be the same in
all FCI's part of the TSTN message. Including a FCI for each
requestor allows each requesting entity to determine that the media
sender targeted have received the request. The Notification SHALL be
sent also for repetitions received. If the request receiver has
received TSTR with several different sequence numbers from a single
requestor it SHALL only respond to the request with the highest
(modulo 256) sequence number.
The TSTN SHALL include the Temporal-Spatial Trade-off index that will
be used as a result of the request. This is not necessarily the same
index as requested, as media sender may need to aggregate requests
from several requesting session participants. It may also have some
other policies or rules that limit the selection.
The ''SSRC of the packet sender'' field indicates the source of the The FCI field SHALL contain one or more TSTN FCI entries.
Notification, and the ''SSRC of media source'' is not used and SHALL
be set to 0. The SSRC of the requesting entity to which the
Notification applies to is in the FCI.
4.3.3.2. Message Format 4.3.3.1. Message Format
The Temporal-Spatial Trade-off Notification uses one additional FCI The content of an FCI entry for the Temporal-Spatial Trade-off
field, the content of which is depicted in Figure 5. The length of Notification is depicted in Figure 6. The length of the TSTN message
the FB message MUST be set to 2+2*N, where N is the number of FCI MUST be set to 2+2*N, where N is the number of FCI entries.
entries.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC | | SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved | Index | | Seq nr. | Reserved | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - Syntax of the TSTN Figure 6 - Syntax of the TSTN
SSRC: The SSRC of the source of the TSTR request which resulted SSRC (32 bits): The SSRC of the source of the TSTR request which
in this Notification. resulted in this Notification.
Seq. nr: The sequence number value from the TSTN request that is Seq. nr (8 bits): The sequence number value from the TSTN request
being acknowledged. that is being acknowledged.
Index: The trade-off value the media sender is using henceforth. Reserved (19 bits): All bits SHALL be set to 0 by the sender and
SHALL be ignored on reception.
Reserved: All bits SHALL be set to 0 and SHALL be ignored on Index (5 bits): The trade-off value the media sender is using
reception. henceforth.
Informative note: The returned trade-off value (Index) may differ Informative note: The returned trade-off value (Index) may differ
from the requested one, for example in cases where a media encoder from the requested one, for example in cases where a media encoder
cannot tune its trade-off, or when pre-recorded content is used. cannot tune its trade-off, or when pre-recorded content is used.
4.3.3.2. Semantics
This feedback message is used to acknowledge the reception of a TSTR.
One TSTN entry in a TSTN feedback message SHALL be sent for each TSTR
entry targeted to this session participant, i.e. each TSTR received
that in the SSRC field in the entry has the receiving entities SSRC.
A single TSTN message MAY acknowledge multiple requests using
multiple FCI entries. The index value included SHALL be the same in
all FCI entries of the TSTN message. Including a FCI for each
requestor allows each requesting entity to determine that the media
sender received the request. The Notification SHALL also be sent in
response to TSTR repetitions received. If the request receiver has
received TSTR with several different sequence numbers from a single
requestor it SHALL only respond to the request with the highest
(modulo 256) sequence number.
The TSTN SHALL include the Temporal-Spatial Trade-off index that will
be used as a result of the request. This is not necessarily the same
index as requested, as the media sender may need to aggregate
requests from several requesting session participants. It may also
have some other policies or rules that limit the selection.
Within the common packet header for feedback messages (as defined in
section 6.1 of [RFC4585]), the "SSRC of the packet sender" field
indicates the source of the Notification, and the "SSRC of media
source" is not used and SHALL be set to 0. The SSRCs of the
requesting entities to which the Notification applies are in the
corresponding FCI entries.
4.3.3.3. Timing Rules 4.3.3.3. Timing Rules
The timing follows the rules outlined in section 3 of [RFC4585]. The timing follows the rules outlined in section 3 of [RFC4585].
This acknowledgement message is not extremely time critical and This acknowledgement message is not extremely time critical and
SHOULD be sent using regular RTCP timing. SHOULD be sent using regular RTCP timing.
4.3.3.4. Handling of message in Mixer and Translators 4.3.3.4. Handling of TSTN in Mixer and Translators
A Mixer or Translator that act upon a TSTR SHALL also send the A mixer or translator that acts upon a TSTR SHALL also send the
corresponding TSTN. In cases it needs to forward a TSTR itself the corresponding TSTN. In cases where it needs to forward a TSTR itself
notification message MAY need to be delayed until that request has the notification message MAY need to be delayed until the TSTR has
been responded to. been responded to.
4.3.3.5. Remarks 4.3.3.5. Remarks
None None
4.3.4. H.271 Video Back Channel Message (VBCM) 4.3.4. H.271 Video Back Channel Message (VBCM)
The VBCM is identified by PT=PSFB and FMT=7. The VBCM is identified by RTCP packet type value PT=PSFB and FMT=7.
There MUST be one or more VBCM entry contained in the FCI field. The FCI field MUST contain one or more VBCM FCI entries.
4.3.4.1. Semantics 4.3.4.1. Message Format
The "payload" of VBCM indication carries codec-specific, different The syntax of an FCI entry within the VBCM indication is depicted in
types of feedback information. The type of feedback information can Figure 7.
be classified as a 'status report' (such as receiving bit stream
without errors, or loss of a partial or complete picture or block) or 0 1 2 3
'update requests' (such as complete refresh of the bit stream). 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq. nr |0| Payload Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VBCM Octet String.... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 - Syntax of an FCI Entry in the VBCM Message
SSRC (32 bits): The SSRC value of the media sender that is requested
to instruct its encoder to react to the VBCM message
Seq. nr (8 bits): Command sequence number. The sequence number space
is unique for pairing of the SSRC of command source and the
SSRC of the command target. The sequence number SHALL be
increased by 1 modulo 256 for each new command. A repetition
SHALL NOT increase the sequence number. The initial value is
arbitrary.
0: Must be set to 0 by the sender and should not be acted upon by the
message receiver.
Payload Type (7 bits): The RTP payload type for which the VBCM bit
stream must be interpreted.
Length (16 bits): The length of the VBCM octet string in octets
exclusive of any padding octets
VBCM Octet String (Variable length): This is the octet string
generated by the decoder carrying a specific feedback sub-
message.
Padding (Variable length): Bits set to 0 to make up a 32 bit
boundary.
4.3.4.2. Semantics
The "payload" of the VBCM indication carries different types of
codec-specific, feedback information. The type of feedback
information can be classified as a 'status report' (such as an
indication that a bit stream was received without errors, or that a
partial or complete picture or block was lost) or 'update requests'
(such as complete refresh of the bit stream).
Note: There are possible overlaps between the VBCM sub- Note: There are possible overlaps between the VBCM sub-
messages and CCM/AVPF feedback messages, such FIR. Please see messages and CCM/AVPF feedback messages, such FIR. Please see
section 3 ..5.3 for further discussions. section 3.5.3 for further discussion.
The different types of feedback sub-messages carried in the VBCM are The different types of feedback sub-messages carried in the VBCM are
indicated by the ''payloadType'' as defined in [VBCM]. The different indicated by the "payloadType" as defined in [VBCM]. These sub-
sub-message types as defined in [VBCM] are re-produced below for message types are reproduced below for convenience. "payloadType",
convenience. ''payloadType'', in ITU-T Rec. H.271 terminology, in ITU-T Rec. H.271 terminology, refers to the sub-type of the H.271
refers to the sub-type of the H.271 message and should not be message and should not be confused with an RTP payload type.
confused with an RTP payload type.
Payload Type Message Content Payload Message Content
Type
--------------------------------------------------------------------- ---------------------------------------------------------------------
0 One or more pictures without detected bitstream error mismatch 0 One or more pictures without detected bit stream error
mismatch
1 One or more pictures that are entirely or partially lost 1 One or more pictures that are entirely or partially lost
2 A set of blocks of one picture that is entirely or partially 2 A set of blocks of one picture that is entirely or partially
lost lost
3 CRC for one parameter set 3 CRC for one parameter set
4 CRC for all parameter sets of a certain type 4 CRC for all parameter sets of a certain type
5 A "reset" request indicating that the sender should completely 5 A "reset" request indicating that the sender should completely
refresh the video bitstream as if no prior bitstream data had refresh the video bit stream as if no prior bit stream data
been received had been received
> 5 Reserved for future use by ITU-T > 5 Reserved for future use by ITU-T
Table 2: H.271 message types Table 2: H.271 message types ("payloadTypes")
The bit string or the "payload" of VBCM message is of variable The bit string or the "payload" of a VBCM message is of variable
length and is self-contained and coded in a variable length, binary length and is self-contained and coded in a variable length, binary
format. The media sender necessarily has to be able to parse this format. The media sender necessarily has to be able to parse this
optimized binary format to make use of VBCM messages optimized binary format to make use of VBCM messages.
Each of the different types of sub-messages (indicated by Each of the different types of sub-messages (indicated by
payloadType) may have different semantic based on the codec used. payloadType) may have different semantics depending on the codec
used.
The ''SSRC of the packet sender'' field indicates the source of the
request, and the ''SSRC of media source'' is not used and SHALL be
set to 0. The SSRC of the media sender to which the VBCM message
applies to is in the FCI.
4.3.4.2. Message Format
The VBCM indication uses one FCI field and the syntax is depicted in
Figure 6.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq. nr |0| Payload Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VBCM Octet String.... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 - Syntax for VBCM Message
SSRC: The SSRC value of the media sender that is requested to
instruct its encoder to react to the VBCM message
Seq. nr: Command sequence number. The sequence number space is unique
for each tuple consisting of the SSRC of command source and
the SSRC of the command target. The sequence number SHALL be
increased by 1 modulo 256 for each new command. A repetition
SHALL NOT increase the sequence number. Initial value is
arbitrary.
0: Must be set to 0 and should not be acted upon receiving.
Payload: The RTP payload type for which the VBCM bit stream must be
interpreted.
Length: The length of the VBCM octet string in octets exclusive any
padding octets
VBCM Octet String: This is the octet string generated by the decoder
carrying a specific feedback sub-message. It is of variable
length.
Padding: Bytes set to 0 to make up a 32 bit boundary. Within the common packet header for feedback messages (as defined in
section 6.1 of [RFC4585]), the "SSRC of the packet sender" field
indicates the source of the request, and the "SSRC of media source"
is not used and SHALL be set to 0. The SSRCs of the media senders to
which the VBCM message applies to are in the corresponding FCI
entries. The sender of the VBCM message MAY send H.271 messages to
multiple media senders and MAY send more than one H.271 message to
the same media sender within the same VBCM message.
4.3.4.3. Timing Rules 4.3.4.3. Timing Rules
The timing follows the rules outlined in section 3 of [RFC4585]. The The timing follows the rules outlined in section 3 of [RFC4585]. The
different sub-message types may have different properties in regards different sub-message types may have different properties in regards
to the timing of messages that should be used. If several different to the timing of messages that should be used. If several different
types are included in the same feedback packet then the sub-message types are included in the same feedback packet then the requirements
type with the most stringent requirements should be followed. for the sub-message type with the most stringent requirements should
be followed.
4.3.4.4. Handling of message in Mixer or Translator 4.3.4.4. Handling of message in Mixer or Translator
The handling of VBCM in a mixer or translator are sub-message type The handling of VBCM in a mixer or translator is sub-message type
dependent. dependent.
4.3.4.5. Remarks 4.3.4.5. Remarks
Please see section 3.5.3 for the applicability of the VBCM message in Please see section 3.5.3 for a discussion of the usage of H.271
relation to messages in both AVPF and this memo with similar messages and messages defined in AVPF [RFC4585] and this memo with
functionality. similar functionality.
Note: There has been some discussion whether the payload type field Note: There has been some discussion whether the payload type field
in this message is needed. It would be needed if there were in this message is needed. It will be needed if there is
potentially more than one VBCM-capable RTP payload types in the same potentially more than one VBCM-capable RTP payload type in the same
session, and that the semantics of a given VBCM message changes from session, and the semantics of a given VBCM message changes between
PT to PT. This appears to be the case. For example, the picture payload types. For example, the picture identification mechanism
identification mechanism in messages of H.271 type 0 is fundamentally in messages of H.271 type 0 is fundamentally different between
different between H.263 and H.264 (although both use the same syntax. H.263 and H.264 (although both use the same syntax). Therefore,
Therefore, the payload field is justified here. It was further the payload field is justified here. There was a further comment
commented that for TSTS and FIR such a need does not exist, because that for TSTS and FIR such a need does not exist, because the
the semantics of TSTS and FIR are either loosely enough defined, or semantics of TSTS and FIR are either loosely enough defined, or
generic enough, to apply to all video payloads currently in generic enough, to apply to all video payloads currently in
existence/envisioned. existence/envisioned.
5. Congestion Control 5. Congestion Control
The correct application of the AVPF timing rules prevents the network The correct application of the AVPF [RFC4585] timing rules prevents
from being flooded by feedback messages. Hence, assuming a correct the network from being flooded by feedback messages. Hence, assuming
implementation, the RTCP channel cannot break its bit-rate commitment a correct implementation and configuration, the RTCP channel cannot
and introduce congestion. break its bit rate commitment and introduce congestion.
The reception of some of the feedback messages modifies the behaviour The reception of some of the feedback messages modifies the behaviour
of the media senders or, more specifically, the media encoders. All of the media senders or, more specifically, the media encoders. Thus
of these modifications MUST only be performed within the bandwidth modified behaviour MUST respect the bandwidth limits that the
limits the applied congestion control provides. For example, when application of congestion control provides. For example, when a
reacting to a FIR, the unusually high number of packets that form the media sender is reacting to a FIR, the unusually high number of
decoder refresh point have to be paced in compliance with the packets that form the decoder refresh point have to be paced in
congestion control algorithm, even if the user experience suffers compliance with the congestion control algorithm, even if the user
from a slowly transmitted decoder refresh point. experience suffers from a slowly transmitted decoder refresh point.
A change of the Temporary Maximum Media Stream Bit-rate value can A change of the Temporary Maximum Media Stream Bit Rate value can
only mitigate congestion, but not cause congestion as long as only mitigate congestion, but not cause congestion as long as
congestion control is also employed. An increase of the value by a congestion control is also employed. An increase of the value by a
request REQUIRES the media sender to use congestion control when request REQUIRES the media sender to use congestion control when
increasing its transmission rate to that value. A reduction of the increasing its transmission rate to that value. A reduction of the
value results in a reduced transmission bit-rate thus reducing the value results in a reduced transmission bit rate thus reducing the
risk for congestion. risk for congestion.
6. Security Considerations 6. Security Considerations
The defined messages have certain properties that have security The defined messages have certain properties that have security
implications. These must be addressed and taken into account by users implications. These must be addressed and taken into account by
of this protocol. users of this protocol.
The defined setup signaling mechanism is sensitive to modification The defined setup signaling mechanism is sensitive to modification
attacks that can result in session creation with sub-optimal attacks that can result in session creation with sub-optimal
configuration, and, in the worst case, session rejection. To prevent configuration, and, in the worst case, session rejection. To prevent
this type of attack, authentication and integrity protection of the this type of attack, authentication and integrity protection of the
setup signaling is required. setup signaling is required.
Spoofed or maliciously created feedback messages of the type defined Spoofed or maliciously created feedback messages of the type defined
in this specification can have the following implications: in this specification can have the following implications:
a. Severely reduced media bit-rate due to false TMMBR messages
that sets the maximum to a very low value. a. severely reduced media bit rate due to false TMMBR messages
b. The assignment of the ownership of a bit-rate limit with a that sets the maximum to a very low value;
TMMBN message to the wrong participant. Thus potentially
freezing the mechanism until a correct TMMBN message reached b. assignment of the ownership of a bounding tuple to the wrong
the participants. participant within a TMMBN message, potentially causing
c. Sending TSTR that result in a video quality different from unnecessary oscillation in the bounding set as the mistakenly
the user's desire, rendering the session less useful. identified owner reports a change in its tuple and the true
d. Frequent FIR commands will potentially reduce the frame-rate owner possibly holds back on changes until a correct TMMBN
making the video jerky due to the frequent usage of decoder message reaches the participants;
c. sending TSTR requests that result in a video quality
different from the user's desire, rendering the session less
useful.
d. Frequent FIR commands will potentially reduce the frame-rate,
making the video jerky, due to the frequent usage of decoder
refresh points. refresh points.
To prevent these attacks there is a need to apply authentication and To prevent these attacks there is a need to apply authentication and
integrity protection of the feedback messages. This can be integrity protection of the feedback messages. This can be
accomplished against threats external to the current RTP session accomplished against threats external to the current RTP session
using the RTP profile that combines SRTP [SRTP] and AVPF into SAVPF using the RTP profile that combines SRTP [SRTP] and AVPF into SAVPF
[SAVPF]. In the Mixer cases, separate security contexts and filtering [SAVPF]. In the mixer cases, separate security contexts and
can be applied between the Mixer and the participants thus protecting filtering can be applied between the mixer and the participants thus
other users on the Mixer from a misbehaving participant. protecting other users on the mixer from a misbehaving participant.
7. SDP Definitions 7. SDP Definitions
Section 4 of [RFC4585] defines new SDP [RFC4566] attributes that are Section 4 of [RFC4585] defines a new SDP [RFC4566] attribute, rtcp-
used for the capability exchange of the AVPF commands and fb, that may be used to negotiate the capability to handle specific
indications, such as Reference Picture selection, Picture loss AVPF commands and indications, such as Reference Picture Selection,
indication etc. The defined SDP attribute is known as rtcp-fb and its Picture Loss Indication etc. The ABNF for rtcp-fb is described in
ABNF is described in section 4.2 of [RFC4585]. In this section we section 4.2 of [RFC4585]. In this section we extend the rtcp-fb
extend the rtcp-fb attribute to include the commands and indications attribute to include the commands and indications that are described
that are described in this document for codec control protocol. We for codec control protocol in the present document. We also discuss
also discuss the Offer/Answer implications for the codec control the Offer/Answer implications for the codec control commands and
commands and indications. indications.
7.1. Extension of rtcp-fb attribute 7.1. Extension of the rtcp-fb Attribute
As described in [RFC4585], the rtcp-fb attribute is defined to As described in AVPF [RFC4585], the rtcp-fb attribute indicates the
indicate the capability of using RTCP feedback. As defined in AVPF capability of using RTCP feedback. AVPF specifies that the rtcp-fb
the rtcp-fb attribute must only be used as a media level attribute attribute must only be used as a media level attribute and must not
and must not be provided at session level. All the rules described be provided at session level. All the rules described in [RFC4585]
in [RFC4585] for rtcp-fb attribute relating to payload type and to for rtcp-fb attribute relating to payload type and to multiple rtcp-
multiple rtcp-fb attributes in a session description also apply to fb attributes in a session description also apply to the new feedback
the new feedback messages defined in this memo. messages defined in this memo.
The ABNF for rtcp-fb as defined in [RFC4585] is The ABNF [RFC4234] for rtcp-fb as defined in [RFC4585] is
Rtcp-fb-syntax = "a=rtcp-fb: " rtcp-fb-pt SP rtcp-fb-val CRLF "a=rtcp-fb: " rtcp-fb-pt SP rtcp-fb-val CRLF
Where rtcp-fb-pt is the payload type and rtcp-fb-val defines the type where rtcp-fb-pt is the payload type and rtcp-fb-val defines the type
of the feedback message such as ack, nack, trr-int and rtcp-fb-id. of the feedback message such as ack, nack, trr-int and rtcp-fb-id.
For example to indicate the support of feedback of picture loss For example to indicate the support of feedback of picture loss
indication, the sender declares the following in SDP indication, the sender declares the following in SDP
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback s=Media with feedback
t=0 0 t=0 0
c=IN IP4 host.example.com c=IN IP4 host.example.com
m=audio 49170 RTP/AVPF 98 m=audio 49170 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 nack pli a=rtcp-fb:98 nack pli
In this document we define a new feedback value type called "ccm" In this document we define a new feedback value "ccm" which indicates
which indicates the support of codec control using RTCP feedback the support of codec control using RTCP feedback messages. The "ccm"
messages. The "ccm" feedback value should be used with parameters, feedback value SHOULD be used with parameters, which indicate the
which indicates the support of which codec commands the session may specific codec control commands supported. In this draft we define
use. In this draft we define four parameters, which can be used with four parameters, which can be used with the ccm feedback value type.
the ccm feedback value type.
o "fir" indicates the support of Full Intra Request o "fir" indicates the support of the Full Intra Request (FIR).
o "tmmbr" indicates the support of Temporal Maximum Media Stream o "tmmbr" indicates the support of the Temporary Maximum Media
Bit-rate. It has an optional sub parameter to indicate the Stream Bit Rate Request/Notification (TMMBR/TMMBN). It has an
session maximum packet rate to be used. If not included it optional sub parameter to indicate the session maximum packet
defaults to infinity. rate to be used. If not included this defaults to infinity.
o "tstr" indicates the support of temporal spatial trade-off o "tstr" indicates the support of the Temporal-Spatial Trade-off
request. Request/Notification (TSTR/TSTN).
O "vbcm" indicates the support of H.271 video back channel O "vbcm" indicates the support of H.271 video back channel
messages. messages (VBCM). It has zero or more subparameters identifying
the supported H.271 "payloadType" values.
In ABNF for rtcp-fb-val defined in [RFC4585], there is a placeholder In the ABNF for rtcp-fb-val defined in [RFC4585], there is a
called rtcp-fb-id to define new feedback types. The ccm is defined as placeholder called rtcp-fb-id to define new feedback types. "ccm" is
a new feedback type in this document and the ABNF for the parameters defined as a new feedback type in this document and the ABNF for the
for ccm are defined here (please refer section 4.2 of [RFC4585] for parameters for ccm are defined here (please refer to section 4.2 of
complete ABNF syntax). [RFC4585] for complete ABNF syntax).
Rtcp-fb-param = SP "app" [SP byte-string] rtcp-fb-param = SP "app" [SP byte-string]
/ SP rtcp-fb-ccm-param / SP rtcp-fb-ccm-param
/ ; empty / ; empty
rtcp-fb-ccm-param = "ccm" SP ccm-param rtcp-fb-ccm-param = "ccm" SP ccm-param
ccm-param = "fir" ; Full Intra Request ccm-param = "fir" ; Full Intra Request
/ "tmmbr" [SP "smaxpr=" MaxPacketRateValue] / "tmmbr" [SP "smaxpr=" MaxPacketRateValue]
; Temporary max media bit rate ; Temporary max media bit rate
/ "tstr" ; Temporal Spatial Trade Off / "tstr" ; Temporal Spatial Trade Off
/ "vbcm" *(SP subMessageType] ; H.271 VBCM messages / "vbcm" *(SP subMessageType) ; H.271 VBCM messages
/ token [SP byte-string] / token [SP byte-string]
; for future commands/indications ; for future commands/indications
subMessageType = 1*8DIGIT subMessageType = 1*8DIGIT
byte-string = <as defined in section 4.2 of [RFC4585] > byte-string = <as defined in section 4.2 of [RFC4585] >
MaxPacketRateValue = 1*15DIGIT MaxPacketRateValue = 1*15DIGIT
7.2. Offer-Answer 7.2. Offer-Answer
The Offer/Answer [RFC3264] implications to codec control protocol The Offer/Answer [RFC3264] implications for codec control protocol
feedback messages are similar those described in [RFC4585]. The feedback messages are similar those described in [RFC4585]. The
offerer MAY indicate the capability to support selected codec offerer MAY indicate the capability to support selected codec
commands and indications. The answerer MUST remove all ccm parameters commands and indications. The answerer MUST remove all ccm
which it does not understand or does not wish to use in this parameters which it does not understand or does not wish to use in
particular media session. The answerer MUST NOT add new ccm this particular media session. The answerer MUST NOT add new ccm
parameters in addition to what has been offered. The answer is parameters in addition to what has been offered. The answer is
binding for the media session and both offerer and answerer MUST only binding for the media session and both offerer and answerer MUST only
use feedback messages negotiated in this way. use feedback messages negotiated in this way.
The session maximum packet rate parameter part of the TMMBR The session maximum packet rate parameter part of the TMMBR
indication is declarative and everyone shall use the highest value indication is declarative and everyone shall use the highest value
indicated in a response. If not present in a offer is SHALL NOT be indicated in a response. If the session maximum packet rate
included by the answerer. parameter is not present in an offer it SHALL NOT be included by the
answerer.
7.3. Examples 7.3. Examples
Example 1: The following SDP describes a point-to-point video call Example 1: The following SDP describes a point-to-point video call
with H.263 with the originator of the call declaring its capability with H.263, with the originator of the call declaring its capability
to support codec control messages - fir, tstr. The SDP is carried in to support the FIR and TSTR/TSTN codec control messages. The SDP is
a high level signaling protocol like SIP carried in a high level signaling protocol like SIP.
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Point-to-Point call s=Point-to-Point call
c=IN IP4 172.11.1.124 c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98 m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir a=rtcp-fb:98 ccm fir
In the above example the sender when it receives a TSTR message from In the above example, when the sender receives a TSTR message from
the remote party can adjust the trade off as indicated in the RTCP the remote party it is capable of adjusting the trade off as
TSTN feedback message. indicated in the RTCP TSTN feedback message.
Example 2: The following SDP describes a SIP end point joining a Example 2: The following SDP describes a SIP end point joining a
video Mixer that is hosting a multiparty video conferencing session. video mixer that is hosting a multiparty video conferencing session.
The participant supports only the FIR (Full Intra Request) codec The participant supports only the FIR (Full Intra Request) codec
control command and it declares it in its session description. The control command and it declares it in its session description.
video Mixer can send an FIR RTCP feedback message to this end point
when it needs to send this participants video to other participants
of the conference.
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multiparty Video Call s=Multiparty Video Call
c=IN IP4 172.11.1.124 c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98 m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm fir a=rtcp-fb:98 ccm fir
When the video MCU decides to route the video of this participant it When the video MCU decides to route the video of this participant it
sends an RTCP FIR feedback message. Upon receiving this feedback sends an RTCP FIR feedback message. Upon receiving this feedback
message the end point is mandated to generate a full intra request. message the end point is required to generate a full intra request.
Example 3: The following example describes the Offer/Answer Example 3: The following example describes the Offer/Answer
implications for the codec control messages. The Offerer wishes to implications for the codec control messages. The Offerer wishes to
support "tstr", "fir" and "tmmbr" messages. The offered SDP is support "tstr", "fir" and "tmmbr". The offered SDP is
-------------> Offer -------------> Offer
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Offer/Answer s=Offer/Answer
c=IN IP4 172.11.1.124 c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98 m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir a=rtcp-fb:98 ccm fir
a=rtcp-fb:* ccm tmmbr smaxpr=120 a=rtcp-fb:* ccm tmmbr smaxpr=120
The answerer only wishes to support FIR and TSTR message as the codec
control messages and the answerer SDP is The answerer wishes to support only the FIR and TSTR/TSTN messages
and the answerer SDP is
<---------------- Answer <---------------- Answer
v=0 v=0
o=alice 3203093520 3203093524 IN IP4 otherhost.example.com o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
s=Offer/Answer s=Offer/Answer
c=IN IP4 189.13.1.37 c=IN IP4 192.0.2.37
m=audio 47190 RTP/AVP 0 m=audio 47190 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 53273 RTP/AVPF 98 m=video 53273 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir a=rtcp-fb:98 ccm fir
Example 4: The following example describes the Offer/Answer Example 4: The following example describes the Offer/Answer
implications for H.271 Video back channel messages (VBCM). The implications for H.271 Video back channel messages (VBCM). The
Offerer wishes to support VBCM and the submessages of payloadType 1 Offerer wishes to support VBCM and the sub-messages of payloadType 1
(One or more pictures that are entirely or partially lost) and 2 (a (one or more pictures that are entirely or partially lost) and 2 (a
set of blocks of one picture that is entirely or partially lost). set of blocks of one picture that are entirely or partially lost).
-------------> Offer -------------> Offer
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Offer/Answer s=Offer/Answer
c=IN IP4 172.11.1.124 c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98 m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm vbcm 1 2 a=rtcp-fb:98 ccm vbcm 1 2
The answerer only wishes to support sub-messages 1 only The answerer only wishes to support sub-messages of type 1 only
<---------------- Answer <---------------- Answer
v=0 v=0
o=alice 3203093520 3203093524 IN IP4 otherhost.example.com o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
s=Offer/Answer s=Offer/Answer
c=IN IP4 189.13.1.37 c=IN IP4 192.0.2.37
m=audio 47190 RTP/AVP 0 m=audio 47190 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 53273 RTP/AVPF 98 m=video 53273 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm vbcm 1 a=rtcp-fb:98 ccm vbcm 1
So in the above example only VBCM indication comprising of only So in the above example only VBCM indications comprised of
"payloadType" 1 will be supported. "payloadType" 1 will be supported.
8. IANA Considerations 8. IANA Considerations
The new value of ccm for the rtcp-fb attribute needs to be registered The new value "ccm" needs to be registered with IANA in the "rtcp-fb"
with IANA. Attribute Values registry located at the time of publication at:
http://www.iana.org/assignments/sdp-parameters
Value name: ccm Value name: ccm
Long Name: Codec Control Commands and Indications Long Name: Codec Control Commands and Indications
Reference: RFC XXXX Reference: RFC XXXX
For use with "ccm" the following values also needs to be A new registry "Codec Control Messages" needs to be created to hold
registered. "ccm" parameters located at time of publication at:
http://www.iana.org/assignments/sdp-parameters
New registration in this registry follows the "Specification
required" policy as defined by [RFC2434]. In addition they are
required to indicate which, if any additional RTCP feedback types,
such as "nack", "ack".
The initial content of the registry is the following values:
Value name: fir Value name: fir
Long name: Full Intra Request Command Long name: Full Intra Request Command
Usable with: ccm Usable with: ccm
Reference: RFC XXXX Reference: RFC XXXX
Value name: tmmbr Value name: tmmbr
Long name: Temporary Maximum Media Stream Bit-rate Long name: Temporary Maximum Media Stream Bit Rate
Usable with: ccm Usable with: ccm
Reference: RFC XXXX Reference: RFC XXXX
Value name: tstr Value name: tstr
Long name: temporal Spatial Trade Off Long name: temporal Spatial Trade Off
Usable with: ccm Usable with: ccm
Reference: RFC XXXX Reference: RFC XXXX
Value name: vbcm Value name: vbcm
Long name: H.271 video back channel messages Long name: H.271 video back channel messages
Usable with: ccm Usable with: ccm
Reference: RFC XXXX Reference: RFC XXXX
9. Acknowledgements The following values need to be registered as FMT values in the "FMT
Values for RTPFB Payload Types" registry located at the time of
publication at: http://www.iana.org/assignments/rtp-parameters
RTPFB range
Name Long Name Value Reference
-------------- --------------------------------- ----- ---------
Reserved 2 [RFCxxxx]
TMMBR Temporary Maximum Media Stream Bit 3 [RFCxxxx]
Rate Request
TMMBN Temporary Maximum Media Stream Bit 4 [RFCxxxx]
Rate Notification
The following values need to be registered as FMT values in the "FMT
Values for PSFB Payload Types" registry located at the time of
publication at: http://www.iana.org/assignments/rtp-parameters
PSFB range
Name Long Name Value Reference
-------------- --------------------------------- ----- ---------
FIR Full Intra Request Command 4 [RFCxxxx]
TSTR Temporal-Spatial Trade-off Request 5 [RFCxxxx]
TSTN Temporal-Spatial Trade-off Notification 6 [RFCxxxx]
VBCM Video Back Channel Message 7 [RFCxxxx]
9. Contributors
Tom Taylor has made a very significant contribution, for which the
authors are very grateful, to this specification by helping rewrite
the specification. Especially the parts regarding the algorithm for
determining bounding sets for TMMBR have benefited.
10. Acknowledgements
The authors would like to thank Andrea Basso, Orit Levin, Nermeen The authors would like to thank Andrea Basso, Orit Levin, Nermeen
Ismail for their work on the requirement and discussion draft Ismail for their work on the requirement and discussion draft
[Basso]. [Basso].
Drafts of this memo were reviewed and extensively commented by Roni Drafts of this memo were reviewed and extensively commented by Roni
Even, Colin Perkins, Randell Jesup, Keith Lantz, Harikishan Desineni, Even, Colin Perkins, Randell Jesup, Keith Lantz, Harikishan Desineni,
Guido Franceschini and others. The authors appreciate these reviews. Guido Franceschini and others. The authors appreciate these reviews.
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
10. References 11. References
10.1. Normative references 11.1. Normative references
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., Rey, J., [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., Rey, J.,
"Extended RTP Profile for Real-Time Transport Control "Extended RTP Profile for Real-Time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Protocol", RFC 2327, April 1998. Description Protocol", RFC 4566, July 2006.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[Topologies] M. Westerlund, and S. Wenger, "RTP Topologies", draft- [Topologies] M. Westerlund, and S. Wenger, "RTP Topologies", draft-
ietf-avt-topologies-00, work in progress, August 2006 ietf-avt-topologies-04, work in progress, Feb 2007.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
10.2. Informative references 11.2. Informative references
[Basso] A. Basso, et. al., "Requirements for transport of video [Basso] A. Basso, et. al., "Requirements for transport of video
control commands", draft-basso-avt-videoconreq-02.txt, control commands", draft-basso-avt-videoconreq-02.txt,
expired Internet Draft, October 2004. expired Internet Draft, October 2004.
[AVC] Joint Video Team of ITU-T and ISO/IEC JTC 1, Draft ITU-T [AVC] Joint Video Team of ITU-T and ISO/IEC JTC 1, Draft ITU-T
Recommendation and Final Draft International Standard of Recommendation and Final Draft International Standard of
Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC
14496-10 AVC), Joint Video Team (JVT) of ISO/IEC MPEG and 14496-10 AVC), Joint Video Team (JVT) of ISO/IEC MPEG
ITU-T VCEG, JVT-G050, March 2003. and ITU-T VCEG, JVT-G050, March 2003.
[H245] ITU-T Rec. HG.245, "Control protocol for multimedia
communication", MAY 2006
[NEWPRED] S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient [NEWPRED] S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient
Video Coding by Dynamic Replacing of Reference Pictures," Video Coding by Dynamic Replacing of Reference
in Proc. Globcom'96, vol. 3, pp. 1503 - 1508, 1996. Pictures," in Proc. Globcom'96, vol. 3, pp. 1503 - 1508,
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1996.
Norrman, "The Secure Real-time Transport Protocol [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
K. Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004. (SRTP)", RFC 3711, March 2004.
[RFC2032] Turletti, T. and C. Huitema, "RTP Payload Format for [RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams",
H.261 Video Streams", RFC 2032, October 1996. RFC 4587, August 2006.
[SAVPF] J. Ott, E. Carrara, "Extended Secure RTP Profile for [SAVPF] J. Ott, E. Carrara, "Extended Secure RTP Profile for
RTCP-based Feedback (RTP/SAVPF)," draft-ietf-avt-profile- RTCP-based Feedback (RTP/SAVPF),"
savpf-02.txt, July, 2005. draft-ietf-avt-profile-savpf-10.txt, Feb, 2007.
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor,
"Gateway Control Protocol Version 1", RFC 3525, June "Gateway Control Protocol Version 1", RFC 3525, June
2003. 2003.
[RFC3448] M. Handley, S. Floyd, J. Padhye, J. Widmer, "TCP
[RFC3448] M. Handley, S. Floyd, J. Padhye, J. Widmer, "TCP Friendly Friendly Rate Control (TFRC): Protocol Specification",
Rate Control (TFRC): Protocol Specification", RFC 3448,
[VBCM] ITU-T Rec. H.271, "Video Back Channel Messages", June [VBCM] ITU-T Rec. H.271, "Video Back Channel Messages", June
2006 2006
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth [RFC3890] Westerlund, M., "A Transport Independent Bandwidth
Modifier for the Session Description Protocol (SDP)", RFC Modifier for the Session Description Protocol (SDP)",
3890, September 2004. RFC 3890, September 2004.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March Congestion Control Protocol (DCCP)", RFC 4340, March
2006. 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC
2198, September 1997.
11. Authors' Addresses 12. Authors' Addresses
Stephan Wenger Stephan Wenger
Nokia Corporation Nokia Corporation
P.O. Box 100 975, Page Mill Road,
FIN-33721 Tampere Palo Alto,CA 94304
FINLAND USA
Phone: +358-50-486-0637 Phone: +1-650-862-7368
EMail: stewe@stewe.org EMail: stewe@stewe.org
Umesh Chandra Umesh Chandra
Nokia Research Center Nokia Research Center
975, Page Mill Road, 975, Page Mill Road,
Palo Alto,CA 94304 Palo Alto,CA 94304
USA USA
Phone: +1-650-796-7502 Phone: +1-650-796-7502
Email: Umesh.Chandra@nokia.com Email: Umesh.Chandra@nokia.com
 End of changes. 331 change blocks. 
1377 lines changed or deleted 1768 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/