draft-ietf-avt-avpf-ccm-06.txt   draft-ietf-avt-avpf-ccm-07.txt 
Network Working Group Stephan Wenger Network Working Group Stephan Wenger
INTERNET-DRAFT Umesh Chandra INTERNET-DRAFT Umesh Chandra
Expires: October 2007 Nokia Expires: October 2007 Nokia
Intended Status: Proposed Standard Magnus Westerlund Magnus Westerlund
Bo Burman Bo Burman
Ericsson Ericsson
May 28, 2007 May 30, 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-06.txt> draft-ietf-avt-avpf-ccm-07.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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-Drafts
material or to cite them other than as "work in progress." as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
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
the Audio-Visual Profile with Feedback (AVPF). They are helpful in the Audio-Visual Profile with Feedback (AVPF). They are
primarily in conversational multimedia scenarios where centralized helpful primarily in conversational multimedia scenarios where
multipoint functionalities are in use. However some are also usable centralized multipoint functionalities are in use. However some
in smaller multicast environments and point-to-point calls. The are also usable in smaller multicast environments and point-to-
extensions discussed are messages related to the ITU-T H.271 Video point calls. The extensions discussed are messages related to the
Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit ITU-T H.271 Video Back Channel, Full Intra Request, Temporary
Rate and Temporal Spatial Trade-off. Maximum Media Stream Bit Rate and Temporal Spatial Trade-off.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction....................................................5 1. Introduction....................................................5
2. Definitions.....................................................6 2. Definitions.....................................................6
2.1. Glossary...................................................6 2.1. Glossary...................................................6
2.2. Terminology................................................6 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...........................14
3.5.1.1. Reliability.....................................14 3.5.1.1. Reliability.....................................14
3.5.2. Temporal Spatial Trade-off Request and Notification..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 3.5.2.2. Point-to-Multipoint Using Multicast or
Translators.....................................16 Translators.....................................17
3.5.2.3. Point-to-Multipoint Using RTP Mixer.............17 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.....................17 3.5.3. H.271 Video Back Channel Message.....................18
3.5.3.1. Reliability.....................................20 3.5.3.1. Reliability.....................................21
3.5.4. Temporary Maximum Media Stream Bit Rate Request and 3.5.4. Temporary Maximum Media Stream Bit Rate Request and
Notification................................................20 Notification.........................................21
3.5.4.1. Behavior for media receivers using TMMBR........22 3.5.4.1. Behavior for media receivers using TMMBR........23
3.5.4.2. Algorithm for establishing current limitations..24 3.5.4.2. Algorithm for establishing current limitations..25
3.5.4.3. Use of TMMBR in a Mixer Based Multipoint 3.5.4.3. Use of TMMBR in a Mixer Based Multipoint
Operation.......................................30 Operation.......................................32
3.5.4.4. Use of TMMBR in Point-to-Multipoint Using 3.5.4.4. Use of TMMBR in Point-to-Multipoint Using
Multicast or Translators........................32 Multicast or Translators........................33
3.5.4.5. Use of TMMBR in Point-to-point operation........32 3.5.4.5. Use of TMMBR in Point-to-point operation........33
3.5.4.6. Reliability.....................................32 3.5.4.6. Reliability.....................................33
4. RTCP Receiver Report Extensions................................34 4. RTCP Receiver Report Extensions................................35
4.1. Design Principles of the Extension Mechanism..............34 4.1. Design Principles of the Extension Mechanism..............35
4.2. Transport Layer Feedback Messages.........................35 4.2. Transport Layer Feedback Messages.........................36
4.2.1. Temporary Maximum Media Stream Bit Rate Request 4.2.1. Temporary Maximum Media Stream Bit Rate Request
(TMMBR)..............................................36 (TMMBR)..............................................37
4.2.1.1. Message Format..................................36 4.2.1.1. Message Format..................................37
4.2.1.2. Semantics.......................................37 4.2.1.2. Semantics.......................................38
4.2.1.3. Timing Rules....................................40 4.2.1.3. Timing Rules....................................42
4.2.1.4. Handling in Translator and Mixers...............40 4.2.1.4. Handling in Translator and Mixers...............42
4.2.2. Temporary Maximum Media Stream Bit Rate Notification 4.2.2. Temporary Maximum Media Stream Bit Rate Notification
(TMMBN)..............................................41 (TMMBN)..............................................42
4.2.2.1. Message Format..................................41 4.2.2.1. Message Format..................................42
4.2.2.2. Semantics.......................................42 4.2.2.2. Semantics.......................................43
4.2.2.3. Timing Rules....................................43 4.2.2.3. Timing Rules....................................44
4.2.2.4. Handling by Translators and Mixers..............43 4.2.2.4. Handling by Translators and Mixers..............44
4.3. Payload Specific Feedback Messages........................43 4.3. Payload Specific Feedback Messages........................44
4.3.1. Full Intra Request (FIR).............................44 4.3.1. Full Intra Request (FIR).............................45
4.3.1.1. Message Format..................................44 4.3.1.1. Message Format..................................45
4.3.1.2. Semantics.......................................45 4.3.1.2. Semantics.......................................46
4.3.1.3. Timing Rules....................................47 4.3.1.3. Timing Rules....................................48
4.3.1.4. Handling of FIR Message in Mixer and 4.3.1.4. Handling of FIR Message in Mixer and Translators48
Translators.....................................47 4.3.1.5. Remarks.........................................49
4.3.1.5. Remarks.........................................47 4.3.2. Temporal-Spatial Trade-off Request (TSTR)............49
4.3.2. Temporal-Spatial Trade-off Request (TSTR)............47 4.3.2.1. Message Format..................................49
4.3.2.1. Message Format..................................48 4.3.2.2. Semantics.......................................50
4.3.2.2. Semantics.......................................48 4.3.2.3. Timing Rules....................................51
4.3.2.3. Timing Rules....................................49 4.3.2.4. Handling of message in Mixers and Translators...51
4.3.2.4. Handling of message in Mixers and Translators...49 4.3.2.5. Remarks.........................................51
4.3.2.5. Remarks.........................................49 4.3.3. Temporal-Spatial Trade-off Notification (TSTN).......51
4.3.3. Temporal-Spatial Trade-off Notification (TSTN).......50 4.3.3.1. Message Format..................................52
4.3.3.1. Message Format..................................50 4.3.3.2. Semantics.......................................52
4.3.3.2. Semantics.......................................51 4.3.3.3. Timing Rules....................................53
4.3.3.3. Timing Rules....................................51 4.3.3.4. Handling of TSTN in Mixer and Translators.......53
4.3.3.4. Handling of TSTN in Mixer and Translators.......51 4.3.3.5. Remarks.........................................53
4.3.3.5. Remarks.........................................51 4.3.4. H.271 Video Back Channel Message (VBCM)..............53
4.3.4. H.271 Video Back Channel Message (VBCM)..............52 4.3.4.1. Message Format..................................54
4.3.4.1. Message Format..................................52 4.3.4.2. Semantics.......................................55
4.3.4.2. Semantics.......................................53 4.3.4.3. Timing Rules....................................56
4.3.4.3. Timing Rules....................................54 4.3.4.4. Handling of message in Mixer or Translator......56
4.3.4.4. Handling of message in Mixer or Translator......54 4.3.4.5. Remarks.........................................56
4.3.4.5. Remarks.........................................54 5. Congestion Control.............................................57
5. Congestion Control.............................................55 6. Security Considerations........................................57
6. Security Considerations........................................55 7. SDP Definitions................................................58
7. SDP Definitions................................................56 7.1. Extension of the rtcp-fb Attribute........................58
7.1. Extension of the rtcp-fb Attribute........................56 7.2. Offer-Answer..............................................60
7.2. Offer-Answer..............................................58 7.3. Examples..................................................60
7.3. Examples..................................................58 8. IANA Considerations............................................64
8. IANA Considerations............................................62 9. Acknowledgements...............................................65
9. Acknowledgements...............................................63 10. References....................................................67
10. References....................................................64 10.1. Normative references.....................................67
10.1. Normative references.....................................64 10.2. Informative references...................................67
10.2. Informative references...................................64 11. Authors' Addresses............................................69
11. Authors' Addresses............................................66
1.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
to-point and small multipoint scenarios without centralized point-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
conferencing industry suggests that there is a need for a few video conferencing industry suggests that there is a need for a
additional feedback messages, to support centralized multipoint few additional feedback messages, to support centralized
conferencing efficiently. Some of the messages have applications multipoint conferencing efficiently. Some of the messages have
beyond centralized multipoint, and this is indicated in the applications beyond centralized multipoint, and this is indicated
description of the message. This is especially true for the message in the description of the message. This is especially true for
intended to carry ITU-T Rec. H.271 [H.271] bit strings for Video Back the message intended to carry ITU-T Rec. H.271 [H.271] bit strings
Channel messages. for Video Back Channel messages.
In Real-time Transport Protocol (RTP) [RFC3550] terminology, MCUs In Real-time Transport Protocol (RTP) [RFC3550] terminology, MCUs
comprise mixers and translators. Most MCUs also include signaling comprise mixers and translators. Most MCUs also include signaling
support. During the development of this memo, it was noticed that support. During the development of this memo, it was noticed that
there is considerable confusion in the community related to the use there is considerable confusion in the community related to the
of terms such as mixer, translator, and MCU. In response to these use of terms such as mixer, translator, and MCU. In response to
concerns, a number of topologies have been identified that are of these concerns, a number of topologies have been identified that
practical relevance to the industry, but are not documented in are of practical relevance to the industry, but are not documented
sufficient detail in [RFC3550]. These topologies are documented in in sufficient detail in [RFC3550]. These topologies are
[Topologies], and understanding this memo requires previous or documented in [Topologies], and understanding this memo requires
parallel study of [Topologies]. 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
not require an explicit notification to the message emitter that they do not require an explicit notification to the message emitter
have been received and/or indicating the message receiver's actions. that they have been received and/or indicating the message
Other messages require a response, leading to a two way communication receiver's actions. Other messages require a response, leading to
model that one could view as useful for control purposes. However, a two way communication model that one could view as useful for
it is not the intention of this memo to open up RTP Control Protocol control purposes. However, it is not the intention of this memo
(RTCP) to a generalized control protocol. All mentioned messages to open up RTP Control Protocol (RTCP) to a generalized control
have relatively strict real-time constraints, in the sense that their protocol. All mentioned messages have relatively strict real-time
value diminishes with increased delay. This makes the use of more constraints, in the sense that their value diminishes with
traditional control protocol means, such as Session Initiation increased delay. This makes the use of more traditional control
Protocol (SIP) re-INVITEs [RFC3261], undesirable when used for the protocol means, such as Session Initiation Protocol (SIP) re-
same purpose. Furthermore, all messages are of a very simple format INVITEs [RFC3261], undesirable when used for the same purpose.
that can be easily processed by an RTP/RTCP sender/receiver. Furthermore, all messages are of a very simple format that can be
Finally, all messages relate only to the RTP stream with which they easily processed by an RTP/RTCP sender/receiver. Finally, and
are associated, and not to any other property of a communication most importantly, all messages relate only to the RTP stream with
system. In particular, none of them relate to the properties of the which they are associated, and not to any other property of a
access links traversed by the session. communication system. In particular, none of them relate to the
properties of the access links traversed by the session.
2. Definitions 2. Definitions
2.1. Glossary 2.1. Glossary
AMID - Additive Increase Multiplicative Decrease AMID - Additive Increase Multiplicative Decrease
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] FCI - Feedback Control Information [RFC4585]
FIR - Full Intra Request FIR - Full Intra Request
skipping to change at page 6, line 29 skipping to change at page 6, line 29
PR - Packet rate PR - Packet rate
QP - Quantizer Parameter QP - Quantizer Parameter
RTT - Round trip time RTT - Round trip time
SSRC - Synchronization Source 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
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
RFC 2119 [RFC2119].
Message: Message:
An RTCP feedback message [RFC4585] defined by this An RTCP feedback message [RFC4585] defined by this
specification, of one of the 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
skipping to change at page 6, line 45 skipping to change at page 7, line 4
specification, of one of the 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:
Message that provides a notification that an event has Message that provides a notification that an event has
occurred. Notifications are commonly generated in response occurred. Notifications are commonly generated in
to a Request. response to a Request.
Note that, with the exception of "Notification", this Note that, with the exception of "Notification", this
terminology is in alignment with ITU-T Rec. H.245 [H245]. terminology is in alignment with ITU-T Rec. H.245 [H245].
Decoder Refresh Point: Decoder Refresh Point:
A bit string, packetized 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. completely resets the decoder to a known state.
Examples for "hard" decoder refresh points are Intra pictures Examples for "hard" decoder refresh points are Intra
in H.261, H.263, MPEG-1, MPEG-2, and MPEG-4 part 2, and pictures in H.261, H.263, MPEG-1, MPEG-2, and MPEG-4 part
Instantaneous Decoder Refresh (IDR) pictures in H.264. 2, and Instantaneous Decoder Refresh (IDR) pictures in
"Gradual" decoder refresh points may also be used; see for H.264. "Gradual" decoder refresh points may also be used;
example [AVC]. While both "hard" and "gradual" decoder see for example [AVC]. While both "hard" and "gradual"
refresh points are acceptable in the scope of this decoder refresh points are acceptable in the scope of this
specification, in most cases the user experience will benefit specification, in most cases the user experience will
from using a "hard" decoder refresh point. 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
above the picture layer (or equivalent, depending on the video information above the picture layer (or equivalent,
compression standard) that is conveyed in-band. In H.264, for depending on the video compression standard) that is
example, a decoder refresh point contains parameter set conveyed in-band. In H.264, for example, a decoder refresh
Network Adaptation Layer (NAL) units that generate parameter point contains parameter set Network Adaptation Layer (NAL)
sets necessary for the decoding of the following slice/data units that generate parameter sets necessary for the
partition NAL units (and that are not conveyed out of band). decoding of the following slice/data 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 media The operation of presenting (parts of) the reconstructed
stream to the user. media 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, implying stream. Stream thinning, preferably, is media-aware,
that media packets are removed in the order of increasing implying that media packets are removed in the order of
relevance to the reproductive quality. However even when increasing relevance to the reproductive quality. However
employing media-aware stream thinning, most media streams even when employing media-aware stream thinning, most media
quickly lose quality when subject to increasing levels of streams quickly lose quality when subject to increasing
thinning. Media-unaware stream thinning leads to even worse levels of thinning. Media-unaware stream thinning leads to
quality degradation. In contrast to transcoding, stream even worse quality degradation. In contrast to
thinning is typically seen as a computationally lightweight transcoding, stream thinning is typically seen as a
operation. computationally lightweight operation.
Media: Media:
Often used (sometimes in conjunction with terms like bit
Often used (sometimes in conjunction with terms like bit rate, rate, stream, sender ...) to identify the content of the
stream, sender ...) to identify the content of the forward RTP forward RTP packet stream (carrying the codec data), to
packet stream (carrying the codec data), to which the codec which the codec control message applies.
control message applies.
Media Stream: Media Stream:
The stream of RTP packets labeled with a single The stream of RTP packets labeled with a single
Synchronization Source (SSRC) carrying the media (and also in Synchronization Source (SSRC) carrying the media (and also
some cases repair information such as retransmission or in some cases repair information such as retransmission or
Forward Error Correction (FEC) information). Forward Error Correction (FEC) information).
Total media bit rate: Total media bit rate:
The total bits per second transferred in a media stream, The total bits per second transferred in a media stream,
measured at an observer-selected protocol layer and averaged measured at an observer-selected protocol layer and
over a reasonable timescale, the length of which depends on averaged over a reasonable timescale, the length of which
the application. In general, a media sender and a media depends on the application. In general, a media sender and
receiver will observe different total media bit rates for the a media receiver will observe different total media bit
same stream, first because they may have selected different rates for the same stream, first because they may have
reference protocol layers, and second, because of changes in selected different reference protocol layers, and second,
per-packet overhead along the transmission path. The goal because of changes in per-packet overhead along the
with bit rate averaging is to be able to ignore any burstiness transmission path. The goal with bit rate averaging is to
on very short timescales, below for example 100 ms, introduced be able to ignore any burstiness on very short timescales,
by scheduling or link layer packetization effects. below for example 100 ms, introduced by scheduling or link
layer packetization effects.
Maximum total media bit rate: Maximum total media bit rate:
The upper limit on total media bit rate for a given media The upper limit on total media bit rate for a given media
stream at a particular receiver and for its selected protocol stream at a particular receiver and for its selected
layer. Note that this value cannot be measured on the received protocol layer. Note that this value cannot be measured on
media stream, instead it needs to be calculated or determined the received media stream, instead it needs to be
through other means, such as QoS negotiations or local calculated or determined through other means, such as QoS
resource limitations. Also note that this value is an average negotiations or local resource limitations. Also note that
(on a timescale that is reasonable for the application) and this value is an average (on a timescale that is reasonable
that it may be different from the instantaneous bit-rate seen for the application) and that it may be different from the
by packets in the media stream. instantaneous bit-rate seen by packets in the media stream.
Overhead: Overhead:
All protocol header information required to convey a packet All protocol header information required to convey a packet
with media data from sender to receiver, from the application with media data from sender to receiver, from the
layer down to a pre-defined protocol level (for example down application layer down to a pre-defined protocol level (for
to, and including, the IP header). Overhead may include, for example down to, and including, the IP header). Overhead
example, IP, UDP, and RTP headers, any layer 2 headers, any may include, for example, IP, UDP, and RTP headers, any
Contributing Sources (CSRCs), RTP-Padding, and RTP header layer 2 headers, any Contributing Sources (CSRCs), RTP-
extensions. Overhead excludes any RTP payload headers and the Padding, and RTP header extensions. Overhead excludes any
payload itself. RTP payload headers and the payload itself.
Net media bit rate: Net media bit rate:
The bit rate carried by a media stream, net of overhead. That The bit rate carried by a media stream, net of overhead.
is, the bits per second accounted for by encoded media, any That is, the bits per second accounted for by encoded
applicable payload headers, and any directly associated meta media, any applicable payload headers, and any directly
payload information placed in the RTP packet. A typical associated meta payload information placed in the RTP
example of the latter is redundancy data provided by the use packet. A typical example of the latter is redundancy data
of RFC 2198 [RFC2198]. Note that, unlike the total media bit provided by the use of RFC 2198 [RFC2198]. Note that,
rate, the net media bit rate will have the same value at the unlike the total media bit rate, the net media bit rate
media sender and at the media receiver unless any mixing or will have the same value at the media sender and at the
translating of the media has occurred. media receiver unless any mixing or translating of the
media has occurred.
For a given observer, the total media bit rate for a media 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 stream is equal to the sum of the net media bit rate and
per-packet overhead as defined above multiplied by the packet the per-packet overhead as defined above multiplied by the
rate. packet rate.
Feasible region: Feasible region:
The set of all combinations of packet rate and net media bit The set of all combinations of packet rate and net media
rate that do not exceed the restrictions in maximum media bit bit rate that do not exceed the restrictions in maximum
rate placed on a given media sender by the Temporary Maximum media bit rate placed on a given media sender by the
Media Stream Bit-rate Request (TMMBR) messages it has Temporary Maximum Media Stream Bit-rate Request (TMMBR)
received. The feasible region will change as new TMMBR messages it has received. The feasible region will change
messages are received. as new TMMBR messages are received.
Bounding set: Bounding set:
The set of TMMBR tuples, selected from all those received at a The set of TMMBR tuples, selected from all those received
given media sender, that define the feasible region for that at a given media sender, that define the feasible region
media sender. The media sender uses an algorithm such as that for that media sender. The media sender uses an algorithm
in section 3.5.4.2 to determine or iteratively approximate the such as that in section 3.5.4.2 to determine or iteratively
current bounding set, and reports that set back to the media approximate the current bounding set, and reports that set
receivers in a Temporary Maximum Media Stream Bit-rate back to the media receivers in a Temporary Maximum Media
Notification (TMMBN) message. Stream Bit-rate Notification (TMMBN) message.
2.3. Topologies 2.3. Topologies
Please refer to [Topologies] for an in depth discussion. The Please refer to [Topologies] for an in depth discussion. The
topologies referred to throughout this memo are labeled (consistently topologies referred to throughout this memo are labeled
with [Topologies]) as follows: (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
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 quote relevant drawn up [Basso]. This draft has expired; however we quote
sections of it to provide motivation and requirements. relevant 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 us begin by looking through the use cases Basso et al. messages. Let us begin by looking through the use cases Basso et
[Basso] proposed. Some of the use cases have been reformulated and al. [Basso] proposed. Some of the use cases have been
comments have been added. reformulated and 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
single encoded video stream. Each time a video source is added, a single encoded video stream. Each time a video source is
the RTP mixer needs to request a decoder refresh point from the added, the RTP mixer needs to request a decoder refresh point
video source, so as to start an uncorrupted prediction chain on from the video source, so as to start an uncorrupted prediction
the spatial area of the mixed picture occupied by the data from chain on the spatial area of the mixed picture occupied by the
the new video source. data from the new video source.
2. An RTP video mixer receives multiple encoded RTP video streams 2. An RTP video mixer receives multiple encoded RTP video streams
from conference participants, and dynamically selects one of the from conference participants, and dynamically selects one of
streams to be included in its output RTP stream. At the time of a the streams to be included in its output RTP stream. At the
bit stream change (determined through means such as voice time of a bit stream change (determined through means such as
activation or the user interface), the mixer requests a decoder voice activation or the user interface), the mixer requests a
refresh point from the remote source, in order to avoid using decoder refresh point from the remote source, in order to avoid
unrelated content as reference data for inter picture prediction. using unrelated content as reference data for inter picture
After requesting the decoder refresh point, the video mixer stops prediction. After requesting the decoder refresh point, the
the delivery of the current RTP stream and monitors the RTP stream video mixer stops the delivery of the current RTP stream and
from the new source until it detects data belonging to the decoder monitors the RTP stream from the new source until it detects
refresh point. At that time, the RTP mixer starts forwarding the data belonging to the decoder refresh point. At that time, the
newly selected stream to the receiver(s). RTP mixer starts forwarding the newly selected stream to the
receiver(s).
3. An application needs to signal to the remote encoder that the 3. An application needs to signal to the remote encoder that the
desired trade-off between temporal and spatial resolution has desired trade-off between temporal and spatial resolution has
changed. For example, one user may prefer a higher frame rate and changed. For example, one user may prefer a higher frame rate
a lower spatial quality, and another user may prefer the opposite. and a lower spatial quality, and another user may prefer the
This choice is also highly content dependent. Many current video opposite. This choice is also highly content dependent. Many
conferencing systems offer in the user interface a mechanism to current video conferencing systems offer in the user interface
make this selection, usually in the form of a slider. The a mechanism to make this selection, usually in the form of a
mechanism is helpful in point-to-point, centralized multipoint and slider. The mechanism is helpful in point-to-point,
non-centralized multipoint uses. centralized multipoint and non-centralized multipoint uses.
4. Use case 4 of the Basso draft applies only to Picture Loss 4. Use case 4 of the Basso draft applies only to Picture Loss
Indication (PLI) as defined in AVPF [RFC4585] and is not Indication (PLI) as defined in AVPF [RFC4585] and is not
reproduced here. 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 trans-rating. One way of achieving this is to set up stream trans-rating. One way of achieving this is to set up
sessions with endpoints using the maximum bit rate accepted by sessions with endpoints using the maximum bit rate accepted by
each endpoint, and accepted by the call admission method used by each endpoint, and accepted by the call admission method used
the mixer. By means of commands that reduce the maximum media by the mixer. By means of commands that reduce the maximum
stream bit rate below what has been negotiated during session set media stream bit rate below what has been negotiated during
up, the mixer can reduce the maximum bit rate sent by endpoints to session set up, the mixer can reduce the maximum bit rate sent
the lowest of all the accepted bit rates. As the lowest accepted by endpoints to the lowest of all the accepted bit rates. As
bit rate changes due to endpoints joining and leaving or due to the lowest accepted bit rate changes due to endpoints joining
network congestion, the mixer can adjust the limits at which and leaving or due to network congestion, the mixer can adjust
endpoints can send their streams to match the new value. The the limits at which endpoints can send their streams to match
mixer then requests a new maximum bit rate, which is equal to or the new value. The mixer then requests a new maximum bit rate,
less than the maximum bit rate negotiated at session setup for a which is equal to or less than the maximum bit rate negotiated
specific media stream, and the remote endpoint can respond with at session setup for a specific media stream, and the remote
the actual bit rate that it can support. endpoint can respond with 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 foresee. However we would like to extend the list with two
additional use cases: additional use cases:
7. Currently deployed congestion control algorithms (AMID and TFRC 7. Currently deployed congestion control algorithms (AMID and TFRC
[RFC3448]) probe for additional available capacity as long as [RFC3448]) probe for additional available capacity as long as
there is something to send. With congestion control algorithms there is something to send. With congestion control algorithms
using packet loss as the indication for congestion, this probing using packet loss as the indication for congestion, this
does generally result in reduced media quality (often to a point probing does generally result in reduced media quality (often
where the distortion is large enough to make the media unusable), to a point where the distortion is large enough to make the
due to packet loss and increased delay. media unusable), due to packet loss and increased delay.
In a number of deployment scenarios, especially cellular ones, the In a number of deployment scenarios, especially cellular ones,
bottleneck link is often the last hop link. That cellular link the bottleneck link is often the last hop link. That cellular
also commonly has some type of QoS negotiation enabling the link also commonly has some type of QoS negotiation enabling
cellular device to learn the maximal bit rate available over this the cellular device to learn the maximal bit rate available
last hop. A media receiver behind this link can, in most (if not over this last hop. A media receiver behind this link can, in
all) cases, calculate at least an upper bound for the bit rate most (if not all) cases, calculate at least an upper bound for
available for each media stream it presently receives. How this the bit rate available for each media stream it presently
is done is an implementation detail and not discussed herein. receives. How this is done is an implementation detail and not
Indicating the maximum available bit rate to the transmitting discussed herein. Indicating the maximum available bit rate to
party for the various media streams can be beneficial to prevent the transmitting party for the various media streams can be
that party from probing for bandwidth for this stream in excess of beneficial to prevent that party from probing for bandwidth for
a known hard limit. For cellular or other mobile devices, the this stream in excess of a known hard limit. For cellular or
known available bit rate for each stream (deduced from the link other mobile devices, the known available bit rate for each
bit rate) can change quickly, due to handover to another stream (deduced from the link bit rate) can change quickly, due
transmission technology, QoS renegotiation due to congestion, etc. to handover to another transmission technology, QoS
To enable minimal disruption of service, quick convergence is renegotiation due to congestion, etc. To enable minimal
necessary, and therefore media path signaling is desirable. disruption of service, quick convergence is 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
and is now widely deployed. When RPS is in use, simplistically [NEWPRED], and is now widely deployed. When RPS is in use,
put, the receiver can send a feedback message to the sender, simplistically put, the receiver can send a feedback message to
indicating a reference picture that should be used for future the sender, indicating a reference picture that should be used
prediction. ([NEWPRED] mentions other forms of feedback as well.) for future prediction. ([NEWPRED] mentions other forms of
AVPF contains a mechanism for conveying such a message, but did feedback as well.) AVPF contains a mechanism for conveying
not specify for which codec and according to which syntax the such a message, but did not specify for which codec and
message should conform. Recently, the ITU-T finalized Rec. H.271 according to which syntax the message should conform.
which (among other message types) also includes a feedback Recently, the ITU-T finalized Rec. H.271 which (among other
message. It is expected that this feedback message will fairly message types) also includes a feedback message. It is
quickly enjoy wide support. Therefore, a mechanism to convey expected that this feedback message will fairly quickly enjoy
feedback messages according to H.271 appears to be desirable. wide support. Therefore, a mechanism to convey 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 often separate the control and media First, systems employing MCUs often separate the control and media
processing parts. As these messages are intended for or generated by processing parts. As these messages are intended for or generated
the media part rather than the signaling part of the MCU, having them by the media part rather than the signaling part of the MCU,
on the media path avoids transmission across interfaces and having them on the media path avoids transmission across
unnecessary control traffic between signaling and processing. If the interfaces and unnecessary control traffic between signaling and
MCU is physically decomposed, the use of the media path avoids the processing. If the MCU is physically decomposed, the use of the
need for media control protocol extensions (e.g. in MEGACO media path avoids the need for media control protocol extensions
[RFC3525]). (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
processing and due to their complex and more generic nature may media processing and due to their complex and more generic nature
result in significant processing delay. The topological locations of may result in significant processing delay. The topological
the signaling entities are also commonly not optimized for minimal locations of the signaling entities are also commonly not
delay, but rather towards other architectural goals. Thus the optimized for minimal delay, but rather towards other
signaling path can be significantly longer in both geographical and architectural goals. Thus the signaling path can be significantly
delay sense. longer in both geographical and delay sense.
3.3. Using AVPF 3.3. Using AVPF
The AVPF feedback message framework [RFC4585] provides the The AVPF feedback message framework [RFC4585] provides the
appropriate framework to implement the new messages. AVPF implements appropriate framework to implement the new messages. AVPF
rules controlling the timing of feedback messages to avoid congestion implements rules controlling the timing of feedback messages to
through network flooding by RTCP traffic. We re-use these rules by avoid congestion through network flooding by RTCP traffic. We re-
referencing AVPF. use these rules by referencing AVPF.
The signaling setup for AVPF allows each individual type of function The signaling setup for AVPF allows each individual type of
to be configured or negotiated on an RTP session basis. function 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
requirements in terms of reliability. However, in all cases, the different requirements in terms of reliability. However, in all
reaction to an (occasional) loss of a feedback message is specified. cases, the reaction to an (occasional) loss of a feedback message
is specified.
3.4. Multicast 3.4. Multicast
The codec control messages might be used with multicast. The RTCP The codec control messages might be used with multicast. The RTCP
timing rules specified in [RFC3550] and [RFC4585] ensure that the timing rules specified in [RFC3550] and [RFC4585] ensure that the
messages do not cause overload of the RTCP connection. The use of messages do not cause overload of the RTCP connection. The use of
multicast may result in the reception of messages with inconsistent multicast may result in the reception of messages with
semantics. The reaction to inconsistencies depends on the message inconsistent semantics. The reaction to inconsistencies depends
type, and is discussed for each message type separately. on the message type, and is discussed for each message type
separately.
3.5. Feedback Messages 3.5. Feedback Messages
This section describes the semantics of the different feedback This section describes the semantics of the different feedback
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
media sender, requires that the media sender sends a Decoder Refresh designated media sender, requires that the media sender sends a
Point (see 2.2) at the earliest opportunity. The evaluation of such Decoder Refresh Point (see 2.2) at the earliest opportunity. The
opportunity includes the current encoder coding strategy and the evaluation of such opportunity includes the current encoder coding
current available network resources. strategy and the current available network resources.
FIR is also known as an "instantaneous decoder refresh request" or FIR is also known as an "instantaneous decoder refresh request" 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
media types that are not video, the analogue applies. For example, predictive media types that are not video, the analogue applies.
if in MPEG-4 systems scene updates are used, the decoder refresh For example, if in MPEG-4 systems scene updates are used, the
point consists of the full representation of the scene and is not decoder refresh point consists of the full representation of the
delta-coded relative to previous updates. scene and is not 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.
in scenarios in which the available bit rate is small, the use of a Thus, in scenarios in which the available bit rate is small, the
decoder refresh point implies a delay that is significantly longer use of a decoder refresh point implies a delay that is
than the typical picture duration. significantly longer than the typical picture duration.
Usage in multicast is possible; however aggregation of the commands Usage in multicast is possible; however aggregation of the
is recommended. A receiver that receives a request closely (within 2 commands is recommended. A receiver that receives a request
times the longest Round Trip Time (RTT) known, plus any AVPF-induced closely (within 2 times the longest Round Trip Time (RTT) known,
RTCP packet sending delays, if those are known) after sending a plus any AVPF-induced RTCP packet sending delays, if those are
decoder refresh point, should await a second request message to known) after sending a decoder refresh point, should await a
ensure that the media receiver has not been served by the previously second request message to ensure that the media receiver has not
delivered decoder refresh point. The reason for the specified delay been served by the previously delivered decoder refresh point.
is to avoid sending unnecessary decoder refresh points. A session The reason for the specified delay is to avoid sending unnecessary
participant may have sent its own request while another participant's decoder refresh points. A session participant may have sent its
request was in-flight to them. Suppressing those requests that may own request while another participant's request was in-flight to
have been sent without knowledge about the other request avoids this them. Suppressing those requests that may have been sent without
issue. knowledge about the other request avoids this issue.
Using the FIR command to recover from errors is explicitly Using the FIR command to recover from errors is explicitly
disallowed, and instead the PLI message defined in AVPF [RFC4585] disallowed, and instead the PLI message defined in AVPF [RFC4585]
should be used. The PLI message reports lost pictures and has been should be used. The PLI message reports lost pictures and has
included in AVPF for precisely that purpose. been included in AVPF for precisely that purpose.
Full Intra Request is applicable in use-cases 1 and 2. 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, unless the message is lost. Decoder refresh points are
easily identifiable from the bit stream. Therefore, there is no
need for protocol-level notification, and a simple command
repetition mechanism is sufficient for ensuring the level of
reliability required. However, the potential use of repetition
does require a mechanism to prevent the recipient from responding
to messages already received and responded to.
The FIR message results in the delivery of a decoder refresh point, To ensure the best possible reliability, a sender of FIR may
unless the message is lost. Decoder refresh points are easily repeat the FIR request until the desired content has been
identifiable from the bit stream. Therefore, there is no need for received. The repetition interval is determined by the RTCP
protocol-level notification, and a simple command repetition timing rules applicable to the session. Upon reception of a
mechanism is sufficient for ensuring the level of reliability complete decoder refresh point or the detection of an attempt to
required. However, the potential use of repetition does require a send a decoder refresh point (which got damaged due to a packet
mechanism to prevent the recipient from responding to messages loss), the repetition of the FIR must stop. If another FIR is
already received and responded to. necessary, the request sequence number must be increased. A FIR
sender shall not have more than one FIR request (different request
To ensure the best possible reliability, a sender of FIR may repeat sequence number) outstanding at any time per media sender in the
the FIR request until the desired content has been received. The session.
repetition interval is determined by the RTCP timing rules applicable
to the session. Upon reception of a complete decoder refresh point
or the detection of an attempt to send a decoder refresh point (which
got damaged due to a packet loss), the repetition of the FIR must
stop. If another FIR is necessary, the request sequence number must
be increased. 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.
The receiver of FIR (i.e. the media sender) behaves in complementary The receiver of FIR (i.e. the media sender) behaves in
fashion to ensure delivery of a decoder refresh point. If it complementary fashion to ensure delivery of a decoder refresh
receives repetitions of the FIR more than 2*RTT after it has sent a point. If it receives repetitions of the FIR more than 2*RTT
decoder refresh point, it shall send a new decoder refresh point. after it has sent a decoder refresh point, it shall send a new
Two round trip times allow time for the decoder refresh point to decoder refresh point. Two round trip times allow time for the
arrive back to the requestor and for the end of repetitions of FIR to decoder refresh point to arrive back to the requestor and for the
reach and be detected by the media sender. 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 An RTP mixer that receives an FIR from a media receiver is
responsible to ensure that a decoder refresh point is delivered to 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. From a reliability perspective, the two legs generate FIR commands. From a reliability perspective, the two
(FIR-requesting endpoint to mixer, and mixer to decoder refresh point legs (FIR-requesting endpoint to mixer, and mixer to decoder
generating endpoint) are handled independently from each other. refresh point 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
the typical picture duration. See use case 3 for an example. The than the typical picture duration. See use case 3 for an example.
encoder decides whether and to what extent the request results in a The encoder decides whether and to what extent the request results
change of the trade-off. It returns a Temporal Spatial Trade-Off in a change of the trade-off. It returns a Temporal Spatial
Notification (TSTN) message to indicate the trade-off that it will Trade-Off Notification (TSTN) message to indicate the trade-off
use henceforth. that it will use henceforth.
TSTR and TSTN have been introduced primarily because it is believed
that control protocol mechanisms, e.g. a SIP re-invite, are too
heavyweight and too slow to allow for a reasonable user experience.
Consider, for example, a user interface where the remote user selects TSTR and TSTN have been introduced primarily because it is
the temporal/spatial trade-off with a slider (as it is common in believed that control protocol mechanisms, e.g. a SIP re-invite,
state-of-the-art video conferencing systems). An immediate feedback are too heavyweight and too slow to allow for a reasonable user
to any slider movement is required for a reasonable user experience. experience. Consider, for example, a user interface where the
A SIP re-INVITE [RFC3261] would require at least two round-trips more remote user selects the temporal/spatial trade-off with a slider
(compared to the TSTR/TSTN mechanism) and may involve proxies and (as it is common in state-of-the-art video conferencing systems).
other complex mechanisms. Even in a well-designed system, it could An immediate feedback to any slider movement is required for a
take a second or so until finally the new trade-off is selected. reasonable user experience. A SIP re-INVITE [RFC3261] would
require at least two round-trips more (compared to the TSTR/TSTN
mechanism) and may involve proxies and other complex mechanisms.
Even in a well-designed system, it could take a second or so until
finally the new trade-off is selected.
Furthermore the use of RTCP solves the multicast use case very Furthermore the use of RTCP solves the multicast use case very
efficiently. 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 achieved in many implementation-specific ways. subject, and can be achieved in many implementation-specific ways.
Problems stem 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,
the new trade-off chosen by its own criteria (which may or may not be carrying the new trade-off chosen by its own criteria (which may
based on the trade-off conveyed by the TSTR). In other words, the or may not be based on the trade-off conveyed by the TSTR). In
trade-off sent in TSTR is a non-binding recommendation, nothing more. other words, the trade-off sent in TSTR is a non-binding
recommendation, nothing more.
Four TSTR/TSTN scenarios need to be distinguished, based on the Four TSTR/TSTN scenarios need to be distinguished, based on the
topologies described in [Topologies]. The scenarios are described in topologies described in [Topologies]. The scenarios are described
the following sub-clauses. in 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, subject to its own capabilities. The TSTN requested value in TSTR, subject to its own capabilities. The
message conveys back the new trade-off value (which may be identical TSTN message conveys back the new trade-off value (which may be
to the old one if, for example, the sender is not capable of identical to the old one if, for example, the sender is not
adjusting its trade-off). capable of 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
Multicast, or following RFC 3550's translator model according to Topo-Multicast, or following RFC 3550's translator model according
Topo-Translator. In these cases, unsynchronized TSTR messages from to Topo-Translator. In these cases, unsynchronized TSTR messages
different receivers may be received, possibly with different from 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).
memo does not specify how the media sender tunes its trade-off. This memo does not specify how the media sender tunes its trade-
Possible strategies include selecting the mean or median of all off. Possible strategies include selecting the mean or median of
trade-off requests received, giving priority to certain participants, all trade-off requests received, giving priority to certain
or continuing to use the previously selected trade-off (e.g. when the participants, or continuing to use the previously selected trade-
sender is not capable of adjusting it). Again, all TSTR messages off (e.g. when the sender is not capable of adjusting it). Again,
need to be acknowledged by TSTN, and the value conveyed back has to all TSTR messages need to be acknowledged by TSTN, and the value
reflect the decision made. conveyed back has to 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). As in the previous scenario, the strategy for forming sender(s). As in the previous scenario, the strategy for forming
this "consensus" is up to the implementation, and can, for example, this "consensus" is up to the implementation, and can, for
encompass averaging the participants' request values, giving priority example, encompass averaging the participants' request values,
to certain participants, or using session default values. giving priority to certain participants, or using session default
values.
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
content the mixer or translator receives is already close to that the content the mixer or translator receives is already close to
trade-off. Thus if the mixer changes its trade-off, it needs to that trade-off. Thus if the mixer changes its trade-off, it needs
request the media sender(s) to use the new value, by creating a TSTR to request the media sender(s) to use the new value, by creating a
of its own. Upon reaching a decision on the used trade-off it TSTR of its own. Upon reaching a decision on the used trade-off
includes that value in the acknowledgement to the downstream it includes that value in the acknowledgement to the downstream
requestors. Only in cases where the original source has requestors. Only in cases where the original source has
substantially higher quality (and bit rate), is it likely that substantially higher quality (and bit rate), is it likely that
transcoding alone can result in the requested trade-off. 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.
A request and reception acknowledgement mechanism is specified. The The Temporal Spatial Trade-off Notification (TSTN) message informs
Temporal Spatial Trade-off Notification (TSTN) message informs the the request-sender that its request has been received, and what
request-sender that its request has been received, and what trade-off trade-off is used henceforth. This acknowledgment mechanism is
is used henceforth. This acknowledgment mechanism is desirable for desirable for at 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 knowing the chosen o User feedback cannot be implemented without knowing the chosen
trade-off value, according to the media sender's constraints. trade-off value, according to the media sender's constraints.
o Repetitive sending of messages requesting an unimplementable trade- o Repetitive sending of messages requesting an unimplementable
off can be avoided. trade-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 structure defined in reaction to a video back channel message. The structure defined
this memo is used to transparently convey such a message from media in this memo is used to transparently convey such a message from
receiver to media sender. In this memo, we refrain from an in-depth media receiver to media sender. In this memo, we refrain from an
discussion of the available code points within H.271 and refer to the in-depth discussion of the available code points within H.271 and
specification text [H.271] instead. refer to the 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
scenarios. Table 1 provides a brief, oversimplifying overview of the multipoint scenarios. Table 1 provides a brief, oversimplifying
messages currently defined in H.271, their roughly corresponding AVPF overview of the messages currently defined in H.271, their roughly
or CCM messages (the latter as specified in this memo), and an corresponding AVPF or CCM messages (the latter as specified in
indication of our current knowledge of their multicast safety. this memo), and an 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 picture loss AVPF PLI Yes 1 picture loss AVPF PLI Yes
2 partial loss AVPF SLI Yes 2 partial loss AVPF SLI Yes
3 one parameter CRC N/A Yes (no required sender action) 3 one parameter CRC N/A Yes (no required sender action)
4 all parameter CRC N/A Yes (no required sender action) 4 all parameter CRC N/A Yes (no required sender action)
5 refresh point CCM FIR Yes 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 Reference Picture Selection Indication (RPSI); it is an AVPF's Reference Picture Selection Indication (RPSI); it is
indication of known-as-correct reference picture(s) at the an indication of known-as-correct reference picture(s) at
decoder. It does not command an encoder to use a defined the decoder. It does not command an encoder to use a
reference picture (the form of control information envisioned defined reference picture (the form of control information
to be carried in RPSI). However, it is believed and intended envisioned to be carried in RPSI). However, it is believed
that H.271 message type 0 will be used for the same purpose as and intended that H.271 message type 0 will be used for the
AVPF's RPSI -- although other use forms are also possible. same purpose as 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
respect to the multicast safety, the following guidelines MUST be with respect to the multicast safety, the following guidelines
followed when an implementation wishes to employ the H.271 video back MUST be followed when an implementation wishes to employ the H.271
channel message: video back channel message:
1. Implementations utilizing the H.271 feedback message MUST stay in 1. Implementations utilizing the H.271 feedback message MUST stay
compliance with congestion control principles, as outlined in in compliance with congestion control principles, as outlined
section 5. in section 5.
2. An implementation SHOULD utilize the IETF-native messages as 2. An implementation SHOULD utilize the IETF-native messages as
defined in [RFC4585] and in this memo instead of similar messages defined in [RFC4585] and in this memo instead of similar
defined in [H.271]. Our current understanding of similar messages messages defined in [H.271]. Our current understanding of
is documented in Table 1 above. One good reason to divert from similar messages is documented in Table 1 above. One good
the SHOULD statement above would be if it is clearly understood reason to divert from the SHOULD statement above would be if it
that, for a given application and video compression standard, the is clearly understood that, for a given application and video
aforementioned "similarity" is not given, in contrast to what 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 code points currently 3. It has been observed that some of the H.271 code points
in existence are not multicast-safe. Therefore, the sensible currently in existence are not multicast-safe. Therefore, the
thing to do is not to use the H.271 feedback message type in sensible thing to do is not to use the H.271 feedback message
multicast environments. It MAY be used only when all the issues type in multicast environments. It MAY be used only when all
mentioned later are fully understood by the implementer, and the issues mentioned later are fully understood by the
properly taken into account by all endpoints. In all other cases, implementer, and properly taken into account by all endpoints.
the H.271 message type MUST NOT be used in conjunction with In all other cases, the H.271 message type MUST NOT be used in
multicast. conjunction with 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
mixer and cooperative endpoints is a very difficult and tedious a mixer and cooperative endpoints is a very difficult and
task. Therefore, H.271 messages MUST NOT be used in centralized tedious task. Therefore, H.271 messages MUST NOT be used in
multipoint scenarios, unless all the issues mentioned below are centralized multipoint scenarios, unless all the issues
fully understood by the implementer, and properly taken into mentioned below are fully understood by the implementer, and
account by both mixer and endpoints. properly taken into 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
multipoint environments: in multipoint environments:
1. Different state on different receivers. In many environments it 1. Different state on different receivers. In many environments
cannot be guaranteed that the decoder state of all media receivers it cannot be guaranteed that the decoder state of all media
is identical at any given point in time. The most obvious reason receivers is identical at any given point in time. The most
for such a possible misalignment of state is a loss that occurs on obvious reason for such a possible misalignment of state is a
the path to only one of many media receivers. However, there are loss that occurs on the path to only one of many media
other not so obvious reasons, such as recent joins to the receivers. However, there are other not so obvious reasons,
multipoint conference (be it by joining the multicast group or such as recent joins to the multipoint conference (be it by
through additional mixer output). Different states can lead the joining the multicast group or through additional mixer
media receivers to issue potentially contradicting H.271 messages output). Different states can lead the media receivers to
(or one media receiver issuing an H.271 message that, when issue potentially contradicting H.271 messages (or one media
observed by the media sender, is not helpful for the other media receiver issuing an H.271 message that, when observed by the
receivers). A naive reaction of the media sender to these media sender, is not helpful for the other media receivers). A
contradicting messages can lead to unpredictable and annoying naive reaction of the media sender to these contradicting
results. messages can lead to unpredictable and annoying 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
is unreliable (there may well be other reasons). In case of many transport is unreliable (there may well be other reasons). In
H.271 messages (i.e. types 0, 2, 3, and 4), the algorithm for case of many H.271 messages (i.e. types 0, 2, 3, and 4), the
combining must be aware both of the network/protocol environment algorithm for combining must be aware both of the
(i.e. with respect to congestion) and of the media codec employed, network/protocol environment (i.e. with respect to congestion)
as H.271 messages of a given type can have different semantics for and of the media codec employed, as H.271 messages of a given
different media codecs. type can have different semantics for 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
mechanisms 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).
example, a receiver is often required to refrain from (or delay) For example, a receiver is often required to refrain from (or
generating requests, based on information it receives from the delay) generating requests, based on information it receives
media stream. For instance, it makes no sense for a receiver to from the media stream. For instance, it makes no sense for a
issue a FIR when a transmission of an Intra/IDR picture is receiver to issue a FIR when a transmission of an Intra/IDR
ongoing. picture is 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
omit sending these messages. For the media sender this looks like even omit sending these messages. For the media sender this
data has not been properly received (although it was received looks like data has not been properly received (although it was
properly), and a naively implemented media sender reacts to these received properly), and a naively implemented media sender
perceived problems where it should not. reacts to these 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 confirmation of the reception of a message can be transmission, and confirmation of the reception of a message can
derived from the forward video bit stream. Therefore, no specific be derived from the forward video bit stream. Therefore, no
reception acknowledgement is specified. specific 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 (see 2.2) to, or below, limit the maximum bit rate for a media stream (see 2.2) to, or
the provided value. The Temporary Maximum Media Stream Bit Rate below, the provided value. The Temporary Maximum Media Stream Bit
Notification (TMMBN) contains the media sender's current view of the Rate Notification (TMMBN) contains the media sender's current view
most limiting subset of the TMMBR-defined limits it has received, to of the most limiting subset of the TMMBR-defined limits it has
help the participants to suppress TMMBR requests that would not received, to help the participants to suppress TMMBR requests that
further restrict the media sender. The primary usage for the would not further restrict the media sender. The primary usage
TMMBR/TMMBN messages is in a scenario with an MCU or mixer (use case for the TMMBR/TMMBN messages is in a scenario with an MCU or mixer
6), corresponding to Topo-Translator or Topo-Mixer, but also to (use case 6), corresponding to Topo-Translator or Topo-Mixer, but
Topo-Point-to-Point. also to Topo-Point-to-Point.
Each temporary limitation on the media stream is expressed as a Each temporary limitation on the media stream is expressed as a
tuple. The first component of the tuple is the maximum total media tuple. The first component of the tuple is the maximum total
bit rate (as defined in section 2.2) that the media receiver is media bit rate (as defined in section 2.2) that the media receiver
currently prepared to accept for this media stream. The second is currently prepared to accept for this media stream. The second
component is the per-packet overhead that the media receiver has component is the per-packet overhead that the media receiver has
observed for this media stream at its chosen reference protocol observed for this media stream at its chosen reference protocol
layer. layer.
As indicated in section 2.2, the overhead as observed by the sender As indicated in section 2.2, the overhead as observed by the
of the TMMBR (i.e. the media receiver) may differ from the overhead sender of the TMMBR (i.e. the media receiver) may differ from the
observed at the receiver of the TMMBR (i.e. the media sender) due to overhead observed at the receiver of the TMMBR (i.e. the media
use of a different reference protocol layer at the other end or due sender) due to use of a different reference protocol layer at the
to the intervention of translators or mixers that affect the amount other end or due to the intervention of translators or mixers that
of per packet overhead. For example, a gateway in between the two affect the amount of per packet overhead. For example, a gateway
that converts between IPv4 and IPv6 affects the per-packet overhead in between the two that converts between IPv4 and IPv6 affects the
by 20 bytes. Other mechanisms that change the overhead include per-packet overhead by 20 bytes. Other mechanisms that change the
tunnels. The problem with varying overhead is also discussed in overhead include tunnels. The problem with varying overhead is
[RFC3890]. As will be seen in the description of the algorithm for also discussed in [RFC3890]. As will be seen in the description
use of TMMBR, the difference in perceived overhead between the of the algorithm for use of TMMBR, the difference in perceived
sending and receiving ends presents no difficulty because overhead between the sending and receiving ends presents no
calculations are carried out in terms of variables (packet rate, net difficulty because calculations are carried out in terms of
media bit rate) that have the same value at the sender as at the variables (packet rate, net media bit rate) that have the same
receiver. value at the sender as at the receiver.
Reporting both maximum total media bit rate and per-packet overhead Reporting both maximum total media bit rate and per-packet
allows different receivers to provide bit rate and overhead values overhead allows different receivers to provide bit rate and
for different protocol layers, for example at the IP level, at the overhead values for different protocol layers, for example at the
outer part of a tunnel protocol, or at the link layer. The protocol IP level, at the outer part of a tunnel protocol, or at the link
level a peer reports on depends on the level of integration the peer layer. The protocol level a peer reports on depends on the level
has, as it needs to be able to extract the information from that of integration the peer has, as it needs to be able to extract the
protocol level. For example, an application with no knowledge of the information from that protocol level. For example, an application
IP version it is running over can not meaningfully determine the with no knowledge of the IP version it is running over can not
overhead of the IP header, and hence will not want to include IP meaningfully determine the overhead of the IP header, and hence
overhead in the overhead or maximum total media bit rate calculation. 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 It is expected that most peers will be able to report values at
for the IP layer. In certain implementations it may be advantageous least for the IP layer. In certain implementations it may be
to also include information pertaining to the link layer, which in advantageous to also include information pertaining to the link
turn allows for a more precise overhead calculation and a better layer, which in turn allows for a more precise overhead
optimization of connectivity resources. calculation and a better optimization of connectivity resources.
The Temporary Maximum Media Stream Bit Rate messages are generic 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 them from the other codec control messages defined in this separates them from the other codec control messages defined in
specification, which apply only to specific media types or payload this specification, which apply only to specific media types or
formats. The TMMBR functionality applies to the transport, and the payload formats. The TMMBR functionality applies to the
requirements the transport places on the media encoding. transport, and the 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
session maximum bit rate, using a signaling protocol. This value can a session maximum bit rate, using a signaling protocol. This
be global, for example in case of point-to-point, multicast, or value can be global, for example in case of point-to-point,
translators. It may also be local between the participant and the multicast, or translators. It may also be local between the
peer or mixer. In either case, the bit rate negotiated in signaling participant and the peer or mixer. In either case, the bit rate
is the one that the participant guarantees to be able to handle negotiated in signaling is the one that the participant guarantees
(depacketize and decode). In practice, the connectivity of the to be able to handle (depacketize and decode). In practice, the
participant also influences the negotiated value -- it does not make connectivity of the participant also influences the negotiated
much sense to negotiate a total media bit rate that one's network value -- it does not make much sense to negotiate a total media
interface does not support. bit rate that one's network 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 an SDP [RFC4566] attribute the session or sender. RFC 3890 provides an SDP [RFC4566]
that can be used for this purpose; however, that attribute is not attribute that can be used for this purpose; however, that
usable in RTP sessions established using offer/answer [RFC3264]. attribute is not usable in RTP sessions established using
Therefore an optional maximum packet rate signaling parameter is offer/answer [RFC3264]. Therefore an optional maximum packet rate
specified in this memo. signaling parameter is specified in this memo.
An already established maximum total media bit rate may be changed at An already established maximum total media bit rate may be changed
any time, subject to the timing rules governing the sending of at any time, subject to the timing rules governing the sending of
feedback messages. The limit may change to any value between zero and feedback messages. The limit may change to any value between zero
the session maximum, as negotiated during session establishment and the session maximum, as negotiated during session
signaling. However, even if a sender has received a TMMBR message establishment signaling. However, even if a sender has received a
allowing an increase in the bit rate, all increases must be governed TMMBR message allowing an increase in the bit rate, all increases
by a congestion control mechanism. TMMBR indicates known limitations must be governed by a congestion control mechanism. TMMBR
only, usually in the local environment, and does not provide any indicates known limitations only, usually in the local
guarantees about the full path. Furthermore, any increases in TMMBR- environment, and does not provide any guarantees about the full
established bit rate limits are to be executed only after a certain path. Furthermore, any increases in TMMBR-established bit rate
delay from the sending of the TMMBN message that notifies the world limits are to be executed only after a certain delay from the
about the increase in limit. The delay is specified as at least sending of the TMMBN message that notifies the world about the
twice the longest RTT as known by the media sender, plus the media increase in limit. The delay is specified as at least twice the
sender's calculation of the required wait time for the sending of longest RTT as known by the media sender, plus the media sender's
another TMMBR message for this session based on AVPF timing rules. calculation of the required wait time for the sending of another
This delay is introduced to allow other session participants to make 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. 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
for the remainder of the session, the TMMBR sender is expected to valid for the remainder of the session, the TMMBR sender is
perform a renegotiation of the session upper limit using the session expected to perform a renegotiation of the session upper limit
signaling protocol. using the session signaling protocol.
3.5.4.1. Behavior for media receivers using TMMBR 3.5.4.1. Behavior for media receivers using TMMBR
This section is an informal description of behaviour described more This section is an informal description of behaviour described
precisely in section 4.2. more precisely in section 4.2.
A media sender begins the session limited by the maximum media bit A media sender begins the session limited by the maximum media bit
rate and maximum packet rate negotiated in session signaling, if any. rate and maximum packet rate negotiated in session signaling, if
any. Note that this value may be negotiated for another protocol
Note that this value may be negotiated for another protocol layer layer than the one the participant uses in its TMMBR messages.
than the one the participant uses in its TMMBR messages. Each media Each media receiver selects a reference protocol layer, forms an
receiver selects a reference protocol layer, forms an estimate of the estimate of the overhead it is observing (or estimating it if no
overhead it is observing (or estimating it if no packets has been packets has been seen yet) at that reference level, and determines
seen yet) at that reference level, and determines the maximum total the maximum total media bit rate it can accept, taking into
media bit rate it can accept, taking into account its own limitations account its own limitations and any transport path limitations of
and any transport path limitations of which it may be aware. In case which it may be aware. In case the current limitations are more
the current limitations are more restricting then what was agreed on restricting then what was agreed on in the session signaling, the
in the session signaling, the media receiver reports its initial media receiver reports its initial estimate of these two
estimate of these two quantities to the media sender using a TMMBR quantities to the media sender using a TMMBR message. Overall
message. Overall message traffic is reduced by the possibility of message traffic is reduced by the possibility of including tuples
including tuples for multiple media senders in the same TMMBR for multiple media senders in the same TMMBR message.
message.
The media sender applies an algorithm such as that specified in The media sender applies an algorithm such as that specified in
section 3.5.4.2 to select which of the tuples it has received are section 3.5.4.2 to select which of the tuples it has received are
most limiting (i.e. the bounding set as defined in section 2.2). It most limiting (i.e. the bounding set as defined in section 2.2).
modifies its operation to stay within the feasible region (as defined It modifies its operation to stay within the feasible region (as
in section 2.2), and also sends out a TMMBN notification to the media defined in section 2.2), and also sends out a TMMBN notification
receivers indicating the selected bounding set. to the media receivers indicating the selected bounding set.
If a media receiver does not own one of the tuples in the bounding If a media receiver does not own one of the tuples in the bounding
set reported by the TMMBN, it applies the same algorithm as the media set reported by the TMMBN, it applies the same algorithm as the
sender to determine if its current estimated (maximum total media bit media sender to determine if its current estimated (maximum total
rate, overhead) tuple would enter the bounding set if known to the media bit rate, overhead) tuple would enter the bounding set if
media sender. If so, it issues a TMMBR request reporting the tuple known to the media sender. If so, it issues a TMMBR request
value to the sender. Otherwise it takes no action for the moment. reporting the tuple value to the sender. Otherwise it takes no
Periodically, its estimated tuple values may change or it may receive action for the moment. Periodically, its estimated tuple values
a new TMMBN. If so, it reapplies the algorithm to decide whether it may change or it may receive a new TMMBN. If so, it reapplies the
needs to issue a TMMBR request. algorithm to decide whether it needs to issue a TMMBR request.
If, alternatively, a media receiver owns one of the tuples in the If, alternatively, a media receiver owns one of the tuples in the
reported bounding set, it takes no action until such time as its 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 estimate of its own tuple values changes. At that time it sends a
TMMBR request to the media sender to report the changed values. TMMBR request to the media sender to report the changed values.
A media receiver may change status between owner and non-owner of a A media receiver may change status between owner and non-owner of
bounding tuple between one TMMBN message and the next. Thus it must a bounding tuple between one TMMBN message and the next. Thus it
check the contents of each TMMBN to determine its subsequent actions. must check the contents of each TMMBN to determine its subsequent
actions.
Implementations may use other algorithms of their choosing, as long Implementations may use other algorithms of their choosing, as
as the bit rate limitations resulting from the exchange of TMMBR and long as the bit rate limitations resulting from the exchange of
TMMBN messages are at least as strict (at least as low, in the bit TMMBR and TMMBN messages are at least as strict (at least as low,
rate dimension) as the ones resulting from the use of the in the bit rate dimension) as the ones resulting from the use of
aforementioned algorithm. the aforementioned algorithm.
Obviously, in point-to-point cases, when there is only one media Obviously, in point-to-point cases, when there is only one media
receiver, this receiver becomes "owner" once it receives the first receiver, this receiver becomes "owner" once it receives the first
TMMBN in response to its own TMMBR, and stays "owner" for the rest of TMMBN in response to its own TMMBR, and stays "owner" for the rest
the session. Therefore, when it is known that there will always be of the session. Therefore, when it is known that there will
only a single media receiver, the above algorithm is not required. always be only a single media receiver, the above algorithm is not
Media receivers that are aware they are the only ones in a session required. Media receivers that are aware they are the only ones
can send TMMBR messages with bit rate limits both higher and lower in a session can send TMMBR messages with bit rate limits both
than the previously notified limit, at any time (subject to the AVPF higher and lower than the previously notified limit, at any time
[RFC4585] RTCP RR send timing rules). However, it may be difficult (subject to the AVPF [RFC4585] RTCP RR send timing rules).
for a session participant to determine if it is the only receiver in However, it may be difficult for a session participant to
the session. Because of this any implementation of TMMBR is required determine if it is the only receiver in the session. Because of
to include the algorithm described in the next section or a stricter this any implementation of TMMBR is required to include the
equivalent. algorithm described in the next section or a stricter equivalent.
3.5.4.2. Algorithm for establishing current limitations 3.5.4.2. Algorithm for establishing current limitations
This section introduces an example algorithm for the calculation of a This section introduces an example algorithm for the calculation
session limit. Other algorithms can be employed, as long as the of a session limit. Other algorithms can be employed, as long as
result of the calculation is at least as restrictive as the result the result of the calculation is at least as restrictive as the
that is obtained by this algorithm. 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
for limiting the media sender's behavior. The bit rate and the tuple for limiting the media sender's behavior. The bit rate and
overhead value result in a two-dimensional solution space for the the overhead value result in a two-dimensional solution space for
calculation of the bit rate of media streams. Fortunately the two the calculation of the bit rate of media streams. Fortunately the
variables are linked. Specifically, the bit rate available for RTP two variables are linked. Specifically, the bit rate available for
payloads is equal to the TMMBR reported bit rate minus the packet RTP payloads is equal to the TMMBR reported bit rate minus the
rate used, multiplied by the TMMBR reported overhead converted to packet rate used, multiplied by the TMMBR reported overhead
bits. As a result, when different bit rate/overhead combinations converted to bits. As a result, when different bit rate/overhead
need to be considered, the packet rate determines the correct combinations need to be considered, the packet rate determines the
limitation. This is perhaps best explained by an example: correct limitation. This is perhaps best explained by an example:
Example: Example:
Receiver A: TMMBR_max total BR = 35 kbps, TMMBR_OH = 40 bytes Receiver A: TMMBR_max total BR = 35 kbps, TMMBR_OH = 40 bytes
Receiver B: TMMBR_max total BR = 40 kbps, TMMBR_OH = 60 bytes 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_net media_BR_A = TMMBR_max total BR_A - PR * TMMBR_OH_A * 8 ... Max_net media_BR_A = TMMBR_max total BR_A - PR * TMMBR_OH_A * 8
(1) ... (1)
Max_net media_BR_B = TMMBR_max total BR_B - PR * TMMBR_OH_B * 8 ... Max_net media_BR_B = TMMBR_max total BR_B - PR * TMMBR_OH_B * 8
(2) ... (2)
For a PR = 20 these calculations will yield a Max_net media_BR_A = For a PR = 20 these calculations will yield a Max_net media_BR_A =
28600 bps and Max_net media_BR_B = 30400 bps, which suggests that 28600 bps and Max_net media_BR_B = 30400 bps, which suggests that
receiver A is the limiting one for this packet rate. However at a receiver A is the limiting one for this packet rate. However at a
certain PR there is a switchover point at which receiver B becomes certain PR there is a switchover point at which receiver B becomes
the limiting one. The switchover point can be identified by setting the limiting one. The switchover point can be identified by
Max_media_BR_A equal to Max_media_BR_B and breaking out PR: setting Max_media_BR_A equal to Max_media_BR_B and breaking out
PR:
TMMBR_max total BR_A - TMMBR_max total BR_B TMMBR_max total BR_A - TMMBR_max total BR_B
PR = ------------------------------------------- ... (3) 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 switchover point which, for the numbers above yields 31.25 as the switchover point
between the two limits. That is, for packet rates below 31.25 per between the two limits. That is, for packet rates below 31.25 per
second, receiver A is the limiting receiver, and for higher packet second, receiver A is the limiting receiver, and for higher packet
rates, receiver B is more limiting. The implications of this rates, receiver B is more limiting. The implications of this
behavior have to be considered by implementations that are going to behavior have to be considered by implementations that are going
control media encoding and its packetization. As exemplified above, to control media encoding and its packetization. As exemplified
multiple TMMBR limits may apply to the trade-off between net media above, multiple TMMBR limits may apply to the trade-off between
bit rate and packet rate. Which limitation applies depends on the net media bit rate and packet rate. Which limitation applies
packet rate being considered. 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
First, there is the possibility that multiple TMMBR tuples are work. First, there is the possibility that multiple TMMBR tuples
providing limitations on the media sender. Secondly there is a need are providing limitations on the media sender. Secondly there is
for any session participant (media sender and receivers) to be able a need for any session participant (media sender and receivers) to
to determine if a given tuple will become a limitation upon the media be able to determine if a given tuple will become a limitation
sender, or if the set of already given limitations is stricter than upon the media sender, or if the set of already given limitations
the given values. In the absence of the ability to make this is stricter than the given values. In the absence of the ability
determination the suppression of TMMBR requests would not work. to make this determination the suppression of TMMBR requests would
not work.
The basic idea of the algorithm is as follows. Each TMMBR tuple can The basic idea of the algorithm is as follows. Each TMMBR tuple
be viewed as the equation of a straight line (cf. equations (1) and can be viewed as the equation of a straight line (cf. equations
(2)) in a space where packet rate lies along the X-axis and maximum (1) and (2)) in a space where packet rate lies along the X-axis
bit rate lies along the Y-axis. The lower envelope of the set of and maximum bit rate lies along the Y-axis. The lower envelope of
lines corresponding to the complete set of TMMBR tuples defines a the set of lines corresponding to the complete set of TMMBR tuples
polygon. Points lying along or below this polygon are combinations of defines a polygon. Points lying along or below this polygon are
packet rate and bit rate that meet all of the TMMBR constraints. The combinations of packet rate and bit rate that meet all of the
highest feasible packet rate within this region is the minimum of the TMMBR constraints. The highest feasible packet rate within this
rate at which the bounding polygon meets the X-axis or the session region is the minimum of the rate at which the bounding polygon
maximum packet rate (SMAXPR) provided by signaling, if any. Typically meets the X-axis or the session maximum packet rate (SMAXPR)
a media sender will prefer to operate at a lower rate than this provided by signaling, if any. Typically a media sender will
theoretical maximum, so as to increase the rate at which actual media prefer to operate at a lower rate than this theoretical maximum,
content reaches the receivers. The purpose of the algorithm is to so as to increase the rate at which actual media content reaches
distinguish the TMMBR tuples constituting the bounding set and thus the receivers. The purpose of the algorithm is to distinguish the
delineate the feasible region, so that the media sender can select TMMBR tuples constituting the bounding set and thus delineate the
its preferred operating point within that region feasible region, so that the media sender can select its preferred
operating point within that region
Figure 1 below shows a bounding polygon formed by TMMBR tuples A and Figure 1 below shows a bounding polygon formed by TMMBR tuples A
B. A third tuple C lies outside the bounding polygon and is therefore and B. A third tuple C lies outside the bounding polygon and is
irrelevant in determining feasible tradeoffs between media rate and therefore irrelevant in determining feasible tradeoffs between
packet rate. The line labeled ss..s represents the limit on packet media rate and packet rate. The line labeled ss..s represents the
rate imposed by the session maximum packet rate (SMAXPR) obtained by limit on packet rate imposed by the session maximum packet rate
signaling during session setup. In Figure 1 the limit determined by (SMAXPR) obtained by signaling during session setup. In Figure 1
tuple B happens to be more restrictive than SMAXPR. The situation the limit determined by tuple B happens to be more restrictive
could easily be the reverse, meaning that the bounding polygon is than SMAXPR. The situation could easily be the reverse, meaning
terminated on the right by the vertical line representing the SMAXPR that the bounding polygon is terminated on the right by the
constraint. vertical line representing the SMAXPR constraint.
Net ^ Net ^
Media|a c b s Media|a c b s
Bit | a c b s Bit | a c b s
Rate | a c b s Rate | a c b s
| a cb s | a cb s
| a c s | a c s
| a bc s | a bc s
| a b c s | a b c s
| ab c s | ab c s
skipping to change at page 26, line 27 skipping to change at page 27, line 25
| a bc s | a bc s
| a b c s | a b c s
| ab c s | ab c s
| Feasible b c s | Feasible b c s
| region ba s | region ba s
| b a s c | b a s c
| b s c | b s c
| b s a | b s a
| bs | bs
+------------------------------> +------------------------------>
Packet rate Packet rate
Figure 1 - Geometric Interpretation of TMMBR Tuples Figure 1 - Geometric Interpretation of TMMBR Tuples
Note that the slopes of the lines making up the bounding polygon are Note that the slopes of the lines making up the bounding polygon
increasingly negative as one moves in the direction of increasing are increasingly negative as one moves in the direction of
packet rate. Note also that with slight rearrangement, equations (1) increasing packet rate. Note also that with slight rearrangement,
and (2) have the canonical form: equations (1) and (2) have the canonical form:
y = mx + b y = mx + b
where where
m is the slope and has value equal to the negative of the tuple m is the slope and has value equal to the negative of the tuple
overhead (in bits), overhead (in bits),
and and
b is the y-intercept and has value equal to the tuple maximum total b is the y-intercept and has value equal to the tuple maximum
media bit rate. total media bit rate.
These observations lead to the conclusion that when processing the These observations lead to the conclusion that when processing the
TMMBR tuples to select the initial bounding set, one should sort and TMMBR tuples to select the initial bounding set, one should sort
process the tuples by order of increasing overhead. Once a particular and process the tuples by order of increasing overhead. Once a
tuple has been added to the bounding set, all tuples not already particular tuple has been added to the bounding set, all tuples
selected and having lower overhead can be eliminated, because the not already selected and having lower overhead can be eliminated,
next side of the bounding polygon has to be steeper (i.e. the because the next side of the bounding polygon has to be steeper
corresponding TMMBR must have higher overhead) than the latest added (i.e. the corresponding TMMBR must have higher overhead) than the
tuple. latest added tuple.
Line cc..c in Figure 1 illustrates another principle. This line is 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 parallel to line aa..a, but has a higher Y-intercept. That is,
corresponding TMMBR tuple contains a higher maximum total media bit the corresponding TMMBR tuple contains a higher maximum total
rate value. Since line cc..c is outside the bounding polygon, it media bit rate value. Since line cc..c is outside the bounding
illustrates the conclusion that if two TMMBR tuples have the same polygon, it illustrates the conclusion that if two TMMBR tuples
overhead value, the one with higher maximum total media bit rate have the same overhead value, the one with higher maximum total
value cannot be part of the bounding set and can be set aside. media bit rate value cannot be part of the bounding set and can be
set aside.
Two further observations complete the algorithm. Obviously, moving Two further observations complete the algorithm. Obviously,
from the left, the successive corners of the bounding polygon (i.e. moving from the left, the successive corners of the bounding
the intersection points between successive pairs of sides) lie at polygon (i.e. the intersection points between successive pairs of
successively higher packet rates. On the other hand, again moving sides) lie at successively higher packet rates. On the other
from the left, each successive line making up the bounding set hand, again moving from the left, each successive line making up
crosses the X-axis at a lower packet rate. the bounding set crosses the X-axis at a lower packet rate.
The complete algorithm can now be specified. The algorithm works with The complete algorithm can now be specified. The algorithm works
two lists of TMMBR tuples, the candidate list X and the selected with two lists of TMMBR tuples, the candidate list X and the
list Y, both ordered by increasing overhead value. The algorithm selected list Y, both ordered by increasing overhead value. The
terminates when all members of X have been discarded or removed for algorithm terminates when all members of X have been discarded or
processing. Membership of the selected list Y is probationary until removed for processing. Membership of the selected list Y is
the algorithm is complete. Each member of the selected list is probationary until the algorithm is complete. Each member of the
associated with an intersection value, which is the packet rate at selected list is associated with an intersection value, which is
which the line corresponding to that TMMBR tuple intersects with the the packet rate at which the line corresponding to that TMMBR
line corresponding to the previous TMMBR tuple in the selected list. tuple intersects with the line corresponding to the previous TMMBR
Each member of the selected list is also associated with a maximum tuple in the selected list. Each member of the selected list is
packet rate value, which is the lesser of the session maximum packet also associated with a maximum packet rate value, which is the
rate SMAXPR (if any) and the packet rate at which the line lesser of the session maximum packet rate SMAXPR (if any) and the
corresponding to that tuple crosses the X-axis. 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 When the algorithm terminates, the selected list is equal to the
bounding set as defined in section 2.2. bounding set as defined in section 2.2.
Initial Algorithm Initial Algorithm
This algorithm is used by the media sender when it has received one This algorithm is used by the media sender when it has received
or more TMMBR requests and before it has determined a bounding set one or more TMMBR requests and before it has determined a bounding
for the first time. set for the first time.
1. Sort the TMMBR tuples by order of increasing overhead. This is 1. Sort the TMMBR tuples by order of increasing overhead. This is
the initial candidate list X. the initial candidate list X.
2. When multiple tuples in the candidate list have the same overhead 2. When multiple tuples in the candidate list have the same
value, discard all but the one with the lowest maximum total media overhead value, discard all but the one with the lowest maximum
bit rate value. total media bit rate value.
3. Select and remove from the candidate list the TMMBR tuple with the 3. Select and remove from the candidate list the TMMBR tuple with
lowest maximum total media bit rate value. If there is more than the lowest maximum total media bit rate value. If there is more
one tuple with that value, choose the one with the highest than one tuple with that value, choose the one with the highest
overhead value. This is the first member of the selected list Y. overhead value. This is the first member of the selected list
Set its intersection value equal to zero. Calculate its maximum Y. Set its intersection value equal to zero. Calculate its
packet rate as the minimum of SMAXPR (if available) and the value maximum packet rate as the minimum of SMAXPR (if available) and
obtained from the following formula, which is the packet rate at the value obtained from the following formula, which is the
which the corresponding line crosses the X-axis. packet rate at which the corresponding line crosses the X-axis.
Max PR = TMMBR max total BR / (8 * TMMBR OH) ... (4) Max PR = TMMBR max total BR / (8 * TMMBR OH) ... (4)
4. Discard from the candidate list all tuples with a lower overhead 4. Discard from the candidate list all tuples with a lower overhead
value than the selected tuple. value than the selected tuple.
5. Remove the first remaining tuple from the candidate list for 5. Remove the first remaining tuple from the candidate list for
processing. Call this the current candidate. processing. Call this the current candidate.
6. Calculate the packet rate PR at the intersection of the line 6. Calculate the packet rate PR at the intersection of the line
generated by the current candidate with the line generated by the generated by the current candidate with the line generated by
last tuple in the selected list Y, using equation (3). the last tuple in the selected list Y, using equation (3).
7. If the calculated value PR is equal to or lower than the 7. If the calculated value PR is equal to or lower than the
intersection value stored for the last tuple of the selected list, intersection value stored for the last tuple of the selected
discard the last tuple of the selected list and go back to step 6 list, discard the last tuple of the selected list and go back to
(retaining the same current candidate). step 6 (retaining the same current candidate).
Note that the choice of the initial member of the selected list Y Note that the choice of the initial member of the selected list
in step 3 guarantees that the selected list will never be emptied Y in step 3 guarantees that the selected list will never be
by this process, meaning that the algorithm must eventually (if emptied by this process, meaning that the algorithm must
not immediately) fall through to the step 8. eventually (if not immediately) fall through to the step 8.
8. (This step is reached when the calculated PR value of the current 8. (This step is reached when the calculated PR value of the
candidate is greater than the intersection value of the current current candidate is greater than the intersection value of the
last member of the selected list Y.) If the calculated value PR current last member of the selected list Y.) If the calculated
of the current candidate is lower than the maximum packet rate value PR of the current candidate is lower than the maximum
associated with the last tuple in the selected list, add the packet rate associated with the last tuple in the selected list,
current candidate tuple to the end of the selected list. Store PR add the current candidate tuple to the end of the selected list.
as its intersection value. Calculate its maximum packet rate as Store PR as its intersection value. Calculate its maximum
the lesser of SMAXPR (if available) and the maximum packet rate packet rate as the lesser of SMAXPR (if available) and the
calculated using equation (4). maximum packet rate calculated using equation (4).
9. If any tuples remain in the candidate list, go back to step 5. 9. If any tuples remain in the candidate list, go back to step 5.
Incremental Algorithm Incremental Algorithm
The previous algorithm covered the initial case, where no selected The previous algorithm covered the initial case, where no selected
list had previously been created. It also applied only to the media list had previously been created. It also applied only to the
sender. When a previously-created selected list is available at media sender. When a previously-created selected list is
either the media sender or media receiver, two other cases can be available at either the media sender or media receiver, two other
considered: cases can be considered:
o when a TMMBR tuple not currently in the selected list is a o when a TMMBR tuple not currently in the selected list is a
candidate for addition; candidate for addition;
o when the values change in a TMMBR tuple currently in the o when the values change in a TMMBR tuple currently in the
selected list. selected list.
At the media receiver these cases correspond respectively to those of At the media receiver these cases correspond respectively to those
the non-owner and owner of a tuple in the TMMBN-reported bounding of the non-owner and owner of a tuple in the TMMBN-reported
set. bounding set.
In either case, the process of updating the selected list to take In either case, the process of updating the selected list to take
account of the new/changed tuple can use the basic algorithm account of the new/changed tuple can use the basic algorithm
described above, with the modification that the initial candidate set described above, with the modification that the initial candidate
consists only of the existing selected list and the new or changed set consists only of the existing selected list and the new or
tuple. Some further optimization is possible (beyond starting with a changed tuple. Some further optimization is possible (beyond
reduced candidate set) by taking advantage of the following starting with a reduced candidate set) by taking advantage of the
observations. following observations.
The first observation is that if the new/changed candidate becomes 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 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 more other tuples to be dropped from the list. However, if more
one other tuple is dropped, the dropped tuples will be consecutive. than one other tuple is dropped, the dropped tuples will be
This can be confirmed geometrically by visualizing a new line that consecutive. This can be confirmed geometrically by visualizing a
cuts off a series of segments from the previously-existing bounding new line that cuts off a series of segments from the previously-
polygon. The cut-off segments are connected one to the next, the existing bounding polygon. The cut-off segments are connected one
geometric equivalent of consecutive tuples in a list ordered by to the next, the geometric equivalent of consecutive tuples in a
overhead value. Beyond the dropped set in either direction all of list ordered by overhead value. Beyond the dropped set in either
the tuples that were in the earlier selected list will be in the direction all of the tuples that were in the earlier selected list
updated one. The second observation is that, leaving aside the new will be in the updated one. The second observation is that,
candidate, the order of tuples remaining in the updated selected list leaving aside the new candidate, the order of tuples remaining in
is unchanged because their overhead values have not changed. the updated selected list is unchanged because their overhead
values have not changed.
The consequence of these two observations is that, once the placement The consequence of these two observations is that, once the
of the new candidate and the extent of the dropped set of tuples (if placement of the new candidate and the extent of the dropped set
any) has been determined, the remaining tuples can be copied directly of tuples (if any) has been determined, the remaining tuples can
from the candidate list into the selected list, preserving their be copied directly from the candidate list into the selected list,
order. This conclusion suggests the following modified algorithm: preserving their order. This conclusion suggests the following
modified algorithm:
o Run steps 1-4 of the basic algorithm. o Run steps 1-4 of the basic algorithm.
o If the new candidate has survived steps 2 and 4 and has become o If the new candidate has survived steps 2 and 4 and has
the new first member of the selected list, run steps 5-9 on become the new first member of the selected list, run steps
subsequent candidates until another candidate is added to the 5-9 on subsequent candidates until another candidate is
selected list. Then move all remaining candidates to the added to the selected list. Then move all remaining
selected list, preserving their order. candidates to the selected list, preserving their order.
o If the new candidate has survived steps 2 and 4 and has not 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 become the new first member of the selected list, start by
moving all tuples in the candidate list with lower overhead moving all tuples in the candidate list with lower overhead
values than that of the new candidate to the selected list, values than that of the new candidate to the selected list,
preserving their order. Run steps 5 through 9 for the new preserving their order. Run steps 5 through 9 for the new
candidate, with the modification that the intersection values candidate, with the modification that the intersection
and maximum packet rates for the tuples on the selected list values and maximum packet rates for the tuples on the
have to be calculated on the fly because they were not selected list have to be calculated on the fly because they
previously stored. Continue processing only until a subsequent were not previously stored. Continue processing only until
tuple has been added to the selected list, then move all a subsequent tuple has been added to the selected list, then
remaining candidates to the selected list, preserving their move all remaining candidates to the selected list,
order. preserving their order.
Note that the new candidate could be added to the selected Note that the new candidate could be added to the selected
list only to be dropped again when the next tuple is list only to be dropped again when the next tuple is
processed. It can easily be seen that in this case the new processed. It can easily be seen that in this case the new
candidate does not displace any of the earlier tuples in the candidate does not displace any of the earlier tuples in the
selected list. The limitations of ASCII art make this selected list. The limitations of ASCII art make this
difficult to show in a figure. Line cc..c in Figure 1 would 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 be an example if it had a steeper slope (tuple C had a
overhead value), but still intersected line aa..a beyond higher overhead value), but still intersected line aa..a
where line aa..a intersects line bb..b. beyond where line aa..a intersects line bb..b.
The algorithm just described is approximate, because it does not take The algorithm just described is approximate, because it does not
account of tuples outside the selected list. To see how such tuples take account of tuples outside the selected list. To see how such
can become relevant, consider Figure 1 and suppose that the maximum tuples can become relevant, consider Figure 1 and suppose that the
total media bit rate in tuple A increases to the point that line maximum total media bit rate in tuple A increases to the point
aa..a moves outside line cc..c. Tuple A will remain in the bounding that line aa..a moves outside line cc..c. Tuple A will remain in
set calculated by the media sender. However, once it issues a new the bounding set calculated by the media sender. However, once it
TMMBN, media receiver C will apply the algorithm and discover that issues a new TMMBN, media receiver C will apply the algorithm and
its tuple C should now enter the bounding set. It will issue a TMMBR discover that its tuple C should now enter the bounding set. It
request to the media sender, which will repeat its calculation and will issue a TMMBR request to the media sender, which will repeat
come to the appropriate conclusion. its calculation and come to the appropriate conclusion.
The rules of section 4.2 require that the media sender refrain from The rules of section 4.2 require that the media sender refrain
raising its sending rate until media receivers have had a chance to from raising its sending rate until media receivers have had a
respond to the TMMBN. In the example just given, this delay ensures chance to respond to the TMMBN. In the example just given, this
that the relaxation of tuple A does not actually result in an attempt delay ensures that the relaxation of tuple A does not actually
to send media at a rate exceeding the capacity at C. 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 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.
conference operates over a number of unicast paths between the 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 (RR) or the the mixer, utilizing, for example, RTCP receiver reports (RR) or
transport protocol, e.g. DCCP [RFC4340]. However, any given the 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 (which is similar to the ones discussed in this draft, the mixer (which is
aware of the congestion situation on all connections it manages) has aware of the congestion situation on all connections it manages)
no standardized means to inform media senders to slow down, short of has no standardized means to inform media senders to slow down,
forging its own receiver reports (which is undesirable). In short of forging its own receiver reports (which is undesirable).
principle, a mixer confronted with such a situation is obliged to In principle, a mixer confronted with such a situation is obliged
thin or transcode streams intended for connections that detected to thin or transcode streams intended for connections that
congestion. detected 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
quality. Hence, a means to slow down senders even in the absence of media quality. Hence, a means to slow down senders even in the
congestion on their connections to the mixer is desirable. absence of congestion on their connections to the mixer is
desirable.
To allow the mixer to throttle traffic on the individual links, To allow the mixer to throttle traffic on the individual links,
without performing transcoding, there is a need for a mechanism that without performing transcoding, there is a need for a mechanism
enables the mixer to ask a participant's media encoders to limit the that enables the mixer to ask a participant's media encoders to
media stream bit rate they are currently generating. TMMBR provides limit the media stream bit rate they are currently generating.
the required mechanism. When the mixer detects congestion between TMMBR provides the required mechanism. When the mixer detects
itself and a given participant, it executes the following procedure: congestion between itself and a given participant, it executes the
following procedure:
1. It starts thinning the media traffic to the congested participant 1. It starts thinning the media traffic to the congested
to the supported bit rate. participant to the supported bit rate.
2. It uses TMMBR to request the media sender(s) to reduce the total 2. It uses 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 total media bit rate sent by them to the mixer, to a value that
compliance with congestion control principles for the slowest is in compliance with congestion control principles for the
link. Slow refers here to the available bandwidth / bit rate / slowest link. Slow refers here to the available bandwidth /
capacity and packet rate after congestion control. bit rate / capacity and packet rate after congestion control.
3. As soon as the bit rate has been reduced by the sending part, the 3. As soon as the bit rate has been reduced by the sending part,
mixer stops stream thinning implicitly, because there is no need the mixer stops stream thinning implicitly, because there is no
for it once the stream is in compliance with congestion control. need for it once the stream is in compliance with congestion
control.
This use of stream thinning as an immediate reaction tool followed up This use of stream thinning as an immediate reaction tool followed
by a quick control mechanism appears to be a reasonable compromise up by a quick control mechanism appears to be a reasonable
between media quality and the need to combat congestion. compromise between media quality and the need to combat
congestion.
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. This allows all Translator, RTCP RRs are transmitted globally. This allows all
participants to detect transmission problems such as congestion, on a participants to detect transmission problems such as congestion,
medium timescale. As all media senders are aware of the congestion on a medium timescale. As all media senders are aware of the
situation of all media receivers, the rationale for the use of TMMBR congestion situation of all media receivers, the rationale for the
in the previous section does not apply. However, even in this case use of TMMBR in the previous section does not apply. However,
the congestion control response can be improved when the unicast even in this case the congestion control response can be improved
links are using congestion controlled transport protocols (such as when the unicast links are using congestion controlled transport
TCP or DCCP). A peer may also report local limitations to the media protocols (such as TCP or DCCP). A peer may also report local
sender. limitations to the media 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
when the known upper limit of the bit rate changes. In this use case performance when the known upper limit of the bit rate changes.
the signaling protocol has established an upper limit for the session In this use case the signaling protocol has established an upper
and total media bit rates. However, at the time of transport link limit for the session and total media bit rates. However, at the
bit rate reduction, a receiver can avoid serious congestion by time of transport link bit rate reduction, a receiver can avoid
sending a TMMBR to the sending side. Thus TMMBR is useful for serious congestion by sending a TMMBR to the sending side. Thus
putting restrictions on the application and thus placing the TMMBR is useful for putting restrictions on the application and
congestion control mechanism in the right ballpark. However TMMBR is thus placing the congestion control mechanism in the right
usually unable to provide the continuously quick feedback loop ballpark. However TMMBR is usually unable to provide the
required for real congestion control. Nor do its semantics match continuously quick feedback loop required for real congestion
those of congestion control given its different purpose. For these control. Nor do its semantics match those of congestion control
reasons TMMBR SHALL NOT be used as a substitute for congestion given its different purpose. For these reasons TMMBR SHALL NOT be
control. 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
not immediately identifiable through inspection of the media stream. is not immediately identifiable through inspection of the media
Therefore, a more explicit mechanism is needed to avoid unnecessary stream. Therefore, a more explicit mechanism is needed to avoid
re-sending of TMMBR messages. Using a statistically based unnecessary re-sending of TMMBR messages. Using a statistically
retransmission scheme would only provide statistical guarantees of based retransmission scheme would only provide statistical
the request being received. It would also not avoid the guarantees of the request being received. It would also not avoid
retransmission of already received messages. In addition, it would the retransmission of already received messages. In addition, it
not allow for easy suppression of other participants' requests. For would not allow for easy suppression of other participants'
these reasons, a mechanism based on explicit notification is used. requests. For these reasons, a mechanism based on explicit
notification is used.
Upon the reception of a request a media sender sends a TMMBN Upon the reception of a request a media sender sends a TMMBN
notification containing the current bounding set, and indicating notification containing the current bounding set, and indicating
which session participants own that limit. In multicast scenarios, which session participants own that limit. In multicast
that allows all other participants to suppress any request they may scenarios, that allows all other participants to suppress any
have, if their limitations are less strict than the current ones request they may have, if their limitations are less strict than
(i.e. define lines lying outside the feasible region as defined in the current ones (i.e. define lines lying outside the feasible
section 2.2). Keeping and notifying only the bounding set of tuples region as defined in section 2.2). Keeping and notifying only the
allows for small message sizes and media sender states. A media bounding set of tuples allows for small message sizes and media
sender only keeps state for the SSRCs of the current owners of the sender states. A media sender only keeps state for the SSRCs of
bounding set of tuples; all other requests and their sources are not the current owners of the bounding set of tuples; all other
saved. Once the bounding set has been established, new TMMBR requests and their sources are not saved. Once the bounding set
messages should be generated only by owners of the bounding tuples has been established, new TMMBR messages should be generated only
and by other entities that determine (by applying the algorithm of by owners of the bounding tuples and by other entities that
section 3.5.4.2 or its equivalent) that their limitations should now determine (by applying the algorithm of section 3.5.4.2 or its
be part of the bounding set. 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 This memo specifies six new feedback messages. The Full Intra
Request (FIR), Temporal-Spatial Trade-off Request (TSTR), Temporal- Request (FIR), Temporal-Spatial Trade-off Request (TSTR),
Spatial Trade-off Notification (TSTN), and Video Back Channel Message Temporal-Spatial Trade-off Notification (TSTN), and Video Back
(VBCM) are "Payload Specific Feedback Messages" as defined in Section Channel Message (VBCM) are "Payload Specific Feedback Messages" as
6.3 of AVPF [RFC4585]. The Temporary Maximum Media Stream Bit Rate defined in Section 6.3 of AVPF [RFC4585]. The Temporary Maximum
Request (TMMBR) and Temporary Maximum Media Stream Bit Rate Media Stream Bit Rate Request (TMMBR) and Temporary Maximum Media
Notification (TMMBN) are "Transport Layer Feedback Messages" as Stream Bit Rate Notification (TMMBN) are "Transport Layer Feedback
defined in Section 6.2 of AVPF. Messages" as defined in Section 6.2 of AVPF.
The new feedback messages are defined in the following subsections, The new feedback messages are defined in the following
following a similar structure to that in sections 6.2 and 6.3 of the subsections, following a similar structure to that in sections 6.2
AVPF specification [RFC4585]. and 6.3 of the 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
A limited set of media control mechanisms were introduced in early coding. A limited set of media control mechanisms were introduced
RTP payload formats for video formats, for example in RFC 4587 in early RTP payload formats for video formats, for example in RFC
[RFC4587]. However, this specification, for the first time, suggests 2032 [RFC2032]. However, this specification, for the first time,
a two-way handshake for some of its messages. There is danger that suggests a two-way handshake for some of its messages. There is
this introduction could be misunderstood as a precedent for the use danger that this introduction could be misunderstood as a
of RTCP as an RTP session control protocol. To prevent such a precedent for the use of RTCP as an RTP session control protocol.
misunderstanding, this subsection attempts to clarify the scope of To prevent such a misunderstanding, this subsection attempts to
the extensions specified in this memo, and strongly suggests that clarify the scope of the extensions specified in this memo, and
future extensions follow the rationale spelled out here, or strongly suggests that future extensions follow the rationale
compellingly explain why they divert from the rationale. spelled out here, or 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 as: included as:
a) have comparatively strict real-time constraints, which prevent the a) have comparatively strict real-time constraints, which prevent
use of mechanisms such as a SIP re-invite in most application the use of mechanisms such as a SIP re-invite in most
scenarios. The real-time constraints are explained separately for application scenarios. The real-time constraints are explained
each message where necessary. separately for 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; and 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,
of media codecs (e.g. video codecs), or a given RTP packet stream. class of media codecs (e.g. video codecs), or a given RTP
packet stream.
In this memo, a two-way handshake is introduced only for messages for In this memo, a two-way handshake is introduced only for messages
which: for which:
a) a notification or acknowledgement is required due to their nature. a) a notification or acknowledgement is required due to their
An analysis to determine whether this requirement exists has been nature. An analysis to determine whether this requirement
performed separately for each message. 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
the media bit stream. from the media bit stream.
All messages in AVPF [RFC4585] and in this memo present their All messages in AVPF [RFC4585] and in this memo present their
contents in a simple, fixed binary format. This accommodates media contents in a simple, fixed binary format. This accommodates
receivers which have not implemented higher control protocol media receivers which have not implemented higher control protocol
functionalities (SDP, XML parsers and such) in their media path. functionalities (SDP, XML parsers and such) in their media path.
Messages that do not conform to the design principles just
described are not an appropriate use of RTCP or of the Codec
Control Framework defined in this document.
4.2. Transport Layer Feedback Messages 4.2. Transport Layer Feedback Messages
As specified in section 6.1 of RFC 4585 [RFC4585], Transport Layer As specified in section 6.1 of RFC 4585 [RFC4585], Transport Layer
Feedback messages are identified by the RTCP packet type value RTPFB Feedback messages are identified by the RTCP packet type value
(205). 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 such messages. They are identified by means of specifies two more such messages. They are identified by means of
the FMT parameter as follows: the FMT parameter as follows:
Assigned in AVPF [RFC4585]: Assigned in AVPF [RFC4585]:
1: Generic NACK 1: Generic NACK
31: reserved for future expansion of the identifier number space 31: reserved for future expansion of the identifier number
space
Assigned in this memo: Assigned in this memo:
2: reserved (see note below) 2: reserved (see note below)
3: Temporary Maximum Media Stream Bit Rate Request (TMMBR) 3: Temporary Maximum Media Stream Bit Rate Request (TMMBR)
4: Temporary Maximum Media Stream Bit Rate Notification (TMMBN) 4: Temporary Maximum Media Stream Bit Rate Notification (TMMBN)
Note: early drafts of AVPF [RFC4585] reserved FMT=2 for a code Note: early drafts of AVPF [RFC4585] reserved FMT=2 for a
point that has later been removed. It has been pointed out code point that has later been removed. It has been
that there may be implementations in the field using this pointed out that there may be implementations in the field
value in accordance with the expired draft. As there is using this value in accordance with the expired draft. As
sufficient numbering space available, we mark FMT=2 as there is sufficient numbering space available, we mark
reserved so to avoid possible interoperability problems with FMT=2 as reserved so to avoid possible interoperability
any such early implementations. problems with any such early implementations.
Available for assignment: Available for assignment:
0: unassigned 0: unassigned
5-30: 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 The following subsection defines the formats of the FCI entries
behaviour at the media sender and receiver. 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) 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. Message Format 4.2.1.1. Message Format
The Feedback Control Information (FCI) consists of one or more TMMBR The Feedback Control Information (FCI) consists of one or more
FCI entries with the following syntax: TMMBR 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp | MxTBR Mantissa |Measured Overhead| | MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Syntax of an FCI entry in the TMMBR message Figure 2 - Syntax of an FCI entry in the TMMBR message
SSRC (32 bits): The SSRC value of the media sender that is SSRC (32 bits): The SSRC value of the media sender that is
requested to obey the new maximum bit rate. requested to obey the new maximum bit rate.
MxTBR Exp (6 bits): The exponential scaling of the mantissa for the MxTBR Exp (6 bits): The exponential scaling of the mantissa for
maximum total media bit rate value. The value is an the maximum total media bit rate value. The value is an
unsigned integer [0..63]. unsigned integer [0..63].
MxTBR Mantissa (17 bits): The mantissa of the maximum total media MxTBR Mantissa (17 bits): The mantissa of the maximum total
bit rate value as an unsigned integer. media 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. The measurement SHALL be done according value in bytes. The measurement SHALL be done according
to description in section 4.2.1.2. The value is an to description in section 4.2.1.2. The value is an
unsigned integer [0..512]. unsigned integer [0..512].
The maximum total media bit rate (MxTBR) value in bits per second is The maximum total media bit rate (MxTBR) value in bits per second
calculated from the MxTBR exponent (exp) and mantissa in the is calculated from the MxTBR exponent (exp) and mantissa in the
following way: following way:
MxTBR = mantissa * 2^exp MxTBR = mantissa * 2^exp
This allows for 17 bits of resolution in the range 0 to 131072*2^63 This allows for 17 bits of resolution in the range 0 to
(approximately 1.2*10^24). 131072*2^63 (approximately 1.2*10^24).
The length of the TMMBR feedback message SHALL be set to 2+2*N where The length of the TMMBR feedback message SHALL be set to 2+2*N
N is the number of TMMBR FCI entries. where N is the number of TMMBR FCI entries.
4.2.1.2. Semantics 4.2.1.2. Semantics
Behaviour at the Media Receiver (Sender of the TMMBR) Behaviour at the Media Receiver (Sender of the TMMBR)
TMMBR is used to indicate a transport related limitation at the TMMBR is used to indicate a transport related limitation at the
reporting entity acting as a media receiver. TMMBR has the form of a reporting entity acting as a media receiver. TMMBR has the form
tuple containing two components. The first value is the highest bit of a tuple containing two components. The first value is the
rate per sender of a media stream, available at a receiver-chosen highest bit rate per sender of a media stream, available at a
protocol layer, which the receiver currently supports in this RTP receiver-chosen protocol layer, which the receiver currently
session. The second value is the measured header overhead in bytes supports in this RTP session. The second value is the measured
as defined in section 2.2 and measured at the chosen protocol layer header overhead in bytes as defined in section 2.2 and measured at
in the packets received for the stream. The measurement of the the chosen protocol layer in the packets received for the stream.
overhead is a running average that is updated for each packet The measurement of the overhead is a running average that is
received for this particular media source (SSRC), using the following updated for each packet received for this particular media source
formula: (SSRC), using the following formula:
avg_OH (new) = 15/16*avg_OH (old) + 1/16*pckt_OH, avg_OH (new) = 15/16*avg_OH (old) + 1/16*pckt_OH,
where avg_OH is the running (exponentially smoothed) average and where avg_OH is the running (exponentially smoothed) average and
pckt_OH is the overhead observed in the latest packet. pckt_OH is the overhead observed in the latest packet.
If a maximum bit rate has been negotiated through signaling, the If a maximum bit rate has been negotiated through signaling, the
maximum total media bit rate that the receiver reports in a TMMBR maximum total media bit rate that the receiver reports in a TMMBR
message MUST NOT exceed the negotiated value converted to a common message MUST NOT exceed the negotiated value converted to a common
basis (i.e. with overheads adjusted to bring it to the same reference basis (i.e. with overheads adjusted to bring it to the same
protocol layer). reference protocol layer).
Within the common packet header for feedback messages (as defined in Within the common packet header for feedback messages (as defined
section 6.1 of [RFC4585]), the "SSRC of the packet sender" field in section 6.1 of [RFC4585]), the "SSRC of the packet sender"
indicates the source of the request, and the "SSRC of media source" field indicates the source of the request, and the "SSRC of media
is not used and SHALL be set to 0. Within a particular TMMBR FCI source" is not used and SHALL be set to 0. Within a particular
entry, the "SSRC of media sender" in the FCI field denotes the media TMMBR FCI entry, the "SSRC of media sender" in the FCI field
sender the tuple applies to. This is useful in the multicast or denotes the media sender the tuple applies to. This is useful in
translator topologies where the reporting entity may address all of the multicast or translator topologies where the reporting entity
the media senders in a single TMMBR message using multiple FCI may address all of the media senders in a single TMMBR message
entries. using multiple FCI entries.
The media receiver SHALL save the contents of the latest TMMBN The media receiver SHALL save the contents of the latest TMMBN
message received from each media sender. message received from each media sender.
The media receiver MAY send a TMMBR FCI entry to a particular media The media receiver MAY send a TMMBR FCI entry to a particular
sender under the following circumstances: media sender under the following circumstances:
o before any TMMBN message has been received from that media o before any TMMBN message has been received from that media
sender; sender;
o when the media receiver has been identified as the source of a o when the media receiver has been identified as the source of
bounding tuple within the latest TMMBN message received from a bounding tuple within the latest TMMBN message received
that media sender, and the value of the maximum total media from that media sender, and the value of the maximum total
bit rate or the overhead relating to that media sender has media bit rate or the overhead relating to that media sender
changed; has changed;
o when the media receiver has not been identified as the source o when the media receiver has not been identified as the
of a bounding tuple within the latest TMMBN message received source of a bounding tuple within the latest TMMBN message
from that media sender, and, after the media receiver applies received from that media sender, and, after the media
the incremental algorithm from section 3.5.4.2 or a stricter receiver applies the incremental algorithm from section
equivalent, the media receiver's tuple relating to that media 3.5.4.2 or a stricter equivalent, the media receiver's tuple
sender is determined to belong to the bounding set. 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 A TMMBR FCI entry MAY be repeated in subsequent TMMBR messages if
Temporary Maximum Media Stream Bit-Rate Notification (TMMBN) FCI has no Temporary Maximum Media Stream Bit-Rate Notification (TMMBN)
been received from the media sender at the time of transmission of FCI has been received from the media sender at the time of
the next RTCP packet. The bit rate value of a TMMBR FCI entry MAY be transmission of the next RTCP packet. The bit rate value of a
changed from one TMMBR message to the next. The overhead measurement TMMBR FCI entry MAY be changed from one TMMBR message to the next.
SHALL be updated to the current value of avg_OH each time the entry The overhead measurement SHALL be updated to the current value of
is sent. 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,
TMMBR setting party SHOULD renegotiate the session parameters to the TMMBR setting party SHOULD renegotiate the session parameters
reflect that using session setup signaling, e.g. a SIP re-invite. to reflect that using session setup signaling, e.g. a SIP re-
invite.
Behaviour at the Media Sender (Receiver of the TMMBR) Behaviour at the Media Sender (Receiver of the TMMBR)
When it receives a TMMBR message containing an FCI entry relating to When it receives a TMMBR message containing an FCI entry relating
it, the media sender SHALL use an initial or incremental algorithm as to it, the media sender SHALL use an initial or incremental
applicable to determine the bounding set of tuples based on the new algorithm as applicable to determine the bounding set of tuples
information. The algorithm used SHALL be at least as strict as the based on the new information. The algorithm used SHALL be at
corresponding algorithm defined in section 3.5.4.2. The media sender least as strict as the corresponding algorithm defined in section
MAY accumulate TMMBR requests over a small interval (relative to the 3.5.4.2. The media sender MAY accumulate TMMBR requests over a
RTCP sending interval) before making this calculation. small interval (relative to the RTCP sending interval) before
making this calculation.
Once it has determined the bounding set of tuples, the media sender Once it has determined the bounding set of tuples, the media
MAY use any combination of packet rate and net media bit rate within sender MAY use any combination of packet rate and net media bit
the feasible region that these tuples describe to produce a lower rate within the feasible region that these tuples describe to
total media stream bit rate, as it may need to address a congestion produce a lower total media stream bit rate, as it may need to
situation or other limiting factors. See section 5 (congestion address a congestion situation or other limiting factors. See
control) for more discussion. section 5. (congestion control) for more discussion.
If the media sender concludes that it can increase the maximum total If the media sender concludes that it can increase the maximum
media bit rate value, it SHALL wait before actually doing so, for a total media bit rate value, it SHALL wait before actually doing
period long enough to allow a media receiver to respond to the TMMBN so, for a period long enough to allow a media receiver to respond
if it determines that its tuple belongs in the bounding set. This to the TMMBN if it determines that its tuple belongs in the
delay period is estimated by the formula: bounding set. This delay period is estimated by the formula:
2 * RTT + T_Dither_Max, 2 * RTT + T_Dither_Max,
where RTT is the longest round trip time known to the media sender where RTT is the longest round trip time known to the media sender
and T_Dither_Max is defined in section 3.4 of [RFC4585]. and T_Dither_Max is defined in section 3.4 of [RFC4585].
A TMMBN message SHALL be sent by the media sender at the earliest A TMMBN message SHALL be sent by the media sender at the earliest
possible point in time, in response to any TMMBR messages received possible point in time, in response to any TMMBR messages received
since the last sending of TMMBN. The TMMBN message indicates the since the last sending of TMMBN. The TMMBN message indicates the
calculated set of bounding tuples and the owners of those tuples at calculated set of bounding tuples and the owners of those tuples
the time of the transmission of the message. at the time of the transmission of the message.
An SSRC may time out according to the default rules for RTP session An SSRC may time out according to the default rules for RTP
participants, i.e. the media sender has not received any RTP or RTCP session participants, i.e. the media sender has not received any
packets from the owner for the last five regular reporting intervals. RTP or RTCP packets from the owner for the last five regular
An SSRC may also explicitly leave the session, with the participant reporting intervals. An SSRC may also explicitly leave the
indicating this through the transmission of an RTCP BYE packet or session, with the participant indicating this through the
using an external signaling channel. If the media sender determines transmission of an RTCP BYE packet or using an external signaling
that the owner of a tuple in the bounding set has left the session, channel. If the media sender determines that the owner of a tuple
the media sender shall transmit a new TMMBN containing the in the bounding set has left the session, the media sender shall
previously-determined set of bounding tuples but with the tuple transmit a new TMMBN containing the previously-determined set of
belonging to the departed owner removed. bounding tuples but with the tuple belonging to the departed owner
removed.
A media sender MAY proactively initiate the equivalent to a TMMBR A media sender MAY proactively initiate the equivalent to a TMMBR
message to itself, when it is aware that its transmission path is message to itself, when it is aware that its transmission path is
more restrictive than the current limitations. As a result, a TMMBN more restrictive than the current limitations. As a result, a
indicating the media source itself as the owner of a tuple is being TMMBN indicating the media source itself as the owner of a tuple
sent, thereby avoiding unnecessary TMMBR messages from other is being sent, thereby avoiding unnecessary TMMBR messages from
participants. However, like any other participant, when the media other participants. However, like any other participant, when the
sender becomes aware of changed limitations, it is required to change media sender becomes aware of changed limitations, it is required
the tuple, and to send a corresponding TMMBN. to change the tuple, and to send a corresponding TMMBN.
Discussion Discussion
Due to the unreliable nature of transport of TMMBR and TMMBN, the Due to the unreliable nature of transport of TMMBR and TMMBN, the
above rules may lead to the sending of TMMBR messages which appear to above rules may lead to the sending of TMMBR messages which appear
disobey those rules. Furthermore, in multicast scenarios it can to disobey those rules. Furthermore, in multicast scenarios it
happen that more than one "non-owning" session participant may can happen that more than one "non-owning" session participant may
determine, rightly or wrongly, that its tuple belongs in the bounding determine, rightly or wrongly, that its tuple belongs in the
set. This is not critical for a number of reasons: bounding set. This is not critical for a number of reasons:
a) If a TMMBR message is lost in transmission, either the media a) If a TMMBR message is lost in transmission, either the media
sender sends a new TMMBN message in response to some other media sender sends a new TMMBN message in response to some other
receiver or it does not send a new TMMBN message at all. In the media receiver or it does not send a new TMMBN message at all.
first case, the media receiver applies the incremental algorithm In the first case, the media receiver applies the incremental
and, if it determines that its tuple should be part of the algorithm and, if it determines that its tuple should be part
bounding set, sends out another TMMBR. In the second case, it of the bounding set, sends out another TMMBR. In the second
repeats the sending of a TMMBR unconditionally. Either way, the case, it repeats the sending of a TMMBR unconditionally.
media sender eventually gets the information it needs. Either way, the media sender eventually gets the information it
needs.
b) Similarly, if a TMMBN message gets lost, the media receiver that b) Similarly, if a TMMBN message gets lost, the media receiver
has sent the corresponding TMMBR request does not receive the that has sent the corresponding TMMBR request does not receive
notification and is expected to re-send the request and trigger the notification and is expected to re-send the request and
the transmission of another TMMBN. trigger the transmission of another TMMBN.
c) If multiple competing TMMBR messages are sent by different session c) If multiple competing TMMBR messages are sent by different
participants, then the algorithm can be applied taking all of session participants, then the algorithm can be applied taking
these messages into account, and the resulting TMMBN provides the all of these messages into account, and the resulting TMMBN
participants with an updated view of how their tuples compare with provides the participants with an updated view of how their
the bounded set. tuples compare with the bounded set.
d) If more than one session participant happens to send TMMBR d) If more than one session participant happens to send TMMBR
messages at the same time and with the same tuple component messages at the same time and with the same tuple component
values, it does not matter which if either tuple is taken into the values, it does not matter which if either tuple is taken into
bounding set. The losing session participant will determine after the bounding set. The losing session participant will
applying the algorithm that its tuple does not enter the bounding determine after applying the algorithm that its tuple does not
set, and will therefore stop sending its TMMBR request. enter the bounding set, and will therefore stop sending its
TMMBR request.
It is important to consider the security risks involved with faked It is important to consider the security risks involved with faked
TMMBRs. See the security considerations in Section 6. TMMBRs. See the security considerations in Section 6.
As indicated already, the feedback messages may be used in both As indicated already, the feedback messages may be used in both
multicast and unicast sessions in any of the specified topologies. multicast and unicast sessions in any of the specified topologies.
However, for sessions with a large number of participants, using the However, for sessions with a large number of participants, using
lowest common denominator, as required by this mechanism, may not be the lowest common denominator, as required by this mechanism, may
the most suitable course of action. Large sessions may need to not be the most suitable course of action. Large sessions may
consider other ways to adapt the bit rate to participants' need to consider other ways to adapt the bit rate to participants'
capabilities, such as partitioning the session into different quality capabilities, such as partitioning the session into different
tiers, or using some other method of achieving bit rate scalability. 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 TMMBR request message MAY use early or The first transmission of the TMMBR request message MAY use early
immediate feedback in cases when timeliness is desirable. Any or 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
transmission timing. its 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
media stream to the receiver. The mixer or translator may act certain media stream to the receiver. The mixer or translator may
locally on the TMMBR request and thus generate a TMMBN to indicate act locally on the TMMBR request and thus generate a TMMBN to
that it has done so. Alternatively, in the case of a media indicate that it has done so. Alternatively, in the case of a
translator it can forward the request, or in the case of a mixer media translator it can forward the request, or in the case of a
generate one of its own and pass it forward. In the latter case, the mixer generate one of its own and pass it forward. In the latter
mixer will need to send a TMMBN back to the original requestor to case, the mixer will need to send a TMMBN back to the original
indicate that it is handling the request. requestor to 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
more TMMBN FCI entries. or more TMMBN FCI entries.
4.2.2.1. 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
TMMBN FCI entries with the following syntax: more 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp | MxTBR Mantissa |Measured Overhead| | MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Syntax of an FCI entry in the TMMBN message Figure 3 - Syntax of an FCI entry in the TMMBN message
skipping to change at page 41, line 33 skipping to change at page 43, line 4
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp | MxTBR Mantissa |Measured Overhead| | MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Syntax of an FCI entry in the TMMBN message Figure 3 - Syntax of an FCI entry in the TMMBN message
SSRC (32 bits): The SSRC value of the "owner" of this tuple. SSRC (32 bits): The SSRC value of the "owner" of this tuple.
MxTBR Exp (6 bits): The exponential scaling of the mantissa for the MxTBR Exp (6 bits): The exponential scaling of the mantissa for
maximum total media bit rate value. The value is an the maximum total media bit rate value. The value is an
unsigned integer [0..63]. unsigned integer [0..63].
MxTBR Mantissa (17 bits): The mantissa of the maximum total media MxTBR Mantissa (17 bits): The mantissa of the maximum total
bit rate value as an unsigned integer. media 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 an unsigned integer. value in bytes represented as an unsigned integer.
Thus the FCI within the TMMBN message contains entries indicating the Thus the FCI within the TMMBN message contains entries indicating
bounding tuples. For each tuple, the entry gives the owner by the the bounding tuples. For each tuple, the entry gives the owner by
SSRC, followed by the applicable maximum total media bit rate and the SSRC, followed by the applicable maximum total media bit rate
overhead value. and overhead value.
The length of the TMMBN message SHALL be set to 2+2*N where N is the The length of the TMMBN message SHALL be set to 2+2*N where N is
number of TMMBN FCI entries. the number of TMMBN FCI entries.
4.2.2.2. Semantics 4.2.2.2. Semantics
This feedback message is used to notify the senders of any TMMBR 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 message that one or more TMMBR messages have been received or that
owner has left the session. It indicates to all participants the an owner has left the session. It indicates to all participants
current set of bounding tuples and the "owners" of those tuples. the current set of bounding tuples and the "owners" of those
tuples.
Within the common packet header for feedback messages (as defined in Within the common packet header for feedback messages (as defined
section 6.1 of [RFC4585]), the "SSRC of the packet sender" field in section 6.1 of [RFC4585]), the "SSRC of the packet sender"
indicates the source of the notification. The "SSRC of media source" field indicates the source of the notification. The "SSRC of
is not used and SHALL be set to 0. media source" is not used and SHALL be set to 0.
A TMMBN message SHALL be scheduled for transmission after the A TMMBN message SHALL be scheduled for transmission after the
reception of a TMMBR message with an FCI entry identifying this media reception of a TMMBR message with an FCI entry identifying this
sender. Only a single TMMBN SHALL be sent, even if more than one media sender. Only a single TMMBN SHALL be sent, even if more
TMMBR message is received between the scheduling of the transmission than one TMMBR message is received between the scheduling of the
and the actual transmission of the TMMBN message. The TMMBN message transmission and the actual transmission of the TMMBN message.
indicates the bounding tuples and their owners at the time of The TMMBN message indicates the bounding tuples and their owners
transmitting the message. The bounding tuples included SHALL be the at the time of transmitting the message. The bounding tuples
set arrived at through application of the applicable algorithm of included SHALL be the set arrived at through application of the
section 3.5.4.2 or an equivalent, applied to the previous bounding applicable algorithm of section 3.5.4.2 or an equivalent, applied
set if any and tuples received in TMMBR messages since the last TMMBN to the previous bounding set if any and tuples received in TMMBR
was transmitted. messages since the last TMMBN was transmitted.
The reception of a TMMBR message SHALL still result in the The reception of a TMMBR message SHALL still result in the
transmission of a TMMBN message even if, after application of the transmission of a TMMBN message even if, after application of the
algorithm, the newly reported TMMBR tuple is not accepted into the algorithm, the newly reported TMMBR tuple is not accepted into the
bounding set. In such a case the bounding tuples and their owners 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 are not changed, unless the TMMBR was from an owner of a tuple
the previously calculated bounding set. This procedure allows within the previously calculated bounding set. This procedure
session participants that did not see the last TMMBN message to get a allows session participants that did not see the last TMMBN
correct view of this media sender's state. message to get a correct view of this media sender's state.
As indicated in section 4.2.1.2, when a media sender determines that As indicated in section 4.2.1.2, when a media sender determines
an "owner" of a bounding tuple has left the session, then that tuple that an "owner" of a bounding tuple has left the session, then
is removed from the bounding set, and the media sender SHALL send a that tuple is removed from the bounding set, and the media sender
TMMBN message indicating the remaining bounding tuples. If there are SHALL send a TMMBN message indicating the remaining bounding
no remaining bounding tuples a TMMBN without any FCI SHALL be sent to tuples. If there are no remaining bounding tuples a TMMBN without
indicate this. any FCI SHALL be sent to indicate this.
Note: if any media receivers remain in the session, this last will Note: if any media receivers remain in the session, this last
be a temporary situation. The empty TMMBN will cause every will be a temporary situation. The empty TMMBN will cause every
remaining media receiver to determine that its limitation belongs remaining media receiver to determine that its limitation
in the bounding set and send a TMMBR in consequence. belongs in the bounding set and send a TMMBR in consequence.
In unicast scenarios (i.e. where a single sender talks to a single In unicast scenarios (i.e. where a single sender talks to a single
receiver), the aforementioned algorithm to determine ownership receiver), the aforementioned algorithm to determine ownership
degenerates to the media receiver becoming the "owner" of the one degenerates to the media receiver becoming the "owner" of the one
bounding tuple as soon as the media receiver has issued the first bounding tuple as soon as the media receiver has issued the first
TMMBR message. TMMBR message.
4.2.2.3. Timing Rules 4.2.2.3. Timing Rules
The TMMBN acknowledgement SHOULD be sent as soon as allowed by the The TMMBN acknowledgement SHOULD be sent as soon as allowed by the
skipping to change at page 43, line 27 skipping to change at page 44, line 46
mode SHOULD 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 mixers or translators may need to As discussed in Section 4.2.1.4 mixers or translators may need to
issue TMMBN messages as responses to TMMBR messages for SSRC's issue TMMBN messages as responses to TMMBR messages for SSRC's
handled by them. handled by them.
4.3. Payload Specific Feedback Messages 4.3. Payload Specific Feedback Messages
As specified by section 6.1 of RFC 4585 [RFC4585], Payload-Specific As specified by section 6.1 of RFC 4585 [RFC4585], Payload-
FB messages are identified by the RTCP packet type value PT=PSFB Specific FB messages are identified by the RTCP packet type value
(206). PT=PSFB (206).
AVPF [RFC4585] defines three payload-specific feedback messages and AVPF [RFC4585] defines three payload-specific feedback messages
one application layer feedback message. This memo specifies four and one application layer feedback message. This memo specifies
additional payload-specific feedback messages. All are identified by four additional payload-specific feedback messages. All are
means of the FMT parameter as follows: identified by means of the FMT parameter as follows:
Assigned in [RFC4585]: Assigned in [RFC4585]:
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 15: Application layer FB message
31: reserved for future expansion of the number space 31: reserved for future expansion of the number space
Assigned in this memo: Assigned in this memo:
skipping to change at page 44, line 4 skipping to change at page 45, line 21
3: Reference Picture Selection Indication (RPSI) 3: Reference Picture Selection Indication (RPSI)
15: Application layer FB message 15: Application layer FB message
31: reserved for future expansion of the number space 31: reserved for future expansion of the number space
Assigned in this memo: 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: Unassigned:
0: unassigned 0: unassigned
8-14: unassigned 8-14: unassigned
16-30: unassigned 16-30: unassigned
The following subsections define the new FCI formats for the payload- The following subsections define the new FCI formats for the
specific feedback messages. payload-specific feedback messages.
4.3.1. Full Intra Request (FIR) 4.3.1. Full Intra Request (FIR)
The FIR message is identified by RTCP packet type value PT=PSFB and The FIR message is identified by RTCP packet type value PT=PSFB
FMT=4. and FMT=4.
The FCI field MUST contain one or more FIR entries. Each entry The FCI field MUST contain one or more FIR entries. Each entry
applies to a different media sender, identified by its SSRC. applies to a different media sender, identified by its SSRC.
4.3.1.1. Message Format 4.3.1.1. Message Format
The Feedback Control Information (FCI) for the Full Intra Request The Feedback Control Information (FCI) for the Full Intra Request
consists of one or more FCI entries, the content of which is depicted consists of one or more FCI entries, the content of which is
in Figure 4. The length of the FIR feedback message MUST be set to depicted in Figure 4. The length of the FIR feedback message MUST
2+2*N, where N is the number of FCI entries. be set to 2+2*N, where N is the number of FCI 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 | | Seq. nr | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - Syntax of an FCI entry in the FIR message Figure 4 - Syntax of an FCI entry in the FIR message
skipping to change at page 45, line 13 skipping to change at page 46, line 33
number. The initial value is arbitrary. number. The initial value is arbitrary.
Reserved (24 bits): All bits SHALL be set to 0 by the sender and Reserved (24 bits): All bits SHALL be set to 0 by the sender and
SHALL be ignored on reception. SHALL be ignored on reception.
The semantics of this feedback message is independent of the RTP The semantics of this feedback message is independent of the RTP
payload type. payload type.
4.3.1.2. Semantics 4.3.1.2. Semantics
Upon reception of FIR, the encoder MUST send a decoder refresh point Upon reception of FIR, the encoder MUST send a decoder refresh
(see section 2.2) as soon as possible. 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 payload widely deployed for FIR, as it appears to be the only RTP payload widely
that relies heavily on media prediction across RTP packet deployed that relies heavily on media prediction across RTP
boundaries. However, use of FIR could also reasonably be packet 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
dynamic updates of MPEG-4 scene descriptions. It is suggested that the dynamic updates of MPEG-4 scene descriptions. It is
payload formats for such media types refer to FIR and other message suggested that payload formats for such media types refer to FIR
types defined in this specification and in AVPF [RFC4585], instead and other message types defined in this specification and in
of creating similar mechanisms in the payload specifications. The AVPF [RFC4585], instead of creating similar mechanisms in the
payload specifications may have to explain how the payload-specific payload specifications. The payload specifications may have to
terminologies map to the video-centric terminology used herein. explain how the payload-specific 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),
reaction to this command cannot be specified. One suitable the 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,
may be preferable not to react to the command at all, e.g. when it may be preferable not to react to the command at all, e.g.
streaming to a large multicast group. Other reactions may also be when streaming to a large multicast group. Other reactions may
possible. When deciding on a strategy, a sender could take into also be possible. When deciding on a strategy, a sender could
account factors such as the size of the receiving group, the take into account factors such as the size of the receiving
"importance" of the sender of the FIR message (however "importance" group, the "importance" of the sender of the FIR message
may be defined in this specific application), the frequency of (however "importance" may be defined in this specific
decoder refresh points in the content, and so on. However a application), the frequency of decoder refresh points in the
session which predominately handles pre-coded content is not content, and so on. However a session which predominately
expected to use FIR at all. handles pre-coded content is not 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 section
which MAY restrict its ability to send a decoder refresh point 5, which MAY restrict its ability to send a decoder refresh point
quickly. quickly.
Note: The relationship between the Picture Loss Indication and FIR Note: The relationship between the Picture Loss Indication and
is as follows. As discussed in section 6.3.1 of AVPF [RFC4585], a FIR is as follows. As discussed in section 6.3.1 of AVPF
Picture Loss Indication informs the decoder about the loss of a [RFC4585], a Picture Loss Indication informs the decoder about
picture and hence the likelihood of misalignment of the reference the loss of a picture and hence the likelihood of misalignment
pictures between the encoder and decoder. Such a scenario is of the reference pictures between the encoder and decoder. Such
normally related to losses in an ongoing connection. In point-to- a scenario is normally related to losses in an ongoing
point scenarios, and without the presence of advanced error connection. In point-to-point scenarios, and without the
resilience tools, one possible option for an encoder consists in presence of advanced error resilience tools, one possible option
sending a decoder refresh point. However, there are other options. for an encoder consists in sending a decoder refresh point.
One example is that the media sender ignores the PLI, because the However, there are other options. One example is that the media
embedded stream redundancy is likely to clean up the reproduced sender ignores the PLI, because the embedded stream redundancy
picture within a reasonable amount of time. The FIR, in contrast, is likely to clean up the reproduced picture within a reasonable
leaves a (real-time) encoder no choice but to send a decoder amount of time. The FIR, in contrast, leaves a (real-time)
refresh point. It does not allow the encoder to take into account encoder no choice but to send a decoder refresh point. It does
any considerations such as the ones mentioned above. not allow the encoder to take into account 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 is problematic from a congestion control point of viewpoint, but is problematic from a congestion control point of
view. "As soon as possible" as mentioned above appears to be a view. "As soon as possible" as mentioned above appears to be 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 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
video unusable for the users. the 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
in a multipoint conference, a new user joins the session and no when, in a multipoint conference, a new user joins the session
regular decoder refresh point interval is established. Another and no regular decoder refresh point interval is established.
example would be a video switching MCU that changes streams. Here, Another example would be a video switching MCU that changes
normally, the MCU issues a FIR to the new sender so to force it to streams. Here, normally, the MCU issues a FIR to the new sender
emit a decoder refresh point. The decoder refresh point normally so to force it to emit a decoder refresh point. The decoder
includes a Freeze Picture Release (defined outside this refresh point normally includes a Freeze Picture Release
specification), which re-starts the rendering process of the (defined outside this specification), which re-starts the
receivers. Both techniques mentioned are commonly used in MCU- rendering process of the receivers. Both techniques mentioned
based multipoint conferences. are commonly used in MCU-based multipoint conferences.
Other RTP payload specifications such as RFC 4587 [RFC4587] already Other RTP payload specifications such as RFC 2032 [RFC2032]
define a feedback mechanism for certain codecs. An application already define a feedback mechanism for certain codecs. An
supporting both schemes MUST use the feedback mechanism defined in application supporting both schemes MUST use the feedback
this specification when sending feedback. For backward compatibility mechanism defined in this specification when sending feedback.
reasons, such an application SHOULD also be capable to receive and For backward compatibility reasons, such an application SHOULD
react to the feedback scheme defined in the respective RTP payload also be capable to receive and react to the feedback scheme
format, if this is required by that payload format. defined in the respective RTP payload format, if this is required
by that payload format.
Within the common packet header for feedback messages (as defined in Within the common packet header for feedback messages (as defined
section 6.1 of [RFC4585]), the "SSRC of the packet sender" field in section 6.1 of [RFC4585]), the "SSRC of the packet sender"
indicates the source of the request, and the "SSRC of media source" field indicates the source of the request, and the "SSRC of media
is not used and SHALL be set to 0. The SSRCs of the media senders to source" is not used and SHALL be set to 0. The SSRCs of the media
which the FIR command applies are in the corresponding FCI entries. senders to which the FIR command applies are in the corresponding
A TSTR message MAY contain requests to multiple media senders, using FCI entries. A TSTR message MAY contain requests to multiple
one FCI entry per target media sender. media senders, using one FCI entry per target media sender.
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].
commands MAY be used with early or immediate feedback. The FIR FIR commands MAY be used with early or immediate feedback. The
feedback message MAY be repeated. If using immediate feedback mode FIR feedback message MAY be repeated. If using immediate feedback
the repetition SHOULD wait at least one RTT before being sent. In mode the repetition SHOULD wait at least one RTT before being
early or regular RTCP mode the repetition is sent in the next regular sent. In early or regular RTCP mode the repetition is sent in the
RTCP packet. next regular RTCP packet.
4.3.1.4. Handling of FIR 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
forward the message unaltered; instead it SHOULD issue a FIR itself. NOT 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
sending of full intra or IDR pictures. Both are several times larger the sending of full intra or IDR pictures. Both are several times
then predicted (inter) pictures. Their size is independent of the larger then predicted (inter) pictures. Their size is independent
time they are generated. In most environments, especially when of the time they are generated. In most environments, especially
employing bandwidth-limited links, the use of an intra picture when employing bandwidth-limited links, the use of an intra
implies an allowed delay that is a significant multiple of the picture implies an allowed delay that is a significant multiple of
typical frame duration. An example: if the sending frame rate is 10 the typical frame duration. An example: if the sending frame rate
fps, and an intra picture is assumed to be 10 times as big as an is 10 fps, and an intra picture is assumed to be 10 times as big
inter picture, then a full second of latency has to be accepted. In as an inter picture, then a full second of latency has to be
such an environment there is no need for a particularly short delay accepted. In such an environment there is no need for a
in sending the FIR message. Hence waiting for the next possible time particularly short delay in sending the FIR message. Hence
slot allowed by RTCP timing rules as per [RFC4585] should not have an waiting for the next possible time slot allowed by RTCP timing
overly negative impact on the system performance. rules as per [RFC4585] should not have an 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 feedback message is identified by RTCP packet type value The TSTR feedback message is identified by RTCP packet type value
PT=PSFB and FMT=5. PT=PSFB and FMT=5.
The FCI field MUST contain one or more TSTR FCI entries. The FCI field MUST contain one or more TSTR FCI entries.
4.3.2.1. Message Format 4.3.2.1. Message Format
The content of the FCI entry for the Temporal-Spatial Trade-off The content of the FCI entry for the Temporal-Spatial Trade-off
Request is depicted in Figure 5. The length of the feedback message Request is depicted in Figure 5. The length of the feedback
MUST be set to 2+2*N, where N is the number of FCI entries included. message MUST be set to 2+2*N, where N is the number of FCI entries
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 5 - Syntax of an FCI Entry in the TSTR Message Figure 5 - Syntax of an FCI Entry in the TSTR Message
SSRC (32 bits): The SSRC of the media sender which is requested
SSRC (32 bits): The SSRC of the media sender which is requested to to apply the tradeoff value given in Index.
apply the tradeoff value given in Index.
Seq. nr (8 bits): Request sequence number. The sequence number Seq. nr (8 bits): Request sequence number. The sequence number
space is unique for pairing of the SSRC of request source space is unique for pairing of the SSRC of request
and the SSRC of the request target. The sequence number source and the SSRC of the request target. The sequence
SHALL be increased by 1 modulo 256 for each new command. number SHALL be increased by 1 modulo 256 for each new
A repetition SHALL NOT increase the sequence number. The command. A repetition SHALL NOT increase the sequence
initial value is arbitrary. number. The initial value is arbitrary.
Reserved (19 bits): All bits SHALL be set to 0 by the sender and Reserved (19 bits): All bits SHALL be set to 0 by the sender and
SHALL be ignored on reception. SHALL be ignored on reception.
Index (5 bits): An integer value between 0 and 31 that indicates Index (5 bits): An integer value between 0 and 31 that indicates
the relative trade off that is requested. An index value the relative trade off that is requested. An index
of 0 index highest possible spatial quality, while 31 value of 0 index highest possible spatial quality, while
indicates highest possible temporal resolution. 31 indicates highest possible temporal resolution.
4.3.2.2. Semantics 4.3.2.2. Semantics
A decoder can suggest a temporal-spatial trade-off level by sending a A decoder can suggest a temporal-spatial trade-off level by
TSTR message to an encoder. If the encoder is capable of adjusting sending a TSTR message to an encoder. If the encoder is capable
its temporal-spatial trade-off, it SHOULD take into account the of adjusting its temporal-spatial trade-off, it SHOULD take into
received TSTR message for future coding of pictures. A value of 0 account the received TSTR message for future coding of pictures.
suggests a high spatial quality and a value of 31 suggests a high A value of 0 suggests a high spatial quality and a value of 31
frame rate. The progression of values from 0 to 31 indicate suggests a high frame rate. The progression of values from 0 to
monotonically a desire for higher frame rate. The index values do 31 indicate monotonically a desire for higher frame rate. The
not correspond to precise values of spatial quality or frame rate. 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 The reaction to the reception of more than one TSTR message by a
media sender from different media receivers is left open to the media sender from different media receivers is left open to the
implementation. The selected trade-off SHALL be communicated to the implementation. The selected trade-off SHALL be communicated to
media receivers by the means of the TSTN message. the media receivers by the means of the TSTN message.
Within the common packet header for feedback messages (as defined in Within the common packet header for feedback messages (as defined
section 6.1 of [RFC4585]), the "SSRC of the packet sender" field in section 6.1 of [RFC4585]), the "SSRC of the packet sender"
indicates the source of the request, and the "SSRC of media source" field indicates the source of the request, and the "SSRC of media
is not used and SHALL be set to 0. The SSRCs of the media senders to source" is not used and SHALL be set to 0. The SSRCs of the media
which the TSTR applies to are in the corresponding FCI entries. senders to which the TSTR applies to are in the corresponding FCI
entries.
A TSTR message MAY contain requests to multiple media senders, using A TSTR message MAY contain requests to multiple media senders,
one FCI entry per target media sender. 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
A mixer or media translator that encodes content sent to the session A mixer or media translator that encodes content sent to the
participant issuing the TSTR SHALL consider the request to determine session participant issuing the TSTR SHALL consider the request to
if it can fulfill it by changing its own encoding parameters. A determine if it can fulfill it by changing its own encoding
media translator unable to fulfill the request MAY forward the parameters. A media translator unable to fulfill the request MAY
request unaltered towards the media sender. A mixer encoding for forward the request unaltered towards the media sender. A mixer
multiple session participants will need to consider the joint needs encoding for multiple session participants will need to consider
of these participants before generating a TSTR on its own behalf the joint needs of these participants before generating a TSTR on
towards the media sender. See also the discussion in Section 3.5.2. its own behalf 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
is using. In fact, in most scenarios the video resolution stays video is using. In fact, in most scenarios the video resolution
constant during the lifetime of a session. However, all video stays constant during the lifetime of a session. However, all
compression standards have means to adjust the spatial quality at a video compression standards have means to adjust the spatial
given resolution, often influenced by the Quantizer Parameter or QP. quality at a given resolution, often influenced by the Quantizer
A numerically low QP results in a good reconstructed picture quality, Parameter or QP. A numerically low QP results in a good
whereas a numerically high QP yields a coarse picture. The typical reconstructed picture quality, whereas a numerically high QP
reaction of an encoder to this request is to change its rate control yields a coarse picture. The typical reaction of an encoder to
parameters to use a lower frame rate and a numerically lower (on this request is to change its rate control parameters to use a
average) QP, or vice versa. The precise mapping of Index value to lower frame rate and a numerically lower (on average) QP, or vice
frame rate and QP is intentionally left open here, as it depends on versa. The precise mapping of Index value to frame rate and QP is
factors such as the compression standard employed, spatial intentionally left open here, as it depends on factors such as the
resolution, content, bit rate, and so on. compression standard employed, spatial 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 RTCP packet type value PT=PSFB and The TSTN message is identified by RTCP packet type value PT=PSFB
FMT=6. and FMT=6.
The FCI field SHALL contain one or more TSTN FCI entries. The FCI field SHALL contain one or more TSTN FCI entries.
4.3.3.1. Message Format 4.3.3.1. Message Format
The content of an FCI entry for the Temporal-Spatial Trade-off The content of an FCI entry for the Temporal-Spatial Trade-off
Notification is depicted in Figure 6. The length of the TSTN message Notification is depicted in Figure 6. The length of the TSTN
MUST be set to 2+2*N, where N is the number of FCI entries. message MUST be set to 2+2*N, where N is the number of FCI
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 6 - Syntax of the TSTN Figure 6 - Syntax of the TSTN
SSRC (32 bits): The SSRC of the source of the TSTR request which SSRC (32 bits): The SSRC of the source of the TSTR request which
resulted in this Notification. resulted in this Notification.
Seq. nr (8 bits): The sequence number value from the TSTN request Seq. nr (8 bits): The sequence number value from the TSTN
that is being acknowledged. request that is being acknowledged.
Reserved (19 bits): All bits SHALL be set to 0 by the sender and Reserved (19 bits): All bits SHALL be set to 0 by the sender and
SHALL be ignored on reception. SHALL be ignored on reception.
Index (5 bits): The trade-off value the media sender is using Index (5 bits): The trade-off value the media sender is using
henceforth. henceforth.
Informative note: The returned trade-off value (Index) may differ Informative note: The returned trade-off value (Index) may
from the requested one, for example in cases where a media encoder differ from the requested one, for example in cases where a
cannot tune its trade-off, or when pre-recorded content is used. media encoder cannot tune its trade-off, or when pre-recorded
content is used.
4.3.3.2. Semantics 4.3.3.2. Semantics
This feedback message is used to acknowledge the reception of a TSTR. This feedback message is used to acknowledge the reception of a
One TSTN entry in a TSTN feedback message SHALL be sent for each TSTR TSTR. One TSTN entry in a TSTN feedback message SHALL be sent for
entry targeted to this session participant, i.e. each TSTR received each TSTR entry targeted to this session participant, i.e. each
that in the SSRC field in the entry has the receiving entities SSRC. TSTR received that in the SSRC field in the entry has the
A single TSTN message MAY acknowledge multiple requests using receiving entities SSRC. A single TSTN message MAY acknowledge
multiple FCI entries. The index value included SHALL be the same in multiple requests using multiple FCI entries. The index value
all FCI entries of the TSTN message. Including a FCI for each included SHALL be the same in all FCI entries of the TSTN message.
requestor allows each requesting entity to determine that the media Including a FCI for each requestor allows each requesting entity
sender received the request. The Notification SHALL also be sent in to determine that the media sender received the request. The
response to TSTR repetitions received. If the request receiver has Notification SHALL also be sent in response to TSTR repetitions
received TSTR with several different sequence numbers from a single received. If the request receiver has received TSTR with several
requestor it SHALL only respond to the request with the highest different sequence numbers from a single requestor it SHALL only
(modulo 256) sequence number. respond to the request with the highest (modulo 256) sequence
number.
The TSTN SHALL include the Temporal-Spatial Trade-off index that will The TSTN SHALL include the Temporal-Spatial Trade-off index that
be used as a result of the request. This is not necessarily the same will be used as a result of the request. This is not necessarily
index as requested, as the media sender may need to aggregate the same index as requested, as the media sender may need to
requests from several requesting session participants. It may also aggregate requests from several requesting session participants.
have some other policies or rules that limit the selection. It may also have some other policies or rules that limit the
selection.
Within the common packet header for feedback messages (as defined in Within the common packet header for feedback messages (as defined
section 6.1 of [RFC4585]), the "SSRC of the packet sender" field in section 6.1 of [RFC4585]), the "SSRC of the packet sender"
indicates the source of the Notification, and the "SSRC of media field indicates the source of the Notification, and the "SSRC of
source" is not used and SHALL be set to 0. The SSRCs of the 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 requesting entities to which the Notification applies are in the
corresponding FCI entries. 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 TSTN in Mixer and Translators 4.3.3.4. Handling of TSTN in Mixer and Translators
A mixer or translator that acts upon a TSTR SHALL also send the A mixer or translator that acts upon a TSTR SHALL also send the
corresponding TSTN. In cases where it needs to forward a TSTR itself corresponding TSTN. In cases where it needs to forward a TSTR
the notification message MAY need to be delayed until the TSTR has itself the notification message MAY need to be delayed until the
been responded to. TSTR has 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 RTCP packet type value PT=PSFB and FMT=7. The VBCM is identified by RTCP packet type value PT=PSFB and
FMT=7.
The FCI field MUST contain one or more VBCM FCI entries. The FCI field MUST contain one or more VBCM FCI entries.
4.3.4.1. Message Format 4.3.4.1. Message Format
The syntax of an FCI entry within the VBCM indication is depicted in The syntax of an FCI entry within the VBCM indication is depicted
Figure 7. in Figure 7.
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 |0| Payload Type| Length | | Seq. nr |0| Payload Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VBCM Octet String.... | Padding | | VBCM Octet String.... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 - Syntax of an FCI Entry in the VBCM Message Figure 7 - Syntax of an FCI Entry in the VBCM Message
SSRC (32 bits): The SSRC value of the media sender that is requested SSRC (32 bits): The SSRC value of the media sender that is
to instruct its encoder to react to the VBCM message requested to instruct its encoder to react to the VBCM
message
Seq. nr (8 bits): Command sequence number. The sequence number space Seq. nr (8 bits): Command sequence number. The sequence number
is unique for pairing of the SSRC of command source and the space is unique for pairing of the SSRC of command source
SSRC of the command target. The sequence number SHALL be and the SSRC of the command target. The sequence number
increased by 1 modulo 256 for each new command. A repetition SHALL be increased by 1 modulo 256 for each new command. A
SHALL NOT increase the sequence number. The initial value is repetition SHALL NOT increase the sequence number. The
arbitrary. initial value is arbitrary.
0: Must be set to 0 by the sender and should not be acted upon by the 0: Must be set to 0 by the sender and should not be acted upon by
message receiver. the message receiver.
Payload Type (7 bits): The RTP payload type for which the VBCM bit Payload Type (7 bits): The RTP payload type for which the VBCM bit
stream must be interpreted. stream must be interpreted.
Length (16 bits): The length of the VBCM octet string in octets Length (16 bits): The length of the VBCM octet string in octets
exclusive of any padding octets exclusive of any padding octets
VBCM Octet String (Variable length): This is the octet string VBCM Octet String (Variable length): This is the octet string
generated by the decoder carrying a specific feedback sub- generated by the decoder carrying a specific feedback sub-
message. message.
Padding (Variable length): Bits set to 0 to make up a 32 bit Padding (Variable length): Bits set to 0 to make up a 32 bit
boundary. boundary.
4.3.4.2. Semantics 4.3.4.2. Semantics
The "payload" of the VBCM indication carries different types of The "payload" of the VBCM indication carries different types of
skipping to change at page 53, line 16 skipping to change at page 55, line 10
message. message.
Padding (Variable length): Bits set to 0 to make up a 32 bit Padding (Variable length): Bits set to 0 to make up a 32 bit
boundary. boundary.
4.3.4.2. Semantics 4.3.4.2. Semantics
The "payload" of the VBCM indication carries different types of The "payload" of the VBCM indication carries different types of
codec-specific, feedback information. The type of feedback codec-specific, feedback information. The type of feedback
information can be classified as a 'status report' (such as an information can be classified as a 'status report' (such as an
indication that a bit stream was received without errors, or that a indication that a bit stream was received without errors, or that
partial or complete picture or block was lost) or 'update requests' a partial or complete picture or block was lost) or 'update
(such as complete refresh of the bit stream). 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
section 3.5.3 for further discussion. see 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
indicated by the "payloadType" as defined in [VBCM]. These sub- are indicated by the "payloadType" as defined in [VBCM]. These
message types are reproduced below for convenience. "payloadType", sub-message types are reproduced below for convenience.
in ITU-T Rec. H.271 terminology, refers to the sub-type of the H.271 "payloadType", in ITU-T Rec. H.271 terminology, refers to the sub-
message and should not be confused with an RTP payload type. type of the H.271 message and should not be confused with an RTP
payload type.
Payload Message Content Payload Message Content
Type Type
--------------------------------------------------------------------- ---------------------------------------------------------------------
0 One or more pictures without detected bit stream error 0 One or more pictures without detected bit stream error
mismatch 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 bit stream as if no prior bit stream data refresh the video bit stream as if no prior bit stream data
had 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 ("payloadTypes") Table 2: H.271 message types ("payloadTypes")
The bit string or the "payload" of a 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,
format. The media sender necessarily has to be able to parse this binary format. The media sender necessarily has to be able to
optimized binary format to make use of VBCM messages. parse this 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 semantics depending on the codec payloadType) may have different semantics depending on the codec
used. used.
Within the common packet header for feedback messages (as defined in Within the common packet header for feedback messages (as defined
section 6.1 of [RFC4585]), the "SSRC of the packet sender" field in section 6.1 of [RFC4585]), the "SSRC of the packet sender"
indicates the source of the request, and the "SSRC of media source" field indicates the source of the request, and the "SSRC of media
is not used and SHALL be set to 0. The SSRCs of the media senders to source" is not used and SHALL be set to 0. The SSRCs of the media
which the VBCM message applies to are in the corresponding FCI senders to which the VBCM message applies to are in the
entries. The sender of the VBCM message MAY send H.271 messages to corresponding FCI entries. The sender of the VBCM message MAY
multiple media senders and MAY send more than one H.271 message to send H.271 messages to multiple media senders and MAY send more
the same media sender within the same VBCM message. 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].
different sub-message types may have different properties in regards The different sub-message types may have different properties in
to the timing of messages that should be used. If several different regards to the timing of messages that should be used. If several
types are included in the same feedback packet then the requirements different types are included in the same feedback packet then the
for the sub-message type with the most stringent requirements should requirements for the sub-message type with the most stringent
be followed. 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 is 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 a discussion of the usage of H.271 Please see section 3.5.3 for a discussion of the usage of H.271
messages and messages defined in AVPF [RFC4585] and this memo with messages and messages defined in AVPF [RFC4585] and this memo with
similar functionality. similar functionality.
Note: There has been some discussion whether the payload type field Note: There has been some discussion whether the payload type
in this message is needed. It will be needed if there is field in this message is needed. It will be needed if there is
potentially more than one VBCM-capable RTP payload type in the same potentially more than one VBCM-capable RTP payload type in the
session, and the semantics of a given VBCM message changes between same session, and the semantics of a given VBCM message changes
payload types. For example, the picture identification mechanism between payload types. For example, the picture identification
in messages of H.271 type 0 is fundamentally different between mechanism in messages of H.271 type 0 is fundamentally different
H.263 and H.264 (although both use the same syntax). Therefore, between H.263 and H.264 (although both use the same syntax).
the payload field is justified here. There was a further comment Therefore, the payload field is justified here. There was a
that for TSTS and FIR such a need does not exist, because the further comment that for TSTS and FIR such a need does not
semantics of TSTS and FIR are either loosely enough defined, or exist, because the semantics of TSTS and FIR are either loosely
generic enough, to apply to all video payloads currently in enough defined, or generic enough, to apply to all video
existence/envisioned. payloads currently in existence/envisioned.
5. Congestion Control 5. Congestion Control
The correct application of the AVPF [RFC4585] timing rules prevents The correct application of the AVPF [RFC4585] timing rules
the network from being flooded by feedback messages. Hence, assuming prevents the network from being flooded by feedback messages.
a correct implementation and configuration, the RTCP channel cannot Hence, assuming a correct implementation and configuration, the
break its bit rate commitment and introduce congestion. RTCP channel cannot 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
of the media senders or, more specifically, the media encoders. Thus behaviour of the media senders or, more specifically, the media
modified behaviour MUST respect the bandwidth limits that the encoders. Thus modified behaviour MUST respect the bandwidth
application of congestion control provides. For example, when a limits that the application of congestion control provides. For
media sender is reacting to a FIR, the unusually high number of example, when a media sender is reacting to a FIR, the unusually
packets that form the decoder refresh point have to be paced in high number of packets that form the decoder refresh point have to
compliance with the congestion control algorithm, even if the user be paced in compliance with the congestion control algorithm, even
experience suffers from a slowly transmitted decoder refresh point. if the user 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
request REQUIRES the media sender to use congestion control when a 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
value results in a reduced transmission bit rate thus reducing the the value results in a reduced transmission bit rate thus reducing
risk for congestion. the 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 implications. These must be addressed and taken into account by
users 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
this type of attack, authentication and integrity protection of the prevent this type of attack, authentication and integrity
setup signaling is required. protection of the setup signaling is required.
Spoofed or maliciously created feedback messages of the type defined Spoofed or maliciously created feedback messages of the type
in this specification can have the following implications: defined in this specification can have the following implications:
a. severely reduced media bit rate due to false TMMBR messages a. severely reduced media bit rate due to false TMMBR messages
that sets the maximum to a very low value; that sets the maximum to a very low value;
b. assignment of the ownership of a bounding tuple to the wrong b. assignment of the ownership of a bounding tuple to the
participant within a TMMBN message, potentially causing wrong participant within a TMMBN message, potentially
unnecessary oscillation in the bounding set as the mistakenly causing unnecessary oscillation in the bounding set as the
identified owner reports a change in its tuple and the true mistakenly identified owner reports a change in its tuple
owner possibly holds back on changes until a correct TMMBN and the true owner possibly holds back on changes until a
message reaches the participants; correct TMMBN message reaches the participants;
c. sending TSTR requests that result in a video quality c. sending TSTR requests that result in a video quality
different from the user's desire, rendering the session less different from the user's desire, rendering the session
useful. less useful.
d. Frequent FIR commands will potentially reduce the frame-rate, d. Frequent FIR commands will potentially reduce the frame-
making the video jerky, due to the frequent usage of decoder rate, making the video jerky, due to the frequent usage of
refresh points. decoder 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
integrity protection of the feedback messages. This can be and 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]. In the mixer cases, separate security contexts and SAVPF [SAVPF]. In the mixer cases, separate security contexts and
filtering can be applied between the mixer and the participants thus filtering can be applied between the mixer and the participants
protecting other users on the mixer from a misbehaving participant. thus protecting other users on the mixer from a misbehaving
participant.
7. SDP Definitions 7. SDP Definitions
Section 4 of [RFC4585] defines a new SDP [RFC4566] attribute, rtcp- Section 4 of [RFC4585] defines a new SDP [RFC4566] attribute,
fb, that may be used to negotiate the capability to handle specific rtcp-fb, that may be used to negotiate the capability to handle
AVPF commands and indications, such as Reference Picture Selection, specific AVPF commands and indications, such as Reference Picture
Picture Loss Indication etc. The ABNF for rtcp-fb is described in Selection, Picture Loss Indication etc. The ABNF for rtcp-fb is
section 4.2 of [RFC4585]. In this section we extend the rtcp-fb described in section 4.2 of [RFC4585]. In this section we extend
attribute to include the commands and indications that are described the rtcp-fb attribute to include the commands and indications that
for codec control protocol in the present document. We also discuss are described for codec control protocol in the present document.
the Offer/Answer implications for the codec control commands and We also discuss the Offer/Answer implications for the codec
indications. control commands and indications.
7.1. Extension of the rtcp-fb Attribute 7.1. Extension of the rtcp-fb Attribute
As described in AVPF [RFC4585], the rtcp-fb attribute indicates the As described in AVPF [RFC4585], the rtcp-fb attribute indicates
capability of using RTCP feedback. AVPF specifies that the rtcp-fb the capability of using RTCP feedback. AVPF specifies that the
attribute must only be used as a media level attribute and must not rtcp-fb attribute must only be used as a media level attribute and
be provided at session level. All the rules described in [RFC4585] must not be provided at session level. All the rules described in
for rtcp-fb attribute relating to payload type and to multiple rtcp- [RFC4585] for rtcp-fb attribute relating to payload type and to
fb attributes in a session description also apply to the new feedback multiple rtcp-fb attributes in a session description also apply to
messages defined in this memo. the new feedback messages defined in this memo.
The ABNF [RFC4234] for rtcp-fb as defined in [RFC4585] is The ABNF [RFC4234] for rtcp-fb as defined in [RFC4585] is
"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
of the feedback message such as ack, nack, trr-int and rtcp-fb-id. type of the feedback message such as ack, nack, trr-int and rtcp-
For example to indicate the support of feedback of picture loss fb-id. For example to indicate the support of feedback of picture
indication, the sender declares the following in SDP loss 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 "ccm" which indicates In this document we define a new feedback value "ccm" which
the support of codec control using RTCP feedback messages. The "ccm" indicates the support of codec control using RTCP feedback
feedback value SHOULD be used with parameters, which indicate the messages. The "ccm" feedback value SHOULD be used with
specific codec control commands supported. In this draft we define parameters, which indicate the specific codec control commands
four parameters, which can be used with the ccm feedback value type. supported. In this draft we define four parameters, which can be
used with the ccm feedback value type.
o "fir" indicates the support of the Full Intra Request (FIR). o "fir" indicates the support of the Full Intra Request (FIR).
o "tmmbr" indicates the support of the Temporary Maximum Media o "tmmbr" indicates the support of the Temporary Maximum Media
Stream Bit Rate Request/Notification (TMMBR/TMMBN). It has an Stream Bit Rate Request/Notification (TMMBR/TMMBN). It has
optional sub parameter to indicate the session maximum packet an optional sub parameter to indicate the session maximum
rate to be used. If not included this defaults to infinity. packet rate to be used. If not included this defaults to
o "tstr" indicates the support of the Temporal-Spatial Trade-off infinity.
Request/Notification (TSTR/TSTN). o "tstr" indicates the support of the Temporal-Spatial Trade-
off 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 (VBCM). It has zero or more subparameters identifying messages (VBCM). It has zero or more subparameters
the supported H.271 "payloadType" values. identifying the supported H.271 "payloadType" values.
In the ABNF for rtcp-fb-val defined in [RFC4585], there is a In the ABNF for rtcp-fb-val defined in [RFC4585], there is a
placeholder called rtcp-fb-id to define new feedback types. "ccm" is placeholder called rtcp-fb-id to define new feedback types. "ccm"
defined as a new feedback type in this document and the ABNF for the is defined as a new feedback type in this document and the ABNF
parameters for ccm are defined here (please refer to section 4.2 of for the parameters for ccm are defined here (please refer to
[RFC4585] for complete ABNF syntax). section 4.2 of [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
skipping to change at page 58, line 23 skipping to change at page 60, line 26
7.2. Offer-Answer 7.2. Offer-Answer
The Offer/Answer [RFC3264] implications for 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 commands and indications. The answerer MUST remove all ccm
parameters which it does not understand or does not wish to use in parameters which it does not understand or does not wish to use in
this 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
use feedback messages negotiated in this way. only 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 the session maximum packet rate indicated in a response. If the session maximum packet rate
parameter is not present in an offer it SHALL NOT be included by the parameter is not present in an offer it SHALL NOT be included by
answerer. 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
to support the FIR and TSTR/TSTN codec control messages. The SDP is capability to support the FIR and TSTR/TSTN codec control
carried in a high level signaling protocol like SIP. messages. The SDP is 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 192.0.2.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
skipping to change at page 59, line 4 skipping to change at page 61, line 8
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 192.0.2.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, when the sender receives a TSTR message from In the above example, when the sender receives a TSTR message from
the remote party it is capable of adjusting the trade off as the remote party it is capable of adjusting the trade off as
indicated in the RTCP 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
The participant supports only the FIR (Full Intra Request) codec session. The participant supports only the FIR (Full Intra
control command and it declares it in its session description. Request) codec control command and it declares it in its session
description.
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 192.0.2.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
sends an RTCP FIR feedback message. Upon receiving this feedback it sends an RTCP FIR feedback message. Upon receiving this
message the end point is required to generate a full intra request. feedback 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
support "tstr", "fir" and "tmmbr". The offered SDP is to 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 192.0.2.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
skipping to change at page 60, line 17 skipping to change at page 62, line 24
c=IN IP4 192.0.2.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 sub-messages of payloadType 1 Offerer wishes to support VBCM and the sub-messages of payloadType
(one or more pictures that are entirely or partially lost) and 2 (a 1 (one or more pictures that are entirely or partially lost) and 2
set of blocks of one picture that are entirely or partially lost). (a 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 192.0.2.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
skipping to change at page 62, line 7 skipping to change at page 64, line 7
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 indications comprised of 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 "ccm" needs to be registered with IANA in the "rtcp-fb" The new value "ccm" needs to be registered with IANA in the "rtcp-
Attribute Values registry located at the time of publication at: fb" Attribute Values registry located at the time of publication
at:
http://www.iana.org/assignments/sdp-parameters 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
A new registry "Codec Control Messages" needs to be created to hold A new registry "Codec Control Messages" needs to be created to
"ccm" parameters located at time of publication at: hold "ccm" parameters located at time of publication at:
http://www.iana.org/assignments/sdp-parameters http://www.iana.org/assignments/sdp-parameters
New registration in this registry follows the "Specification New registration in this registry follows the "Specification
required" policy as defined by [RFC2434]. In addition they are required" policy as defined by [RFC2434]. In addition they are
required to indicate which, if any additional RTCP feedback types, required to indicate which, if any additional RTCP feedback types,
such as "nack", "ack". such as "nack", "ack".
The initial content of the registry is the following values: The initial content of the registry is the following values:
Value name: fir Value name: fir
skipping to change at page 62, line 46 skipping to change at page 64, line 47
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
The following values need to be registered as FMT values in the "FMT The following values need to be registered as FMT values in the
Values for RTPFB Payload Types" registry located at the time of "FMT Values for RTPFB Payload Types" registry located at the time
publication at: http://www.iana.org/assignments/rtp-parameters of publication at: http://www.iana.org/assignments/rtp-parameters
RTPFB range RTPFB range
Name Long Name Value Reference Name Long Name Value Reference
-------------- --------------------------------- ----- --------- -------------- --------------------------------- ----- ---------
Reserved 2 [RFCxxxx] Reserved 2 [RFCxxxx]
TMMBR Temporary Maximum Media Stream Bit 3 [RFCxxxx] TMMBR Temporary Maximum Media Stream Bit 3 [RFCxxxx]
Rate Request Rate Request
TMMBN Temporary Maximum Media Stream Bit 4 [RFCxxxx] TMMBN Temporary Maximum Media Stream Bit 4 [RFCxxxx]
Rate Notification Rate Notification
The following values need to be registered as FMT values in the "FMT The following values need to be registered as FMT values in the
Values for PSFB Payload Types" registry located at the time of "FMT Values for PSFB Payload Types" registry located at the time
publication at: http://www.iana.org/assignments/rtp-parameters of publication at: http://www.iana.org/assignments/rtp-parameters
PSFB range PSFB range
Name Long Name Value Reference Name Long Name Value Reference
-------------- --------------------------------- ----- --------- -------------- --------------------------------- ----- ---------
FIR Full Intra Request Command 4 [RFCxxxx] FIR Full Intra Request Command 4 [RFCxxxx]
TSTR Temporal-Spatial Trade-off Request 5 [RFCxxxx] TSTR Temporal-Spatial Trade-off Request 5 [RFCxxxx]
TSTN Temporal-Spatial Trade-off Notification 6 [RFCxxxx] TSTN Temporal-Spatial Trade-off Notification 6 [RFCxxxx]
VBCM Video Back Channel Message 7 [RFCxxxx] VBCM Video Back Channel Message 7 [RFCxxxx]
9. Contributors 9. Contributors
Tom Taylor has made a very significant contribution, for which the Tom Taylor has made a very significant contribution, for which the
authors are very grateful, to this specification by helping rewrite authors are very grateful, to this specification by helping
the specification. Especially the parts regarding the algorithm for rewrite the specification. Especially the parts regarding the
determining bounding sets for TMMBR have benefited. algorithm for determining bounding sets for TMMBR have benefited.
10. Acknowledgements 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
Even, Colin Perkins, Randell Jesup, Keith Lantz, Harikishan Desineni, Roni Even, Colin Perkins, Randell Jesup, Keith Lantz, Harikishan
Guido Franceschini and others. The authors appreciate these reviews. Desineni, 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.
11. References 11. References
11.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,
"Extended RTP Profile for Real-Time Transport Control J., "Extended RTP Profile for Real-Time Transport
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Control Protocol (RTCP)-Based Feedback (RTP/AVPF)",
[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.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Description Protocol", RFC 4566, July 2006. Session 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
with Session Description Protocol (SDP)", RFC 3264, June Model with Session Description Protocol (SDP)", RFC
2002. 3264, June 2002.
[Topologies] M. Westerlund, and S. Wenger, "RTP Topologies", draft- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an an IANA Considerations Section in RFCs", BCP 26, RFC
IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2434, October 1998.
October 1998.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
11.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
control commands", draft-basso-avt-videoconreq-02.txt, video control commands", draft-basso-avt-videoconreq-
expired Internet Draft, October 2004. 02.txt, 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
Recommendation and Final Draft International Standard of ITU-T Recommendation and Final Draft International
Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC Standard of Joint Video Specification (ITU-T Rec.
14496-10 AVC), Joint Video Team (JVT) of ISO/IEC MPEG H.264 | ISO/IEC 14496-10 AVC), Joint Video Team (JVT)
and ITU-T VCEG, JVT-G050, March 2003. of ISO/IEC MPEG and ITU-T VCEG, JVT-G050, March 2003.
[H245] ITU-T Rec. HG.245, "Control protocol for multimedia [H245] ITU-T Rec. HG.245, "Control protocol for multimedia
communication", MAY 2006 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 Video Coding by Dynamic Replacing of Reference
Pictures," in Proc. Globcom'96, vol. 3, pp. 1503 - 1508, Pictures," in Proc. Globcom'96, vol. 3, pp. 1503 -
1996. 1508, 1996.
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
Norrman, "The Secure Real-time Transport Protocol 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- RTCP-based Feedback (RTP/SAVPF)," draft-ietf-avt-
profile-savpf-10.txt, February, 2007. profile-savpf-10.txt, February, 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 Friendly [RFC3448] M. Handley, S. Floyd, J. Padhye, J. Widmer, "TCP
Rate Control (TFRC): Protocol Specification", RFC 3448, Friendly Rate Control (TFRC): Protocol Specification",
[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)", Modifier for the Session Description Protocol (SDP)",
RFC 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.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
A., Peterson, J., Sparks, R., Handley, M., and E. Johnston, A., Peterson, J., Sparks, R., Handley, M.,
Schooler, "SIP: Session Initiation Protocol", RFC 3261, and E. Schooler, "SIP: Session Initiation Protocol",
June 2002. RFC 3261, June 2002.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC Parisis, "RTP Payload for Redundant Audio Data", RFC
2198, September 1997. 2198, September 1997.
[Topologies] M. Westerlund, and S. Wenger, "RTP Topologies",
draft-ietf-avt-topologies-04, work in progress, Feb
2007.
12. Authors' Addresses 12. Authors' Addresses
Stephan Wenger Stephan Wenger
Nokia Corporation Nokia Corporation
975, Page Mill Road, 975, Page Mill Road,
Palo Alto,CA 94304 Palo Alto,CA 94304
USA USA
Phone: +1-650-862-7368 Phone: +1-650-862-7368
skipping to change at page 67, line 13 skipping to change at page 70, line 13
EMail: bo.burman@ericsson.com EMail: bo.burman@ericsson.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE. PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights.
Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use
of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository
at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
RFC Editor Considerations RFC Editor Considerations
The RFC editor is requested to replace all occurrences of XXXX with The RFC editor is requested to replace all occurrences of XXXX
the RFC number this document receives. with the RFC number this document receives.
 End of changes. 306 change blocks. 
1516 lines changed or deleted 1605 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/