draft-ietf-avt-avpf-ccm-09.txt   draft-ietf-avt-avpf-ccm-10.txt 
Network Working Group Stephan Wenger Network Working Group Stephan Wenger
INTERNET-DRAFT Umesh Chandra INTERNET-DRAFT Umesh Chandra
Expires: February 2008 Nokia Expires: April 2008 Nokia
Intended Status: Proposed Standard Magnus Westerlund Intended Status: Proposed Standard Magnus Westerlund
Bo Burman Bo Burman
Ericsson Ericsson
August 1, 2007 October 26, 2007
Codec Control Messages in the Codec Control Messages in the
RTP Audio-Visual Profile with Feedback (AVPF) RTP Audio-Visual Profile with Feedback (AVPF)
<draft-ietf-avt-avpf-ccm-10.txt>
<draft-ietf-avt-avpf-ccm-09.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 23 skipping to change at page 3, line 23
3.1. Use Cases.................................................10 3.1. Use Cases.................................................10
3.2. Using the Media Path......................................12 3.2. Using the Media Path......................................12
3.3. Using AVPF................................................13 3.3. Using AVPF................................................13
3.3.1. Reliability..........................................13 3.3.1. Reliability..........................................13
3.4. Multicast.................................................13 3.4. Multicast.................................................13
3.5. Feedback Messages.........................................13 3.5. Feedback Messages.........................................13
3.5.1. Full Intra Request Command...........................13 3.5.1. Full Intra Request Command...........................13
3.5.1.1. Reliability.....................................14 3.5.1.1. Reliability.....................................14
3.5.2. Temporal Spatial Trade-off Request and Notification..15 3.5.2. Temporal Spatial Trade-off Request and Notification..15
3.5.2.1. Point-to-Point..................................16 3.5.2.1. Point-to-Point..................................16
3.5.2.2. Point-to-Multipoint Using Multicast or 3.5.2.2. Point-to-Multipoint Using Multicast or Translators16
Translators.....................................16
3.5.2.3. Point-to-Multipoint Using RTP Mixer.............17 3.5.2.3. Point-to-Multipoint Using RTP Mixer.............17
3.5.2.4. Reliability.....................................17 3.5.2.4. Reliability.....................................17
3.5.3. H.271 Video Back Channel Message.....................18 3.5.3. H.271 Video Back Channel Message.....................18
3.5.3.1. Reliability.....................................20 3.5.3.1. Reliability.....................................20
3.5.4. Temporary Maximum Media Stream Bit Rate Request and 3.5.4. Temporary Maximum Media Stream Bit Rate Request and
Notification.........................................20 Notification................................................20
3.5.4.1. Behavior for media receivers using TMMBR........23 3.5.4.1. Behavior for media receivers using TMMBR........23
3.5.4.2. Algorithm for establishing current limitations..24 3.5.4.2. Algorithm for establishing current limitations..24
3.5.4.3. Use of TMMBR in a Mixer Based Multipoint 3.5.4.3. Use of TMMBR in a Mixer Based Multipoint Operation31
Operation.......................................31
3.5.4.4. Use of TMMBR in Point-to-Multipoint Using 3.5.4.4. Use of TMMBR in Point-to-Multipoint Using
Multicast or Translators........................32 Multicast or Translators........................32
3.5.4.5. Use of TMMBR in Point-to-point operation........32 3.5.4.5. Use of TMMBR in Point-to-point operation........32
3.5.4.6. Reliability.....................................32 3.5.4.6. Reliability.....................................33
4. RTCP Receiver Report Extensions..............................34 4. RTCP Receiver Report Extensions..............................34
4.1. Design Principles of the Extension Mechanism..............34 4.1. Design Principles of the Extension Mechanism..............34
4.2. Transport Layer Feedback Messages.........................35 4.2. Transport Layer Feedback Messages.........................35
4.2.1. Temporary Maximum Media Stream Bit Rate Request 4.2.1. Temporary Maximum Media Stream Bit Rate Request (TMMBR)36
(TMMBR)..............................................36
4.2.1.1. Message Format..................................36 4.2.1.1. Message Format..................................36
4.2.1.2. Semantics.......................................37 4.2.1.2. Semantics.......................................37
4.2.1.3. Timing Rules....................................41 4.2.1.3. Timing Rules....................................41
4.2.1.4. Handling in Translator and Mixers...............41 4.2.1.4. Handling in Translator and Mixers...............41
4.2.2. Temporary Maximum Media Stream Bit Rate Notification 4.2.2. Temporary Maximum Media Stream Bit Rate Notification
(TMMBN)..............................................41 (TMMBN)..............................................41
4.2.2.1. Message Format..................................41 4.2.2.1. Message Format..................................41
4.2.2.2. Semantics.......................................42 4.2.2.2. Semantics.......................................42
4.2.2.3. Timing Rules....................................43 4.2.2.3. Timing Rules....................................43
4.2.2.4. Handling by Translators and Mixers..............43 4.2.2.4. Handling by Translators and Mixers..............43
4.3. Payload Specific Feedback Messages........................43 4.3. Payload Specific Feedback Messages........................43
4.3.1. Full Intra Request (FIR).............................44 4.3.1. Full Intra Request (FIR).............................44
4.3.1.1. Message Format..................................44 4.3.1.1. Message Format..................................44
4.3.1.2. Semantics.......................................45 4.3.1.2. Semantics.......................................45
4.3.1.3. Timing Rules....................................46 4.3.1.3. Timing Rules....................................46
4.3.1.4. Handling of FIR Message in Mixer and 4.3.1.4. Handling of FIR Message in Mixer and Translators 46
Translators.....................................46
4.3.1.5. Remarks.........................................46 4.3.1.5. Remarks.........................................46
4.3.2. Temporal-Spatial Trade-off Request (TSTR)............48 4.3.2. Temporal-Spatial Trade-off Request (TSTR)............48
4.3.2.1. Message Format..................................48 4.3.2.1. Message Format..................................48
4.3.2.2. Semantics.......................................49 4.3.2.2. Semantics.......................................49
4.3.2.3. Timing Rules....................................49 4.3.2.3. Timing Rules....................................49
4.3.2.4. Handling of message in Mixers and Translators...49 4.3.2.4. Handling of message in Mixers and Translators...50
4.3.2.5. Remarks.........................................50 4.3.2.5. Remarks.........................................50
4.3.3. Temporal-Spatial Trade-off Notification (TSTN).......50 4.3.3. Temporal-Spatial Trade-off Notification (TSTN).......50
4.3.3.1. Message Format..................................50 4.3.3.1. Message Format..................................50
4.3.3.2. Semantics.......................................51 4.3.3.2. Semantics.......................................51
4.3.3.3. Timing Rules....................................52 4.3.3.3. Timing Rules....................................52
4.3.3.4. Handling of TSTN in Mixer and Translators.......52 4.3.3.4. Handling of TSTN in Mixer and Translators.......52
4.3.3.5. Remarks.........................................52 4.3.3.5. Remarks.........................................52
4.3.4. H.271 Video Back Channel Message (VBCM)..............52 4.3.4. H.271 Video Back Channel Message (VBCM)..............52
4.3.4.1. Message Format..................................52 4.3.4.1. Message Format..................................52
4.3.4.2. Semantics.......................................53 4.3.4.2. Semantics.......................................53
4.3.4.3. Timing Rules....................................54 4.3.4.3. Timing Rules....................................55
4.3.4.4. Handling of message in Mixer or Translator......55 4.3.4.4. Handling of message in Mixer or Translator......55
4.3.4.5. Remarks.........................................55 4.3.4.5. Remarks.........................................55
5. Congestion Control...........................................55 5. Congestion Control...........................................55
6. Security Considerations......................................56 6. Security Considerations......................................56
7. SDP Definitions..............................................57 7. SDP Definitions..............................................57
7.1. Extension of the rtcp-fb Attribute........................57 7.1. Extension of the rtcp-fb Attribute........................57
7.2. Offer-Answer..............................................58 7.2. Offer-Answer..............................................59
7.3. Examples..................................................59 7.3. Examples..................................................59
8. IANA Considerations..........................................62 8. IANA Considerations..........................................63
9. Contributors.................................................63 9. Contributors.................................................64
10. Acknowledgements.............................................63 10. Acknowledgements.............................................64
11. References...................................................64 11. References...................................................65
11.1. Normative references.....................................64 11.1. Normative references.....................................65
11.2. Informative references...................................64 11.2. Informative references...................................65
12. Authors' Addresses...........................................66 12. Authors' Addresses...........................................67
1. Introduction 1. Introduction
When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was
developed, the main emphasis lay in the efficient support of point- developed, the main emphasis lay in the efficient support of point-
to-point and small multipoint scenarios without centralized to-point and small multipoint scenarios without centralized
multipoint control. However, in practice, many small multipoint multipoint control. However, in practice, many small multipoint
conferences operate utilizing devices known as Multipoint Control conferences operate utilizing devices known as Multipoint Control
Units (MCUs). Long-standing experience of the conversational video Units (MCUs). Long-standing experience of the conversational video
conferencing industry suggests that there is a need for a few conferencing industry suggests that there is a need for a few
skipping to change at page 5, line 42 skipping to change at page 5, line 42
Some of the messages defined here are forward only, in that they do Some of the messages defined here are forward only, in that they do
not require an explicit notification to the message emitter that not require an explicit notification to the message emitter that
they have been received and/or indicating the message receiver's they have been received and/or indicating the message receiver's
actions. Other messages require a response, leading to a two way actions. Other messages require a response, leading to a two way
communication model that one could view as useful for control communication model that one could view as useful for control
purposes. However, it is not the intention of this memo to open up purposes. However, it is not the intention of this memo to open up
RTP Control Protocol (RTCP) to a generalized control protocol. All RTP Control Protocol (RTCP) to a generalized control protocol. All
mentioned messages have relatively strict real-time constraints, in mentioned messages have relatively strict real-time constraints, in
the sense that their value diminishes with increased delay. This the sense that their value diminishes with increased delay. This
makes the use of more traditional control protocol means, such as makes the use of more traditional control protocol means, such as
Session Initiation Protocol (SIP) re-INVITEs [RFC3261], undesirable Session Initiation Protocol (SIP) [RFC3261], undesirable when used
when used for the same purpose. Furthermore, all messages are of a for the same purpose. That is why this solution is recommended
very simple format that can be easily processed by an RTP/RTCP instead of "XML Schema for Media Control" [XML-MC], which uses SIP
Info to transfer XML messages with similar semantics to what are
defined in this memo. Furthermore, all messages are of a very
simple format that can be easily processed by an RTP/RTCP
sender/receiver. Finally, and most importantly, all messages relate sender/receiver. Finally, and most importantly, all messages relate
only to the RTP stream with which they are associated, and not to only to the RTP stream with which they are associated, and not to
any other property of a communication system. In particular, none any other property of a communication system. In particular, none
of them relate to the properties of the access links traversed by of them relate to the properties of the access links traversed by
the session. the session.
2. Definitions 2. Definitions
2.1. Glossary 2.1. Glossary
skipping to change at page 11, line 35 skipping to change at page 11, line 35
up, the mixer can reduce the maximum bit rate sent by endpoints up, the mixer can reduce the maximum bit rate sent by endpoints
to the lowest of all the accepted bit rates. As the lowest to the lowest of all the accepted bit rates. As the lowest
accepted bit rate changes due to endpoints joining and leaving or accepted bit rate changes due to endpoints joining and leaving or
due to network congestion, the mixer can adjust the limits at due to network congestion, the mixer can adjust the limits at
which endpoints can send their streams to match the new value. which endpoints can send their streams to match the new value.
The mixer then requests a new maximum bit rate, which is equal to The mixer then requests a new maximum bit rate, which is equal to
or less than the maximum bit rate negotiated at session setup for or less than the maximum bit rate negotiated at session setup for
a specific media stream, and the remote endpoint can respond with a specific media stream, and the remote endpoint can respond with
the actual bit rate that it can support. the actual bit rate that it can support.
The picture Basso, et al draws up covers most applications we The picture Basso et al draws up covers most applications we
foresee. However, we would like to extend the list with two foresee. However, we would like to extend the list with two
additional use cases: additional use cases:
7. Currently deployed congestion control algorithms (AIMD and TFRC 7. Currently deployed congestion control algorithms (AIMD and TFRC
[RFC3448]) probe for additional available capacity as long as [RFC3448]) probe for additional available capacity as long as
there is something to send. With congestion control algorithms there is something to send. With congestion control algorithms
using packet loss as the indication for congestion, this probing using packet loss as the indication for congestion, this probing
generally results in reduced media quality (often to a point generally results in reduced media quality (often to a point
where the distortion is large enough to make the media unusable), where the distortion is large enough to make the media unusable),
due to packet loss and increased delay. due to packet loss and increased delay.
skipping to change at page 12, line 33 skipping to change at page 12, line 33
well.) AVPF contains a mechanism for conveying such a message, well.) AVPF contains a mechanism for conveying such a message,
but did not specify for which codec and according to which syntax but did not specify for which codec and according to which syntax
the message should conform. Recently, the ITU-T finalized Rec. the message should conform. Recently, the ITU-T finalized Rec.
H.271 which (among other message types) also includes a feedback H.271 which (among other message types) also includes a feedback
message. It is expected that this feedback message will fairly message. It is expected that this feedback message will fairly
quickly enjoy wide support. Therefore, a mechanism to convey quickly enjoy wide support. Therefore, a mechanism to convey
feedback messages according to H.271 appears to be desirable. feedback messages according to H.271 appears to be desirable.
3.2. Using the Media Path 3.2. Using the Media Path
There are multiple reasons why we use the media path for the codec There are two reasons why we use the media path for the codec
control messages. control messages.
First, systems employing MCUs often separate the control and media First, systems employing MCUs often separate the control and media
processing parts. As these messages are intended for or generated processing parts. As these messages are intended for or generated
by the media part rather than the signaling part of the MCU, having by the media part rather than the signaling part of the MCU, having
them on the media path avoids transmission across interfaces and them on the media path avoids transmission across interfaces and
unnecessary control traffic between signaling and processing. If unnecessary control traffic between signaling and processing. If
the MCU is physically decomposed, the use of the media path avoids the MCU is physically decomposed, the use of the media path avoids
the need for media control protocol extensions (e.g. in MEGACO the need for media control protocol extensions (e.g. in MEGACO
[RFC3525]). [RFC3525]).
skipping to change at page 23, line 19 skipping to change at page 23, line 19
A media sender begins the session limited by the maximum media bit A media sender begins the session limited by the maximum media bit
rate and maximum packet rate negotiated in session signaling, if rate and maximum packet rate negotiated in session signaling, if
any. Note that this value may be negotiated for another protocol any. Note that this value may be negotiated for another protocol
layer than the one the participant uses in its TMMBR messages. Each layer than the one the participant uses in its TMMBR messages. Each
media receiver selects a reference protocol layer, forms an estimate media receiver selects a reference protocol layer, forms an estimate
of the overhead it is observing (or estimating it if no packets has of the overhead it is observing (or estimating it if no packets has
been seen yet) at that reference level, and determines the maximum been seen yet) at that reference level, and determines the maximum
total media bit rate it can accept, taking into account its own total media bit rate it can accept, taking into account its own
limitations and any transport path limitations of which it may be limitations and any transport path limitations of which it may be
aware. In case the current limitations are more restricting then aware. In case the current limitations are more restricting than
what was agreed on in the session signaling, the media receiver what was agreed on in the session signaling, the media receiver
reports its initial estimate of these two quantities to the media reports its initial estimate of these two quantities to the media
sender using a TMMBR message. Overall message traffic is reduced by sender using a TMMBR message. Overall message traffic is reduced by
the possibility of including tuples for multiple media senders in the possibility of including tuples for multiple media senders in
the same TMMBR message. the same TMMBR message.
The media sender applies an algorithm such as that specified in The media sender applies an algorithm such as that specified in
section 3.5.4.2 to select which of the tuples it has received are section 3.5.4.2 to select which of the tuples it has received are
most limiting (i.e. the bounding set as defined in section 2.2). It most limiting (i.e. the bounding set as defined in section 2.2). It
modifies its operation to stay within the feasible region (as modifies its operation to stay within the feasible region (as
defined in section 2.2), and also sends out a TMMBN notification to defined in section 2.2), and also sends out a TMMBN notification to
the media receivers indicating the selected bounding set. the media receivers indicating the selected bounding set. That
notification also indicates who was responsible for the tuples in
the bounding set, i.e. the "owner"(s) of the limitation. A session
participant that owns no tuple in the bounding set is called a "non-
owner".
If a media receiver does not own one of the tuples in the bounding If a media receiver does not own one of the tuples in the bounding
set reported by the TMMBN, it applies the same algorithm as the set reported by the TMMBN, it applies the same algorithm as the
media sender to determine if its current estimated (maximum total media sender to determine if its current estimated (maximum total
media bit rate, overhead) tuple would enter the bounding set if media bit rate, overhead) tuple would enter the bounding set if
known to the media sender. If so, it issues a TMMBR request known to the media sender. If so, it issues a TMMBR request
reporting the tuple value to the sender. Otherwise it takes no reporting the tuple value to the sender. Otherwise it takes no
action for the moment. Periodically, its estimated tuple values may action for the moment. Periodically, its estimated tuple values may
change or it may receive a new TMMBN. If so, it reapplies the change or it may receive a new TMMBN. If so, it reapplies the
algorithm to decide whether it needs to issue a TMMBR request. algorithm to decide whether it needs to issue a TMMBR request.
skipping to change at page 24, line 47 skipping to change at page 25, line 4
payloads is equal to the TMMBR reported bit rate minus the packet payloads is equal to the TMMBR reported bit rate minus the packet
rate used, multiplied by the TMMBR reported overhead converted to rate used, multiplied by the TMMBR reported overhead converted to
bits. As a result, when different bit rate/overhead combinations bits. As a result, when different bit rate/overhead combinations
need to be considered, the packet rate determines the correct need to be considered, the packet rate determines the correct
limitation. This is perhaps best explained by an example: limitation. This is perhaps best explained by an example:
Example: Example:
Receiver A: TMMBR_max total BR = 35 kbps, TMMBR_OH = 40 bytes Receiver A: TMMBR_max total BR = 35 kbps, TMMBR_OH = 40 bytes
Receiver B: TMMBR_max total BR = 40 kbps, TMMBR_OH = 60 bytes Receiver B: TMMBR_max total BR = 40 kbps, TMMBR_OH = 60 bytes
For a given packet rate (PR) the bit rate available for media For a given packet rate (PR) the bit rate available for media
payloads in RTP will be: payloads in RTP will be:
Max_net media_BR_A = TMMBR_max total BR_A - PR * TMMBR_OH_A * 8 ... Max_net media_BR_A =
(1) TMMBR_max total BR_A - PR * TMMBR_OH_A * 8 ... (1)
Max_net media_BR_B = TMMBR_max total BR_B - PR * TMMBR_OH_B * 8 ...
(2) Max_net media_BR_B =
TMMBR_max total BR_B - PR * TMMBR_OH_B * 8 ... (2)
For a PR = 20 these calculations will yield a Max_net media_BR_A = For a PR = 20 these calculations will yield a Max_net media_BR_A =
28600 bps and Max_net media_BR_B = 30400 bps, which suggests that 28600 bps and Max_net media_BR_B = 30400 bps, which suggests that
receiver A is the limiting one for this packet rate. However, at a receiver A is the limiting one for this packet rate. However, at a
certain PR there is a switchover point at which receiver B becomes certain PR there is a switchover point at which receiver B becomes
the limiting one. The switchover point can be identified by setting the limiting one. The switchover point can be identified by setting
Max_media_BR_A equal to Max_media_BR_B and breaking out PR: Max_media_BR_A equal to Max_media_BR_B and breaking out PR:
TMMBR_max total BR_A - TMMBR_max total BR_B TMMBR_max total BR_A - TMMBR_max total BR_B
PR = ------------------------------------------- ... (3) PR = ------------------------------------------- ... (3)
skipping to change at page 36, line 12 skipping to change at page 36, line 12
value in accordance with the expired draft. As there is value in accordance with the expired draft. As there is
sufficient numbering space available, we mark FMT=2 as sufficient numbering space available, we mark FMT=2 as
reserved so to avoid possible interoperability problems with reserved so to avoid possible interoperability problems with
any such early implementations. any such early implementations.
Available for assignment: Available for assignment:
0: unassigned 0: unassigned
5-30: unassigned 5-30: unassigned
The following subsection defines the formats of the FCI entries for The following subsection defines the formats of the Feedback Control
the TMMBR and TMMBN messages respectively and specify the associated Information (FCI) entries for the TMMBR and TMMBN messages
behaviour at the media sender and receiver. respectively and specify the associated behaviour at the media
sender and receiver.
4.2.1. Temporary Maximum Media Stream Bit Rate Request (TMMBR) 4.2.1. Temporary Maximum Media Stream Bit Rate Request (TMMBR)
The Temporary Maximum Media Stream Bit Rate Request is identified by The Temporary Maximum Media Stream Bit Rate Request is identified by
RTCP packet type value PT=RTPFB and FMT=3. RTCP packet type value PT=RTPFB and FMT=3.
The FCI field of a Temporary Maximum Media Stream Bit-Rate Request The FCI field of a Temporary Maximum Media Stream Bit-Rate Request
(TMMBR) message SHALL contain one or more FCI entries. (TMMBR) message SHALL contain one or more FCI entries.
4.2.1.1. Message Format 4.2.1.1. Message Format
skipping to change at page 37, line 8 skipping to change at page 37, line 8
MxTBR Exp (6 bits): The exponential scaling of the mantissa for MxTBR Exp (6 bits): The exponential scaling of the mantissa for
the maximum total media bit rate value. The value is an the maximum total media bit rate value. The value is an
unsigned integer [0..63]. unsigned integer [0..63].
MxTBR Mantissa (17 bits): The mantissa of the maximum total media MxTBR Mantissa (17 bits): The mantissa of the maximum total media
bit rate value as an unsigned integer. bit rate value as an unsigned integer.
Measured Overhead (9 bits): The measured average packet overhead Measured Overhead (9 bits): The measured average packet overhead
value in bytes. The measurement SHALL be done according value in bytes. The measurement SHALL be done according
to the description in section 4.2.1.2. The value is an to the description in section 4.2.1.2. The value is an
unsigned integer [0..512]. unsigned integer [0..511].
The maximum total media bit rate (MxTBR) value in bits per second is The maximum total media bit rate (MxTBR) value in bits per second is
calculated from the MxTBR exponent (exp) and mantissa in the calculated from the MxTBR exponent (exp) and mantissa in the
following way: following way:
MxTBR = mantissa * 2^exp MxTBR = mantissa * 2^exp
This allows for 17 bits of resolution in the range 0 to 131072*2^63 This allows for 17 bits of resolution in the range 0 to 131072*2^63
(approximately 1.2*10^24). (approximately 1.2*10^24).
skipping to change at page 39, line 26 skipping to change at page 39, line 28
media bit rate value, it SHALL wait before actually doing so, for a media bit rate value, it SHALL wait before actually doing so, for a
period long enough to allow a media receiver to respond to the TMMBN period long enough to allow a media receiver to respond to the TMMBN
if it determines that its tuple belongs in the bounding set. This if it determines that its tuple belongs in the bounding set. This
delay period is estimated by the formula: delay period is estimated by the formula:
2 * RTT + T_Dither_Max, 2 * RTT + T_Dither_Max,
where RTT is the longest round trip time known to the media sender where RTT is the longest round trip time known to the media sender
and T_Dither_Max is defined in section 3.4 of [RFC4585]. Even in and T_Dither_Max is defined in section 3.4 of [RFC4585]. Even in
point-to-point sessions a media sender MUST obey to the point-to-point sessions a media sender MUST obey to the
aforementioned rule, as it not guaranteed that a participant is able aforementioned rule, as it is not guaranteed that a participant is
to determine correctly whether all the sources are co-located in a able to determine correctly whether all the sources are co-located
single node, and are coordinated. in a single node, and are coordinated.
A TMMBN message SHALL be sent by the media sender at the earliest A TMMBN message SHALL be sent by the media sender at the earliest
possible point in time, in response to any TMMBR messages received possible point in time, in response to any TMMBR messages received
since the last sending of TMMBN. The TMMBN message indicates the since the last sending of TMMBN. The TMMBN message indicates the
calculated set of bounding tuples and the owners of those tuples at calculated set of bounding tuples and the owners of those tuples at
the time of the transmission of the message. the time of the transmission of the message.
An SSRC may time out according to the default rules for RTP session An SSRC may time out according to the default rules for RTP session
participants, i.e. the media sender has not received any RTP or RTCP participants, i.e. the media sender has not received any RTP or RTCP
packets from the owner for the last five regular reporting packets from the owner for the last five regular reporting
intervals. An SSRC may also explicitly leave the session, with the intervals. An SSRC may also explicitly leave the session, with the
participant indicating this through the transmission of an RTCP BYE participant indicating this through the transmission of an RTCP BYE
packet or using an external signaling channel. If the media sender packet or using an external signaling channel. If the media sender
determines that the owner of a tuple in the bounding set has left determines that the owner of a tuple in the bounding set has left
the session, the media sender shall transmit a new TMMBN containing the session, the media sender SHALL transmit a new TMMBN containing
the previously-determined set of bounding tuples but with the tuple the previously-determined set of bounding tuples but with the tuple
belonging to the departed owner removed. belonging to the departed owner removed.
A media sender MAY proactively initiate the equivalent to a TMMBR A media sender MAY proactively initiate the equivalent to a TMMBR
message to itself, when it is aware that its transmission path is message to itself, when it is aware that its transmission path is
more restrictive than the current limitations. As a result, a TMMBN more restrictive than the current limitations. As a result, a TMMBN
indicating the media source itself as the owner of a tuple is being indicating the media source itself as the owner of a tuple is being
sent, thereby avoiding unnecessary TMMBR messages from other sent, thereby avoiding unnecessary TMMBR messages from other
participants. However, like any other participant, when the media participants. However, like any other participant, when the media
sender becomes aware of changed limitations, it is required to sender becomes aware of changed limitations, it is required to
skipping to change at page 42, line 14 skipping to change at page 42, line 16
SSRC (32 bits): The SSRC value of the "owner" of this tuple. SSRC (32 bits): The SSRC value of the "owner" of this tuple.
MxTBR Exp (6 bits): The exponential scaling of the mantissa for MxTBR Exp (6 bits): The exponential scaling of the mantissa for
the maximum total media bit rate value. The value is an the maximum total media bit rate value. The value is an
unsigned integer [0..63]. unsigned integer [0..63].
MxTBR Mantissa (17 bits): The mantissa of the maximum total media MxTBR Mantissa (17 bits): The mantissa of the maximum total media
bit rate value as an unsigned integer. bit rate value as an unsigned integer.
Measured Overhead (9 bits): The measured average packet overhead Measured Overhead (9 bits): The measured average packet overhead
value in bytes represented as an unsigned integer. value in bytes represented as an unsigned integer
[0..511].
Thus, the FCI within the TMMBN message contains entries indicating Thus, the FCI within the TMMBN message contains entries indicating
the bounding tuples. For each tuple, the entry gives the owner by the bounding tuples. For each tuple, the entry gives the owner by
the SSRC, followed by the applicable maximum total media bit rate the SSRC, followed by the applicable maximum total media bit rate
and overhead value. and overhead value.
The length of the TMMBN message SHALL be set to 2+2*N where N is the The length of the TMMBN message SHALL be set to 2+2*N where N is the
number of TMMBN FCI entries. number of TMMBN FCI entries.
4.2.2.2. Semantics 4.2.2.2. Semantics
skipping to change at page 42, line 45 skipping to change at page 43, line 4
A TMMBN message SHALL be scheduled for transmission after the A TMMBN message SHALL be scheduled for transmission after the
reception of a TMMBR message with an FCI entry identifying this reception of a TMMBR message with an FCI entry identifying this
media sender. Only a single TMMBN SHALL be sent, even if more than media sender. Only a single TMMBN SHALL be sent, even if more than
one TMMBR message is received between the scheduling of the one TMMBR message is 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 bounding tuples and their owners at the TMMBN message indicates the bounding tuples and their owners at the
time of transmitting the message. The bounding tuples included time of transmitting the message. The bounding tuples included
SHALL be the set arrived at through application of the applicable SHALL be the set arrived at through application of the applicable
algorithm of section 3.5.4.2 or an equivalent, applied to the algorithm of section 3.5.4.2 or an equivalent, applied to the
previous bounding set if any and tuples received in TMMBR messages previous bounding set, if any, and tuples received in TMMBR messages
since the last TMMBN was transmitted. since the last TMMBN was transmitted.
The reception of a TMMBR message SHALL still result in the The reception of a TMMBR message SHALL still result in the
transmission of a TMMBN message even if, after application of the transmission of a TMMBN message even if, after application of the
algorithm, the newly reported TMMBR tuple is not accepted into the algorithm, the newly reported TMMBR tuple is not accepted into the
bounding set. In such a case the bounding tuples and their owners bounding set. In such a case the bounding tuples and their owners
are not changed, unless the TMMBR was from an owner of a tuple are not changed, unless the TMMBR was from an owner of a tuple
within the previously calculated bounding set. This procedure within the previously calculated bounding set. This procedure
allows session participants that did not see the last TMMBN message allows session participants that did not see the last TMMBN message
to get a correct view of this media sender's state. to get a correct view of this media sender's state.
As indicated in section 4.2.1.2, when a media sender determines that As indicated in section 4.2.1.2, when a media sender determines that
an "owner" of a bounding tuple has left the session, then that tuple an "owner" of a bounding tuple has left the session, then that tuple
is removed from the bounding set, and the media sender SHALL send a is removed from the bounding set, and the media sender SHALL send a
TMMBN message indicating the remaining bounding tuples. If there TMMBN message indicating the remaining bounding tuples. If there
are no remaining bounding tuples a TMMBN without any FCI SHALL be are no remaining bounding tuples a TMMBN without any FCI SHALL be
sent to indicate this. Without a remaining bounding tuple, the sent to indicate this. Without a remaining bounding tuple, the
maximum media bit rate and maximum packet rate negotiated in session maximum media bit rate and maximum packet rate negotiated in session
signaling, if any, apply. signaling, if any, apply.
.Note: if any media receivers remain in the session, this last Note: if any media receivers remain in the session, this last will
will be a temporary situation. The empty TMMBN will cause every be a temporary situation. The empty TMMBN will cause every
remaining media receiver to determine that its limitation belongs remaining media receiver to determine that its limitation belongs
in the bounding set and send a TMMBR in consequence. in the bounding set and send a TMMBR in consequence.
In unicast scenarios (i.e. where a single sender talks to a single In unicast scenarios (i.e. where a single sender talks to a single
receiver), the aforementioned algorithm to determine ownership receiver), the aforementioned algorithm to determine ownership
degenerates to the media receiver becoming the "owner" of the one degenerates to the media receiver becoming the "owner" of the one
bounding tuple as soon as the media receiver has issued the first bounding tuple as soon as the media receiver has issued the first
TMMBR message. TMMBR message.
4.2.2.3. Timing Rules 4.2.2.3. Timing Rules
skipping to change at page 54, line 8 skipping to change at page 54, line 20
The different types of feedback sub-messages carried in the VBCM are The different types of feedback sub-messages carried in the VBCM are
indicated by the "payloadType" as defined in [VBCM]. These sub- indicated by the "payloadType" as defined in [VBCM]. These sub-
message types are reproduced below for convenience. "payloadType", message types are reproduced below for convenience. "payloadType",
in ITU-T Rec. H.271 terminology, refers to the sub-type of the H.271 in ITU-T Rec. H.271 terminology, refers to the sub-type of the H.271
message and should not be confused with an RTP payload type. message and should not be confused with an RTP payload type.
Payload Message Content Payload Message Content
Type Type
-------------------------------------------------------------------- --------------------------------------------------------------------
0 One or more pictures without detected bit stream error 0 One or more pictures without detected bit stream error
mismatch mismatch
1 One or more pictures that are entirely or partially lost 1 One or more pictures that are entirely or partially lost
2 A set of blocks of one picture that is entirely or partially 2 A set of blocks of one picture that is entirely or partially
lost lost
3 CRC for one parameter set 3 CRC for one parameter set
4 CRC for all parameter sets of a certain type 4 CRC for all parameter sets of a certain type
5 A "reset" request indicating that the sender should completely 5 A "reset" request indicating that the sender should
completely
refresh the video bit stream as if no prior bit stream data refresh the video bit stream as if no prior bit stream data
had been received had been received
> 5 Reserved for future use by ITU-T > 5 Reserved for future use by ITU-T
Table 2: H.271 message types ("payloadTypes") Table 2: H.271 message types ("payloadTypes")
The bit string or the "payload" of a VBCM message is of variable The bit string or the "payload" of a VBCM message is of variable
length and is self-contained and coded in a variable length, binary length and is self-contained and coded in a variable length, 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.
skipping to change at page 65, line 7 skipping to change at page 66, line 7
Pictures," in Proc. Globcom'96, vol. 3, pp. 1503 - 1508, Pictures," in Proc. Globcom'96, vol. 3, pp. 1503 - 1508,
1996. 1996.
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
K. Norrman, "The Secure Real-time Transport Protocol K. Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004. (SRTP)", RFC 3711, March 2004.
[RFC2032] Turletti, T. and C. Huitema, "RTP Payload Format for [RFC2032] Turletti, T. and C. Huitema, "RTP Payload Format for
H.261 Video Streams", RFC 2032, October 1996. H.261 Video Streams", RFC 2032, October 1996.
[SAVPF] J. Ott, E. Carrara, "Extended Secure RTP Profile for [SAVPF] J. Ott, E. Carrara, "Extended Secure RTP Profile for
RTCP-based Feedback (RTP/SAVPF)," draft-ietf-avt- RTCP-based Feedback (RTP/SAVPF)," draft-ietf-avt-
profile-savpf-10.txt, February, 2007. profile-savpf-11.txt, February, 2007.
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor,
"Gateway Control Protocol Version 1", RFC 3525, June "Gateway Control Protocol Version 1", RFC 3525, June
2003. 2003.
[RFC3448] M. Handley, S. Floyd, J. Padhye, J. Widmer, "TCP [RFC3448] M. Handley, S. Floyd, J. Padhye, J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
[VBCM] ITU-T Rec. H.271, "Video Back Channel Messages", June [VBCM] ITU-T Rec. H.271, "Video Back Channel Messages", June
2006 2006
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth [RFC3890] Westerlund, M., "A Transport Independent Bandwidth
Modifier for the Session Description Protocol (SDP)", Modifier for the Session Description Protocol (SDP)",
RFC 3890, September 2004. RFC 3890, September 2004.
skipping to change at page 66, line 4 skipping to change at page 66, line 31
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC Parisis, "RTP Payload for Redundant Audio Data", RFC
2198, September 1997. 2198, September 1997.
[Topologies] M. Westerlund, and S. Wenger, "RTP Topologies", draft- [Topologies] M. Westerlund, and S. Wenger, "RTP Topologies", draft-
ietf-avt-topologies-06, work in progress, Aug 2007. ietf-avt-topologies-06, work in progress, Aug 2007.
[XML-MC] O. Levin, R. Even, P. Hagendorf, "XML Schema for Media
Control," draft-levin-mmusic-xml-media-control-11, work
in progress, July 2007.
12. Authors' Addresses 12. Authors' Addresses
Stephan Wenger Stephan Wenger
Nokia Corporation Nokia Corporation
975, Page Mill Road, 975, Page Mill Road,
Palo Alto,CA 94304 Palo Alto,CA 94304
USA USA
Phone: +1-650-862-7368 Phone: +1-650-862-7368
 End of changes. 31 change blocks. 
51 lines changed or deleted 58 lines changed or added

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