draft-ietf-avt-avpf-ccm-02.txt   draft-ietf-avt-avpf-ccm-03.txt 
Network Working Group Stephan Wenger Network Working Group Stephan Wenger
INTERNET-DRAFT Umesh Chandra INTERNET-DRAFT Umesh Chandra
Expires: April 2007 Nokia Expires: May 2007 Nokia
Magnus Westerlund Magnus Westerlund
Bo Burman Bo Burman
Ericsson Ericsson
October 20, 2006 November 30, 2006
Codec Control Messages in the Codec Control Messages in the
Audio-Visual Profile with Feedback (AVPF) RTP Audio-Visual Profile with Feedback (AVPF)
draft-ietf-avt-avpf-ccm-02.txt> draft-ietf-avt-avpf-ccm-03.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 28 skipping to change at page 3, line 28
3.5. Feedback Messages.........................................13 3.5. Feedback Messages.........................................13
3.5.1. Full Intra Request Command...........................13 3.5.1. Full Intra Request Command...........................13
3.5.1.1. Reliability.....................................14 3.5.1.1. Reliability.....................................14
3.5.2. Temporal Spatial Trade-off Request and Announcement..15 3.5.2. Temporal Spatial Trade-off Request and 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.....................................20
3.5.4. Temporary Maximum Media Bit-rate Request.............19 3.5.4. Temporary Maximum Media Bit-rate Request.............20
3.5.4.1. MCU based Multi-point operation.................20 3.5.4.1. MCU based Multi-point operation.................21
3.5.4.2. Point-to-Multipoint using Multicast or Translators22 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.....................................23
4. RTCP Receiver Report Extensions................................24 4. RTCP Receiver Report Extensions................................24
4.1. Design Principles of the Extension Mechanism..............24 4.1. Design Principles of the Extension Mechanism..............24
4.2. Transport Layer Feedback Messages.........................25 4.2. Transport Layer Feedback Messages.........................25
4.2.1. Temporary Maximum Media Bit-rate Request (TMMBR).....25 4.2.1. Temporary Maximum Media Bit-rate Request (TMMBR).....25
4.2.1.1. Semantics.......................................25 4.2.1.1. Semantics.......................................25
4.2.1.2. Message Format..................................27 4.2.1.2. Message Format..................................27
4.2.1.3. Timing Rules....................................28 4.2.1.3. Timing Rules....................................28
4.2.2. Temporary Maximum Media Bit-rate Notification (TMMBN) 28 4.2.2. Temporary Maximum Media Bit-rate Notification (TMMBN) 28
4.2.2.1. Semantics.......................................28 4.2.2.1. Semantics.......................................28
4.2.2.2. Message Format..................................29 4.2.2.2. Message Format..................................29
skipping to change at page 17, line 25 skipping to change at page 17, line 25
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 transparently convey such a message from media this memo is used to transparently convey such a message from media
receiver to media sender. receiver to media sender.
We refrain from an in-depth discussion of the available codepoints In this memo, we refrain from an in-depth discussion of the available
within H.271 in this memo for a number of reasons. The perhaps most codepoints within H.271 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.
Another reason lies in the complexity of the H.271 specification: it Another reason lies in the complexity of the H.271 specification: it
is a dense document with currently 16 pages of content. It does not is a dense document with currently 16 pages of content. It does not
make any sense to try to summarize its content in a few sentences of make any sense to try to summarize its content in a few sentences of
IETF lingo -- oversimplification and misguidance would be inevitable. IETF lingo -- oversimplification and misguidance would be inevitable.
Finally, please note that H.271 contains many statements of Finally, please note that H.271 contains many statements of
applicability and interpretation of its various messages in applicability and interpretation of its various messages in
conjunction with specific video compression standards. This type of conjunction with specific video compression standards. This type of
discussion would overload the present memo. discussion would overload the present memo.
skipping to change at page 18, line 51 skipping to change at page 18, line 51
3. It has been observed that some of the H.271 codepoints currently 3. It has been observed that some of the H.271 codepoints currently
in existence are not multicast-safe. Therefore, the sensible in existence are not multicast-safe. Therefore, the sensible
thing to do is not to use the H.271 feedback message type in thing to do is not to use the H.271 feedback message type in
multicast environments. It MAY be used only when all the issues multicast environments. It MAY be used only when all the issues
mentioned later are fully understood by the implementer, and mentioned later are fully understood by the implementer, and
properly taken into account by all endpoints. In all other cases, properly taken into account by all endpoints. In all other cases,
the H.271 message type MUST NOT be used in conjunction with the H.271 message type MUST NOT be used in conjunction with
multicast. multicast.
4. It has been observed that even in centralized multipoint 4. It has been observed that even in centralized multipoint
environments, where the mixer should theoretically be able to environments, where the mixer should theoretically be able to
resolve issues as deocumented below, the implementation of such a resolve issues as documented below, the implementation of such a
mixer and cooperative endpoints is a very difficult and tedious mixer and cooperative endpoints is a very difficult and tedious
task. Therefore, H.271 message MUST NOT be used in centralized task. Therefore, H.271 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 to be taken into account when considering the use of H.271 in
multipoint environments:
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. Different state on different receivers. In many environments it
1. Combination of multiple message or requests into an action or cannot be guarantied that the decoder state of all media receivers
response. is identical at any given point in time. The most obvious reason
2. for such a possible misalignment of state is a loss that occurs on
the link to only one of many media receivers. However, there are
other not so obvious reasons, such as recent joins to the
multipoint conference (be it by joining the multicast group or
through additional mixer output). Different states can lead the
media receivers to issue potentially contradicting H.271 messages
(or one media receiver issuing an H.271 message that, when
observed by the media sender, is not helpful for the other media
receivers). A naive reaction of the media sender to these
contradicting messages can lead to unpredictable and annoying
results.
2. Combining messages from different media receivers in a media
sender is a non-trivial task. As reasons, we note that these
messages may be contradicting each other, and that their transport
is unreliable (there may well be other reasons). In case of many
H.271 messages (i.e. types 0, 2, 3, and 4), the algorithm for
combining must be both aware of the network/protocol environment
(i.e. with respect to congestion) and of the media codec employed,
as H.271 messages of a given type can have different semantics for
different media codecs.
3. The suppression of requests may need to go beyond the basic
mechanism described in AVPF (which are driven exclusively by
timing/bandwidth considerations on the protocol level). For
example, a receiver is often required to refrain from (or delay)
generating requests, based on information it receives from the
media stream. For instance, it makes no sense for a receiver to
issue a FIR when a transmission of an Intra/IDR picture is
ongoing.
4. When using the not multicast save messages (e.g. H.271 type 0
positive ACK of received pictures/slices) in larger multicast
groups, the media receiver will likely be forced to delay or even
omit sending these messages. For the media sender this looks like
data has not been properly received (although it was received
properly), and a naively implemented media sender reacts to these
perceived problems where it shouldn't.
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.
skipping to change at page 45, line 30 skipping to change at page 45, line 30
c=IN IP4 189.13.1.37 c=IN IP4 189.13.1.37
m=audio 47190 RTP/AVP 0 m=audio 47190 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 53273 RTP/AVPF 98 m=video 53273 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir a=rtcp-fb:98 ccm fir
Example 4: The following example describes the Offer/Answer Example 4: The following example describes the Offer/Answer
implications for H.271 Video back channel messages (VBCM). The implications for H.271 Video back channel messages (VBCM). The
Offerer wishes to support VBCM and the submessages of payloadType 2( Offerer wishes to support VBCM and the submessages of payloadType 1
A set of blocks of one picture that is entirely or partially lost, 3 (One or more pictures that are entirely or partially lost) and 2 (a
(CRC for one parameter set) and 4 (CRC for all parameter sets of a set of blocks of one picture that is entirely or partially lost).
certain type).
-------------> 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
a=rtcp-fb:98 ccm vbcm 2 3 4 a=rtcp-fb:98 ccm vbcm 1 2
The answerer only wishes to support sub-messages 3 and 4 only The answerer only wishes to support sub-messages 1 only
<---------------- Answer <---------------- Answer
v=0 v=0
o=alice 3203093520 3203093524 IN IP4 otherhost.example.com o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
s=Offer/Answer s=Offer/Answer
c=IN IP4 189.13.1.37 c=IN IP4 189.13.1.37
m=audio 47190 RTP/AVP 0 m=audio 47190 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 53273 RTP/AVPF 98 m=video 53273 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm vbcm 3 4 a=rtcp-fb:98 ccm vbcm 1
So in the above example only VBCM indication comprising of only So in the above example only VBCM indication comprising of only
"payloadType" 3 and 4 will be supported. "payloadType" 1 will be supported.
8. IANA Considerations 8. IANA Considerations
The new value of ccm for the rtcp-fb attribute needs to be registered The new value of ccm for the rtcp-fb attribute needs to be registered
with IANA. with IANA.
Value name: ccm Value name: ccm
Long Name: Codec Control Commands and Indications Long Name: Codec Control Commands and Indications
Reference: RFC XXXX Reference: RFC XXXX
skipping to change at page 49, line 41 skipping to change at page 49, line 41
EMail: magnus.westerlund@ericsson.com EMail: magnus.westerlund@ericsson.com
Bo Burman Bo Burman
Ericsson Research Ericsson Research
Ericsson AB Ericsson AB
SE-164 80 Stockholm, SWEDEN SE-164 80 Stockholm, SWEDEN
Phone: +46 8 7190000 Phone: +46 8 7190000
EMail: bo.burman@ericsson.com EMail: bo.burman@ericsson.com
12. List of Changes relative to previous drafts
The following changes since draft-wenger-avt-avpf-ccm-01 have been
made:
- The topologies have been rewritten and clarified.
- The TMMBR mechanism has been completely revised to use notification
and suppress messages in deployments with large common SSRC spaces.
The following changes since draft-wenger-avt-avpf-ccm-02 have been
made:
- Update of section 4.2.2.1 (TMMBN) as per discussions between
Harikishan Desineni and Magnus Westerlund on the AVT list around
Feb 21, 2006
- Section 2.3.4 clarified as per email exchange between Colin Perkins
and Magnus Westerlund around Feb 24
- Section 3.5.2 and other occurrences throughout the draft,
Temporal/Spatial Acknowledgement renamed to Temporal/Spatial
Annoucement
Changes relative to draft-wenger-avt-avpf-ccm-03
- Moved "topologies" out to another draft
- Editorial improvements
- Added new code point VBCM for H.271 Video back channel messages.
Sections 3,4 and 7 were modified in response to H.271 introduction.
- Removed Basso use case referring to forward Freeze command, added
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.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 15 change blocks. 
65 lines changed or deleted 58 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/