draft-ietf-avt-avpf-ccm-01.txt   draft-ietf-avt-avpf-ccm-02.txt 
Network Working Group Stephan Wenger Network Working Group Stephan Wenger
INTERNET-DRAFT Umesh Chandra INTERNET-DRAFT Umesh Chandra
Expires: March 2007 Nokia Expires: April 2007 Nokia
Magnus Westerlund Magnus Westerlund
Bo Burman Bo Burman
Ericsson Ericsson
September 17, 2006 October 20, 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-01.txt> draft-ietf-avt-avpf-ccm-02.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 3, line 31 skipping to change at page 3, line 31
3.5.2. Temporal Spatial Trade-off Request and Announcement..15 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 Translators16 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.....................................19 3.5.3.1. Reliability.....................................19
3.5.4. Temporary Maximum Media Bit-rate Request.............19 3.5.4. Temporary Maximum Media Bit-rate Request.............19
3.5.4.1. MCU based Multi-point operation.................20 3.5.4.1. MCU based Multi-point operation.................20
3.5.4.2. Point-to-Multipoint using Multicast or Translators21 3.5.4.2. Point-to-Multipoint using Multicast or Translators22
3.5.4.3. Point-to-point operation........................22 3.5.4.3. Point-to-point operation........................22
3.5.4.4. Reliability.....................................22 3.5.4.4. Reliability.....................................22
4. RTCP Receiver Report Extensions................................23 4. RTCP Receiver Report Extensions................................24
4.1. Design Principles of the Extension Mechanism..............23 4.1. Design Principles of the Extension Mechanism..............24
4.2. Transport Layer Feedback Messages.........................24 4.2. Transport Layer Feedback Messages.........................25
4.2.1. Temporary Maximum Media Bit-rate Request (TMMBR).....24 4.2.1. Temporary Maximum Media Bit-rate Request (TMMBR).....25
4.2.1.1. Semantics.......................................24 4.2.1.1. Semantics.......................................25
4.2.1.2. Message Format..................................26 4.2.1.2. Message Format..................................27
4.2.1.3. Timing Rules....................................27 4.2.1.3. Timing Rules....................................28
4.2.2. Temporary Maximum Media Bit-rate Notification (TMMBN) 27 4.2.2. Temporary Maximum Media Bit-rate Notification (TMMBN) 28
4.2.2.1. Semantics.......................................27 4.2.2.1. Semantics.......................................28
4.2.2.2. Message Format..................................28 4.2.2.2. Message Format..................................29
4.2.2.3. Timing Rules....................................29 4.2.2.3. Timing Rules....................................30
4.3. Payload Specific Feedback Messages........................29 4.3. Payload Specific Feedback Messages........................30
4.3.1. Full Intra Request (FIR) command.....................29 4.3.1. Full Intra Request (FIR) command.....................30
4.3.1.1. Semantics.......................................29 4.3.1.1. Semantics.......................................30
4.3.1.2. Message Format..................................31 4.3.1.2. Message Format..................................32
4.3.1.3. Timing Rules....................................32 4.3.1.3. Timing Rules....................................33
4.3.1.4. Remarks.........................................32 4.3.1.4. Remarks.........................................33
4.3.2. Temporal-Spatial Trade-off Request (TSTR)............33 4.3.2. Temporal-Spatial Trade-off Request (TSTR)............34
4.3.2.1. Semantics.......................................33 4.3.2.1. Semantics.......................................34
4.3.2.2. Message Format..................................33 4.3.2.2. Message Format..................................34
4.3.2.3. Timing Rules....................................34 4.3.2.3. Timing Rules....................................35
4.3.2.4. Remarks.........................................34 4.3.2.4. Remarks.........................................35
4.3.3. Temporal-Spatial Trade-off Announcement (TSTA).......35 4.3.3. Temporal-Spatial Trade-off Announcement (TSTA).......36
4.3.3.1. Semantics.......................................35 4.3.3.1. Semantics.......................................36
4.3.3.2. Message Format..................................35 4.3.3.2. Message Format..................................36
4.3.3.3. Timing Rules....................................36 4.3.3.3. Timing Rules....................................37
4.3.3.4. Remarks.........................................36 4.3.3.4. Remarks.........................................37
4.3.4. H.271 VideoBackChannelMessage (VBCM).................36 4.3.4. H.271 VideoBackChannelMessage (VBCM).................37
5. Congestion Control.............................................39 5. Congestion Control.............................................40
6. Security Considerations........................................39 6. Security Considerations........................................41
7. SDP Definitions................................................40 7. SDP Definitions................................................41
7.1. Extension of rtcp-fb attribute............................40 7.1. Extension of rtcp-fb attribute............................42
7.2. Offer-Answer..............................................42 7.2. Offer-Answer..............................................43
7.3. Examples..................................................42 7.3. Examples..................................................43
8. IANA Considerations............................................45 8. IANA Considerations............................................46
9. Acknowledgements...............................................45 9. Acknowledgements...............................................47
10. References....................................................46 10. References....................................................48
10.1. Normative references.....................................46 10.1. Normative references.....................................48
10.2. Informative references...................................46 10.2. Informative references...................................48
11. Authors' Addresses............................................47 11. Authors' Addresses............................................49
12. List of Changes relative to previous drafts...................47 12. List of Changes relative to previous drafts...................49
1. Introduction 1. Introduction
When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was
developed, the main emphasis 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", community related to the use of terms such as mixer, translator, and
"translator", and "MCU". In response to these concerns, a number of MCU. In response to these concerns, a number of topologies have been
topologies have been identified that are of practical relevance to identified that are of practical relevance to the industry, but were
the industry, but were not envisioned (or at least not documented in not envisioned (or at least not documented in sufficient detail) in
sufficient detail) in RTP. These topologies are documented in RTP. These topologies are documented in [Topologies], and
[Topologies], and understanding this memo requires previous or understanding this memo requires previous or parallel study of
parallel study of [Topologies]. [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 constraints -- in the sense that their value diminishes with
increased delay. This makes the use of more traditional control increased delay. This makes the use of more traditional control
protocol means, such as SIP re-invites, undesirable. Furthermore, protocol means, such as SIP re-invites, undesirable. Furthermore,
skipping to change at page 9, line 36 skipping to change at page 9, line 36
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. the Please refer to [Topologies] for an in depth discussion. the
topologies referred to throughout this memo are labeled (consistent topologies referred to throughout this memo are labeled (consistent
with [Topologies] as follows: with [Topologies] as follows:
Topo-Point-to-Point . . . . . point-to-point communication Topo-Point-to-Point . . . . . point-to-point communication
> Topo-Multicast . . . . . . multicast communication as in RFC 3550 Topo-Multicast . . . . . . . multicast communication as in RFC 3550
> Topo-Translator . . . . . . translator based as in RFC 3550 Topo-Translator . . . . . . . translator based as in RFC 3550
> Topo-Mixer . . . . . . . . mixer based as in RFC 3550 Topo-Mixer . . . . . . . . . mixer based as in RFC 3550
> Topo-Video-switch-MCU . . . video switching MCU, Topo-Video-switch-MCU . . . . video switching MCU,
> Topo-RTCP-terminating-MCU . mixer but terminating RTCP Topo-RTCP-terminating-MCU . . mixer but terminating RTCP
3. Motivation (Informative) 3. Motivation (Informative)
This section discusses the motivation and usage of the different This section discusses the motivation and usage of the different
video and media control messages. The video control messages have video and media control messages. The video control messages have
been under discussion for a long time, and a requirement draft was been under discussion for a long time, and a requirement draft was
drawn up [Basso]. This draft has expired; however we do quote drawn up [Basso]. This draft has expired; however we 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 17, line 46 skipping to change at page 17, line 46
discussion would overload the present memo. discussion would overload the present memo.
In so far, this memo follows the guidance of a decade of RTP payload In so far, this memo follows the guidance of a decade of RTP payload
format specification work -- the details of the media format carried format specification work -- the details of the media format carried
is normally not described in any significant detail. 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. Furthermore, we note that native messages of AVPF and this memo. Furthermore, we note that
some H.271 message are known to require caution in multicast some H.271 message are known to require caution in multicast
environments -- or are plainly not usable in multicast or multipoint environments -- or are plainly not usable in multicast or multipoint
scenarios. Table xxx provides a brief, oversimplifying overview of scenarios. Table 1 provides a brief, oversimplifying overview of the
the messages currenty defined in H.271, their similar AVPF or CCM messages currenty defined in H.271, their similar AVPF or CCM
messages (the latter as specified in this memo), and an indication of messages (the latter as specified in this memo), and an indication of
our current knowledge of their multicast safety. our current knowledge of their multicast safety.
H.271 msg type AVPF/CCM msg type multicast-safe H.271 msg type AVPF/CCM msg type multicast-safe
0 (when used for reference 0 (when used for
picture selection) AVPF RPSI No (positive ACK of pictures) reference picture
selection) AVPF RPSI No (positive ACK of pictures)
1 AVPF PLI Yes 1 AVPF PLI Yes
2 AVPF SLI Yes 2 AVPF SLI Yes
3 N/A Yes (no required sender action) 3 N/A Yes (no required sender action)
4 N/A Yes (no required sender action) 4 N/A Yes (no required sender action)
Table 1: H.271 messages and their AVPF/CCM equivalents
Note: H.271 message type 0 is not a strict equivalent to Note: H.271 message type 0 is not a strict equivalent to
AVPF's RPSI; it is an indication of known-as-correct reference AVPF's RPSI; it is an indication of known-as-correct reference
picture(s) at the decoder. It does not command an encoder to picture(s) at the decoder. It does not command an encoder to
use a defined reference picture (the form of control use a defined reference picture (the form of control
information envisioned to be carried in RPSI). However, it is information envisioned to be carried in RPSI). However, it is
believed and intended that H.271 message type 0 will be used believed and intended that H.271 message type 0 will be used
for the same purpose as AVPF's RPSI -- although other use for the same purpose as AVPF's RPSI -- although other use
forms are also possible. forms are also possible.
In response to the opaqueness of the H.271 messages especially with In response to the opaqueness of the H.271 messages especially with
respect to the multicast safety, the following guidelines MUST be respect to the multicast safety, the following guidelines MUST be
followed when an implementation wishes to employ the H.271 video back followed when an implementation wishes to employ the H.271 video back
channel message: channel message:
1. Implementations utilizing the H.271 feedback message MUST stay in 1. Implementations utilizing the H.271 feedback message MUST stay in
compliance with congestion control principles, as outlined in compliance with congestion control principles, as outlined in
section 5. section 5.
2. An implementation SHOULD utilize the native messages as defined in 2. An implementation SHOULD utilize the native messages as defined in
[RFC4585] and in this memo instead of similar messages defined in [RFC4585] and in this memo instead of similar messages defined in
[H.271]. Our current understanding of similar messages is [H.271]. Our current understanding of similar messages is
documented in table xxx above. One good reason to divert from the documented in Table 1 above. One good reason to divert from the
SHOULD statement above would be if it is clearly understood that, SHOULD statement above would be if it is clearly understood that,
for a given application and video compression standard, the for a given application and video compression standard, the
aforementioned "similarity" is not given, in contrast to what aforementioned "similarity" is not given, in contrast to what
the table indicates. the table indicates.
3. It has been observed that some of the H.271 codepoints currently 3. It has been observed that some of the H.271 codepoints currently
in existence are not multicast-save. Therefore, the sensible in existence are not multicast-safe. Therefore, the sensible
thing to do is not to use the H.271 feedback message type in thing to do is not to use the H.271 feedback message type in
multicast environments. It MAY be used only when all the issues multicast environments. It MAY be used only when all the issues
mentioned later are fully understood by the implementer, and mentioned later are fully understood by the implementer, and
properly taken into account by all endpoints. In all other cases, properly taken into account by all endpoints. In all other cases,
the H.271 message type MUST NOT be used in conjunction with the H.271 message type MUST NOT be used in conjunction with
multicast. multicast.
4. It has been observed that even in centralized multipoint 4. It has been observed that even in centralized multipoint
environments, where the mixer should theoretically be able to environments, where the mixer should theoretically be able to
resolve issues as deocumented below, the implementation of such a resolve issues as deocumented below, the implementation of such a
mixer and cooperative endpoints is a very difficult and tedious mixer and cooperative endpoints is a very difficult and tedious
task. Therefore, H.271 message MUST NOT be used in centralized task. Therefore, H.271 message MUST NOT be used in centralized
multipoint scenarios, unless all the issues mentioned below are multipoint scenarios, unless all the issues mentioned below are
fully understood by the implementer, and properly taken into fully understood by the implementer, and properly taken into
account by both mixer and endpoints. account by both mixer and endpoints.
Issues with point to Multi-point: Issues with point to Multi-point:
1. Different state established on different receivers. One example is 1. Different state established on different receivers. One example is
the reference picture feedback message, which, when sent to receivers the reference picture feedback message, which, when sent to
in which the video codecs are at different state due to previous receivers in which the video codecs are at different state due to
losses or stream switches, the results can be unpredictable and previous losses or stream switches, the results can be
annoying. unpredictable and annoying.
2. Combination of multiple messages/requests by a media sender into 2. Combination of multiple messages/requests by a media sender into
an action and or response. an action and or response.
3. Suppression of requests may need to go beyond the basic mechanism 3. Suppression of requests may need to go beyond the basic mechanism
described in AVPF. For example forward messages may be need to described in AVPF. For example forward messages may be need to
suppress the generation of requests. suppress the generation of requests.
Issues with translators and mixers Issues with translators and mixers
1. Combination of multiple message or requests into an action or 1. Combination of multiple message or requests into an action or
response. response.
2. 2.
skipping to change at page 21, line 43 skipping to change at page 21, line 49
sender in the Mixer only - as there is no multicast transmission. sender in the Mixer only - as there is no multicast transmission.
The stream that needs to be bandwidth-reduced, however, is the one The stream that needs to be bandwidth-reduced, however, is the one
between the original sending endpoint and the Mixer. This endpoint between the original sending endpoint and the Mixer. This endpoint
doesn't see the aforementioned RTCP RRs, and hence needs explicitly doesn't see the aforementioned RTCP RRs, and hence needs explicitly
informed about desired bandwidth adjustments. informed about desired bandwidth adjustments.
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 under Topo-Mixer in [Topologies]),
can be employed for those few of the session participants that have which can be employed for those few of the session participants that
the lowest available bit-rates. have 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 these topologies, corresponding to Topo-Multicast or Topo- In these topologies, corresponding to Topo-Multicast or Topo-
Translator RTCP RRs are transmitted globally which allows for the Translator RTCP RRs are transmitted globally which allows for the
detection of transmission problems such as congestion, on a medium detection of transmission problems such as congestion, on a medium
timescale. As all media senders are aware of the congestion 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
skipping to change at page 26, line 4 skipping to change at page 27, line 4
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
disobeying the rules above. Furthermore, in multicast scenarios it disobeying the rules above. Furthermore, in multicast scenarios it
can happen that more than one session participants believes it "owns" can happen that more than one session participants believes it "owns"
the current bandwidth limitation. This is not critical for a number the current bandwidth limitation. This is not critical for a number
of reasons: of reasons:
a) If a TMMBR message is lost in transmission, the media sender does a) If a TMMBR message is lost in transmission, the media sender does
not learn about the restrictions imposed on it. However, it also not learn about the restrictions imposed on it. However, it also
does not send a TMMBN message notifying reception of a request it has does not send a TMMBN message notifying reception of a request it
never received. Therefore, no new limit is established, the media has never received. Therefore, no new limit is established, the
receiver sending the more restrictive TMMBR is not the owner. Since media receiver sending the more restrictive TMMBR is not the
this media receiver has not seen a notification corresponding to its owner. Since this media receiver has not seen a notification
request, it is free to re-send it. corresponding to its request, it is free to re-send it.
b) Similarly, if a TMMBN message gets lost, the media receiver that b) Similarly, if a TMMBN message gets lost, the media receiver that
has sent the corresponding TMMBR request does not receive has sent the corresponding TMMBR request does not receive
acknowledgement. In that case, it is also not the "owner" of the acknowledgement. In that case, it is also not the "owner" of the
restriction and is free to re-send the request. restriction and is free to re-send the request.
c) If multiple competing TMMBR messages are sent by different session c) If multiple competing TMMBR messages are sent by different session
participants, then the resulting TMMBN indicates the lowest bandwidth participants, then the resulting TMMBN indicates the lowest
requested; the owner is set to the sender of the TMMBR with the bandwidth requested; the owner is set to the sender of the TMMBR
lowest requested bandwidth value. with the lowest requested bandwidth value.
TMMBR feedback SHOULD NOT be used if the underlying transport TMMBR feedback SHOULD NOT be used if the underlying transport
protocol is capable of providing similar feedback information from protocol is capable of providing similar feedback information from
the receiver to the sender. the receiver to the sender.
It also important to consider the security risks involved with faked It also important to consider the security risks involved with faked
TMMBRs. See security considerations in Section 6. TMMBRs. See security considerations in Section 6.
The feedback messages may be used in both multicast and unicast The feedback messages may be used in both multicast and unicast
sessions of any of the specified topologies. sessions of any of the specified topologies.
skipping to change at page 35, line 26 skipping to change at page 36, line 28
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.
A single TSTA message MAY acknowledge multiple requests using A single TSTA message MAY acknowledge multiple requests using
multiple FCI entries. The index value included SHALL be the same in multiple FCI entries. The index value included SHALL be the same in
all FCI's part of the TSTA message. Including a FCI for each all FCI's part of the TSTA message. Including a FCI for each
requestor allows each requesting entity to determine that the media requestor allows each requesting entity to determine that the media
sender targeted have received the request. The acknowledgement SHALL sender targeted have received the request. The announcement SHALL be
be sent also for repetitions received. If the request receiver has sent also for repetitions received. If the request receiver has
received TSTR with several different sequence numbers from a single received TSTR with several different sequence numbers from a single
requestor it SHALL only respond to the request with the highest requestor it SHALL only respond to the request with the highest
(modulo 256) sequence number. (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.
The "SSRC of the packet sender" field indicates the source of the
announcement, and the "SSRC of media source" is not used and SHALL be
set to 0. The SSRC of the requesting entity to which the announcement
applies to is in the FCI.
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 36, line 32 skipping to change at page 37, line 38
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 [RFC4585]. The timing follows the rules outlined in section 3 of [RFC4585].
This acknowledgement message is not extremely time critical and This acknowledgement message is not extremely time critical and
SHOULD be sent using regular RTCP timing. SHOULD be sent using regular RTCP timing.
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.
skipping to change at page 37, line 28 skipping to change at page 38, line 33
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
received been received
> 5 Reserved for future use by ITU-T > 5 Reserved for future use by ITU-T
Table 2: H.271 message types
The bit string or the "payload" of VBCM message is of variable The bit string or the "payload" of VBCM message is of variable
length and is self-contained and coded in a variable length, binary length and is self-contained and coded in a variable length, binary
format. The media sender necessarily has to be able to parse this format. The media sender necessarily has to be able to parse this
optimized binary format to make use of VBCM messages optimized binary format to make use of VBCM messages
Each of the different types of sub-messages (indicated by Each of the different types of sub-messages (indicated by
payloadType)e may have different semantic based on the codec used. payloadType) may have different semantic based on the codec used.
The "SSRC of the packet sender" field indicates the source of the
request, and the "SSRC of media source" is not used and SHALL be set
to 0. The SSRC of the media sender to which the VBCM message applies
to is in the FCI.
4.3.4.2. Message Format 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 Octet String.... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 - Syntax for VBCM Message Figure 6 - Syntax for VBCM Message
SSRC: The SSRC value of the media sender that is target of the SSRC: The SSRC value of the media sender that is target of the
message, i.e. the sender whose encoder should to react to the message, i.e. the media sender whose encoder should to react
VBCM message to the VBCM message
Seq. nr : Command sequence number. The sequence number space is Seq. nr: Command sequence number. The sequence number space is unique
unique for each tuple consisting of the SSRC of command source for each tuple consisting of the SSRC of command source and
and the SSRC of the command target. The sequence number SHALL the SSRC of the command target. The sequence number SHALL be
be increased by 1 modulo 256 for each new command. A increased by 1 modulo 256 for each new command. A repetition
repetition SHALL NOT increase the sequence number. Initial SHALL NOT increase the sequence number. Initial value is
value is arbitrary. 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 must be Payload: The RTP payload type for which the VBCM bit stream must be
interpreted. interpreted.
Length: The length of the VBCM bit string in octets. Length: The length of the VBCM octet string in octets exclusive any
padding octets
VBCM Bit String : This is the bit string generated by the decoder VBCM Octet String: This is the octet string generated by the decoder
carrying a specific feedback sub-message. It is of variable carrying a specific feedback sub-message. It is of variable
length. length.
Padding: Bits set to 0 to make up a 32 bit boundry Padding: Bytes set to 0 to make up a 32 bit boundary.
Timing Rules Timing Rules
The timing follows the rules outlined in section 3 of [RFC4585] The timing follows the rules outlined in section 3 of [RFC4585].
The different sub-message types may have different properties in
regards to the timing of messages that should be used. If several
different types are included in the same feedback packet then the
sub-message type with the most stringent requiremnts should be
followed.
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 Note: There has been some discussion whether the payload type field
whether we need the payload type field in this message. It would in this message is needed. It would be needed if there were
be needed if there were potentially more than one VBCM-capable potentially more than one VBCM-capable RTP payload types in the
payload types in the same session, && that the semantics of a given same session, and that the semantics of a given VBCM message
VBCM message changes from PT to PT. This appears to be the case. changes from PT to PT. This appears to be the case. For example,
For example, the picture identification mechanism in messages of the picture identification mechanism in messages of H.271 type 0 is
H.271 type 0 is fundamentally different between H.263 and H.264 fundamentally different between H.263 and H.264 (although both use
(although both use the same syntax. So the payload field appears the same syntax. Therefore, the payload field is justified here.
to be justified. It was further commented that for TSTS and FIR It was further commented that for TSTS and FIR such a need does not
such a need may not exist, simply because the semantics of TSTS and exist, because the semantics of TSTS and FIR are either loosely
FIR are either loosely enough defined, or generic enough, to apply enough defined, or generic enough, to apply to all video payloads
to all video payloads currently in existence/envisioned. So that currently in existence/envisioned.
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
skipping to change at page 46, line 5 skipping to change at page 47, line 11
Long name: H.271 video back channel messages Long name: H.271 video back channel messages
Usable with: ccm Usable with: ccm
Reference: RFC XXXX Reference: RFC XXXX
9. Acknowledgements 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].
Funding for the RFC Editor function is currently provided by the
Internet Society.
10. References 10. References
10.1. Normative references 10.1. Normative references
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., Rey, J., [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., Rey, J.,
"Extended RTP Profile for Real-Time Transport Control "Extended RTP Profile for Real-Time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
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.
skipping to change at page 46, line 36 skipping to change at page 48, line 35
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
ITU-T VCEG, JVT-G050, March 2003. ITU-T VCEG, JVT-G050, March 2003.
[NEWPRED] S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient Video [NEWPRED] S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient
Coding by Dynamic Replacing of Reference Pictures," in Video Coding by Dynamic Replacing of Reference Pictures,"
Proc. Globcom'96, vol. 3, pp. 1503 - 1508, 1996. in Proc. Globcom'96, vol. 3, pp. 1503 - 1508, 1996.
[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
RFC 3711, March 2004. (SRTP)", 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
Video Streams", RFC 2032, October 1996. H.261 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
based Feedback (RTP/SAVPF)," draft-ietf-avt-profile-savpf- RTCP-based Feedback (RTP/SAVPF)," draft-ietf-avt-profile-
02.txt, July, 2005. savpf-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 Back Channel Messages", June
2006
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
skipping to change at page 49, line 18 skipping to change at page 51, line 19
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
RFC Editor Considerations RFC Editor Considerations
The RFC editor is requested to replace all occurrences of XXXX with The RFC editor is requested to replace all occurrences of XXXX with
the RFC number this document receives. the RFC number this document receives.
 End of changes. 36 change blocks. 
134 lines changed or deleted 147 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/