draft-ietf-avt-avpf-ccm-00.txt   draft-ietf-avt-avpf-ccm-01.txt 
Network Working Group Stephan Wenger Network Working Group Stephan Wenger
INTERNET-DRAFT Umesh Chandra INTERNET-DRAFT Umesh Chandra
Expires: February 2007 Nokia Expires: March 2007 Nokia
Magnus Westerlund Magnus Westerlund
Bo Burman Bo Burman
Ericsson Ericsson
August 28, 2006 September 17, 2006
Codec Control Messages in the Codec Control Messages in the
Audio-Visual Profile with Feedback (AVPF) Audio-Visual Profile with Feedback (AVPF)
draft-ietf-avt-avpf-ccm-00.txt> draft-ietf-avt-avpf-ccm-01.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies a few extensions to the messages defined in This document specifies a few extensions to the messages defined in
the Audio-Visual Profile with Feedback (AVPF). They are helpful the Audio-Visual Profile with Feedback (AVPF). They are helpful
primarily in conversational multimedia scenarios where centralized primarily in conversational multimedia scenarios where centralized
multipoint functionalities are in use. However some are also usable multipoint functionalities are in use. However some are also usable
in smaller multicast environments and point-to-point calls. The in smaller multicast environments and point-to-point calls. The
extensions discussed are Full Intra Request, Temporary Maximum Media extensions discussed are H.271 video back channel, Full Intra
Bit-rate and Temporal Spatial Trade-off. Request, Temporary Maximum Media Bit-rate and Temporal Spatial Trade-
off.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction....................................................5 1. Introduction....................................................5
2. Definitions.....................................................7 2. Definitions.....................................................7
2.1. Glossary...................................................7 2.1. Glossary...................................................7
2.2. Terminology................................................7 2.2. Terminology................................................8
2.3. Topologies.................................................9 2.3. Topologies.................................................9
3. Motivation (Informative)........................................9 3. Motivation (Informative)........................................9
3.1. Use Cases..................................................9 3.1. Use Cases.................................................10
3.2. Using the Media Path......................................11 3.2. Using the Media Path......................................12
3.3. Using AVPF................................................12 3.3. Using AVPF................................................12
3.3.1. Reliability..........................................12 3.3.1. Reliability..........................................12
3.4. Multicast.................................................12 3.4. Multicast.................................................13
3.5. Feedback Messages.........................................13 3.5. Feedback Messages.........................................13
3.5.1. Full Intra Request Command...........................13 3.5.1. Full Intra Request Command...........................13
3.5.1.1. Reliability.....................................14 3.5.1.1. Reliability.....................................14
3.5.2. Temporal Spatial Trade-off Request and Announcement..14 3.5.2. Temporal Spatial Trade-off Request and Announcement..15
3.5.2.1. Point-to-point..................................15 3.5.2.1. Point-to-point..................................15
3.5.2.2. Point-to-Multipoint using Multicast or Translators15 3.5.2.2. Point-to-Multipoint using Multicast or Translators16
3.5.2.3. Point-to-Multipoint using RTP Mixer.............16 3.5.2.3. Point-to-Multipoint using RTP Mixer.............16
3.5.2.4. Reliability.....................................16 3.5.2.4. Reliability.....................................16
3.5.3. H.271 Video Back Channel Message conforming to ITU-T Rec. 3.5.3. H.271 Video Back Channel Message conforming to ITU-T Rec.
H.271.......................................................17 H.271.......................................................17
3.5.3.1. Reliability.....................................17 3.5.3.1. Reliability.....................................19
3.5.4. Temporary Maximum Media Bit-rate Request.............17 3.5.4. Temporary Maximum Media Bit-rate Request.............19
3.5.4.1. MCU based Multi-point operation.................18 3.5.4.1. MCU based Multi-point operation.................20
3.5.4.2. Point-to-Multipoint using Multicast or Translators20 3.5.4.2. Point-to-Multipoint using Multicast or Translators21
3.5.4.3. Point-to-point operation........................20 3.5.4.3. Point-to-point operation........................22
3.5.4.4. Reliability.....................................20 3.5.4.4. Reliability.....................................22
4. RTCP Receiver Report Extensions................................22 4. RTCP Receiver Report Extensions................................23
4.1. Design Principles of the Extension Mechanism..............22 4.1. Design Principles of the Extension Mechanism..............23
4.2. Transport Layer Feedback Messages.........................23 4.2. Transport Layer Feedback Messages.........................24
4.2.1. Temporary Maximum Media Bit-rate Request (TMMBR).....23 4.2.1. Temporary Maximum Media Bit-rate Request (TMMBR).....24
4.2.1.1. Semantics.......................................23 4.2.1.1. Semantics.......................................24
4.2.1.2. Message Format..................................25 4.2.1.2. Message Format..................................26
4.2.1.3. Timing Rules....................................26 4.2.1.3. Timing Rules....................................27
4.2.2. Temporary Maximum Media Bit-rate Notification (TMMBN) 26 4.2.2. Temporary Maximum Media Bit-rate Notification (TMMBN) 27
4.2.2.1. Semantics.......................................26 4.2.2.1. Semantics.......................................27
4.2.2.2. Message Format..................................27 4.2.2.2. Message Format..................................28
4.2.2.3. Timing Rules....................................27 4.2.2.3. Timing Rules....................................29
4.3. Payload Specific Feedback Messages........................27 4.3. Payload Specific Feedback Messages........................29
4.3.1. Full Intra Request (FIR) command.....................28 4.3.1. Full Intra Request (FIR) command.....................29
4.3.1.1. Semantics.......................................28 4.3.1.1. Semantics.......................................29
4.3.1.2. Message Format..................................30 4.3.1.2. Message Format..................................31
4.3.1.3. Timing Rules....................................31 4.3.1.3. Timing Rules....................................32
4.3.1.4. Remarks.........................................31 4.3.1.4. Remarks.........................................32
4.3.2. Temporal-Spatial Trade-off Request (TSTR)............31 4.3.2. Temporal-Spatial Trade-off Request (TSTR)............33
4.3.2.1. Semantics.......................................32 4.3.2.1. Semantics.......................................33
4.3.2.2. Message Format..................................32 4.3.2.2. Message Format..................................33
4.3.2.3. Timing Rules....................................33 4.3.2.3. Timing Rules....................................34
4.3.2.4. Remarks.........................................33 4.3.2.4. Remarks.........................................34
4.3.3. Temporal-Spatial Trade-off Announcement (TSTA).......33 4.3.3. Temporal-Spatial Trade-off Announcement (TSTA).......35
4.3.3.1. Semantics.......................................34 4.3.3.1. Semantics.......................................35
4.3.3.2. Message Format..................................34 4.3.3.2. Message Format..................................35
4.3.3.3. Timing Rules....................................35 4.3.3.3. Timing Rules....................................36
4.3.3.4. Remarks.........................................35 4.3.3.4. Remarks.........................................36
4.3.4. H.271 VideoBackChannelMessage (VBCM).................35 4.3.4. H.271 VideoBackChannelMessage (VBCM).................36
5. Congestion Control.............................................37 5. Congestion Control.............................................39
6. Security Considerations........................................38 6. Security Considerations........................................39
7. SDP Definitions................................................38 7. SDP Definitions................................................40
7.1. Extension of rtcp-fb attribute............................39 7.1. Extension of rtcp-fb attribute............................40
7.2. Offer-Answer..............................................40 7.2. Offer-Answer..............................................42
7.3. Examples..................................................40 7.3. Examples..................................................42
8. IANA Considerations............................................43 8. IANA Considerations............................................45
9. Acknowledgements...............................................44 9. Acknowledgements...............................................45
10. References....................................................45 10. References....................................................46
10.1. Normative references.....................................45 10.1. Normative references.....................................46
10.2. Informative references...................................45 10.2. Informative references...................................46
11. Authors' Addresses............................................46 11. Authors' Addresses............................................47
12. List of Changes relative to previous drafts...................46 12. List of Changes relative to previous drafts...................47
1. Introduction 1. Introduction
When the Audio-Visual Profile with Feedback (AVPF) [RFC4548] was When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was
developed, the main emphasis lied in the efficient support of point- developed, the main emphasis lied in the efficient support of point-
to-point and small multipoint scenarios without centralized to-point and small multipoint scenarios without centralized
multipoint control. However, in practice, many small multipoint multipoint control. However, in practice, many small multipoint
conferences operate utilizing devices known as Multipoint Control conferences operate utilizing devices known as Multipoint Control
Units (MCUs). Long standing experience of the conversational video Units (MCUs). Long standing experience of the conversational video
conferencing industry suggests that there is a need for a few conferencing industry suggests that there is a need for a few
additional feedback messages, to efficiently support MCU-based additional feedback messages, to efficiently support MCU-based
multipoint conferencing. Some of the messages have applications multipoint conferencing. Some of the messages have applications
beyond centralized multipoint, and this is indicated in the beyond centralized multipoint, and this is indicated in the
description of the message. This is especially true for the message description of the message. This is especially true for the message
intended to carry ITU-T Rec. H.271 [H.271] bitstrings for video back intended to carry ITU-T Rec. H.271 [H.271] bitstrings for video back
channel messages. channel messages.
In RTP [RFC3550] terminology, MCUs comprise mixers and translators. In RTP [RFC3550] terminology, MCUs comprise mixers and translators.
Most MCUs also include signalling support. During the development of Most MCUs also include signalling support. During the development of
this memo, it was noticed that there is considerable confusion in the this memo, it was noticed that there is considerable confusion in the
community related to the use of terms such as "mixer", "translator", community related to the use of terms such as "mixer",
and "MCU". In response to these concerns, a number of topologies "translator", and "MCU". In response to these concerns, a number of
have been identified that are of practical relevance to the industry, topologies have been identified that are of practical relevance to
but were not envisioned (or at least not documented in sufficient the industry, but were not envisioned (or at least not documented in
detail) in RTP. These topologies are documented in [Topologies], and sufficient detail) in RTP. These topologies are documented in
this memo frequently refers to sections in that document. [Topologies], and understanding this memo requires previous or
parallel study of [Topologies].
Some of the messages defined here are forward only, in that they do Some of the messages defined here are forward only, in that they do
not require an explicit acknowledgement. Other messages require not require an explicit acknowledgement. Other messages require
acknowledgement, leading to a two way communication model that could acknowledgement, leading to a two way communication model that could
suggest to some to be useful for control purposes. It is not the suggest to some to be useful for control purposes. It is not the
intention of this memo to open up RTCP to a generalized control intention of this memo to open up RTCP to a generalized control
protocol. All mentioned messages have relatively strict real-time protocol. All mentioned messages have relatively strict real-time
constraints - in the sense that their value diminishes with increased constraints -- in the sense that their value diminishes with
delay. This makes the use of more traditional control protocol increased delay. This makes the use of more traditional control
means, such as SIP re-invites, undesirable. Furthermore, all protocol means, such as SIP re-invites, undesirable. Furthermore,
messages are of a very simple format that can be easily processed by all messages are of a very simple format that can be easily processed
an RTP/RTCP sender/receiver. Finally, all messages infer only to the by an RTP/RTCP sender/receiver. Finally, all messages infer only to
RTP stream they are related to, and not to any other property of a the RTP stream they are related to, and not to any other property of
communication system. a communication system.
The Full Intra Request (FIR) Command requires the receiver of the The Full Intra Request (FIR) Command requires the receiver of the
message (and sender of the stream) to immediately insert a decoder message (and sender of the stream) to immediately insert a decoder
refresh point. In video coding, one commonly used form of a decoder refresh point. In video coding, one commonly used form of a decoder
refresh point is an IDR or Intra picture. Other codecs may have refresh point is an IDR or Intra picture. Other codecs may have
other forms of decoder refresh points. In order to fulfil congestion other forms of decoder refresh points. In order to fulfil congestion
control constraints, sending a decoder refresh point may imply a control constraints, sending a decoder refresh point may imply a
significant drop in frame rate, as they are commonly much larger than significant drop in frame rate, as they are commonly much larger than
regular predicted content. The use of this message is restricted to regular predicted content. The use of this message is restricted to
cases where no other means of decoder refresh can be employed, e.g. cases where no other means of decoder refresh can be employed, e.g.
during the join-phase of a new participant in a multipoint during the join-phase of a new participant in a multipoint
conference. It is explicitly disallowed to use the FIR command for conference. It is explicitly disallowed to use the FIR command for
error resilience purposes, and instead it is referred to AVPF's PLI error resilience purposes, and instead it is referred to AVPF's
message, which reports lost pictures and has been included in AVPF [RFC4585] PLI message, which reports lost pictures and has been
for precisely that purpose. The message does not require an included in AVPF for precisely that purpose. The message does not
acknowledgement, as the presence of a decoder refresh point can be require an acknowledgement, as the presence of a decoder refresh
easily derived from the media bit stream. Today, the FIR message point can be easily derived from the media bit stream. Today, the
appears to be useful primarily with video streams, but in the future FIR message appears to be useful primarily with video streams, but in
it may become helpful also in conjunction with other media codecs the future it may become helpful also in conjunction with other media
that support prediction across RTP packets. codecs that support prediction across RTP packets.
The Temporary Maximum Media Bandwidth Request (TMMBR) Message allows The Temporary Maximum Media Bandwidth Request (TMMBR) Message allows
to signal, from media receiver to media sender, the current maximum to signal, from media receiver to media sender, the current maximum
supported media bit-rate for a given media stream. Once a bandwidth supported media bit-rate for a given media stream. Once a bandwidth
limitation is established by the media sender, that sender notifies limitation is established by the media sender, that sender notifies
the initiator of the request, and all other session participants, by the initiator of the request, and all other session participants, by
sending a TMMBN notification message. One usage scenarios can be sending a TMMBN notification message. One usage scenarios can be
seen as limiting media senders in multiparty conferencing to the seen as limiting media senders in multiparty conferencing to the
slowest receiver's maximum media bandwidth reception/handling slowest receiver's maximum media bandwidth reception/handling
capability. Such a use is helpful, for example, because the capability. Such a use is helpful, for example, because the
skipping to change at page 6, line 42 skipping to change at page 6, line 43
congestion induced bandwidth reduction. Another application involves congestion induced bandwidth reduction. Another application involves
graceful bandwidth adaptation in scenarios where the upper limit graceful bandwidth adaptation in scenarios where the upper limit
connection bandwidth to a receiver changes, but is known in the connection bandwidth to a receiver changes, but is known in the
interval between these dynamic changes. The TMMBR message is useful interval between these dynamic changes. The TMMBR message is useful
for all media types that are not inherently of constant bit rate. for all media types that are not inherently of constant bit rate.
The Video back channel message (VBCM) allows conveying bit streams The Video back channel message (VBCM) allows conveying bit streams
conforming to ITU-T Rec. H.271 [H.271], from a video receiver to conforming to ITU-T Rec. H.271 [H.271], from a video receiver to
video sender. This ITU-T Recommendation defines codepoints for a video sender. This ITU-T Recommendation defines codepoints for a
number of video-specific feedback messages. Examples include number of video-specific feedback messages. Examples include
messages to signal messages to signal:
- the corruption of reference pictures or parts thereof, - the corruption of reference pictures or parts thereof,
- the corruption of decoder state information, e.g. parameter sets, - the corruption of decoder state information, e.g. parameter sets,
- the suggestion of using a reference picture other than the one - the suggestion of using a reference picture other than the one
typically used, e.g. to support the NEWPRED algorithm [NEWPRED]. typically used, e.g. to support the NEWPRED algorithm [NEWPRED].
The ITU-T plans to add codepoints to H.271 every time a need arises, The ITU-T plans to add codepoints to H.271 every time a need arises,
e.g. with the introduction of new video codecs or new tools into e.g. with the introduction of new video codecs or new tools into
existing video codecs. existing video codecs.
There exists some overlap between H.271 messages and "native" There exists some overlap between H.271 messages and "native"
messages specified in this memo and in AVPF. Examples include the messages specified in this memo and in AVPF. Examples include the
PLI message of [RFC4548] and the FIR message specified herein. As a PLI message of [RFC4585] and the FIR message specified herein. As a
general rule, the "native" messages should be prefered over the general rule, the "native" messages should be prefered over the
sending of VBCM messages when all senders and receivers implement sending of VBCM messages when all senders and receivers implement
this memo. However, if gateways are in the picture, it may be more this memo. However, if gateways are in the picture, it may be more
advisable to utilize VBCM. Similarly, for feedback message types advisable to utilize VBCM. Similarly, for feedback message types
that exist in H.271 but do not exist in this memo or AVPF, there is that exist in H.271 but do not exist in this memo or AVPF, there is
no other choice but using VBCM. no other choice but using VBCM.
Video feedback channel messages according to H.271 do not require Video feedback channel messages according to H.271 do not require
acknowledgements on a protocol level, because the appropriate acknowledgements on a protocol level, because the appropriate
reaction of the video encoder and sender can be derived from the reaction of the video encoder and sender can be derived from the
forward video bit stream. forward video bit stream.
skipping to change at page 9, line 29 skipping to change at page 9, line 31
stream. Stream thinning, preferably, is performed media stream. Stream thinning, preferably, is performed media
aware, implying that media packets are removed in the order aware, implying that media packets are removed in the order
of their relevance to the reproductive quality. However even of their relevance to the reproductive quality. However even
when employing media-aware stream thinning, most media when employing media-aware stream thinning, most media
streams quickly lose quality when subject to increasing streams quickly lose quality when subject to increasing
levels of thinning. Media-unaware stream thinning leads to levels of thinning. Media-unaware stream thinning leads to
even worse quality degradation. even worse quality degradation.
2.3. Topologies 2.3. Topologies
Please refer to [Topologies] for an in depth discussion. Please refer to [Topologies] for an in depth discussion. the
topologies referred to throughout this memo are labeled (consistent
with [Topologies] as follows:
Topo-Point-to-Point . . . . . point-to-point communication
> Topo-Multicast . . . . . . multicast communication as in RFC 3550
> Topo-Translator . . . . . . translator based as in RFC 3550
> Topo-Mixer . . . . . . . . mixer based as in RFC 3550
> Topo-Video-switch-MCU . . . video switching MCU,
> Topo-RTCP-terminating-MCU . mixer but terminating RTCP
3. Motivation (Informative) 3. Motivation (Informative)
This section discusses the motivation and usage of the different This section discusses the motivation and usage of the different
video and media control messages. The video control messages have video and media control messages. The video control messages have
been under discussion for a long time, and a requirement draft was been under discussion for a long time, and a requirement draft was
drawn up [Basso]. This draft has expired; however we do quote drawn up [Basso]. This draft has expired; however we do quote
relevant 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
skipping to change at page 10, line 32 skipping to change at page 10, line 42
3. An application needs to signal to the remote encoder a request of 3. An application needs to signal to the remote encoder a request of
change of the desired trade-off in temporal/spatial resolution. change of the desired trade-off in temporal/spatial resolution.
For example, one user may prefer a higher frame rate and a lower For example, one user may prefer a higher frame rate and a lower
spatial quality, and another use may prefer the opposite. This spatial quality, and another use may prefer the opposite. This
choice is also highly content dependent. Many current video choice is also highly content dependent. Many current video
conferencing systems offer in the user interface a mechanism to conferencing systems offer in the user interface a mechanism to
make this selection, usually in the form of a slider. The make this selection, usually in the form of a slider. The
mechanism is helpful in point-to-point, centralized multipoint and mechanism is helpful in point-to-point, centralized multipoint and
non-centralized multipoint uses. non-centralized multipoint uses.
4. Use case 4 of the Basso draft applies only to AVPF's PLI and is 4. Use case 4 of the Basso draft applies only to AVPF's PLI [RFC4585]
not reproduced here. and is not reproduced here.
5. Use case 5 of the Basso draft relates to a mechanism known as 5. Use case 5 of the Basso draft relates to a mechanism known as
"freeze picture request". Sending freeze picture requests over a "freeze picture request". Sending freeze picture requests
non-reliable forward RTCP channel has been identified as over a non-reliable forward RTCP channel has been identified as
problematic. Therefore, no freeze picture request has been problematic. Therefore, no freeze picture request has been
included in this memo, and the use case discussion is not included in this memo, and the use case discussion is not
reproduced here. reproduced here.
6. A video mixer dynamically selects one of the received video 6. A video mixer dynamically selects one of the received video
streams to be sent out to participants and tries to provide the streams to be sent out to participants and tries to provide the
highest bit rate possible to all participants, while minimizing highest bit rate possible to all participants, while minimizing
stream transrating. One way of achieving this is to setup sessions stream transrating. One way of achieving this is to setup sessions
with endpoints using the maximum bit rate accepted by that with endpoints using the maximum bit rate accepted by that
endpoint, and by the call admission method used by the mixer. By endpoint, and by the call admission method used by the mixer. By
skipping to change at page 11, line 46 skipping to change at page 12, line 10
8. The use of reference picture selection as an error resilience tool 8. The use of reference picture selection as an error resilience tool
has been introduced in 1997 as NEWPRED [NEWPRED], and is now has been introduced in 1997 as NEWPRED [NEWPRED], and is now
widely deployed. It operates the receiver sending a feedback widely deployed. It operates the receiver sending a feedback
message to the sender, indicating a reference picture that should message to the sender, indicating a reference picture that should
be used for future prediction. AVPF contains a mechanism for be used for future prediction. AVPF contains a mechanism for
conveying such a message, but did not specify for which codec and conveying such a message, but did not specify for which codec and
according to which syntax the message conforms to. Recently, the according to which syntax the message conforms to. Recently, the
ITU-T finalized Rec. H.271 which (among other message types) also ITU-T finalized Rec. H.271 which (among other message types) also
includes a feedback message. It is expected that this feedback includes a feedback message. It is expected that this feedback
message will enjoy wide support and fairly quickly. Therefore, a message will enjoy wide support and fairly quickly. Therefore, a
mechanisms to convey feedback messages according to H.271 appears mechanism to convey feedback messages according to H.271 appears
to be desirable. to be desirable.
3.2. Using the Media Path 3.2. Using the Media Path
There are multiple reasons why we propose to use the media path for There are multiple reasons why we propose to use the media path for
the codec control messages. First, systems employing MCUs are often the codec control messages. First, systems employing MCUs are often
separating the control and media processing parts. As these messages separating the control and media processing parts. As these messages
are intended or generated by the media part rather than the are intended or generated by the media part rather than the
signalling part of the MCU, having them on the media path avoids signalling part of the MCU, having them on the media path avoids
interfaces and unnecessary control traffic between signalling and interfaces and unnecessary control traffic between signalling and
processing. If the MCU is physically decomposite, the use of the processing. If the MCU is physically decomposite, the use of the
media path avoids the need for media control protocol extensions media path avoids the need for media control protocol extensions
(e.g. in MEGACO [RFC3525]). (e.g. in MEGACO [RFC3525]).
skipping to change at page 12, line 26 skipping to change at page 12, line 37
Avoiding signalling entities avoids delay for several reasons. Avoiding signalling entities avoids delay for several reasons.
Proxies have less stringent delay requirements than media processing Proxies have less stringent delay requirements than media processing
and due to their complex and more generic nature may result in and due to their complex and more generic nature may result in
significant processing delay. The topological locations of the significant processing delay. The topological locations of the
signalling entities are also commonly not optimized for minimal signalling entities are also commonly not optimized for minimal
delay, rather other architectural goals. Thus the signalling path can delay, rather other architectural goals. Thus the signalling path can
be significantly longer in both geographical and delay sense. be significantly longer in both geographical and delay sense.
3.3. Using AVPF 3.3. Using AVPF
The AVPF feedback message framework provides a simple way of The AVPF feedback message framework [RFC4585] provides a simple way
implementing the new messages. Furthermore, AVPF implements rules of implementing the new messages. Furthermore, AVPF implements rules
controlling the timing of feedback messages so to avoid congestion controlling the timing of feedback messages so to avoid congestion
through network flooding. We re-use these rules by referencing to through network flooding. We re-use these rules by referencing to
AVPF. AVPF.
The signalling setup for AVPF allows each individual type of function The signalling setup for AVPF allows each individual type of function
to be configured or negotiated on a RTP session basis. to be configured or negotiated on a 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
skipping to change at page 12, line 39 skipping to change at page 13, line 4
through network flooding. We re-use these rules by referencing to through network flooding. We re-use these rules by referencing to
AVPF. AVPF.
The signalling setup for AVPF allows each individual type of function The signalling setup for AVPF allows each individual type of function
to be configured or negotiated on a RTP session basis. to be configured or negotiated on a RTP session basis.
3.3.1. Reliability 3.3.1. Reliability
The use of RTCP messages implies that each message transfer is The use of RTCP messages implies that each message transfer is
unreliable, unless the lower layer transport provides reliability. unreliable, unless the lower layer transport provides reliability.
The different messages proposed in this specification have different The different messages proposed in this specification have different
requirements in terms of reliability. However, in all cases, the requirements in terms of reliability. However, in all cases, the
reaction to an (occasional) loss of a feedback message is specified. reaction to an (occasional) loss of a feedback message is specified.
3.4. Multicast 3.4. Multicast
The media related requests might be used with multicast. The RTCP The media related requests might be used with multicast. The RTCP
timing rules specified in [RFC3550] and [RFC4548] ensure that the timing rules specified in [RFC3550] and [RFC4585] ensure that the
messages do not cause overload of the RTCP connection. The use of messages do not cause overload of the RTCP connection. The use of
multicast may result in the reception of messages with inconsistent multicast may result in the reception of messages with inconsistent
semantics. The reaction to inconsistencies depends on the message semantics. The reaction to inconsistencies depends on the message
type, and is discussed for each message type separately. type, and is discussed for each message type separately.
3.5. Feedback Messages 3.5. Feedback Messages
This section describes the semantics of the different feedback This section describes the semantics of the different feedback
messages and how they apply to the different use cases. messages and how they apply to the different use cases.
skipping to change at page 15, line 38 skipping to change at page 15, line 50
chosen by its own criteria (which may or may not be based on the chosen by its own criteria (which may or may not be based on the
trade-off conveyed by TSTR). In other words, the trade-off sent in trade-off conveyed by TSTR). In other words, the trade-off sent in
TSTR is a non-binding recommendation; nothing more. TSTR is a non-binding recommendation; nothing more.
With respect to TSTR/TSTA, four scenarios based on the topologies With respect to TSTR/TSTA, four scenarios based on the topologies
described in [Topologies] need to be distinguished. The scenarios are described in [Topologies] need to be distinguished. The scenarios are
described in the following sub-clauses. described in the following sub-clauses.
3.5.2.1. Point-to-point 3.5.2.1. Point-to-point
In this most trivial case, the media sender typically adjusts its In this most trivial case (Topo-Point-to-Point), the media sender
temporal/spatial trade-off based on the requested value in TSTR, and typically adjusts its temporal/spatial trade-off based on the
within its capabilities. The TSTA message conveys back the new requested value in TSTR, and within its capabilities. The TSTA
trade-off value (which may be identical to the old one if, for message conveys back the new trade-off value (which may be identical
example, the sender is not capable to adjust its trade-off). to the old one if, for example, the sender is not capable to adjust
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-
Section 2.3.2 of [Topologies], or following RFC 3550's translator Multicast, or following RFC 3550's translator model according to
model according to Section 2.3.3 of [Topologies]. In these cases, Topo-Translator. In these cases, TSTR messages from different
TSTR messages from different receivers may be received receivers may be received unsynchronized, and possibly with different
unsynchronized, and possibly with different requested trade-offs requested trade-offs (because of different user preferences). This
(because of different user preferences). This memo does not specify memo does not specify how the media sender tunes its trade-off.
how the media sender tunes its trade-off. Possible strategies Possible strategies include selecting the mean, or median, of all
include selecting the mean, or median, of all trade-off requests trade-off requests received, prioritize certain participants, or
received, prioritize certain participants, or continue using the continue using the previously selected trade-off (e.g. when the
previously selected trade-off (e.g. when the sender is not capable of sender is not capable of adjusting it). Again, all TSTR messages
adjusting it). Again, all TSTR messages need to be acknowledged by need to be acknowledged by TSTA, and the value conveyed back has to
TSTA, and the value conveyed back has to reflect the decision made. reflect the decision made.
3.5.2.3. Point-to-Multipoint using RTP Mixer 3.5.2.3. Point-to-Multipoint using RTP Mixer
In this scenario the RTP Mixer receives all TSTR messages, and has In this scenario (Topo-Mixer) the RTP Mixer receives all TSTR
the opportunity to act on them based on its own criteria. In most messages, and has the opportunity to act on them based on its own
cases, the MCU should form a "consensus" of potentially conflicting criteria. In most cases, the MCU should form a "consensus" of
TSTR messages arriving from different participants, and initiate its potentially conflicting TSTR messages arriving from different
own TSTR message(s) to the media sender(s). The strategy of forming participants, and initiate its own TSTR message(s) to the media
this "consensus" is open for the implementation, and can, for sender(s). The strategy of forming this "consensus" is open for the
example, encompass averaging the participant's request values, implementation, and can, for example, encompass averaging the
prioritizing certain participants, or use session default values. If participant's request values, prioritizing certain participants, or
the Mixer changes its trade-off, it needs to request from the media use session default values. If the Mixer changes its trade-off, it
sender(s) the use of the new value, by creating a TSTR of its own. needs to request from the media sender(s) the use of the new value,
Upon reaching a decision on the used trade-off it includes that value by creating a TSTR of its own. Upon reaching a decision on the used
in the acknowledgement. trade-off it includes that value in the acknowledgement.
Even if a Mixer or Translator performs transcoding, it is very Even if a Mixer or Translator performs transcoding, it is very
difficult to deliver media with the requested trade-off, unless the difficult to deliver media with the requested trade-off, unless the
content the MCU receives is already close to that trade-off. Only in content the MCU receives is already close to that trade-off. Only in
cases where the original source has substantially higher quality (and cases where the original source has substantially higher quality (and
bit-rate), it is likely that transcoding can result in the requested bit-rate), it is likely that transcoding can result in the requested
trade-off. 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 Announcement (TSTA) message informs the Temporal Spatial Trade-off Announcement (TSTA) message informs the
request-sender that its request has been received, and what trade-off request-sender that its request has been received, and what trade-off
is used henceforth. This acknowledgment mechanism is desirable for at is used henceforth. This acknowledgment mechanism is desirable for 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 information of the o User feedback cannot be implemented without information of the
chosen trade-off value, according to the media sender's chosen trade-off value, according to the media sender's
skipping to change at page 17, line 9 skipping to change at page 17, line 22
o User feedback cannot be implemented without information of the o User feedback cannot be implemented without information of the
chosen trade-off value, according to the media sender's chosen trade-off value, according to the media sender's
constraints, constraints,
o Repetitive sending of messages requesting an unimplementable trade- o Repetitive sending of messages requesting an unimplementable trade-
off can be avoided. off can be avoided.
3.5.3. H.271 Video Back Channel Message 3.5.3. H.271 Video Back Channel Message
ITU-T Rec. H.271 defines syntax, semantics, and suggested encoder ITU-T Rec. H.271 defines syntax, semantics, and suggested encoder
reaction to a video back channel message. The codepoint defined in reaction to a video back channel message. The codepoint defined in
this memo is used to convey such a message from media receiver to this memo is used to transparently convey such a message from media
media sender. receiver to media sender.
We refrain from an in-depth discussion of the available codepoints We refrain from an in-depth discussion of the available codepoints
within H.271 in this memo for a number of reason. The perhaps most within H.271 in this memo for a number of reasons. The perhaps most
important reason is that we expect backward-compatible additions of important reason is that we expect backward-compatible additions of
codepoints to H.271 outside the update/maturity cycle of this memo. codepoints to H.271 outside the update/maturity cycle of this memo.
The situation is similar to RTP payload format specs - the data Another reason lies in the complexity of the H.271 specification: it
carried within the spec is normally not described in any significant is a dense document with currently 16 pages of content. It does not
detail. make any sense to try to summarize its content in a few sentences of
IETF lingo -- oversimplification and misguidance would be inevitable.
Finally, please note that H.271 contains many statements of
applicability and interpretation of its various messages in
conjunction with specific video compression standards. This type of
discussion would overload the present memo.
In so far, this memo follows the guidance of a decade of RTP payload
format specification work -- the details of the media format carried
is normally not described in any significant detail.
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, which are known to require native messages of AVPF and this memo. Furthermore, we note that
caution in multicast environments. One example is the reference some H.271 message are known to require caution in multicast
picture feedback message, which appears to be critical to environments -- or are plainly not usable in multicast or multipoint
contradicting information. While it would perhaps be possible to scenarios. Table xxx provides a brief, oversimplifying overview of
specify an algorithm to resolve eventual contradictions, this would the messages currenty defined in H.271, their similar AVPF or CCM
require an amount of awareness to the details of H.271 and the video messages (the latter as specified in this memo), and an indication of
codec employed which we would like to avoid in this memo. Therefore, our current knowledge of their multicast safety.
we err on the side of caution and discourage the use of VBCM in
topologies other than point-to-point (section 2.3.1 of [Topologies]) H.271 msg type AVPF/CCM msg type multicast-safe
and point-to-multipoint utilizing a mixer (section 2.3.4. of 0 (when used for reference
[Topologies]). In the former case, obviously, no inconsistency picture selection) AVPF RPSI No (positive ACK of pictures)
problem exists. In the latter case, it is the mixer's responsibility 1 AVPF PLI Yes
to resolve the inconsistencies, and the mixer is media aware and can 2 AVPF SLI Yes
do so. 3 N/A Yes (no required sender action)
4 N/A Yes (no required sender action)
Note: H.271 message type 0 is not a strict equivalent to
AVPF's RPSI; it is an indication of known-as-correct reference
picture(s) at the decoder. It does not command an encoder to
use a defined reference picture (the form of control
information envisioned to be carried in RPSI). However, it is
believed and intended that H.271 message type 0 will be used
for the same purpose as AVPF's RPSI -- although other use
forms are also possible.
In response to the opaqueness of the H.271 messages especially with
respect to the multicast safety, the following guidelines MUST be
followed when an implementation wishes to employ the H.271 video back
channel message:
1. Implementations utilizing the H.271 feedback message MUST stay in
compliance with congestion control principles, as outlined in
section 5.
2. An implementation SHOULD utilize the native messages as defined in
[RFC4585] and in this memo instead of similar messages defined in
[H.271]. Our current understanding of similar messages is
documented in table xxx above. One good reason to divert from the
SHOULD statement above would be if it is clearly understood that,
for a given application and video compression standard, the
aforementioned "similarity" is not given, in contrast to what
the table indicates.
3. It has been observed that some of the H.271 codepoints currently
in existence are not multicast-save. Therefore, the sensible
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
mentioned later are fully understood by the implementer, and
properly taken into account by all endpoints. In all other cases,
the H.271 message type MUST NOT be used in conjunction with
multicast.
4. It has been observed that even in centralized multipoint
environments, where the mixer should theoretically be able to
resolve issues as deocumented below, the implementation of such a
mixer and cooperative endpoints is a very difficult and tedious
task. Therefore, H.271 message MUST NOT be used in centralized
multipoint scenarios, unless all the issues mentioned below are
fully understood by the implementer, and properly taken into
account by both mixer and endpoints.
Issues with point to Multi-point:
1. Different state established on different receivers. One example is
the reference picture feedback message, which, when sent to receivers
in which the video codecs are at different state due to previous
losses or stream switches, the results can be unpredictable and
annoying.
2. Combination of multiple messages/requests by a media sender into
an action and or response.
3. Suppression of requests may need to go beyond the basic mechanism
described in AVPF. For example forward messages may be need to
suppress the generation of requests.
Issues with translators and mixers
1. Combination of multiple message or requests into an action or
response.
2.
3.5.3.1. Reliability 3.5.3.1. Reliability
H.271 video back channel messages do not require reliable H.271 video back channel messages do not require reliable
transmission, and the reception of a message can be derived from the transmission, and the reception of a message can be derived from the
forward video bit stream. Therefore, no specific reception forward video bit stream. Therefore, no specific reception
acknowledgement is specified. acknowledgement is specified.
With respect to re-sending rules, clause 3.5.1.1. applies. With respect to re-sending rules, clause 3.5.1.1. applies.
3.5.4. Temporary Maximum Media Bit-rate Request 3.5.4. Temporary Maximum Media Bit-rate Request
A receiver, translator or mixer uses the Temporary Maximum Media Bit- A receiver, translator or mixer uses the Temporary Maximum Media Bit-
rate Request (TMMBR, "timber") to request a sender to limit the rate Request (TMMBR, "timber") to request a sender to limit the
maximum bit-rate for a media stream to, or below, the provided value. maximum bit-rate for a media stream to, or below, the provided value.
The primary usage for this is a scenario with MCU (use case 6), The primary usage for this is a scenario with MCU (use case 6),
corresponding to topologies in 2.3.3 of [Topologies] (translator) and corresponding to Topo-Translator or Topo-Mixer, but also Topo-Point-
2.3.4 of [Topologies] (mixer), but also .2.3.1 of Topologies (point- to-Point.
to-point).
The temporary maximum media bit-rate messages are generic messages The temporary maximum media bit-rate messages are generic messages
that can be applied to any media. that can be applied to any media.
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 the signalling protocol. This value session maximum bit-rate, using the signalling protocol. This value
can be global, for example in case of point-to-point, multicast, or can be global, for example in case of point-to-point, multicast, or
translators. It may also be local between the participant and the translators. It may also be local between the participant and the
peer or mixer. In both cases, the bit-rate negotiated in signalling peer or mixer. In both cases, the bit-rate negotiated in signalling
is the one that the participant guarantees to be able to handle is the one that the participant guarantees to be able to handle
skipping to change at page 18, line 38 skipping to change at page 20, line 25
usually in the local environment, and does not provide any usually in the local environment, and does not provide any
guarantees. guarantees.
If it is likely that the new bit-rate indicated by TMMBR will be If it is likely that the new bit-rate indicated by TMMBR will be
valid for the remainder of the session, the TMMBR sender can perform valid for the remainder of the session, the TMMBR sender can perform
a renegotiation of the session upper limit using the session a renegotiation of the session upper limit using the session
signalling protocol. signalling protocol.
3.5.4.1. MCU based Multi-point operation 3.5.4.1. MCU based Multi-point operation
Assume a small multiparty conference is ongoing, as depicted in Assume a small mixer-based multiparty conference is ongoing, as
Section 2.3.4 of [Topologies]. All participants (A-D) have negotiated depicted in Topo-Mixer of [Topologies]. All participants (A-D) have
a common maximum bit-rate that this session can use. The conference negotiated a common maximum bit-rate that this session can use. The
operates over a number of unicast links between the participants and conference operates over a number of unicast links between the
the MCU. The congestion situation on each of these links can easily participants and the MCU. The congestion situation on each of these
be monitored by the participant in question and by the MCU, links can easily be monitored by the participant in question and by
utilizing, for example, RTCP Receiver Reports. However, any given the MCU, utilizing, for example, RTCP Receiver Reports. However, any
participant has no knowledge of the congestion situation of the given participant has no knowledge of the congestion situation of the
connections to the other participants. Worse, without mechanisms connections to the other participants. Worse, without mechanisms
similar to the ones discussed in this draft, the MCU (who is aware of similar to the ones discussed in this draft, the MCU (who is aware of
the congestion situation on all connections it manages) has no the congestion situation on all connections it manages) has no
standardized means to inform participants to slow down, short of standardized means to inform participants to slow down, short of
forging its own receiver reports (which is undesirable). In forging its own receiver reports (which is undesirable). In
principle, an MCU confronted with such a situation is obliged to thin principle, an MCU confronted with such a situation is obliged to thin
or transcode streams intended for connections that detected or transcode streams intended for connections that detected
congestion. congestion.
In practice, stream thinning - if performed media aware - is In practice, stream thinning - if performed media aware - is
skipping to change at page 20, line 15 skipping to change at page 21, line 49
In this topology it is the Mixer's responsibility to collect, and In this topology it is the Mixer's responsibility to collect, and
consider jointly, the different bit-rates which the different links consider jointly, the different bit-rates which the different links
may support, into the bit rate requested. This aggregation may also may support, into the bit rate requested. This aggregation may also
take into account that the Mixer may contain certain transcoding take into account that the Mixer may contain certain transcoding
capabilities (as discussed in section 2.3.4 of [Topologies]), which capabilities (as discussed in section 2.3.4 of [Topologies]), which
can be employed for those few of the session participants that have can be employed for those few of the session participants that have
the lowest available bit-rates. the lowest available bit-rates.
3.5.4.2. Point-to-Multipoint using Multicast or Translators 3.5.4.2. Point-to-Multipoint using Multicast or Translators
In this topology, RTCP RRs are transmitted globally which allows for In these topologies, corresponding to Topo-Multicast or Topo-
the detection of transmission problems such as congestion, on a Translator RTCP RRs are transmitted globally which allows for the
medium timescale. As all media senders are aware of the congestion detection of transmission problems such as congestion, on a medium
timescale. As all media senders are aware of the congestion
situation of all media receivers, the rationale of the use of TMMBR situation of all media receivers, the rationale of the use of TMMBR
of section 3.5.4.1 does not apply. However, even in this case the of section 3.5.4.1 does not apply. However, even in this case the
congestion control response can be improved when the unicast links congestion control response can be improved when the unicast links
are employing congestion controlled transport protocols (such as TCP are employing congestion controlled transport protocols (such as TCP
or DCCP). A peer may also report local limitation to the media or DCCP). A peer may also report local limitation to the media
sender. sender.
3.5.4.3. Point-to-point operation 3.5.4.3. 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
skipping to change at page 22, line 11 skipping to change at page 23, line 11
its limitation. Otherwise anyone that ever set a limitation would its limitation. Otherwise anyone that ever set a limitation would
need to remove it to allow the maximum bit-rate to be raised beyond need to remove it to allow the maximum bit-rate to be raised beyond
that value. that value.
4. RTCP Receiver Report Extensions 4. RTCP Receiver Report Extensions
This memo specifies six new feedback messages. The Full Intra Request This memo specifies six new feedback messages. The Full Intra Request
(FIR), Temporal-Spatial Trade-off Request (TSTR), Temporal-Spatial (FIR), Temporal-Spatial Trade-off Request (TSTR), Temporal-Spatial
Trade-off Announcement (TSTA), and Video Back Channel Message (VBCM) Trade-off Announcement (TSTA), and Video Back Channel Message (VBCM)
are "Payload Specific Feedback Messages" in the sense of section 6.3 are "Payload Specific Feedback Messages" in the sense of section 6.3
of AVPF [RFC4548]. The Temporary Maximum Media Bit-rate Request of AVPF [RFC4585]. The Temporary Maximum Media Bit-rate Request
(TMMBR) and Temporary Maximum Media Bit-rate Notification (TMMBN) are (TMMBR) and Temporary Maximum Media Bit-rate Notification (TMMBN) are
"Transport Layer Feedback Messages" in the sense of section 6.2 of "Transport Layer Feedback Messages" in the sense of section 6.2 of
AVPF. AVPF.
In the following subsections, the new feedback messages are defined, In the following subsections, the new feedback messages are defined,
following a similar structure as in the AVPF specification's sections following a similar structure as in the AVPF specification's sections
6.2 and 6.3, respectively. 6.2 and 6.3, respectively.
4.1. Design Principles of the Extension Mechanism 4.1. Design Principles of the Extension Mechanism
skipping to change at page 22, line 35 skipping to change at page 23, line 35
early RTP payload formats for video formats, for example in RFC 2032 early RTP payload formats for video formats, for example in RFC 2032
[RFC2032]. However, this specification, for the first time, suggests [RFC2032]. However, this specification, for the first time, suggests
a two-way handshake for one of its messages. There is danger that a two-way handshake for one of its messages. There is danger that
this introduction could be misunderstood as the precedence for the this introduction could be misunderstood as the precedence for the
use of RTCP as an RTP session control protocol. In order to prevent use of RTCP as an RTP session control protocol. In order to prevent
these misunderstandings, this subsection attempts to clarify the these misunderstandings, this subsection attempts to clarify the
scope of the extensions specified in this memo, and strongly suggests scope of the extensions specified in this memo, and strongly suggests
that future extensions follow the rationale spelled out here, or that future extensions follow the rationale spelled out here, or
compellingly explain why they divert from the rationale. compellingly explain why they divert from the rationale.
In this memo, and in AVPF [RFC4548], only such messages have been In this memo, and in AVPF [RFC4585], only such messages have been
included which included which
a) have comparatively strict real-time constraints, which prevent the a) have comparatively strict real-time constraints, which prevent the
use of mechanisms such as a SIP re-invite in most application use of mechanisms such as a SIP re-invite in most application
scenarios. The real-time constraints are explained separately for scenarios. The real-time constraints are explained separately for
each message where necessary each message where necessary
b) are multicast-safe in that the reaction to potentially b) are multicast-safe in that the reaction to potentially
contradicting feedback messages is specified, as necessary for contradicting feedback messages is specified, as necessary for
each message each message
c) are directly related to activities of a certain media codec, class c) are directly related to activities of a certain media codec, class
of media codecs (e.g. video codecs), or the given media stream. of media codecs (e.g. video codecs), or the given media stream.
In this memo, a two-way handshake is only introduced for such In this memo, a two-way handshake is only introduced for such
messages that messages that
a) require a notification or acknowledgement due to their nature, a) require a notification or acknowledgement due to their nature,
which is motivated separately for each message which is motivated 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 [RFC4548] and in this memo follow a number of All messages in AVPF [RFC4585] and in this memo follow a number of
common design principles. In particular: common design principles. In particular:
a) Media receivers are not always implementing higher control a) Media receivers are not always implementing higher control
protocol functionalities (SDP, XML parsers and such) in their protocol functionalities (SDP, XML parsers and such) in their
media path. Therefore, simple binary representations are used in media path. Therefore, simple binary representations are used in
the feedback messages and not an (otherwise desirable) flexible the feedback messages and not an (otherwise desirable) flexible
format such as, for example, XML. format such as, for example, XML.
4.2. Transport Layer Feedback Messages 4.2. Transport Layer Feedback Messages
Transport Layer FB messages are identified by the value RTPFB (205) Transport Layer FB messages are identified by the value RTPFB (205)
as RTCP packet type. as RTCP packet type.
In AVPF, one message of this category had been defined. This memo In AVPF, one message of this category had been defined. This memo
specifies two more messages for a total of three messages of this specifies two more messages for a total of three messages of this
type. They are identified by means of the FMT parameter as follows: type. They are identified by means of the FMT parameter as follows:
0: unassigned 0: unassigned
1: Generic NACK (as per AVPF) 1: Generic NACK (as per AVPF)
2: Maximum Media Bit-rate Request 2: Temporary Maximum Media Bit-rate Request
3: Maximum Media Bit-rate Notification 3: Temporary Maximum Media Bit-rate Notification
4-30: unassigned 4-30: unassigned
31: reserved for future expansion of the identifier number space 31: reserved for future expansion of the identifier number space
The following subsection defines the formats of the FCI field for The following subsection defines the formats of the FCI field for
this type of FB message. this type of FB message.
4.2.1. Temporary Maximum Media Bit-rate Request (TMMBR) 4.2.1. Temporary Maximum Media Bit-rate Request (TMMBR)
The FCI field of a TMMBR Feedback message SHALL contain one or more The FCI field of a TMMBR Feedback message SHALL contain one or more
FCI entries. FCI entries.
skipping to change at page 24, line 18 skipping to change at page 25, line 18
sender the message applies to. This is useful in the multicast or sender the message applies to. This is useful in the multicast or
translator topologies where each media sender may be addressed in a translator topologies where each media sender may be addressed in a
single TMMBR message using multiple FCIs. single TMMBR message using multiple FCIs.
A TMMBR FCI MAY be repeated in subsequent TMMBR messages if no A TMMBR FCI MAY be repeated in subsequent TMMBR messages if no
applicable TMMBN FCI has been received at the time of transmission of applicable TMMBN FCI has been received at the time of transmission of
the next RTCP packet. The bit-rate value of a TMMBR FCI MAY be the next RTCP packet. The bit-rate value of a TMMBR FCI MAY be
changed from a previous TMMBR message and the next, regardless of the changed from a previous TMMBR message and the next, regardless of the
eventual reception of an applicable TMMBN FCI. eventual reception of an applicable TMMBN FCI.
Please note that a TMMBN message is sent by the media sender at the Please note that a TMMBN message SHALL be sent by the media sender at
earliest possible point in time, as a result of any TMMBR messages the earliest possible point in time, as a result of any TMMBR
received since the last sending of TMMBN. The TMMBN message messages received since the last sending of TMMBN. The TMMBN message
indicates the limit and the owner of that limit at the time of the indicates the limit and the owner of that limit at the time of the
transmission of the message. The limit is the lowest of all values transmission of the message. The limit is the lowest of the previous
received since the last TMMBN was transmitted. value and all values received in TMMBR FCI's since the last TMMBN was
transmitted.
A media receiver who is not the owner of the bandwidth limit when A media receiver who is not the owner of the bandwidth limit when
sending a TMMBR, MUST request a bandwidth lower than their knowledge planning to send a TMMBR, SHOULD request a bandwidth lower than their
of currently established bandwidth limit for this media sender. knowledge of currently established bandwidth limit for this media
Therefore, all received requests for bandwidth limits greater or sender, or suppres their transmission for TMMBR. The exception to
equal to the one currently established are ignored. A media receiver the above rule is when a receiver either doesn't know the limit or
who is the owner of the current bandwidth limit, MAY lower the value are certain that their local representation of the value is in error.
All received requests for bandwidth limits greater or equal to the
one currently established are ignored, with the exception of them
resulting in the transmission of a TMMBN. A media receiver who is
the owner of the current bandwidth limit, MAY lower the value
further, raise the value or remove the restriction completely by further, raise the value or remove the restriction completely by
setting the bandwidth limit equal to the session limit. setting the bandwidth limit equal to the session limit.
Once a session participant receives the TMMBN in response to its Once a session participant receives the TMMBN in response to its
TMMBR, with its own SSRC, it knows that it "owns" the bandwidth TMMBR, with its own SSRC, it knows that it "owns" the bandwidth
limitation. Only the "owner" of a bandwidth limitation can raise it limitation. Only the "owner" of a bandwidth limitation can raise it
or reset it to the session limit. or reset it to the session limit.
Note that, due to the unreliable nature of transport of TMMBR and Note that, due to the unreliable nature of transport of TMMBR and
TMMBN, the above rules may lead to the sending of TMMBR messages TMMBN, the above rules may lead to the sending of TMMBR messages
skipping to change at page 25, line 35 skipping to change at page 26, line 39
common denominator, as required by this mechanism, may not be the common denominator, as required by this mechanism, may not be the
most suitable course of action. Larger session may need to consider most suitable course of action. Larger session may need to consider
other ways to support adapted bit-rate to participants, such as other ways to support adapted bit-rate to participants, such as
partitioning the session in different quality tiers, or use some partitioning the session in different quality tiers, or use some
other method of achieving bit-rate scalability. other method of achieving bit-rate scalability.
If the value set by a TMMBR message is expected to be permanent the If the value set by a TMMBR message is expected to be permanent the
TMMBR setting party is RECOMMENDED to renegotiate the session TMMBR setting party is RECOMMENDED to renegotiate the session
parameters to reflect that using the setup signalling. parameters to reflect that using the setup signalling.
4.2.1.2. Message Format An SSRC may time out according to the default rules for RTP session
participants, i.e. the media sender has not received any RTCP packet
from the owner for the last five regular reporting intervals. An SSRC
may also leave the session, indicating this through the transmission
of an RTCP BYE packet or an external signalling channel. In all of
these cases the entity is considered to have left the session. In the
case the "owner" leaves the session, the value SHALL be set to the
session maximum and the transmission of a TMMBN is scheduled.
4.2.1.2. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum bit-rate in units of 128 bits/s | | Maximum bit-rate in units of 128 bits/s |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 47 skipping to change at page 28, line 16
notification. The "SSRC of media source" SHALL be set to the SSRC of notification. The "SSRC of media source" SHALL be set to the SSRC of
the media receiver that currently owns the bit-rate limitation. the media receiver that currently owns the bit-rate limitation.
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 a FCI including the session reception of a TMMBR message with a FCI including the session
participant's SSRC. Only a single TMMBN SHALL be sent, even if more participant's SSRC. Only a single TMMBN SHALL be sent, even if more
than one TMMBR messages are received between the scheduling of the than one TMMBR messages are received between the scheduling of the
transmission and the actual transmission of the TMMBN message. The transmission and the actual transmission of the TMMBN message. The
TMMBN message indicates the limit and the owner of that limit at the TMMBN message indicates the limit and the owner of that limit at the
time of transmitting the message. The limit SHALL be the lowest of time of transmitting the message. The limit SHALL be the lowest of
all values received since the last TMMBN was transmitted. The one the existing and all values received in TMMBR messages since the last
sending that request SHALL become the owner of the limit. TMMBN was transmitted. The one sending that request SHALL become the
owner of the limit.
The reception of a TMMBR message with a transmission limit greater or The reception of a TMMBR message with a transmission limit greater or
equal than the current limit SHALL still result in the transmission equal than the current limit SHALL still result in the transmission
of a TMMBN message. However the limit and owner is not changed, of a TMMBN message. However the limit and owner is not changed,
unless it was from the owner, and the current limit and owner is unless it was from the same owner, and the current limit and owner is
indicated in the TMMBN message. This procedure allows session indicated in the TMMBN message. This procedure allows session
participants that haven't seen the last TMMBN message to get a participants that haven't seen the last TMMBN message to get a
correct view of this media sender's state. correct view of this media sender's state.
When a media sender determines an "owner" of a limitation has left When a media sender determines an "owner" of a limitation has left
the session, then the current limitation is removed, and the media the session, then the current limitation is removed, and the media
sender SHALL send a TMMBN message indicating the maximum session sender SHALL send a TMMBN message indicating the maximum session
bandwidth. bandwidth.
4.2.2.2. Message Format 4.2.2.2. Message Format
skipping to change at page 28, line 18 skipping to change at page 29, line 32
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)
4: Full Intra Request Command (FIR) 4: Full Intra Request Command (FIR)
5: Temporal-Spatial Trade-off Request (TSTR) 5: Temporal-Spatial Trade-off Request (TSTR)
6: Temporal-Spatial Trade-off Announcement (TSTA) 6: Temporal-Spatial Trade-off Announcement (TSTA)
7: Video Back Channel Message (VBCM) 7: Video Back Channel Message (VBCM)
8-14: unassigned 8-14: unassigned
15: Application layer FB message 15: Application layer FB message
16-30: unassigned 16-30: unassigned
31: reserved for future expansion of the sequence number space 31: reserved for future expansion of the number space
The following subsections define the new FCI formats for the payload- The following subsections define the new FCI formats for the payload-
specific FB messages. specific FB messages.
4.3.1. Full Intra Request (FIR) command 4.3.1. Full Intra Request (FIR) command
The FIR command FB message is identified by PT=PSFB and FMT=4. The FIR command FB message is identified by PT=PSFB and FMT=4.
There MUST be one or more FIR entry contained in the FCI field. There MUST be one or more FIR entry contained in the FCI field.
skipping to change at page 29, line 10 skipping to change at page 30, line 27
terminologies map to the video-centric terminology used here. terminologies map to the video-centric terminology used here.
Note: In environments where the sender has no control over the Note: In environments where the sender has no control over the
codec (e.g. when streaming pre-recorded and pre-coded content), the codec (e.g. when streaming pre-recorded and pre-coded content), the
reaction to this command cannot be specified. One suitable reaction to this command cannot be specified. One suitable
reaction of a sender would be to skip forward in the video bit reaction of a sender would be to skip forward in the video bit
stream to the next decoder refresh point. In other scenarios, it stream to the next decoder refresh point. In other scenarios, it
may be preferable not to react to the command at all, e.g. when may be preferable not to react to the command at all, e.g. when
streaming to a large multicast group. Other reactions may also be streaming to a large multicast group. Other reactions may also be
possible. When deciding on a strategy, a sender could take into possible. When deciding on a strategy, a sender could take into
account factors such as the size of the receiving multicast group, account factors such as the size of the receiving group, the
the "importance" of the sender of the FIR message (however "importance" of the sender of the FIR message (however "importance"
"importance" may be defined in this specific application), the may be defined in this specific application), the frequency of
frequency of decoder refresh points in the content, and others. decoder refresh points in the content, and others. However a
However the usage of FIR in a session which predominately handles session which predominately handles pre-coded content shouldn't use
pre-coded content shouldn't use the FIR at all. the FIR at all.
The sender MUST consider congestion control as outlined in section 5, The sender MUST consider congestion control as outlined in section 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.
Note: The relationship between the Picture Loss Indication and FIR Note: The relationship between the Picture Loss Indication and FIR
is as follows. As discussed in section 6.3.1 of AVPF, a Picture is as follows. As discussed in section 6.3.1 of AVPF, 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 likeliness of misalignment of the reference pictures in hence the likeliness of misalignment of the reference pictures in
encoder and decoder. Such a scenario is normally related to losses encoder and decoder. Such a scenario is normally related to losses
in an ongoing connection. In point-to-point scenarios, and without in an ongoing connection. In point-to-point scenarios, and without
the presence of advanced error resilience tools, one possible the presence of advanced error resilience tools, one possible
option an encoder has is to send a decoder refresh point. However, option an encoder has is to send a decoder refresh point. However,
there are other options including ignoring the PLI, for example if there are other options including ignoring the PLI, for example if
only one receiver of many has sent a PLI or when the embedded only one receiver of many has sent a PLI or when the embedded
stream redundancy is likely to clean up the reproduced picture stream redundancy is likely to clean up the reproduced picture
within a reasonable amount of time. within a reasonable amount of time. The FIR, in contrast, leaves a
The FIR, in contrast, leaves a real-time encoder no choice but to real-time encoder no choice but to send a decoder refresh point.
send a decoder refresh point. It disallows the encoder to take It disallows the encoder to take into account any considerations
into account any considerations such as the ones mentioned above. such as the ones mentioned above.
Note: Mandating a maximum delay for completing the sending of a Note: Mandating a maximum delay for completing the sending of a
decoder refresh point would be desirable from an application decoder refresh point would be desirable from an application
viewpoint, but may be problematic from a congestion control point viewpoint, but may be problematic from a congestion control point
of view. "As soon as possible" as mentioned above appears to be a of view. "As soon as possible" as mentioned above appears to be a
reasonable compromise. reasonable compromise.
FIR SHALL NOT be sent as a reaction to picture losses - it is FIR SHALL NOT be sent as a reaction to picture losses - it is
RECOMMENDED to use PLI instead. FIR SHOULD be used only in such RECOMMENDED to use PLI instead. FIR SHOULD be used only in such
situations where not sending a decoder refresh point would render the situations where not sending a decoder refresh point would render the
video unusable for the users. video unusable for the users.
Note: a typical example where sending FIR is adequate is when, in a Note: a typical example where sending FIR is adequate 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 be a video switching MCU that changes streams. Here, would be a video switching MCU that changes streams. Here,
normally, the MCU issues a freeze picture request (through protocol normally, the MCU issues a FIR to the new sender so to force it to
means outside this specification) to the receiver(s), switches the emit a decoder refresh point. The decoder refresh point includes
streams, and issues a FIR to the new sender so to force it to emit
a decoder refresh point. The decoder refresh point includes
normally a Freeze Picture Release (defined outside this normally a Freeze Picture Release (defined outside this
specification), which re-starts the rendering process of the specification), which re-starts the rendering process of the
receivers. Both techniques mentioned are commonly used in MCU- receivers. Both techniques mentioned are commonly used in MCU-
based multipoint conferences. based multipoint conferences.
Other RTP payload specifications such as RFC 2032 [RFC2032] already Other RTP payload specifications such as RFC 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 compatibility this specification when sending feedback. For backward compatibility
reasons, such an application SHOULD also be capable to receive and reasons, such an application SHOULD also be capable to receive and
skipping to change at page 31, line 17 skipping to change at page 32, line 30
number. Initial value is arbitrary. number. Initial value is arbitrary.
Reserved: All bits SHALL be set to 0 and SHALL be ignored on Reserved: All bits SHALL be set to 0 and SHALL be ignored on
reception. reception.
The semantics of this FB message is independent of the RTP payload The semantics of this FB message is independent of the RTP payload
type. type.
4.3.1.3. Timing Rules 4.3.1.3. Timing Rules
The timing follows the rules outlined in section 3 of [RFC4548]. FIR The timing follows the rules outlined in section 3 of [RFC4585]. FIR
commands MAY be used with early or immediate feedback. The FIR commands MAY be used with early or immediate feedback. The FIR
feedback message MAY be repeated. If using immediate feedback mode feedback message MAY be repeated. If using immediate feedback mode
the repetition SHOULD wait at least on RTT before being sent. In the repetition SHOULD wait at least onee RTT before being sent. In
early or regular RTCP mode the repetition is sent in the next regular early or regular RTCP mode the repetition is sent in the next regular
RTCP packet. RTCP packet.
4.3.1.4. Remarks 4.3.1.4. Remarks
FIR messages typically trigger the sending of full intra or IDR FIR messages typically trigger the sending of full intra or IDR
pictures. Both are several times larger then predicted (inter) pictures. Both are several times larger then predicted (inter)
pictures. Their size is independent of the time they are generated. pictures. Their size is independent of the time they are generated.
In most environments, especially when employing bandwidth-limited In most environments, especially when employing bandwidth-limited
links, the use of an intra picture implies an allowed delay that is a links, the use of an intra picture implies an allowed delay that is a
significant multitude of the typical frame duration. An example: If significant multitude of the typical frame duration. An example: If
the sending frame rate is 10 fps, and an intra picture is assumed to the sending frame rate is 10 fps, and an intra picture is assumed to
be 10 times as big as an inter picture, then a full second of latency be 10 times as big as an inter picture, then a full second of latency
has to be accepted. In such an environment there is no need for a has to be accepted. In such an environment there is no need for a
particular short delay in sending the FIR message. Hence waiting for particular short delay in sending the FIR message. Hence waiting for
the next possible time slot allowed by RTCP timing rules as per the next possible time slot allowed by RTCP timing rules as per
[RFC4548] may not have an overly negative impact on the system [RFC4585] may not have an overly negative impact on the system
performance. performance.
4.3.2. Temporal-Spatial Trade-off Request (TSTR) 4.3.2. Temporal-Spatial Trade-off Request (TSTR)
The TSTR FB message is identified by PT=PSFB and FMT=5. The TSTR FB message is identified by PT=PSFB and FMT=5.
There MUST be one or more TSTR entry contained in the FCI field. There MUST be one or more TSTR entry contained in the FCI field.
4.3.2.1. Semantics 4.3.2.1. Semantics
skipping to change at page 33, line 22 skipping to change at page 34, line 32
Index: An integer value between 0 and 31 that indicates the Index: An integer value between 0 and 31 that indicates the
relative trade off that is requested. An index value of 0 relative trade off that is requested. An index value of 0
index highest possible spatial quality, while 31 indicates index highest possible spatial quality, while 31 indicates
highest possible temporal resolution. highest possible temporal resolution.
Reserved: All bits SHALL be set to 0 and SHALL be ignored on Reserved: All bits SHALL be set to 0 and SHALL be ignored on
reception. reception.
4.3.2.3. Timing Rules 4.3.2.3. Timing Rules
The timing follows the rules outlined in section 3 of [RFC4548]. The timing follows the rules outlined in section 3 of [RFC4585].
This request message is not time critical and SHOULD be sent using This request message is not time critical and SHOULD be sent using
regular RTCP timing. Only if it is known that the user interface regular RTCP timing. Only if it is known that the user interface
requires a quick feedback, the message MAY be sent with early or requires a quick feedback, the message MAY be sent with early or
immediate feedback timing. immediate feedback timing.
4.3.2.4. Remarks 4.3.2.4. Remarks
The term "spatial quality" does not necessarily refer to the The term "spatial quality" does not necessarily refer to the
resolution, measured by the number of pixels the reconstructed video resolution, measured by the number of pixels the reconstructed video
is using. In fact, in most scenarios the video resolution stays is using. In fact, in most scenarios the video resolution stays
skipping to change at page 34, line 11 skipping to change at page 35, line 22
The TSTA FB message is identified by PT=PSFB and FMT=6. The TSTA FB message is identified by PT=PSFB and FMT=6.
There SHALL be one or more TSTA contained in the FCI field. There SHALL be one or more TSTA contained in the FCI field.
4.3.3.1. Semantics 4.3.3.1. Semantics
This feedback message is used to acknowledge the reception of a TSTR. This feedback message is used to acknowledge the reception of a TSTR.
A TSTA entry in a TSTA feedback message SHALL be sent for each TSTR A TSTA entry in a TSTA feedback message SHALL be sent for each TSTR
entry targeted to this session participant, i.e. each TSTR received entry targeted to this session participant, i.e. each TSTR received
that in the SSRC field in the entry has the receiving entities SSRC. that in the SSRC field in the entry has the receiving entities SSRC.
The acknowledgement SHALL be sent also for repetitions received. If A single TSTA message MAY acknowledge multiple requests using
the request receiver has received TSTR with several different multiple FCI entries. The index value included SHALL be the same in
sequence numbers from a single requestor it SHALL only respond to the all FCI's part of the TSTA message. Including a FCI for each
request with the highest (modulo 256) sequence number. requestor allows each requesting entity to determine that the media
sender targeted have received the request. The acknowledgement SHALL
be sent also for repetitions received. If the request receiver has
received TSTR with several different sequence numbers from a single
requestor it SHALL only respond to the request with the highest
(modulo 256) sequence number.
The TSTA SHALL include the Temporal-Spatial Trade-off index that will The TSTA SHALL include the Temporal-Spatial Trade-off index that will
be used as a result of the request. This is not necessarily the same be used as a result of the request. This is not necessarily the same
index as requested, as media sender may need to aggregate requests index as requested, as media sender may need to aggregate requests
from several requesting session participants. It may also have some from several requesting session participants. It may also have some
other policies or rules that limit the selection. other policies or rules that limit the selection.
A single TSTA message MAY acknowledge multiple requests using
multiple FCI entries.
4.3.3.2. Message Format 4.3.3.2. Message Format
The Temporal-Spatial Trade-off Announcement uses one additional FCI The Temporal-Spatial Trade-off Announcement uses one additional FCI
field, the content of which is depicted in Figure 5. The length of field, the content of which is depicted in Figure 5. The length of
the FB message MUST be set to 2+2*N, where N is the number of FCI the FB message MUST be set to 2+2*N, where N is the number of FCI
entries. entries.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 35, line 14 skipping to change at page 36, line 28
Reserved: All bits SHALL be set to 0 and SHALL be ignored on Reserved: All bits SHALL be set to 0 and SHALL be ignored on
reception. reception.
Informative note: The returned trade-off value (Index) may differ Informative note: The returned trade-off value (Index) may differ
from the requested one, for example in cases where a media encoder from the requested one, for example in cases where a media encoder
cannot tune its trade-off, or when pre-recorded content is used. cannot tune its trade-off, or when pre-recorded content is used.
4.3.3.3. Timing Rules 4.3.3.3. Timing Rules
The timing follows the rules outlined in section 3 of [RFC4548]. 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.
Edt. Note: a comment from Magnus: We might like to expand on this in
relation to certain applications
4.3.3.4. Remarks 4.3.3.4. Remarks
None None
4.3.4. H.271 VideoBackChannelMessage (VBCM) 4.3.4. H.271 VideoBackChannelMessage (VBCM)
The VBCM FB message is identified by PT=PSFB and FMT=7. The VBCM FB message is identified by PT=PSFB and FMT=7.
There MUST be one or more VBCM entry contained in the FCI field. There MUST be one or more VBCM entry contained in the FCI field.
Semantics 4.3.4.1. Semantics
The "payload" of VBCM indication carries codec specific, different The "payload" of VBCM indication carries codec specific, different
types of feedback information. The type of feedback information can types of feedback information. The type of feedback information can
be classified as "status report" such as receiving bit stream without be classified as "status report" such as receiving bit stream
errors, loss of partial or complete picture or block or "update without errors, loss of partial or complete picture or block or
requests" such as complete refresh of the bit stream. "update requests" such as complete refresh of the bit stream.
Note: There are possible overlap between the VBCM sub-messages Note: There are possible overlap between the VBCM sub-messages
and CCM/AVPF feedback messages, such FIR. Please see section and CCM/AVPF feedback messages, such FIR. Please see section
3.5.3 for further discussions. 3.5.3 for further discussions.
The different types of feedback sub-messages carried in the VBCM are The different types of feedback sub-messages carried in the VBCM are
indicated by the "payloadType" as defined in [VBCM]. The different indicated by the "payloadType" as defined in [VBCM]. The different
sub-message types as defined in [VBCM] are re-produced below for sub-message types as defined in [VBCM] are re-produced below for
convenience. "payloadType", in ITU-T Rec. H.271 terminology, refers convenience. "payloadType", in ITU-T Rec. H.271 terminology,
to the sub-type of the H.271 message and should not be confused with refers to the sub-type of the H.271 message and should not be
an RTP payload type. confused with an RTP payload type.
Payload Type Message Content Payload Type Message Content
0 One or more pictures without detected bitstream error mismatch 0 One or more pictures without detected bitstream error mismatch
1 One or more pictures that are entirely or partially lost 1 One or more pictures that are entirely or partially lost
2 A set of blocks of one picture that is entirely or partially 2 A set of blocks of one picture that is entirely or partially
lost lost
3 CRC for one parameter set 3 CRC for one parameter set
4 CRC for all parameter sets of a certain type 4 CRC for all parameter sets of a certain type
5 A "reset" request indicating that the sender should completely 5 A "reset" request indicating that the sender should completely
refresh the video bitstream as if no prior bitstream data had been refresh the video bitstream as if no prior bitstream data had been
received received
> 5 Reserved for future use by ITU-T > 5 Reserved for future use by ITU-T
skipping to change at page 36, line 15 skipping to change at page 37, line 32
1 One or more pictures that are entirely or partially lost 1 One or more pictures that are entirely or partially lost
2 A set of blocks of one picture that is entirely or partially 2 A set of blocks of one picture that is entirely or partially
lost lost
3 CRC for one parameter set 3 CRC for one parameter set
4 CRC for all parameter sets of a certain type 4 CRC for all parameter sets of a certain type
5 A "reset" request indicating that the sender should completely 5 A "reset" request indicating that the sender should completely
refresh the video bitstream as if no prior bitstream data had been refresh the video bitstream as if no prior bitstream data had been
received received
> 5 Reserved for future use by ITU-T > 5 Reserved for future use by ITU-T
The bit string or the "payload" of VBCM message is of variable length The bit string or the "payload" of VBCM message is of variable
and is self-contained and coded in a variable length, binary format. length and is self-contained and coded in a variable length, binary
The media sender necessarily has to be able to parse this optimized format. The media sender necessarily has to be able to parse this
binary format to make use of VBCM messages optimized binary format to make use of VBCM messages
Each of the different types of sub-messages (indicated by Each of the different types of sub-messages (indicated by
payloadType)e may have different semantic based on the codec used. payloadType)e may have different semantic based on the codec used.
Message Format 4.3.4.2. Message Format
The VBCM indication uses one FCI field and the syntax is depicted in The VBCM indication uses one FCI field and the syntax is depicted in
Figure 6. Figure 6.
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 Bit String.... | Padding | | VBCM Bit String.... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 - Syntax for VBCM Message Figure 6 - Syntax for VBCM Message
SSRC: The SSRC value of the media sender of this specific VBCM
indication message.
Seq. nr : Command sequence number. The sequence number space SSRC: The SSRC value of the media sender that is target of the
is unique for each tuple consisting of the SSRC of command message, i.e. the sender whose encoder should to react to the
source and the SSRC of the command target. The sequence number VBCM message
SHALL be increased by 1 modulo 256 for each new command. A
Seq. nr : Command sequence number. The sequence number space is
unique for each tuple consisting of the SSRC of command source
and the SSRC of the command target. The sequence number SHALL
be increased by 1 modulo 256 for each new command. A
repetition SHALL NOT increase the sequence number. Initial repetition SHALL NOT increase the sequence number. Initial
value is arbitrary. value is arbitrary.
0: Must be set to 0 and should not be acted upon receiving. 0: Must be set to 0 and should not be acted upon receiving.
Payload: The RTP payload type for which the VBCM bit stream Payload: The RTP payload type for which the VBCM bit stream must be
must be interpreted. interpreted.
NOTE : Stephan I think this payload type is redundant, Length: The length of the VBCM bit string in octets.
since during session set up phase you do lock down the payload
type that you are going to use for this session. But I am
keeping it since it is there in RPSI of AVPF. Is there any
reason for this ? From an implementation point of view I can
see this being helpful (and fast) since you don't have to go
back to your session information.
VBCM Bit String : This is the bit string generated by the VBCM Bit String : This is the bit string generated by the decoder
decoder carrying a specific feedback sub-message. It is of carrying a specific feedback sub-message. It is of variable
variable length. length.
Padding: Bits set to 0 to make up a 32 bit boundry Padding: Bits set to 0 to make up a 32 bit boundry
Timing Rules Timing Rules
The timing follows the rules outlined in section 3 of [RFC4548] The timing follows the rules outlined in section 3 of [RFC4585]
Remarks Remarks
Please see section 3.5.3 for the applicability of the VBCM message Please see section 3.5.3 for the applicability of the VBCM message
in relation to messages in both AVPF and this memo with similar in relation to messages in both AVPF and this memo with similar
functionality. functionality.
Edt. note: Between the authors there is an ongoing discussion
whether we need the payload type field in this message. It would
be needed if there were potentially more than one VBCM-capable
payload types in the same session, && that the semantics of a given
VBCM message changes from PT to PT. This appears to be the case.
For example, the picture identification mechanism in messages of
H.271 type 0 is fundamentally different between H.263 and H.264
(although both use the same syntax. So the payload field appears
to be justified. It was further commented that for TSTS and FIR
such a need may not exist, simply because the semantics of TSTS and
FIR are either loosely enough defined, or generic enough, to apply
to all video payloads currently in existence/envisioned. So that
part of the draft seems ok.
Edt. note: (related to SSRC field): Magnus commented [...]. There
is also need to define what the meaning of the fixed header SSRC
values are.
5. Congestion Control 5. Congestion Control
The correct application of the AVPF timing rules prevents the network The correct application of the AVPF timing rules prevents the network
flooding by feedback messages. Hence, assuming a correct flooding by feedback messages. Hence, assuming a correct
implementation, the RTCP channel cannot break its bit-rate commitment implementation, the RTCP channel cannot break its bit-rate commitment
and introduce congestion. and introduce congestion.
The reception of some of the feedback messages modifies the behaviour The reception of some of the feedback messages modifies the behaviour
of the media senders or, more specifically, the media encoders. All of the media senders or, more specifically, the media encoders. All
of these modifications MUST only be performed within the bandwidth of these modifications MUST only be performed within the bandwidth
limits the applied congestion control provides. For example, when limits the applied congestion control provides. For example, when
reacting to a FIR, the unusually high number of packets that form the reacting to a FIR, the unusually high number of packets that form the
decoder refresh point have to be paced in compliance with the decoder refresh point have to be paced in compliance with the
congestion control algorithm, even if the user experience suffers congestion control algorithm, even if the user experience suffers
from a slowly transmitted decoder refresh point. from a slowly transmitted decoder refresh point.
A change of the Temporary Maximum Media Bit-rate value can only A change of the Temporary Maximum Media Bit-rate value can only
mitigate congestion, but not cause congestion. An increase of the mitigate congestion, but not cause congestion as long as congestion
value by a request REQUIRES the media sender to use congestion control is also employed. An increase of the value by a request
control when increasing its transmission rate to that value. A REQUIRES the media sender to use congestion control when increasing
reduction of the value results in a reduced transmission bit-rate its transmission rate to that value. A reduction of the value results
thus reducing the risk for congestion. in a reduced transmission bit-rate thus reducing the risk for
congestion.
6. Security Considerations 6. Security Considerations
The defined messages have certain properties that have security The defined messages have certain properties that have security
implications. These must be addressed and taken into account by users implications. These must be addressed and taken into account by users
of this protocol. of this protocol.
The defined setup signalling mechanism is sensitive to modification The defined setup signalling mechanism is sensitive to modification
attacks that can result in session creation with sub-optimal attacks that can result in session creation with sub-optimal
configuration, and, in the worst case, session rejection. To prevent configuration, and, in the worst case, session rejection. To prevent
skipping to change at page 38, line 48 skipping to change at page 40, line 35
To prevent these attacks there is need to apply authentication and To prevent these attacks there is 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 group external threats using the RTP profile accomplished against group external threats using the RTP profile
that combines SRTP [SRTP] and AVPF into SAVPF [SAVPF]. In the MCU that combines SRTP [SRTP] and AVPF into SAVPF [SAVPF]. In the MCU
cases, separate security contexts and filtering can be applied cases, separate security contexts and filtering can be applied
between the MCU and the participants thus protecting other MCU users between the MCU and the participants thus protecting other MCU users
from a misbehaving participant. from a misbehaving participant.
7. SDP Definitions 7. SDP Definitions
Section 4 of [RFC4548] defines new SDP [RFC2327] attributes that are Section 4 of [RFC4585] defines new SDP [RFC2327] attributes that are
used for the capability exchange of the AVPF commands and used for the capability exchange of the AVPF commands and
indications, such as Reference Picture selection, Picture loss indications, such as Reference Picture selection, Picture loss
indication etc. The defined SDP attribute is known as rtcp-fb and its indication etc. The defined SDP attribute is known as rtcp-fb and its
ABNF is described in section 4.2 of [RFC4548]. In this section we ABNF is described in section 4.2 of [RFC4585]. In this section we
extend the rtcp-fb attribute to include the commands and indications extend the rtcp-fb attribute to include the commands and indications
that are described in this document for codec control protocol. We that are described in this document for codec control protocol. We
also discuss the Offer/Answer implications for the codec control also discuss the Offer/Answer implications for the codec control
commands and indications. commands and indications.
7.1. Extension of rtcp-fb attribute 7.1. Extension of rtcp-fb attribute
As described in [RFC4548], the rtcp-fb attribute is defined to As described in [RFC4585], the rtcp-fb attribute is defined to
indicate the capability of using RTCP feedback. As defined in AVPF indicate the capability of using RTCP feedback. As defined in AVPF
the rtcp-fb attribute must only be used as a media level attribute the rtcp-fb attribute must only be used as a media level attribute
and must not be provided at session level. and must not be provided at session level.
All the rules described in [RFC4548] for rtcp-fb attribute relating
All the rules described in [RFC4585] for rtcp-fb attribute relating
to payload type, multiple rtcp-fb attributes in a session description to payload type, multiple rtcp-fb attributes in a session description
hold for the new feedback messages for codec control defined in this hold for the new feedback messages for codec control defined in this
document. document.
The ABNF for rtcp-fb attributed as defined in [RFC4548] is The ABNF for rtcp-fb attributed as defined in [RFC4585] is
Rtcp-fb-syntax = "a=rtcp-fb: " rtcp-fb-pt SP rtcp-fb-val CRLF Rtcp-fb-syntax = "a=rtcp-fb: " rtcp-fb-pt SP rtcp-fb-val CRLF
Where rtcp-fb-pt is the payload type and rtcp-fb-val defines the type Where rtcp-fb-pt is the payload type and rtcp-fb-val defines the type
of the feedback message such as ack, nack, trr-int and rtcp-fb-id. of the feedback message such as ack, nack, trr-int and rtcp-fb-id.
For example to indicate the support of feedback of picture loss For example to indicate the support of feedback of picture loss
indication, the sender declares the following in SDP indication, the sender declares the following in SDP
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com o=alice 3203093520 3203093520 IN IP4 host.example.com
skipping to change at page 40, line 6 skipping to change at page 41, line 39
which indicates the support of codec control using RTCP feedback which indicates the support of codec control using RTCP feedback
messages. The "ccm" feedback value should be used with parameters, messages. The "ccm" feedback value should be used with parameters,
which indicates the support of which codec commands the session may which indicates the support of which codec commands the session may
use. In this draft we define four parameters, which can be used with use. In this draft we define four parameters, which can be used with
the ccm feedback value type. the ccm feedback value type.
o "fir" indicates the support of Full Intra Request o "fir" indicates the support of Full Intra Request
o "tmmbr" indicates the support of Temporal Maximum Media Bit-rate o "tmmbr" indicates the support of Temporal Maximum Media Bit-rate
o "tstr" indicates the support of temporal spatial trade-off o "tstr" indicates the support of temporal spatial trade-off
request. request.
O "bbcm" indicates the support of H.271 video back channel O "vbcm" indicates the support of H.271 video back channel
messages. messages.
In ABNF for rtcp-fb-val defined in [RFC4548], there is a placeholder In ABNF for rtcp-fb-val defined in [RFC4585], there is a placeholder
called rtcp-fb-id to define new feedback types. The ccm is defined as called rtcp-fb-id to define new feedback types. The ccm is defined as
a new feedback type in this document and the ABNF for the parameters a new feedback type in this document and the ABNF for the parameters
for ccm are defined here (please refer section 4.2 of [RFC4548] for for ccm are defined here (please refer section 4.2 of [RFC4585] for
complete ABNF syntax). complete ABNF syntax).
Rtcp-fb-param = SP "app" [SP byte-string] Rtcp-fb-param = SP "app" [SP byte-string]
/ SP rtcp-fb-ccm-param / SP rtcp-fb-ccm-param
/ ; empty / ; empty
rtcp-fb-ccm-param = "ccm" SP ccm-param rtcp-fb-ccm-param = "ccm" SP ccm-param
ccm-param = "fir" ; Full Intra Request ccm-param = "fir" ; Full Intra Request
/ "tmmbr" ; Temporary max media bit rate / "tmmbr" ; Temporary max media bit rate
/ "tstr" ; Temporal Spatial Trade Off / "tstr" ; Temporal Spatial Trade Off
/ "vbcm" 1*[SP subMessageType] ; H.271 VBCM messages / "vbcm" 1*[SP subMessageType] ; H.271 VBCM messages
/ token [SP byte-string] / token [SP byte-string]
; for future commands/indications ; for future commands/indications
subMessageType = 1*[integer]; subMessageType = 1*[integer];
byte-string = <as defined in section 4.2 of [RFC4548] > byte-string = <as defined in section 4.2 of [RFC4585] >
7.2. Offer-Answer 7.2. Offer-Answer
The Offer/Answer [RFC3264] implications to codec control protocol The Offer/Answer [RFC3264] implications to codec control protocol
feedback messages are similar to as described in [RFC4548]. The feedback messages are similar to as described in [RFC4585]. The
offerer MAY indicate the capability to support selected codec offerer MAY indicate the capability to support selected codec
commands and indications. The answerer MUST remove all ccm commands and indications. The answerer MUST remove all ccm
parameters, which it does not understand or does not wish to use in parameters, which it does not understand or does not wish to use in
this particular media session. The answerer MUST NOT add new ccm this particular media session. The answerer MUST NOT add new ccm
parameters in addition to what has been offered. The answer is parameters in addition to what has been offered. The answer is
binding for the media session and both offerer and answerer MUST only binding for the media session and both offerer and answerer MUST only
use feedback messages negotiated in this way. use feedback messages negotiated in this way.
7.3. Examples 7.3. Examples
skipping to change at page 41, line 43 skipping to change at page 43, line 32
m=video 51372 RTP/AVPF 98 m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm fir a=rtcp-fb:98 ccm fir
When the video MCU decides to route the video of this participant it When the video MCU decides to route the video of this participant it
sends an RTCP FIR feedback message. Upon receiving this feedback sends an RTCP FIR feedback message. Upon receiving this feedback
message the end point is mandated to generate a full intra request. message the end point is mandated 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 all the commands and indications of codec control messages. support "tstr", "fir" and "tmmbr" messages. The offered SDP is
The offered SDP is
-------------> Offer -------------> Offer
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Offer/Answer s=Offer/Answer
c=IN IP4 172.11.1.124 c=IN IP4 172.11.1.124
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98 m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
skipping to change at page 45, line 9 skipping to change at page 46, line 9
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Andrea Basso, Orit Levin, Nermeen The authors would like to thank Andrea Basso, Orit Levin, Nermeen
Ismail for their work on the requirement and discussion draft Ismail for their work on the requirement and discussion draft
[Basso]. [Basso].
10. References 10. References
10.1. Normative references 10.1. Normative references
[RFC4548] Ott, J., Wenger, S., Sato, N., Burmeister, C., Rey, J., [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., Rey, J.,
"Extended RTP Profile for Real-Time Transport Control "Extended RTP Profile for Real-Time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
2006 2006
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[Topologies] M. Westerlund, and S. Wenger, "Topologies", RFC xxxx, x [Topologies] M. Westerlund, and S. Wenger, "RTP Topologies", draft-
ietf-avt-topologies-00, work in progress, August 2006
10.2. Informative references 10.2. Informative references
[Basso] A. Basso, et. al., "Requirements for transport of video [Basso] A. Basso, et. al., "Requirements for transport of video
control commands", draft-basso-avt-videoconreq-02.txt, control commands", draft-basso-avt-videoconreq-02.txt,
expired Internet Draft, October 2004. expired Internet Draft, October 2004.
[AVC] Joint Video Team of ITU-T and ISO/IEC JTC 1, Draft ITU-T [AVC] Joint Video Team of ITU-T and ISO/IEC JTC 1, Draft ITU-T
Recommendation and Final Draft International Standard of Recommendation and Final Draft International Standard of
Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC
14496-10 AVC), Joint Video Team (JVT) of ISO/IEC MPEG and 14496-10 AVC), Joint Video Team (JVT) of ISO/IEC MPEG and
skipping to change at page 45, line 48 skipping to change at page 47, line 4
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC2032] Turletti, T. and C. Huitema, "RTP Payload Format for H.261 [RFC2032] Turletti, T. and C. Huitema, "RTP Payload Format for H.261
Video Streams", RFC 2032, October 1996. Video Streams", RFC 2032, October 1996.
[SAVPF] J. Ott, E. Carrara, "Extended Secure RTP Profile for RTCP- [SAVPF] J. Ott, E. Carrara, "Extended Secure RTP Profile for RTCP-
based Feedback (RTP/SAVPF)," draft-ietf-avt-profile-savpf- based Feedback (RTP/SAVPF)," draft-ietf-avt-profile-savpf-
02.txt, July, 2005. 02.txt, July, 2005.
[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 2003. "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[VBCM] ITU-T Rec. H.271, "Video Bach Channel Messages", pre-
Any 3GPP document can be downloaded from the 3GPP web server,
"http://www.3gpp.org/", see specifications.
11. Authors' Addresses 11. Authors' Addresses
Stephan Wenger Stephan Wenger
Nokia Corporation Nokia Corporation
P.O. Box 100 P.O. Box 100
FIN-33721 Tampere FIN-33721 Tampere
FINLAND FINLAND
Phone: +358-50-486-0637 Phone: +358-50-486-0637
EMail: stewe@stewe.org EMail: stewe@stewe.org
Umesh Chandra Umesh Chandra
Nokia Research Center Nokia Research Center
6000 Connection Drive 975, Page Mill Road,
Irving, Texas 75063 Palo Alto,CA 94304
USA USA
Phone: +1-972-894-6017 Phone: +1-650-796-7502
Email: Umesh.Chandra@nokia.com Email: Umesh.Chandra@nokia.com
Magnus Westerlund Magnus Westerlund
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: magnus.westerlund@ericsson.com EMail: magnus.westerlund@ericsson.com
skipping to change at page 47, line 25 skipping to change at page 48, line 20
and Magnus Westerlund around Feb 24 and Magnus Westerlund around Feb 24
- Section 3.5.2 and other occurrences throughout the draft, - Section 3.5.2 and other occurrences throughout the draft,
Temporal/Spatial Acknowledgement renamed to Temporal/Spatial Temporal/Spatial Acknowledgement renamed to Temporal/Spatial
Annoucement Annoucement
Changes relative to draft-wenger-avt-avpf-ccm-03 Changes relative to draft-wenger-avt-avpf-ccm-03
- Moved "topologies" out to another draft - Moved "topologies" out to another draft
- Editorial improvements - Editorial improvements
- Added new code point VBCM for H.271 Video back channel messages. - Added new code point VBCM for H.271 Video back channel messages.
Several sections - 3,4 and 7 were modified for this new CCM Sections 3,4 and 7 were modified in response to H.271 introduction.
message.
- Removed Basso use case referring to forward Freeze command, added - Removed Basso use case referring to forward Freeze command, added
justification. justification.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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.
 End of changes. 91 change blocks. 
260 lines changed or deleted 373 lines changed or added

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