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

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