draft-ietf-avt-avpf-ccm-05.txt   draft-ietf-avt-avpf-ccm-06.txt 
Network Working Group Stephan Wenger Network Working Group Stephan Wenger
INTERNET-DRAFT Umesh Chandra INTERNET-DRAFT Umesh Chandra
Expires: October 2007 Nokia Expires: October 2007 Nokia
Magnus Westerlund Intended Status: Proposed Standard Magnus Westerlund
Bo Burman Bo Burman
Ericsson Ericsson
May 14, 2007 May 28, 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-05.txt> draft-ietf-avt-avpf-ccm-06.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 51 skipping to change at page 3, line 51
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....................................40 4.2.1.3. Timing Rules....................................40
4.2.1.4. Handling in Translator and Mixers...............40 4.2.1.4. Handling in Translator and Mixers...............40
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.......................................41 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....................................47 4.3.1.3. Timing Rules....................................47
4.3.1.4. Handling of FIR Message in Mixer and 4.3.1.4. Handling of FIR Message in Mixer and
Translators.................................... 47 Translators.....................................47
4.3.1.5. Remarks.........................................47 4.3.1.5. Remarks.........................................47
4.3.2. Temporal-Spatial Trade-off Request (TSTR)............47 4.3.2. Temporal-Spatial Trade-off Request (TSTR)............47
4.3.2.1. Message Format..................................47 4.3.2.1. Message Format..................................48
4.3.2.2. Semantics.......................................48 4.3.2.2. Semantics.......................................48
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.........................................49 4.3.2.5. Remarks.........................................49
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.......................................50 4.3.3.2. Semantics.......................................51
4.3.3.3. Timing Rules....................................51 4.3.3.3. Timing Rules....................................51
4.3.3.4. Handling of TSTN in Mixer and Translators.......51 4.3.3.4. Handling of TSTN in Mixer and Translators.......51
4.3.3.5. Remarks.........................................51 4.3.3.5. Remarks.........................................51
4.3.4. H.271 Video Back Channel Message (VBCM)..............51 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.......................................52 4.3.4.2. Semantics.......................................53
4.3.4.3. Timing Rules....................................54 4.3.4.3. Timing Rules....................................54
4.3.4.4. Handling of message in Mixer or Translator......54 4.3.4.4. Handling of message in Mixer or Translator......54
4.3.4.5. Remarks.........................................54 4.3.4.5. Remarks.........................................54
5. Congestion Control.............................................54 5. Congestion Control.............................................55
6. Security Considerations........................................55 6. Security Considerations........................................55
7. SDP Definitions................................................56 7. SDP Definitions................................................56
7.1. Extension of the rtcp-fb Attribute........................56 7.1. Extension of the rtcp-fb Attribute........................56
7.2. Offer-Answer..............................................58 7.2. Offer-Answer..............................................58
7.3. Examples..................................................58 7.3. Examples..................................................58
8. IANA Considerations............................................61 8. IANA Considerations............................................62
9. Acknowledgements...............................................62 9. Acknowledgements...............................................63
10. References....................................................63 10. References....................................................64
10.1. Normative references.....................................63 10.1. Normative references.....................................64
10.2. Informative references...................................63 10.2. Informative references...................................64
11. Authors' Addresses............................................64 11. Authors' Addresses............................................66
1.1. Introduction 1.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 20, line 48 skipping to change at page 20, line 48
A receiver, translator or mixer uses the Temporary Maximum Media A receiver, translator or mixer uses the Temporary Maximum Media
Stream Bit Rate Request (TMMBR, "timber") to request a sender to Stream Bit Rate Request (TMMBR, "timber") to request a sender to
limit the maximum bit rate for a media stream (see 2.2) to, or below, limit the maximum bit rate for a media stream (see 2.2) to, or below,
the provided value. The Temporary Maximum Media Stream Bit Rate the provided value. The Temporary Maximum Media Stream Bit Rate
Notification (TMMBN) contains the media sender's current view of the Notification (TMMBN) contains the media sender's current view of the
most limiting subset of the TMMBR-defined limits it has received, to most limiting subset of the TMMBR-defined limits it has received, to
help the participants to suppress TMMBR requests that would not help the participants to suppress TMMBR requests that would not
further restrict the media sender. The primary usage for the further restrict the media sender. The primary usage for the
TMMBR/TMMBN messages is in a scenario with an MCU or mixer (use case TMMBR/TMMBN messages is in a scenario with an MCU or mixer (use case
6), corresponding to Topo-Translator or Topo-Mixer, but also to Topo- 6), corresponding to Topo-Translator or Topo-Mixer, but also to
Point-to-Point. Topo-Point-to-Point.
Each temporary limitation on the media stream is expressed as a Each temporary limitation on the media stream is expressed as a
tuple. The first component of the tuple is the maximum total media tuple. The first component of the tuple is the maximum total media
bit rate (as defined in section 2.2) that the media receiver is bit rate (as defined in section 2.2) that the media receiver is
currently prepared to accept for this media stream. The second currently prepared to accept for this media stream. The second
component is the per-packet overhead that the media receiver has component is the per-packet overhead that the media receiver has
observed for this media stream at its chosen reference protocol observed for this media stream at its chosen reference protocol
layer. layer.
As indicated in section 2.2, the overhead as observed by the sender As indicated in section 2.2, the overhead as observed by the sender
skipping to change at page 26, line 11 skipping to change at page 26, line 11
B. A third tuple C lies outside the bounding polygon and is therefore B. A third tuple C lies outside the bounding polygon and is therefore
irrelevant in determining feasible tradeoffs between media rate and irrelevant in determining feasible tradeoffs between media rate and
packet rate. The line labeled ss..s represents the limit on packet packet rate. The line labeled ss..s represents the limit on packet
rate imposed by the session maximum packet rate (SMAXPR) obtained by rate imposed by the session maximum packet rate (SMAXPR) obtained by
signaling during session setup. In Figure 1 the limit determined by signaling during session setup. In Figure 1 the limit determined by
tuple B happens to be more restrictive than SMAXPR. The situation tuple B happens to be more restrictive than SMAXPR. The situation
could easily be the reverse, meaning that the bounding polygon is could easily be the reverse, meaning that the bounding polygon is
terminated on the right by the vertical line representing the SMAXPR terminated on the right by the vertical line representing the SMAXPR
constraint. constraint.
^ Net ^
|a c b s Media|a c b s
Bit | a c b s Bit | a c b s
Rate | a c b s Rate | a c b s
| a cb s | a cb s
| 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 (1) packet rate. Note also that with slight rearrangement, equations (1)
and (2) have the canonical form: and (2) have the canonical form:
skipping to change at page 27, line 24 skipping to change at page 27, line 24
overhead value, the one with higher maximum total media bit rate overhead value, the one with higher maximum total media bit rate
value cannot be part of the bounding set and can be set aside. value cannot be part of the bounding set and can be set aside.
Two further observations complete the algorithm. Obviously, moving Two further observations complete the algorithm. Obviously, moving
from the left, the successive corners of the bounding polygon (i.e. from the left, the successive corners of the bounding polygon (i.e.
the intersection points between successive pairs of sides) lie at the intersection points between successive pairs of sides) lie at
successively higher packet rates. On the other hand, again moving successively higher packet rates. On the other hand, again moving
from the left, each successive line making up the bounding set from the left, each successive line making up the bounding set
crosses the X-axis at a lower packet rate. crosses the X-axis at a lower packet rate.
The complete algorithm can now be specified. The algorithm works The complete algorithm can now be specified. The algorithm works with
with two lists of TMMBR tuples, the candidate list X and the selected two lists of TMMBR tuples, the candidate list X and the selected
list Y, both ordered by increasing overhead value. The algorithm list Y, both ordered by increasing overhead value. The algorithm
terminates when all members of X have been discarded or removed for terminates when all members of X have been discarded or removed for
processing. Membership of the selected list Y is probationary until processing. Membership of the selected list Y is probationary until
the algorithm is complete. Each member of the selected list is the algorithm is complete. Each member of the selected list is
associated with an intersection value, which is the packet rate at associated with an intersection value, which is the packet rate at
which the line corresponding to that TMMBR tuple intersects with the which the line corresponding to that TMMBR tuple intersects with the
line corresponding to the previous TMMBR tuple in the selected list. line corresponding to the previous TMMBR tuple in the selected list.
Each member of the selected list is also associated with a maximum Each member of the selected list is also associated with a maximum
packet rate value, which is the lesser of the session maximum packet packet rate value, which is the lesser of the session maximum packet
rate SMAXPR (if any) and the packet rate at which the line rate SMAXPR (if any) and the packet rate at which the line
skipping to change at page 27, line 50 skipping to change at page 27, line 50
Initial Algorithm Initial Algorithm
This algorithm is used by the media sender when it has received one This algorithm is used by the media sender when it has received one
or more TMMBR requests and before it has determined a bounding set or more TMMBR requests and before it has determined a bounding set
for the first time. for the first time.
1. Sort the TMMBR tuples by order of increasing overhead. This is 1. Sort the TMMBR tuples by order of increasing overhead. This is
the initial candidate list X. the initial candidate list X.
2. When multiple tuples in the candidate list have the same 2. When multiple tuples in the candidate list have the same overhead
overhead value, discard all but the one with the lowest maximum value, discard all but the one with the lowest maximum total media
total media bit rate value. bit rate value.
3. Select and remove from the candidate list the TMMBR tuple with the 3. Select and remove from the candidate list the TMMBR tuple with the
lowest maximum total media bit rate value. If there is more than lowest maximum total media bit rate value. If there is more than
one tuple with that value, choose the one with the highest one tuple with that value, choose the one with the highest
overhead value. This is the first member of the selected list Y. overhead value. This is the first member of the selected list Y.
Set its intersection value equal to zero. Calculate its maximum Set its intersection value equal to zero. Calculate its maximum
packet rate as the minimum of SMAXPR (if available) and the value packet rate as the minimum of SMAXPR (if available) and the value
obtained from the following formula, which is the packet rate at obtained from the following formula, which is the packet rate at
which the corresponding line crosses the X-axis. which the corresponding line crosses the X-axis.
skipping to change at page 28, line 42 skipping to change at page 28, line 42
Note that the choice of the initial member of the selected list Y Note that the choice of the initial member of the selected list Y
in step 3 guarantees that the selected list will never be emptied in step 3 guarantees that the selected list will never be emptied
by this process, meaning that the algorithm must eventually (if by this process, meaning that the algorithm must eventually (if
not immediately) fall through to the step 8. not immediately) fall through to the step 8.
8. (This step is reached when the calculated PR value of the current 8. (This step is reached when the calculated PR value of the current
candidate is greater than the intersection value of the current candidate is greater than the intersection value of the current
last member of the selected list Y.) If the calculated value PR last member of the selected list Y.) If the calculated value PR
of the current candidate is lower than the maximum packet rate of the current candidate is lower than the maximum packet rate
associated with the last tuple in the selected list, add the associated with the last tuple in the selected list, add the
current candidate tuple to the end of the selected list. Store current candidate tuple to the end of the selected list. Store PR
PR as its intersection value. Calculate its maximum packet rate as its intersection value. Calculate its maximum packet rate as
as the lesser of SMAXPR (if available) and the maximum packet the lesser of SMAXPR (if available) and the maximum packet rate
rate calculated using equation (4). calculated using equation (4).
9. If any tuples remain in the candidate list, go back to step 5. 9. If any tuples remain in the candidate list, go back to step 5.
Incremental Algorithm Incremental Algorithm
The previous algorithm covered the initial case, where no selected The previous algorithm covered the initial case, where no selected
list had previously been created. It also applied only to the media list had previously been created. It also applied only to the media
sender. When a previously-created selected list is available at sender. When a previously-created selected list is available at
either the media sender or media receiver, two other cases can be either the media sender or media receiver, two other cases can be
considered: considered:
o when a TMMBR tuple not currently in the selected list is a o when a TMMBR tuple not currently in the selected list is a
candidate for addition; candidate for addition;
o when the values change in a TMMBR tuple currently in the o when the values change in a TMMBR tuple currently in the
selected list. selected list.
At the media receiver these cases correspond respectively to those At the media receiver these cases correspond respectively to those of
of the non-owner and owner of a tuple in the TMMBN-reported bounding the non-owner and owner of a tuple in the TMMBN-reported bounding
set. set.
In either case, the process of updating the selected list to take In either case, the process of updating the selected list to take
account of the new/changed tuple can use the basic algorithm account of the new/changed tuple can use the basic algorithm
described above, with the modification that the initial candidate described above, with the modification that the initial candidate set
set consists only of the existing selected list and the new or consists only of the existing selected list and the new or changed
changed tuple. Some further optimization is possible (beyond tuple. Some further optimization is possible (beyond starting with a
starting with a reduced candidate set) by taking advantage of the reduced candidate set) by taking advantage of the following
following observations. observations.
The first observation is that if the new/changed candidate becomes The first observation is that if the new/changed candidate becomes
part of the new selected list, the result may be to cause zero or part of the new selected list, the result may be to cause zero or
more other tuples to be dropped from the list. However, if more than more other tuples to be dropped from the list. However, if more than
one other tuple is dropped, the dropped tuples will be consecutive. one other tuple is dropped, the dropped tuples will be consecutive.
This can be confirmed geometrically by visualizing a new line that This can be confirmed geometrically by visualizing a new line that
cuts off a series of segments from the previously-existing bounding cuts off a series of segments from the previously-existing bounding
polygon. The cut-off segments are connected one to the next, the polygon. The cut-off segments are connected one to the next, the
geometric equivalent of consecutive tuples in a list ordered by geometric equivalent of consecutive tuples in a list ordered by
overhead value. Beyond the dropped set in either direction all of overhead value. Beyond the dropped set in either direction all of
skipping to change at page 30, line 16 skipping to change at page 30, line 16
selected list, preserving their order. selected list, preserving their order.
o If the new candidate has survived steps 2 and 4 and has not o If the new candidate has survived steps 2 and 4 and has not
become the new first member of the selected list, start by become the new first member of the selected list, start by
moving all tuples in the candidate list with lower overhead moving all tuples in the candidate list with lower overhead
values than that of the new candidate to the selected list, values than that of the new candidate to the selected list,
preserving their order. Run steps 5 through 9 for the new preserving their order. Run steps 5 through 9 for the new
candidate, with the modification that the intersection values candidate, with the modification that the intersection values
and maximum packet rates for the tuples on the selected list and maximum packet rates for the tuples on the selected list
have to be calculated on the fly because they were not have to be calculated on the fly because they were not
previously stored. Continue processing only until a previously stored. Continue processing only until a subsequent
subsequent tuple has been added to the selected list, then tuple has been added to the selected list, then move all
move all remaining candidates to the selected list, preserving remaining candidates to the selected list, preserving their
their order. order.
Note that the new candidate could be added to the selected Note that the new candidate could be added to the selected
list only to be dropped again when the next tuple is list only to be dropped again when the next tuple is
processed. It can easily be seen that in this case the new processed. It can easily be seen that in this case the new
candidate does not displace any of the earlier tuples in the candidate does not displace any of the earlier tuples in the
selected list. The limitations of ASCII art make this selected list. The limitations of ASCII art make this
difficult to show in a figure. Line cc..c in Figure 1 would difficult to show in a figure. Line cc..c in Figure 1 would
be an example if it had a steeper slope (tuple C had a higher be an example if it had a steeper slope (tuple C had a higher
overhead value), but still intersected line aa..a beyond where overhead value), but still intersected line aa..a beyond
line aa..a intersects line bb..b. where line aa..a intersects line bb..b.
The algorithm just described is approximate, because it does not take The algorithm just described is approximate, because it does not take
account of tuples outside the selected list. To see how such tuples account of tuples outside the selected list. To see how such tuples
can become relevant, consider Figure 1 and suppose that the maximum can become relevant, consider Figure 1 and suppose that the maximum
total media bit rate in tuple A increases to the point that line total media bit rate in tuple A increases to the point that line
aa..a moves outside line cc..c. Tuple A will remain in the bounding aa..a moves outside line cc..c. Tuple A will remain in the bounding
set calculated by the media sender. However, once it issues a new set calculated by the media sender. However, once it issues a new
TMMBN, media receiver C will apply the algorithm and discover that TMMBN, media receiver C will apply the algorithm and discover that
its tuple C should now enter the bounding set. It will issue a TMMBR its tuple C should now enter the bounding set. It will issue a TMMBR
request to the media sender, which will repeat its calculation and request to the media sender, which will repeat its calculation and
skipping to change at page 37, line 20 skipping to change at page 37, line 20
The length of the TMMBR feedback message SHALL be set to 2+2*N where The length of the TMMBR feedback message SHALL be set to 2+2*N where
N is the number of TMMBR FCI entries. N is the number of TMMBR FCI entries.
4.2.1.2. Semantics 4.2.1.2. Semantics
Behaviour at the Media Receiver (Sender of the TMMBR) Behaviour at the Media Receiver (Sender of the TMMBR)
TMMBR is used to indicate a transport related limitation at the TMMBR is used to indicate a transport related limitation at the
reporting entity acting as a media receiver. TMMBR has the form of a reporting entity acting as a media receiver. TMMBR has the form of a
tuple containing two components. The first value is the highest bit tuple containing two components. The first value is the highest bit
rate per sender of a media stream, observed at a receiver-chosen rate per sender of a media stream, available at a receiver-chosen
protocol layer, which the receiver currently supports in this RTP protocol layer, which the receiver currently supports in this RTP
session. The second value is the measured header overhead in bytes session. The second value is the measured header overhead in bytes
as defined in section 2.2 and measured at the chosen protocol layer as defined in section 2.2 and measured at the chosen protocol layer
in the packets received for the stream. The measurement of the in the packets received for the stream. The measurement of the
overhead is a running average that is updated for each packet overhead is a running average that is updated for each packet
received for this particular media source (SSRC), using the following received for this particular media source (SSRC), using the following
formula: formula:
avg_OH (new) = 15/16*avg_OH (old) + 1/16*pckt_OH, avg_OH (new) = 15/16*avg_OH (old) + 1/16*pckt_OH,
skipping to change at page 39, line 33 skipping to change at page 39, line 33
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 intervals. packets from the owner for the last five regular reporting intervals.
An SSRC may also explicitly leave the session, with the participant An SSRC may also explicitly leave the session, with the participant
indicating this through the transmission of an RTCP BYE packet or indicating this through the transmission of an RTCP BYE packet or
using an external signaling channel. If the media sender determines using an external signaling channel. If the media sender determines
that the owner of a tuple in the bounding set has left the session, that the owner of a tuple in the bounding set has left the session,
the media sender shall transmit a new TMMBN containing the the media sender shall transmit a new TMMBN containing the
previously-determined set of bounding tuples but with the tuple 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
message to itself, when it is aware that its transmission path is
more restrictive than the current limitations. As a result, a TMMBN
indicating the media source itself as the owner of a tuple is being
sent, thereby avoiding unnecessary TMMBR messages from other
participants. However, like any other participant, when the media
sender becomes aware of changed limitations, it is required to change
the tuple, and to send a corresponding TMMBN.
Discussion Discussion
Due to the unreliable nature of transport of TMMBR and TMMBN, the Due to the unreliable nature of transport of TMMBR and TMMBN, the
above rules may lead to the sending of TMMBR messages which appear to above rules may lead to the sending of TMMBR messages which appear to
disobey those rules. Furthermore, in multicast scenarios it can disobey those rules. Furthermore, in multicast scenarios it can
happen that more than one "non-owning" session participant may happen that more than one "non-owning" session participant may
determine, rightly or wrongly, that its tuple belongs in the bounding determine, rightly or wrongly, that its tuple belongs in the bounding
set. This is not critical for a number of reasons: set. This is not critical for a number of reasons:
a) If a TMMBR message is lost in transmission, either the media a) If a TMMBR message is lost in transmission, either the media
skipping to change at page 42, line 33 skipping to change at page 42, line 41
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 within are not changed, unless the TMMBR was from an owner of a tuple within
the previously calculated bounding set. This procedure allows the previously calculated bounding set. This procedure allows
session participants that did not see the last TMMBN message to get a session participants that did not see the last TMMBN message to get a
correct view of this media sender's state. correct view of this media sender's state.
As indicated in section Error! Reference source not found., when a As indicated in section 4.2.1.2, when a media sender determines that
media sender determines that an "owner" of a bounding tuple has left an "owner" of a bounding tuple has left the session, then that tuple
the session, then that tuple is removed from the bounding set, and is removed from the bounding set, and the media sender SHALL send a
the media sender SHALL send a TMMBN message indicating the remaining TMMBN message indicating the remaining bounding tuples. If there are
bounding tuples. If there are no remaining bounding tuples a TMMBN no remaining bounding tuples a TMMBN without any FCI SHALL be sent to
without any FCI SHALL be sent to indicate this. indicate this.
Note: if any media receivers remain in the session, this last will Note: if any media receivers remain in the session, this last 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
skipping to change at page 45, line 39 skipping to change at page 45, line 45
may be preferable not to react to the command at all, e.g. when may be preferable not to react to the command at all, e.g. when
streaming to a large multicast group. Other reactions may also be streaming to a large multicast group. Other reactions may also be
possible. When deciding on a strategy, a sender could take into possible. When deciding on a strategy, a sender could take into
account factors such as the size of the receiving group, the account factors such as the size of the receiving group, the
"importance" of the sender of the FIR message (however "importance" "importance" of the sender of the FIR message (however "importance"
may be defined in this specific application), the frequency of may be defined in this specific application), the frequency of
decoder refresh points in the content, and so on. However a decoder refresh points in the content, and so on. However a
session which predominately handles pre-coded content is not session which predominately handles pre-coded content is not
expected to use FIR at all. expected to use FIR at all.
The sender MUST consider congestion control as outlined in The sender MUST consider congestion control as outlined in section 5,
section 5., which MAY restrict its ability to send a decoder refresh which MAY restrict its ability to send a decoder refresh point
point quickly. quickly.
Note: The relationship between the Picture Loss Indication and FIR Note: The relationship between the Picture Loss Indication and FIR
is as follows. As discussed in section 6.3.1 of AVPF [RFC4585], a is as follows. As discussed in section 6.3.1 of AVPF [RFC4585], a
Picture Loss Indication informs the decoder about the loss of a Picture Loss Indication informs the decoder about the loss of a
picture and hence the likelihood of misalignment of the reference picture and hence the likelihood of misalignment of the reference
pictures between the encoder and decoder. Such a scenario is pictures between the encoder and decoder. Such a scenario is
normally related to losses in an ongoing connection. In point-to- normally related to losses in an ongoing connection. In point-to-
point scenarios, and without the presence of advanced error point scenarios, and without the presence of advanced error
resilience tools, one possible option for an encoder consists in resilience tools, one possible option for an encoder consists in
sending a decoder refresh point. However, there are other options. sending a decoder refresh point. However, there are other options.
skipping to change at page 63, line 23 skipping to change at page 64, line 23
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[Topologies] M. Westerlund, and S. Wenger, "RTP Topologies", draft- [Topologies] M. Westerlund, and S. Wenger, "RTP Topologies", draft-
ietf-avt-topologies-04, work in progress, Feb 2007.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
11.2. Informative references 11.2. Informative references
[Basso] A. Basso, et. al., "Requirements for transport of video [Basso] A. Basso, et. al., "Requirements for transport of video
control commands", draft-basso-avt-videoconreq-02.txt, control commands", draft-basso-avt-videoconreq-02.txt,
skipping to change at page 63, line 46 skipping to change at page 64, line 45
Recommendation and Final Draft International Standard of Recommendation and Final Draft International Standard of
Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC
14496-10 AVC), Joint Video Team (JVT) of ISO/IEC MPEG 14496-10 AVC), Joint Video Team (JVT) of ISO/IEC MPEG
and ITU-T VCEG, JVT-G050, March 2003. and ITU-T VCEG, JVT-G050, March 2003.
[H245] ITU-T Rec. HG.245, "Control protocol for multimedia [H245] ITU-T Rec. HG.245, "Control protocol for multimedia
communication", MAY 2006 communication", MAY 2006
[NEWPRED] S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient [NEWPRED] S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient
Video Coding by Dynamic Replacing of Reference Video Coding by Dynamic Replacing of Reference
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.
K. Norrman, "The Secure Real-time Transport Protocol Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004. (SRTP)", RFC 3711, March 2004.
[RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", [RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams",
RFC 4587, August 2006. RFC 4587, August 2006.
[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)," RTCP-based Feedback (RTP/SAVPF)," draft-ietf-avt-
draft-ietf-avt-profile-savpf-10.txt, Feb, 2007. profile-savpf-10.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
Friendly Rate Control (TFRC): Protocol Specification", Rate Control (TFRC): Protocol Specification", RFC 3448,
[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.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March Congestion Control Protocol (DCCP)", RFC 4340, March
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.
 End of changes. 30 change blocks. 
61 lines changed or deleted 70 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/