draft-ietf-avt-avpf-ccm-08.txt   draft-ietf-avt-avpf-ccm-09.txt 
Network Working Group Stephan Wenger Network Working Group Stephan Wenger
INTERNET-DRAFT Umesh Chandra INTERNET-DRAFT Umesh Chandra
Expires: January 2008 Nokia Expires: February 2008 Nokia
Intended Status: Proposed Standard Magnus Westerlund Intended Status: Proposed Standard Magnus Westerlund
Bo Burman Bo Burman
Ericsson Ericsson
July 6, 2007 August 1, 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-08.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 38 skipping to change at page 3, line 38
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
Operation.......................................31 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.....................................33 3.5.4.6. Reliability.....................................32
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 Translators46 4.3.1.4. Handling of FIR Message in Mixer and
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...49
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
skipping to change at page 9, line 50 skipping to change at page 9, line 50
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 topologies referred to throughout this memo are labeled
(consistently with [Topologies]) as follows: (consistently with [Topologies]) as follows:
Topo-Point-to-Point . . . . . Point-to-point communication Topo-Point-to-Point . . . . . Point-to-point communication
Topo-Multicast . . . . . . . Multicast communication Topo-Multicast . . . . . . . Multicast communication
Topo-Translator . . . . . . . Translator based Topo-Translator . . . . . . . Translator based
Topo-Mixer . . . . . . . . . Mixer based Topo-Mixer . . . . . . . . . Mixer based
Topo-Video-switch-MCU . . . . Video switching MCU, Topo-RTP-switch-MCU . . . . RTP stream switching MCU,
Topo-RTCP-terminating-MCU . . Mixer but terminating RTCP Topo-RTCP-terminating-MCU . . Mixer but terminating RTCP
3. Motivation 3. Motivation
This section discusses the motivation and usage of the different This section discusses the motivation and usage of the different
video and media control messages. The video control messages have video and media control messages. The video control messages have
been under discussion for a long time, and a requirement draft was been under discussion for a long time, and a requirement draft was
drawn up [Basso]. This draft has expired; however we quote relevant drawn up [Basso]. This draft has expired; however we quote relevant
sections of it to provide motivation and requirements. sections of it to provide motivation and requirements.
skipping to change at page 13, line 45 skipping to change at page 13, line 45
3.5. Feedback Messages 3.5. Feedback Messages
This section describes the semantics of the different feedback This section describes the semantics of the different feedback
messages and how they apply to the different use cases. messages and how they apply to the different use cases.
3.5.1. Full Intra Request Command 3.5.1. Full Intra Request Command
A Full Intra Request (FIR) Command, when received by the designated A Full Intra Request (FIR) Command, when received by the designated
media sender, requires that the media sender sends a Decoder Refresh media sender, requires that the media sender sends a Decoder Refresh
Point (see 2 Point (see 2.2) at the earliest opportunity. The evaluation of such
.2) at the earliest opportunity. The evaluation of such
opportunity includes the current encoder coding strategy and the opportunity includes the current encoder coding strategy and the
current available network resources. current available network resources.
FIR is also known as an "instantaneous decoder refresh request", FIR is also known as an "instantaneous decoder refresh request",
"fast video update request" or "video fast update request". "fast video update request" or "video fast update request".
Using a decoder refresh point implies refraining from using any Using a decoder refresh point implies refraining from using any
picture sent prior to that point as a reference for the encoding picture sent prior to that point as a reference for the encoding
process of any subsequent picture sent in the stream. For process of any subsequent picture sent in the stream. For
predictive media types that are not video, the analogue applies. predictive media types that are not video, the analogue applies.
skipping to change at page 15, line 26 skipping to change at page 15, line 26
outstanding at any time per media sender in the session. outstanding at any time per media sender in the session.
The receiver of FIR (i.e. the media sender) behaves in complementary The receiver of FIR (i.e. the media sender) behaves in complementary
fashion to ensure delivery of a decoder refresh point. If it fashion to ensure delivery of a decoder refresh point. If it
receives repetitions of the FIR more than 2*RTT after it has sent a receives repetitions of the FIR more than 2*RTT after it has sent a
decoder refresh point, it shall send a new decoder refresh point. decoder refresh point, it shall send a new decoder refresh point.
Two round trip times allow time for the decoder refresh point to Two round trip times allow time for the decoder refresh point to
arrive back to the requestor and for the end of repetitions of FIR arrive back to the requestor and for the end of repetitions of FIR
to reach and be detected by the media sender. to reach and be detected by the media sender.
An RTP mixer that receives an FIR from a media receiver is An RTP mixer or RTP switching MCU that receive a FIR from a media
responsible to ensure that a decoder refresh point is delivered to receiver is responsible to ensure that a decoder refresh point is
the requesting receiver. It may be necessary for the mixer to delivered to the requesting receiver. It may be necessary for the
generate FIR commands. From a reliability perspective, the two legs mixer/MCU to generate FIR commands. From a reliability perspective,
(FIR-requesting endpoint to mixer, and mixer to decoder refresh the two legs (FIR-requesting endpoint to mixer/MCU, and mixer/MCU to
point generating endpoint) are handled independently from each decoder refresh point generating endpoint) are handled independently
other. from each other.
3.5.2. Temporal Spatial Trade-off Request and Notification 3.5.2. Temporal Spatial Trade-off Request and Notification
The Temporal Spatial Trade-off Request (TSTR) instructs the video The Temporal Spatial Trade-off Request (TSTR) instructs the video
encoder to change its trade-off between temporal and spatial encoder to change its trade-off between temporal and spatial
resolution. Index values from 0 to 31 indicate monotonically a resolution. Index values from 0 to 31 indicate monotonically a
desire for higher frame rate. That is, a requester asking for an desire for higher frame rate. That is, a requester asking for an
index of 0 prefers a high quality and is willing to accept a low index of 0 prefers a high quality and is willing to accept a low
frame rate, whereas a requester asking for 31 wishes a high frame frame rate, whereas a requester asking for 31 wishes a high frame
rate, potentially at the cost of low spatial quality. rate, potentially at the cost of low spatial quality.
skipping to change at page 16, line 9 skipping to change at page 16, line 9
than the typical picture duration. See use case 3 for an example. than the typical picture duration. See use case 3 for an example.
The encoder decides whether and to what extent the request results The encoder decides whether and to what extent the request results
in a change of the trade-off. It returns a Temporal Spatial Trade- in a change of the trade-off. It returns a Temporal Spatial Trade-
Off Notification (TSTN) message to indicate the trade-off that it Off Notification (TSTN) message to indicate the trade-off that it
will use henceforth. will use henceforth.
TSTR and TSTN have been introduced primarily because it is believed TSTR and TSTN have been introduced primarily because it is believed
that control protocol mechanisms, e.g. a SIP re-invite, are too that control protocol mechanisms, e.g. a SIP re-invite, are too
heavyweight and too slow to allow for a reasonable user experience. heavyweight and too slow to allow for a reasonable user experience.
Consider, for example, a user interface where the remote user Consider, for example, a user interface where the remote user
selects the temporal/spatial trade-off with a slider (as it is selects the temporal/spatial trade-off with a slider. An immediate
common in state-of-the-art video conferencing systems). An feedback to any slider movement is required for a reasonable user
immediate feedback to any slider movement is required for a experience. A SIP re-INVITE [RFC3261] would require at least two
reasonable user experience. A SIP re-INVITE [RFC3261] would require round-trips more (compared to the TSTR/TSTN mechanism) and may
at least two round-trips more (compared to the TSTR/TSTN mechanism) involve proxies and other complex mechanisms. Even in a well-
and may involve proxies and other complex mechanisms. Even in a designed system, it could take a second or so until the new trade-
well-designed system, it could take a second or so until the new off is finally selected. Furthermore the use of RTCP solves the
trade-off is finally selected. Furthermore the use of RTCP solves multicast use case very efficiently.
the multicast use case very efficiently.
The use of TSTR and TSTN in multipoint scenarios is a non-trivial The use of TSTR and TSTN in multipoint scenarios is a non-trivial
subject, and can be achieved in many implementation-specific ways. subject, and can be achieved in many implementation-specific ways.
Problems stem from the fact that TSTRs will typically arrive Problems stem from the fact that TSTRs will typically arrive
unsynchronized, and may request different trade-off values for the unsynchronized, and may request different trade-off values for the
same stream and/or endpoint encoder. This memo does not specify a same stream and/or endpoint encoder. This memo does not specify a
translator's, mixer's or endpoint's reaction to the reception of a translator's, mixer's or endpoint's reaction to the reception of a
suggested trade-off as conveyed in the TSTR. We only require the suggested trade-off as conveyed in the TSTR. We only require the
receiver of a TSTR message to reply to it by sending a TSTN, receiver of a TSTR message to reply to it by sending a TSTN,
carrying the new trade-off chosen by its own criteria (which may or carrying the new trade-off chosen by its own criteria (which may or
may not be based on the trade-off conveyed by the TSTR). In other may not be based on the trade-off conveyed by the TSTR). In other
words, the trade-off sent in TSTR is a non-binding recommendation, words, the trade-off sent in TSTR is a non-binding recommendation,
nothing more. nothing more.
Four TSTR/TSTN scenarios need to be distinguished, based on the Three TSTR/TSTN scenarios need to be distinguished, based on the
topologies described in [Topologies]. The scenarios are described topologies described in [Topologies]. The scenarios are described
in the following sub-clauses. in the following sub-clauses.
3.5.2.1. Point-to-Point 3.5.2.1. Point-to-Point
In this most trivial case (Topo-Point-to-Point), the media sender In this most trivial case (Topo-Point-to-Point), the media sender
typically adjusts its temporal/spatial trade-off based on the typically adjusts its temporal/spatial trade-off based on the
requested value in TSTR, subject to its own capabilities. The TSTN requested value in TSTR, subject to its own capabilities. The TSTN
message conveys back the new trade-off value (which may be identical message conveys back the new trade-off value (which may be identical
to the old one if, for example, the sender is not capable of to the old one if, for example, the sender is not capable of
skipping to change at page 26, line 4 skipping to change at page 25, line 49
The basic idea of the algorithm is as follows. Each TMMBR tuple can The basic idea of the algorithm is as follows. Each TMMBR tuple can
be viewed as the equation of a straight line (cf. equations (1) and be viewed as the equation of a straight line (cf. equations (1) and
(2)) in a space where packet rate lies along the X-axis and maximum (2)) in a space where packet rate lies along the X-axis and maximum
bit rate lies along the Y-axis. The lower envelope of the set of bit rate lies along the Y-axis. The lower envelope of the set of
lines corresponding to the complete set of TMMR tuples, together lines corresponding to the complete set of TMMR tuples, together
with the X and Y axes, defines a polygon. Points lying within this with the X and Y axes, defines a polygon. Points lying within this
polygon are combinations of packet rate and bit rate that meet all polygon are combinations of packet rate and bit rate that meet all
of the TMMBR constraints. The highest feasible packet rate within of the TMMBR constraints. The highest feasible packet rate within
this region is the minimum of the rate at which the bounding polygon this region is the minimum of the rate at which the bounding polygon
meets the X-axis or the session maximum packet rate (SMAXPR) meets the X-axis or the session maximum packet rate (SMAXPR,
provided by signaling, if any. Typically a media sender will prefer measured in packets per second) provided by signaling, if any.
to operate at a lower rate than this theoretical maximum, so as to Typically a media sender will prefer to operate at a lower rate than
increase the rate at which actual media content reaches the this theoretical maximum, so as to increase the rate at which actual
receivers. The purpose of the algorithm is to distinguish the TMMBR media content reaches the receivers. The purpose of the algorithm
tuples constituting the bounding set and thus delineate the feasible is to distinguish the TMMBR tuples constituting the bounding set and
region, so that the media sender can select its preferred operating thus delineate the feasible region, so that the media sender can
point within that region select its preferred operating point within that region
Figure 1 below shows a bounding polygon formed by TMMBR tuples A and Figure 1 below shows a bounding polygon formed by TMMBR tuples A and
B. A third tuple C lies outside the bounding polygon and is B. A third tuple C lies outside the bounding polygon and is
therefore irrelevant in determining feasible tradeoffs between media therefore irrelevant in determining feasible tradeoffs between media
rate and packet rate. The line labeled ss..s represents the limit rate and packet rate. The line labeled ss..s represents the limit
on packet rate imposed by the session maximum packet rate (SMAXPR) on packet rate imposed by the session maximum packet rate (SMAXPR)
obtained by signaling during session setup. In Figure 1 the limit obtained by signaling during session setup. In Figure 1 the limit
determined by tuple B happens to be more restrictive than SMAXPR. determined by tuple B happens to be more restrictive than SMAXPR.
The situation could easily be the reverse, meaning that the bounding The situation could easily be the reverse, meaning that the bounding
polygon is terminated on the right by the vertical line representing polygon is terminated on the right by the vertical line representing
skipping to change at page 26, line 39 skipping to change at page 26, line 36
| a c s | a c s
| a bc s | a bc s
| a b c s | a b c s
| ab c s | ab c s
| Feasible b c s | Feasible b c s
| region ba s | region ba s
| b a s c | b a s c
| b s c | b s c
| b s a | b s a
|_____________________bs________ |_____________________bs________
+------------------------------> +------------------------------>____________
Packet rate Packet rate
Figure 1 - Geometric Interpretation of TMMBR Tuples Figure 1 - Geometric Interpretation of TMMBR Tuples
Note that the slopes of the lines making up the bounding polygon are Note that the slopes of the lines making up the bounding polygon are
increasingly negative as one moves in the direction of increasing increasingly negative as one moves in the direction of increasing
packet rate. Note also that with slight rearrangement, equations packet rate. Note also that with slight rearrangement, equations
(1) and (2) have the canonical form: (1) and (2) have the canonical form:
skipping to change at page 35, line 44 skipping to change at page 35, line 44
Assigned in AVPF [RFC4585]: Assigned in AVPF [RFC4585]:
1: Generic NACK 1: Generic NACK
31: reserved for future expansion of the identifier number 31: reserved for future expansion of the identifier number
space space
Assigned in this memo: Assigned in this memo:
2: reserved (see note below) 2: reserved (see note below)
3: Temporary Maximum Media Stream Bit Rate Request (TMMBR) 3: Temporary Maximum Media Stream Bit Rate Request (TMMBR)
4: Temporary Maximum Media Stream Bit Rate Notification (TMMBN) 4: Temporary Maximum Media Stream Bit Rate Notification
(TMMBN)
Note: early drafts of AVPF [RFC4585] reserved FMT=2 for a Note: early drafts of AVPF [RFC4585] reserved FMT=2 for a
code point that has later been removed. It has been pointed code point that has later been removed. It has been pointed
out that there may be implementations in the field using this out that there may be implementations in the field using this
value in accordance with the expired draft. As there is value in accordance with the expired 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:
skipping to change at page 39, line 24 skipping to change at page 39, line 24
If the media sender concludes that it can increase the maximum total If the media sender concludes that it can increase the maximum total
media bit rate value, it SHALL wait before actually doing so, for a media bit rate value, it SHALL wait before actually doing so, for a
period long enough to allow a media receiver to respond to the TMMBN period long enough to allow a media receiver to respond to the TMMBN
if it determines that its tuple belongs in the bounding set. This if it determines that its tuple belongs in the bounding set. This
delay period is estimated by the formula: delay period is estimated by the formula:
2 * RTT + T_Dither_Max, 2 * RTT + T_Dither_Max,
where RTT is the longest round trip time known to the media sender where RTT is the longest round trip time known to the media sender
and T_Dither_Max is defined in section 3.4 of [RFC4585]. 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
aforementioned rule, as it not guaranteed that a participant is able
to determine correctly whether all the sources are co-located 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
skipping to change at page 40, line 36 skipping to change at page 40, line 39
the transmission of another TMMBN. the transmission of another TMMBN.
c) If multiple competing TMMBR messages are sent by different c) If multiple competing TMMBR messages are sent by different
session participants, then the algorithm can be applied taking session participants, then the algorithm can be applied taking
all of these messages into account, and the resulting TMMBN all of these messages into account, and the resulting TMMBN
provides the participants with an updated view of how their provides the participants with an updated view of how their
tuples compare with the bounded set. tuples compare with the bounded set.
d) If more than one session participant happens to send TMMBR d) If more than one session participant happens to send TMMBR
messages at the same time and with the same tuple component messages at the same time and with the same tuple component
values, it does not matter which if either tuple is taken into values, it does not matter which of those tuples is taken into
the bounding set. The losing session participant will determine the bounding set. The losing session participant will determine,
after applying the algorithm that its tuple does not enter the after applying the algorithm, that its tuple does not enter the
bounding set, and will therefore stop sending its TMMBR request. bounding set, and will therefore stop sending its TMMBR request.
It is important to consider the security risks involved with faked It is important to consider the security risks involved with faked
TMMBRs. See the security considerations in Section 6. TMMBRs. See the security considerations in Section 6.
As indicated already, the feedback messages may be used in both As indicated already, the feedback messages may be used in both
multicast and unicast sessions in any of the specified topologies. multicast and unicast sessions in any of the specified topologies.
However, for sessions with a large number of participants, using the However, for sessions with a large number of participants, using the
lowest common denominator, as required by this mechanism, may not be lowest common denominator, as required by this mechanism, may not be
the most suitable course of action. Large sessions may need to the most suitable course of action. Large sessions may need to
skipping to change at page 43, line 14 skipping to change at page 43, line 19
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. sent to indicate this. Without a remaining bounding tuple, the
maximum media bit rate and maximum packet rate negotiated in session
signaling, if any, apply.
Note: if any media receivers remain in the session, this last will .Note: if any media receivers remain in the session, this last
be a temporary situation. The empty TMMBN will cause every will 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 45, line 38 skipping to change at page 45, line 38
The semantics of this feedback message is independent of the RTP The semantics of this feedback message is independent of the RTP
payload type. payload type.
4.3.1.2. Semantics 4.3.1.2. Semantics
Within the common packet header for feedback messages (as defined in Within the common packet header for feedback messages (as defined in
section 6.1 of [RFC4585]), the "SSRC of the packet sender" field section 6.1 of [RFC4585]), the "SSRC of the packet sender" field
indicates the source of the request, and the "SSRC of media source" indicates the source of the request, and the "SSRC of media source"
is not used and SHALL be set to 0. The SSRCs of the media senders is not used and SHALL be set to 0. The SSRCs of the media senders
to which the FIR command applies are in the corresponding FCI to which the FIR command applies are in the corresponding FCI
entries. A TSTR message MAY contain requests to multiple media entries. A FIR message MAY contain requests to multiple media
senders, using one FCI entry per target media sender. senders, using one FCI entry per target media sender.
Upon reception of FIR, the encoder MUST send a decoder refresh point Upon reception of FIR, the encoder MUST send a decoder refresh point
(see section 2.2) as soon as possible. (see section 2.2) as soon as possible.
The sender MUST consider congestion control as outlined in section The sender MUST consider congestion control as outlined in section
5, which MAY restrict its ability to send a decoder refresh point 5, which MAY restrict its ability to send a decoder refresh point
quickly. quickly.
FIR SHALL NOT be sent as a reaction to picture losses -- it is FIR SHALL NOT be sent as a reaction to picture losses -- it is
skipping to change at page 51, line 5 skipping to change at page 51, line 4
Notification is depicted in Figure 6. The length of the TSTN Notification is depicted in Figure 6. The length of the TSTN
message MUST be set to 2+2*N, where N is the number of FCI entries. message MUST be set to 2+2*N, where N is the number of FCI entries.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC | | SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved | Index | | Seq nr. | Reserved | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 - Syntax of the TSTN Figure 6 - Syntax of the TSTN
SSRC (32 bits): The SSRC of the source of the TSTR request which SSRC (32 bits): The SSRC of the source of the TSTR request which
resulted in this Notification. resulted in this Notification.
Seq. nr (8 bits): The sequence number value from the TSTN request Seq. nr (8 bits): The sequence number value from the TSTR request
that is being acknowledged. that is being acknowledged.
Reserved (19 bits): All bits SHALL be set to 0 by the sender and Reserved (19 bits): All bits SHALL be set to 0 by the sender and
SHALL be ignored on reception. SHALL be ignored on reception.
Index (5 bits): The trade-off value the media sender is using Index (5 bits): The trade-off value the media sender is using
henceforth. henceforth.
Informative note: The returned trade-off value (Index) may differ Informative note: The returned trade-off value (Index) may differ
from the requested one, for example in cases where a media encoder from the requested one, for example in cases where a media encoder
skipping to change at page 53, line 40 skipping to change at page 53, line 40
4.3.4.2. Semantics 4.3.4.2. Semantics
The "payload" of the VBCM indication carries different types of The "payload" of the VBCM indication carries different types of
codec-specific, feedback information. The type of feedback codec-specific, feedback information. The type of feedback
information can be classified as a 'status report' (such as an information can be classified as a 'status report' (such as an
indication that a bit stream was received without errors, or that a indication that a bit stream was received without errors, or that a
partial or complete picture or block was lost) or 'update requests' partial or complete picture or block was lost) or 'update requests'
(such as complete refresh of the bit stream). (such as complete refresh of the bit stream).
Note: There are possible overlaps between the VBCM sub- Note: There are possible overlaps between the VBCM sub-
messages and CCM/AVPF feedback messages, such FIR. Please messages and CCM/AVPF feedback messages, such as FIR. Please
see section 3.5.3 for further discussion. see section 3.5.3 for further discussion.
The different types of feedback sub-messages carried in the VBCM are The different types of feedback sub-messages carried in the VBCM are
indicated by the "payloadType" as defined in [VBCM]. These sub- indicated by the "payloadType" as defined in [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
skipping to change at page 55, line 16 skipping to change at page 55, line 16
The handling of VBCM in a mixer or translator is sub-message type The handling of VBCM in a mixer or translator is sub-message type
dependent. dependent.
4.3.4.5. Remarks 4.3.4.5. Remarks
Please see section 3.5.3 for a discussion of the usage of H.271 Please see section 3.5.3 for a discussion of the usage of H.271
messages and messages defined in AVPF [RFC4585] and this memo with messages and messages defined in AVPF [RFC4585] and this memo with
similar functionality. similar functionality.
Note: There has been some discussion whether the payload type Note: There has been some discussion whether the RTP payload type
field in this message is needed. It will be needed if there is field in this message is needed. It will be needed if there is
potentially more than one VBCM-capable RTP payload type in the potentially more than one VBCM-capable RTP payload type in the
same session, and the semantics of a given VBCM message changes same session, and the semantics of a given VBCM message changes
between payload types. For example, the picture identification between payload types. For example, the picture identification
mechanism in messages of H.271 type 0 is fundamentally different mechanism in messages of H.271 type 0 is fundamentally different
between H.263 and H.264 (although both use the same syntax). between H.263 and H.264 (although both use the same syntax).
Therefore, the payload field is justified here. There was a Therefore, the payload field is justified here. There was a
further comment that for TSTS and FIR such a need does not exist, further comment that for TSTR and FIR such a need does not exist,
because the semantics of TSTS and FIR are either loosely enough because the semantics of TSTR and FIR are either loosely enough
defined, or generic enough, to apply to all video payloads defined, or generic enough, to apply to all video payloads
currently in existence/envisioned. currently in existence/envisioned.
5. Congestion Control 5. Congestion Control
The correct application of the AVPF [RFC4585] timing rules prevents The correct application of the AVPF [RFC4585] timing rules prevents
the network from being flooded by feedback messages. Hence, the network from being flooded by feedback messages. Hence,
assuming a correct implementation and configuration, the RTCP assuming a correct implementation and configuration, the RTCP
channel cannot break its bit rate commitment and introduce channel cannot break its bit rate commitment and introduce
congestion. congestion.
skipping to change at page 58, line 9 skipping to change at page 58, line 9
In this document we define a new feedback value "ccm" which In this document we define a new feedback value "ccm" which
indicates the support of codec control using RTCP feedback messages. indicates the support of codec control using RTCP feedback messages.
The "ccm" feedback value SHOULD be used with parameters that The "ccm" feedback value SHOULD be used with parameters that
indicate the specific codec control commands supported. In this indicate the specific codec control commands supported. In this
draft we define four such parameters, namely: draft we define four such parameters, namely:
o "fir" indicates support of the Full Intra Request (FIR). o "fir" indicates support of the Full Intra Request (FIR).
o "tmmbr" indicates support of the Temporary Maximum Media Stream o "tmmbr" indicates support of the Temporary Maximum Media Stream
Bit Rate Request/Notification (TMMBR/TMMBN). It has an Bit Rate Request/Notification (TMMBR/TMMBN). It has an
optional sub parameter to indicate the session maximum packet optional sub parameter to indicate the session maximum packet
rate to be used. If not included this defaults to infinity. rate (measured in packets per second) to be used. If not
included this defaults to infinity.
o "tstr" indicates support of the Temporal-Spatial Trade-off o "tstr" indicates support of the Temporal-Spatial Trade-off
Request/Notification (TSTR/TSTN). Request/Notification (TSTR/TSTN).
O "vbcm" indicates support of H.271 video back channel messages O "vbcm" indicates support of H.271 video back channel messages
(VBCM). It has zero or more subparameters identifying the (VBCM). It has zero or more subparameters identifying the
supported H.271 "payloadType" values. supported H.271 "payloadType" values.
In the ABNF for rtcp-fb-val defined in [RFC4585], there is a In the ABNF for rtcp-fb-val defined in [RFC4585], there is a
placeholder called rtcp-fb-id to define new feedback types. "ccm" placeholder called rtcp-fb-id to define new feedback types. "ccm"
is defined as a new feedback type in this document and the ABNF for is defined as a new feedback type in this document and the ABNF for
the parameters for ccm are defined here (please refer to section 4.2 the parameters for ccm are defined here (please refer to section 4.2
skipping to change at page 58, line 45 skipping to change at page 58, line 46
subMessageType = 1*8DIGIT subMessageType = 1*8DIGIT
byte-string = <as defined in section 4.2 of [RFC4585] > byte-string = <as defined in section 4.2 of [RFC4585] >
MaxPacketRateValue = 1*15DIGIT MaxPacketRateValue = 1*15DIGIT
7.2. Offer-Answer 7.2. Offer-Answer
The Offer/Answer [RFC3264] implications for codec control protocol The Offer/Answer [RFC3264] implications for codec control protocol
feedback messages are similar to those described in [RFC4585]. The feedback messages are similar to those described in [RFC4585]. The
offerer MAY indicate the capability to support selected codec offerer MAY indicate the capability to support selected codec
commands and indications. The answerer MUST remove all ccm commands and indications. The answerer MUST remove all ccm
parameters that it does not understand or does not wish to use in parameters corresponding to the CCM messages that it does not wish
this particular media session. The answerer MUST NOT add new ccm to support in this particular media session (for example because it
parameters in addition to what has been offered. The answer is does not implement the message in question, or because its
binding for the media session and both offerer and answerer MUST application logic suggests the support of the message adds no
only use feedback messages negotiated in this way. value). The answerer MUST NOT add new ccm parameters in addition to
what has been offered. The answer is binding for the media session
and both offerer and answerer MUST NOT use any feedback messages
other than what both sides have explicitly indicated as being
supported. In others words only the joint subset of CCM parameters
from the offer and answer may be used.
Note, that including a CCM parameter in an offer or answer indicates
that the party (offerer or answerer) is at least capable of
receiving the corresponding CCM message(s) and act upon them. In
cases when the reception of a negotiated CCM messages mandates the
party to respond with another CCM message, it must also have that
capability. Although it is not mandated to initiate CCM messages of
any negotiated type, it is generally expected that an party will
initiate CCM messages when appropriate.
The session maximum packet rate parameter part of the TMMBR The session maximum packet rate parameter part of the TMMBR
indication is declarative and everyone SHALL use the highest value indication is declarative and everyone SHALL use the highest value
indicated in a response. If the session maximum packet rate indicated in a response. If the session maximum packet rate
parameter is not present in an offer it SHALL NOT be included by the parameter is not present in an offer it SHALL NOT be included by the
answerer. answerer.
7.3. Examples 7.3. Examples
Example 1: The following SDP describes a point-to-point video call Example 1: The following SDP describes a point-to-point video call
skipping to change at page 65, line 30 skipping to change at page 65, line 30
2006. 2006.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC Parisis, "RTP Payload for Redundant Audio Data", RFC
2198, September 1997. 2198, September 1997.
[Topologies] M. Westerlund, and S. Wenger, "RTP Topologies", draft- [Topologies] M. Westerlund, and S. Wenger, "RTP Topologies", draft-
ietf-avt-topologies-04, work in progress, Feb 2007. ietf-avt-topologies-06, work in progress, Aug 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. 26 change blocks. 
56 lines changed or deleted 77 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/