draft-ietf-avt-rtcp-feedback-00.txt   draft-ietf-avt-rtcp-feedback-01.txt 
INTERNET-DRAFT Jųrg Ott/UniversitĄt Bremen TZI INTERNET-DRAFT Jųrg Ott/UniversitĄt Bremen TZI
draft-ietf-avt-rtcp-feedback-00.txt Stephan Wenger/TU Berlin draft-ietf-avt-rtcp-feedback-01.txt Stephan Wenger/TU Berlin
Shigeru Fukunaga/Oki Shigeru Fukunaga/Oki
Noriyuki Sato/Oki Noriyuki Sato/Oki
Koichi Yano/Fast Forward Networks Koichi Yano/Fast Forward Networks
Akihiro Miyazaki/Matsushita Akihiro Miyazaki/Matsushita
Koichi Hata/Matsushita Koichi Hata/Matsushita
Rolf Hakenberg/Matsushita Rolf Hakenberg/Matsushita
Carsten Burmeister/Matsushita Carsten Burmeister/Matsushita
13 July, 2001 21 November, 2001
Expires January 2002 Expires May 2002
Extended RTP Profile for RTCP-based Feedback Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at line 90 skipping to change at line 90
minutes) to adapt their coding scheme and transmission behavior to minutes) to adapt their coding scheme and transmission behavior to
the observed network QoS. However, except for a few payload specific the observed network QoS. However, except for a few payload specific
mechanisms [10], RTP makes no provision for timely feedback that mechanisms [10], RTP makes no provision for timely feedback that
would allow a sender to repair the media stream immediately: through would allow a sender to repair the media stream immediately: through
retransmissions, retro-active FEC, or media-specific mechanisms such retransmissions, retro-active FEC, or media-specific mechanisms such
as reference picture selection. as reference picture selection.
Current mechanisms available with RTP to improve error resilience Current mechanisms available with RTP to improve error resilience
include audio redundancy coding [7], video redundancy coding [11], include audio redundancy coding [7], video redundancy coding [11],
RTP-level FEC [5], and general considerations on more robust media RTP-level FEC [5], and general considerations on more robust media
streams transmission [6]. Particularly in small groups, however, streams transmission [6]. These mechanisms may be applied pro-
virtually all kinds of real-time media streams could benefit from a actively (thereby increasing the bandwidth of a given media stream).
mechanism that would enable a sender to perform media stream repair - Alternatively, in sufficiently small groups with short RTTs, the
- including but not limited to audio, video, DTMF, and text chat senders may perform repair on-demand, using the above mechanisms
streams. In some cases of networks with acceptable round-trip times and/or media-encoding-specific approaches. Note that "small group"
but scarce bandwidth, occasional retransmissions may be much and "sufficiently short RTT" are both highly application dependent.
preferred over continuous transmission of redundant information.
For example, predictive video coding is not loss resilient. Any loss
of coded data leads to annoying artifacts not only in the reproduced
picture in which the loss occurred, but also in subsequent pictures.
Error resilience can be achieved by allocating bits to convey
redundant information using source coding based mechanisms or
transport based mechanisms. This can be done without the use of any
feedback between the decoder(s) and the encoder. Similar
consideration apply to protecting e.g. DTMF (and other tones) carried
in an RTP stream [9].
Ott et al. Expires January 2002 [Page 2]
Alternatively, where applicable, receivers can inform the sender
through a feedback channel about a loss situation, and the sender can
react accordingly. This approach provides better media quality and
is more efficient with respect to the bandwidth used by the sender to
achieve a given media quality. However, using feedback mechanisms is
limited to certain application scenarios identified by encoder
characteristics, delay constraints, and/or the number of recipients.
This document specifies a modified RTP Profile for Audio and Video This document specifies a modified RTP Profile for Audio and Video
conferences with minimal control based upon [1] and [2] by means two conferences with minimal control based upon [1] and [2] by means of
modifications/additions: two modifications/additions: To achieve timely feedback the concepts
of Immediate Feedback messages and Early RTCP messages as well as
To achieve timely feedback the concepts of Immediate Feedback algorithms allowing for low delay feedback in small multicast groups
messages and Early RTCP messages as well as algorithms allowing for (and preventing feedback implosion in large ones) are introduced.
low delay feedback in small multicast groups (and preventing feedback Special consideration is given to point-to-point scenarios. And a
implosion in large ones) are introduced. Special consideration is small number general-purpose feedback messages as well as a format
given to point-to-point scenarios.
In addition, various types of general-purpose feedback messages as Ott et al. Expires May 2002 [Page 2]
well as a format for codec and application-specific feedback for codec and application-specific feedback information is defined as
information are defined as specific RTCP payloads. specific RTCP payloads.
1.1 Definitions 1.1 Definitions
The definitions from [1] and [2] apply. In addition, the following The definitions from [1] and [2] apply. In addition, the following
definitions are used in this document: definitions are used in this document:
Early RTCP mode: Early RTCP mode:
The mode of operation in which a receiver of a media stream The mode of operation in which a receiver of a media stream
is, statistically, often (but not always) capable of is, statistically, often (but not always) capable of
reporting events of interest back to the sender close to reporting events of interest back to the sender close to
skipping to change at line 163 skipping to change at line 142
(potentially) of interest to the sender -- such as a packet (potentially) of interest to the sender -- such as a packet
loss or packet reception, frame loss, etc. -- and thus to be loss or packet reception, frame loss, etc. -- and thus to be
reported back to the sender by means of a Feedback message. reported back to the sender by means of a Feedback message.
Feedback (FB) message: Feedback (FB) message:
An RTCP message as defined in this document used to convey An RTCP message as defined in this document used to convey
events observed at a receiver -- in addition to long term events observed at a receiver -- in addition to long term
receiver status information which is carried in RTCP RRs Ż receiver status information which is carried in RTCP RRs Ż
back to the sender of the media stream. back to the sender of the media stream.
Ott et al. Expires January 2002 [Page 3]
Feedback (FB) threshold: Feedback (FB) threshold:
The FB threshold indicates the "borderline" between Immediate The FB threshold indicates the "borderline" between Immediate
Feedback and Early RTCP mode. For a multicast scenario, the Feedback and Early RTCP mode. For a multicast scenario, the
FB threshold indicates the maximum group size at which, on FB threshold indicates the maximum group size at which, on
average, each receiver is able to report each event back to average, each receiver is able to report each event back to
the sender(s) immediately, i.e. without having to wait for the sender(s) immediately, i.e. without having to wait for
its regularly scheduled RTCP interval. This threshold is its regularly scheduled RTCP interval. This threshold is
highly dependent on network QoS (e.g. packet loss probability highly dependent on network QoS (e.g. packet loss probability
and distribution), codec and packetization in use, and and distribution), codec and packetization in use, and
application requirements. Hence, no formal definition is application requirements. Hence, no formal definition is
presented in this document. presented in this document.
Immediate Feedback mode: Immediate Feedback mode:
Mode of operation in which each receiver of a media is, Mode of operation in which each receiver of a media is,
statistically, capable of reporting each event of interest statistically, capable of reporting each event of interest
immediately back to the media stream sender. In Immediate immediately back to the media stream sender. In Immediate
Feedback mode, RTCP feedback messages are transmitted Feedback mode, RTCP feedback messages are transmitted
according to the timing rules defined in this document. according to the timing rules defined in this document.
Ott et al. Expires May 2002 [Page 3]
Regular RTCP mode: Regular RTCP mode:
Mode of operation in which no preferred transmission of Mode of operation in which no preferred transmission of
feedback messages is allowed. Instead, RTCP messages are feedback messages is allowed. Instead, RTCP messages are
sent following the rules of [1] and may contain feedback sent following the rules of [1] and may contain feedback
messages information as defined in this document. messages information as defined in this document.
Regularly Scheduled RTCP packet: Regularly Scheduled RTCP packet:
An RTCP packet that is not sent as an Early RTCP packet. An RTCP packet that is not sent as an Early RTCP packet.
1.2 Terminology 1.2 Terminology
skipping to change at line 217 skipping to change at line 196
RTCP report intervals: RTCP report intervals:
This memo describes three modes of operation which influence This memo describes three modes of operation which influence
the RTCP report intervals (see section 3.2). In regular the RTCP report intervals (see section 3.2). In regular
RTCP mode, all rules from [1] apply. In both Immediate RTCP mode, all rules from [1] apply. In both Immediate
Feedback and Early RTCP modes the minimal interval of 5 Feedback and Early RTCP modes the minimal interval of 5
seconds between 2 RTCP reports is dropped and the rules seconds between 2 RTCP reports is dropped and the rules
specified in section 3 apply if RTCP packets containing specified in section 3 apply if RTCP packets containing
feedback messages (defined in section 4) are to be feedback messages (defined in section 4) are to be
transmitted. transmitted.
Ott et al. Expires January 2002 [Page 4]
The rules set forth in [1] may be overridden by session The rules set forth in [1] may be overridden by session
descriptions specifying different parameters (e.g. for the descriptions specifying different parameters (e.g. for the
bandwidth share assigned to RTCP for senders and receivers, bandwidth share assigned to RTCP for senders and receivers,
respectively. For sessions defined using the Session respectively. For sessions defined using the Session
Description Protocol (SDP) [3], the rules of [4] apply. Description Protocol (SDP) [3], the rules of [4] apply.
Congestion control: Congestion control:
The same basic rules as detailed in [2] apply. Beyond this, The same basic rules as detailed in [2] apply. Beyond this,
in section 5, further consideration is given to the impact of in section 5, further consideration is given to the impact of
feedback and a sender's reaction to feedback messages. feedback and a sender's reaction to feedback messages.
3. Rules for RTCP Feedback 3. Rules for RTCP Feedback
3.1 Compound RTCP Feedback Packets 3.1 Compound RTCP Feedback Packets
Ott et al. Expires May 2002 [Page 4]
Two components constitute RTCP-based feedback as described in this Two components constitute RTCP-based feedback as described in this
memo: memo:
. Status reports are contained in SR/RR messages and are transmitted . Status reports are contained in SR/RR messages and are transmitted
at regular intervals as part of compound RTCP packets (which also at regular intervals as part of compound RTCP packets (which also
include SDES and possibly other messages); these status reports include SDES and possibly other messages); these status reports
provide an overall indication for the recent reception quality of provide an overall indication for the recent reception quality of
a media stream. a media stream.
. Feedback messages as defined in this document that indicate loss . Feedback messages as defined in this document that indicate loss
skipping to change at line 263 skipping to change at line 242
RTCP packets containing Feedback packets as defined in this document RTCP packets containing Feedback packets as defined in this document
MUST contain RTCP packets in the order as defined in [1]: MUST contain RTCP packets in the order as defined in [1]:
. OPTIONAL encryption prefix that MUST be present if the RTCP . OPTIONAL encryption prefix that MUST be present if the RTCP
message is to be encrypted. message is to be encrypted.
. MANDATORY SR or RR. . MANDATORY SR or RR.
. MANDATORY SDES which MUST contain the CNAME item; all other SDES . MANDATORY SDES which MUST contain the CNAME item; all other SDES
items are OPTIONAL. items are OPTIONAL.
. One or more FB messages. . One or more FB messages.
The FB MUST be placed in the compound packet after all RTCP packets The FB MUST be placed in the compound packet after RR and SDES RTCP
defined in [1]. The ordering with respect to other RTCP extensions packets defined in [1]. The ordering with respect to other RTCP
is not defined. extensions is not defined.
Two types of compound RTCP packets carrying feedback packets are used Two types of compound RTCP packets carrying feedback packets are used
in this document: in this document:
Ott et al. Expires January 2002 [Page 5]
a) Minimal compound RTCP feedback packet a) Minimal compound RTCP feedback packet
A minimal compound RTCP feedback packet MUST contain only the A minimal compound RTCP feedback packet MUST contain only the
mandatory information as listed above: encryption prefix if mandatory information as listed above: encryption prefix if
necessary, exactly one RR or SR, exactly one SDES with only the necessary, exactly one RR or SR, exactly one SDES with only the
CNAME item present, and the feedback message(s). This is to CNAME item present, and the feedback message(s). This is to
minimize the size of the RTCP packet transmitted to convey minimize the size of the RTCP packet transmitted to convey
feedback and thus to maximize the frequency at which feedback can feedback and thus to maximize the frequency at which feedback can
be provided while still adhering to the RTCP bandwidth be provided while still adhering to the RTCP bandwidth
limitations. limitations.
This packet format SHOULD be used whenever an RTCP feedback This packet format SHOULD be used whenever an RTCP feedback
message is sent as part of an Early RTCP packet. message is sent as part of an Early RTCP packet.
b) (Full) compound RTCP feedback packet b) (Full) compound RTCP feedback packet
Ott et al. Expires May 2002 [Page 5]
A (full) compound RTCP feedback packet MAY contain any additional A (full) compound RTCP feedback packet MAY contain any additional
number of RTCP packets (additional RRs, further SDES items, number of RTCP packets (additional RRs, further SDES items,
etc.). etc.).
This packet format MUST be used whenever an RTCP feedback message This packet format MUST be used whenever an RTCP feedback message
is sent as part of a regularly scheduled RTCP packet or in is sent as part of a regularly scheduled RTCP packet or in
Regular RTCP mode. This packet format MAY also be used to send Regular RTCP mode. This packet format MAY also be used to send
RTCP feedback messages in Immediate Feedback or Early RTCP mode. RTCP feedback messages in Immediate Feedback or Early RTCP mode.
RTCP packets that do not contain FB messages are referred to as non- RTCP packets that do not contain FB messages are referred to as non-
skipping to change at line 326 skipping to change at line 305
FB messages have to be conveyed, compound RTCP packets are sent FB messages have to be conveyed, compound RTCP packets are sent
following the rules of RTP [1] -- except that the 5s minimum interval following the rules of RTP [1] -- except that the 5s minimum interval
between RTCP reports is not enforced. If a receiver detects the need between RTCP reports is not enforced. If a receiver detects the need
for an FB message, the receiver waits for a short, random dithering for an FB message, the receiver waits for a short, random dithering
interval (in case of multicast) and then checks whether it has interval (in case of multicast) and then checks whether it has
already seen a corresponding FB message from any other receiver already seen a corresponding FB message from any other receiver
(which it can do with all FB messages that are transmitted via (which it can do with all FB messages that are transmitted via
multicast; for unicast sessions, there is no such delay). If this is multicast; for unicast sessions, there is no such delay). If this is
the case then the receiver refrains from sending the FB message and the case then the receiver refrains from sending the FB message and
continues to follow the regular RTCP sending schedule. If the continues to follow the regular RTCP sending schedule. If the
Ott et al. Expires January 2002 [Page 6]
receiver has not yet seen a similar FB message from any other receiver has not yet seen a similar FB message from any other
receiver, it checks whether it has recently exceeded its RTCP bit receiver, it checks whether it has recently exceeded its RTCP bit
rate budget to transmit another FB message (without waiting for its rate budget to transmit another FB message (without waiting for its
regularly scheduled RTCP transmission time). Only if this is not the regularly scheduled RTCP transmission time). Only if this is not the
case, it sends the FB message as part of a (minimal) compound RTCP case, it sends the FB message as part of a (minimal) compound RTCP
packet. packet.
FB messages may also be sent as part of full compound RTCP packets FB messages may also be sent as part of full compound RTCP packets
which are interspersed as per [1] in regular intervals. which are interspersed as per [1] in regular intervals.
3.3 Modes of Operation 3.3 Modes of Operation
RTCP-based feedback may operate in one of three modes (figure 1): RTCP-based feedback may operate in one of three modes (figure 1):
Ott et al. Expires May 2002 [Page 6]
a) Immediate feedback mode: the group size is below the FB threshold a) Immediate feedback mode: the group size is below the FB threshold
which gives each receiving party sufficient bandwidth to transmit which gives each receiving party sufficient bandwidth to transmit
the feedback traffic for the intended purpose. This means, for the feedback traffic for the intended purpose. This means, for
each receiver there is enough bandwidth to report each event it is each receiver there is enough bandwidth to report each event it is
supposed/expected to by means of a virtually "immediate" RTCP supposed/expected to by means of a virtually "immediate" RTCP
feedback packet. feedback packet.
The group size threshold is a function of a number of parameters The group size threshold is a function of a number of parameters
including (but not necessarily limited to) the type of feedback including (but not necessarily limited to) the type of feedback
used (e.g. ACK vs. NACK), bandwidth, packet rate, packet loss used (e.g. ACK vs. NACK), bandwidth, packet rate, packet loss
skipping to change at line 374 skipping to change at line 352
stream transmission accordingly and thereby increase the overall stream transmission accordingly and thereby increase the overall
reproduced media quality. reproduced media quality.
c) From some group size upwards, it is no longer useful to provide c) From some group size upwards, it is no longer useful to provide
feedback from individual receivers at all -- because of the time feedback from individual receivers at all -- because of the time
scale in which the feedback could be provided and/or because in scale in which the feedback could be provided and/or because in
large groups the sender(s) have no chance to react to individual large groups the sender(s) have no chance to react to individual
feedback anymore. feedback anymore.
As the feedback algorithm described in this memo scales smoothly, As the feedback algorithm described in this memo scales smoothly,
there is no need for an agreement on the precise values of the there is no need for an agreement among the participants on the
respective "thresholds" within the group. Hence the borders between precise values of the respective "thresholds" within the group.
all these modes are allowed to be fluent. Hence the borders between all these modes are allowed to be fluent.
Ott et al. Expires January 2002 [Page 7]
ACK ACK
feedback feedback
V V
:<- - - - NACK feedback - - - ->// :<- - - - NACK feedback - - - ->//
: :
: Immediate || : Immediate ||
: Feedback mode ||Early RTCP mode Regular RTCP mode : Feedback mode ||Early RTCP mode Regular RTCP mode
:<=============>||<=============>//<=================> :<=============>||<=============>//<=================>
: || : ||
-+---------------||---------------//------------------> group size -+---------------||---------------//------------------> group size
2 || 2 ||
Application-specific FB Threshold Application-specific FB Threshold
= f(data rate, packet loss, codec, ...) = f(data rate, packet loss, codec, ...)
Figure 1: Modes of operation Figure 1: Modes of operation
Ott et al. Expires May 2002 [Page 7]
The respective thresholds depend on a number of technical parameters The respective thresholds depend on a number of technical parameters
(of the codec, the transport, the feedback used, etc.) but also on (of the codec, the transport, the feedback used, etc.) but also on
the respective application scenarios. Section 3.5 provides some the respective application scenarios. Section 3.5 provides some
useful hints (but no complete precise calculations) on estimating useful hints (but no complete precise calculations) on estimating
these thresholds. these thresholds.
3.4 Definitions 3.4 Definitions
The following pieces of state information need to be maintained The following pieces of state information need to be maintained per
(largely taken from [1]): receiver (largely taken from [1]). Note that all variables (except
for h) are calculated independently at each receiver and so their
local values may differ at a given point in time.
a) Let senders be the number of active senders in the RTP session. a) Let senders be the number of active senders in the RTP session.
b) Let members be the current estimate of the number of receivers b) Let members be the current estimate of the number of receivers
in the RTP session. in the RTP session.
c) Let T_rtt be the maximum round trip time as measured by RTCP c) Let T_rtt be the maximum round trip time as measured by RTCP
(if available to the receiver). Note that this may be asymmetric. (if available to the receiver). Note that this may be asymmetric.
d) Let tn and tp be the time for the next (last) scheduled d) Let tn and tp be the time for the next (last) scheduled
RTCP RR transmission calculated prior to reconsideration. RTCP RR transmission calculated prior to reconsideration.
e) Let T_rr be the interval after which, having just sent a regularly e) Let T_rr be the interval after which, having just sent a regularly
scheduled RTCP packet, a receiver would schedule the transmission scheduled RTCP packet, a receiver would schedule the transmission
of its next RTCP packet following the rules of [1]: T_rr = tn Ż of its next RTCP packet following the rules of [1]: T_rr = tn -
tp. Note that the 5s minimum interval between two report as tp. Note that the 5s minimum interval between two report as
defined in [1] SHOULD NOT be enforced. defined in [1] SHOULD NOT be enforced.
f) Let t0 be the time at which an event is detected by a receiver. f) Let t0 be the time at which an event that is to be reported is
detected by a receiver.
g) Let T_dither_max be the maximum interval for which an RTCP g) Let T_dither_max be the maximum interval for which an RTCP
feedback packet may be additionally delayed (to prevent feedback packet may be additionally delayed (to prevent
implosions). implosions).
h) Let T_max_fb_delay be the upper bound within which feedback to h) Let T_max_fb_delay be the upper bound within which feedback to
an event needs to be reported back to the sender to be useful at an event needs to be reported back to the sender to be useful at
all. all. Note that this value is application-specific.
i) Let te be the time for which a feedback packet is scheduled. i) Let te be the time for which a feedback packet is scheduled.
Ott et al. Expires January 2002 [Page 8]
j) Let T_fd be the actual (randomized) delay for the transmission of j) Let T_fd be the actual (randomized) delay for the transmission of
feedback message in response to an event that a certain packet P feedback message in response to an event that a certain packet P
caused. caused.
k) Let allow_early be a variable that indicates whether a receiver k) Let allow_early be a Boolean variable that indicates whether the
may transmit feedback messages prior to its next regularly receiver currently may transmit feedback messages prior to its
scheduled RTCP interval tn. next regularly scheduled RTCP interval tn. This variable is used
to throttle the feedback sent by a single receiver. allow_early
is adjusted (set to FALSE) after early feedback transmission and
is reset to TRUE as soon as the next regular RTCP transmission is
scheduled.
Ott et al. Expires May 2002 [Page 8]
l) Let avg_rtcp_size be the moving average on the RTCP packet size as l) Let avg_rtcp_size be the moving average on the RTCP packet size as
defined in [1]. defined in [1].
The feedback situation for an event to report at a receiver is The feedback situation for an event to report at a receiver is
depicted in figure 2 below. At time t0, such an event (e.g. a packet depicted in figure 2 below. At time t0, such an event (e.g. a packet
loss) is detected at the receiver. The receiver decides -- based loss) is detected at the receiver. The receiver decides -- based
upon current T_rtt, group size, and other (application-specific) upon current T_rtt, group size, and other (application-specific)
parameters -- that a feedback message needs to be sent back to the parameters -- that a feedback message needs to be sent back to the
sender. sender.
To avoid an implosion of immediate feedback packets, the receiver To avoid an implosion of immediate feedback packets, the receiver
MUST delay the transmission of the compound feedback packet by a MUST delay the transmission of the compound feedback packet by a
random amount T_fd (with the random number evenly distributed in the random amount T_fd (with the random number evenly distributed in the
interval [0, T_dither_max]. Transmission of the compound RTCP packet interval [0, T_dither_max]. Transmission of the compound RTCP packet
is then scheduled for te = t0 + T_fd. is then scheduled for te = t0 + T_fd.
The T_dither_max parameter is chosen based upon the group size, the The T_dither_max parameter is chosen based upon the round-trip time
RTCP bandwidth constraints, and, if available, the round-trip time. or, if the round-trip time is not available, based upon the group
size.
Based upon the parameters influencing T_dither_max and a number of Based upon the parameters influencing T_dither_max and a number of
other parameters (such as the type of feedback to be provided) the other parameters (such as the type of feedback to be provided) the
receiver may determine T_max_fb_delay (as static value or dynamically receiver may determine T_max_fb_delay (as static value or dynamically
adjusted) as the upper bound for the feedback information to be adjusted) as the upper bound for the feedback information to be
useful when it reaches the sender. useful when it reaches the sender.
If a compound RTCP feedback packet is scheduled, the time slot for If a compound RTCP feedback packet is scheduled, the time slot for
the next scheduled compound RTCP packet is updated accordingly to a the next scheduled compound RTCP packet is updated accordingly to a
new tn. new tn.
skipping to change at line 490 skipping to change at line 476
|---+--------+-------------+-----+------------| |--------+---------> |---+--------+-------------+-----+------------| |--------+--------->
| | | | ( ( | | | | | ( ( |
| t0 te | | t0 te |
tp tn tp tn
\_______ ________/ \_______ ________/
\/ \/
T_dither_max T_dither_max
Figure 2: Event report and parameters for Early RTCP scheduling Figure 2: Event report and parameters for Early RTCP scheduling
Ott et al. Expires January 2002 [Page 9]
3.5 Early RTCP Algorithm 3.5 Early RTCP Algorithm
Ott et al. Expires May 2002 [Page 9]
Assume an active sender S0 (out of S senders) and a number N of Assume an active sender S0 (out of S senders) and a number N of
receivers with R being one of these receivers. receivers with R being one of these receivers.
Assume further that R has verified that using feedback mechanisms is Assume further that R has verified that using feedback mechanisms is
reasonable at the current constellation (which is highly application reasonable at the current constellation (which is highly application
specific and hence not specified in this memo). specific and hence not specified in this memo).
Then, receiver R MUST use the following rules for transmitting a Then, receiver R MUST use the following rules for transmitting one or
Feedback messages as minimal or full compound RTCP packet: more Feedback messages as minimal or full compound RTCP packet:
Initially, R MUST set allow_early := TRUE. Initially, R MUST set allow_early := TRUE.
R has transmitted the last RTCP RR packet at tp and has scheduled the R has transmitted the last RTCP RR packet at tp and has scheduled the
next transmission (prior to reconsideration) for tn. next transmission (prior to reconsideration) for tn.
At time t0, R detects the need to transmit a feedback message (e.g. At time t0, R detects the need to transmit one or more feedback
because a media "unit" needs to be ACKed or NACKed) and finds that messages (e.g. because media "units" needs to be ACKed or NACKed) and
sending the feedback message is useful for the sender. finds that sending the feedback information is useful for the sender.
R first checks whether there is still an RTCP feedback packet waiting R first checks whether there is still a compound RTCP feedback packet
for transmission. If so, the new feedback message MUST be appended waiting for transmission (scheduled as early or regular RTCP packet).
to the packet; the schedule for the waiting RTCP feedback packet MUST If so, the new feedback message MUST be appended to the packet; the
remain unchanged. schedule for the waiting RTCP feedback packet MUST remain unchanged.
When appending, the feedback information of several RTCP feedback
packets SHOULD be merged as few packets as possible.
If no RTCP feedback message is already awaiting transmission (as part If no RTCP feedback message is already awaiting transmission, a new
of an Early RTCP packet), a new (minimal) compound RTCP feedback (minimal) compound RTCP feedback packet MUST be created and the
packet MUST be created and the interval T_dither_max MUST be chosen minimal interval for T_dither_max MUST be chosen as follows:
as follows:
i) If the session is a unicast session (group size = 2) then i) If the session is a unicast session (group size = 2) then
T_dither_max := 0. T_dither_max := 0.
ii) If the receiver has an RTT estimate to the originator of the ii) If the receiver has an RTT estimate to the originator of the
media unit to provide feedback about, then media unit to provide feedback about, then
T_dither_max := k * T_rtt/2 * members T_dither_max := k * T_rtt/2 * members
with k=1. with k=1.
iii) If the receiver does not have an RTT estimate to the originator, iii) If the receiver does not have an RTT estimate to the originator,
then then
T_dither_max := l * T_rr T_dither_max := l * T_rr
with l=0.5. with l=0.5.
(Application-specific feedback considerations may make it worthwhile The values given above for T_dither_max are minimal values.
Application-specific feedback considerations may make it worthwhile
to increase T_dither_max beyond this value. This is up to the to increase T_dither_max beyond this value. This is up to the
discretion of the implementer.) discretion of the implementer.
Then, R MUST check whether its next regularly scheduled RTCP packet Then, R MUST check whether its next regularly scheduled RTCP packet
is within the time bounds for the RTCP FB (t0 + T_dither_max > tn). is within the time bounds for the RTCP FB (t0 + T_dither_max > tn).
If so, an Early RTCP packet MUST NOT be scheduled; instead the FB
Ott et al. Expires January 2002 [Page 10] Ott et al. Expires May 2002 [Page 10]
message MUST be stored to be appended to the regular RTCP packet If so, an Early RTCP packet MUST NOT be scheduled; instead the FB
message(s) MUST be stored to be appended to the regular RTCP packet
scheduled for tn. scheduled for tn.
Otherwise, R MUST check whether it is allowed to transmit an Early Otherwise, R MUST check whether it is allowed to transmit an Early
RTCP packet (allow_early == TRUE). RTCP packet (allow_early == TRUE).
If so, R MUST schedule an Early RTCP packet for te := t0 + RND * If so, R MUST schedule an Early RTCP packet for te := t0 + RND *
T_dither_max with the RND function evenly distributed between 0 T_dither_max with the RND function evenly distributed between 0
and 1. and 1.
If, while waiting for te, R receives an RTCP feedback packet R If, while waiting for te, R receives RTCP feedback packets
MUST act as follows: contained in one or more (minimal) compound RTCP packets, R MUST
act as follows for each of the RTCP feedback packets in the one or
more compound RTCP packets received:
1. If R understands the received feedback message's semantics and 1. If R understands the received feedback message's semantics and
the message contents is a superset of the feedback R wanted to the message contents is a superset of the feedback R wanted to
send then R MUST discard its own feedback message and MUST re- send then R MUST discard its own feedback message and MUST re-
schedule the next regular RTCP message transmission for tn (as schedule the next regular RTCP message transmission for tn (as
calculated before). calculated before).
2. If R understands the received feedback message's semantics and 2. If R understands the received feedback message's semantics and
the message contents is not a superset of the feedback R the message contents is not a superset of the feedback R
wanted to send then R SHOULD transmit its own feedback message wanted to send then R SHOULD transmit its own feedback message
as scheduled. as scheduled. If there is an overlap between the feedback
information to send and the feedback information to receive,
the amount of feedback transmitted is up to R: R MAY send its
feedback information unchanged, R MAY as well eliminate any
redundancy between its own feedback and the feedback received
so far.
3. If R does not understand the received feedback message's 3. If R does not understand the received feedback message's
semantics then R MAY send its own feedback message as or Early semantics, R checks whether the compound RTCP packet contains
a Generic INFO message. If a Generic INFO message is present
R performs the comparison based upon this information and
proceeds with alternative 1. or 2. above depending on the
outcome of the comparison. If no Generic INFO message is
present, then R MAY send its own feedback message as or Early
RTCP packet. Alternatively, R MAY re-schedule the next RTCP packet. Alternatively, R MAY re-schedule the next
regular RTCP message transmission for tn (as calculated regular RTCP message transmission for tn (as calculated
before) and MAY append the feedback message the now regularly before) and MAY append the feedback message to the now
scheduled RTCP message. regularly scheduled RTCP message.
Refer to section 4 on the comparison of feedback messages and for Refer to section 4 on the comparison of feedback messages and for
which feedback messages must be understood by a receiver. which feedback messages MUST be understood by a receiver.
Otherwise, when te is reached, R MUST transmit the RTCP packet Otherwise, when te is reached, R MUST transmit the RTCP packet
containing the FB message. R then MUST set allow_early := FALSE containing the FB message. R then MUST set allow_early := FALSE
and MUST recalculate tn := tp + 2*T_rr. As soon as R sends its and MUST recalculate tn := tp + 2*T_rr. As soon as R sends its
next regularly scheduled RTCP RR (at the new tn), it MUST set next regularly scheduled RTCP RR (at the new tn), it MUST set
allow_early := TRUE again. allow_early := TRUE again.
Ott et al. Expires May 2002 [Page 11]
If allow_early == FALSE then R MUST check the time for the next If allow_early == FALSE then R MUST check the time for the next
scheduled RR: scheduled RR:
1. If tn Ż t0 < T_max_fb_delay (i.e. if, despite late reception, the 1. If tn Ż t0 < T_max_fb_delay (i.e. if, despite late reception, the
feedback could still be useful for the sender) then R MAY create feedback could still be useful for the sender) then R MAY create
an RTCP FB message for transmission along with the RTCP packet at an RTCP FB message for transmission along with the RTCP packet at
tn. tn.
2. Otherwise, R MUST discard the RTCP feedback message. 2. Otherwise, R MUST discard the RTCP feedback message.
In regular RTCP intervals as specified by [1] (except for the five In regular RTCP intervals as specified by [1] (except for the five
second minimum), a full compound RTCP packet is sent (which may also second minimum), a full compound RTCP packet is sent (which may also
contain a feedback message if one has been created according to the contain a feedback message if one has been created according to the
above rules and scheduled for transmission along the full compound above rules and scheduled for transmission along the full compound
RTCP message). RTCP message).
Ott et al. Expires January 2002 [Page 11]
The E bit in the message header is used upon reception to detect
whether this RTCP feedback message was sent as Early RTCP or not.
Hence, a feedback message that is sent as an Immediate or Early RTCP
packet MUST set the E bit in the message header to "1". Feedback
messages piggy-backed on regularly scheduled RTCP packets MUST set
the E bit to "0". If a receiver R receives an Early RTCP packet
(E=1), then it MAY set allow_early := TRUE.
Whenever an RTCP packet is sent or received -- minimal or full Whenever an RTCP packet is sent or received -- minimal or full
compound, early or regularly scheduled -- the avg_rtcp_size variable compound, early or regularly scheduled -- the avg_rtcp_size variable
is updated accordingly (see [1]) and the tn is calculated using the is updated accordingly (see [1]) and the tn is calculated using the
new avg_rtcp_size. new avg_rtcp_size.
3.6 Considerations on the Group Size 3.6 Considerations on the Group Size
This section provides guidelines to the group sizes at which the This section provides guidelines to the group sizes at which the
various feedback modes may be used. various feedback modes may be used.
3.6.1 ACK mode 3.6.1 ACK mode
The group size MUST be exactly two participants, i.e. point-to-point The group size MUST be exactly two participants, i.e. point-to-point
communications. Unicast addresses SHOULD be used in the session communications. Unicast addresses SHOULD be used in the session
description. description.
For unidirectional as well as bi-directional communication between For unidirectional as well as bi-directional communication between
two parties, 2.5% of the RTP session bandwidth are available for RTCP two parties, 2.5% of the RTP session bandwidth are available for RTCP
traffic from the receivers including feedback. , Assuming that out traffic from the receivers including feedback. Assuming that out of
of ten RTCP packets, nine are sent as minimal compound RTCP packets ten RTCP packets, nine are sent as minimal compound RTCP packets and
and one as full compound RTCP packet, at 64kbit/s unidirectional one as full compound RTCP packet, at 64kbit/s unidirectional
communication scenario, a receiver can report 1.5 events per second communication scenario, a receiver can report 1.5 events per second
back to the sender, at 256kbit/s 6 events and so forth. back to the sender, at 256kbit/s 6 events and so forth.
From 1 Mbit/s upwards, a receiver would be able to acknowledge each From 1 Mbit/s upwards, a receiver would be able to acknowledge each
individual frame (not packet!) in a 25 fps video stream. individual frame (not packet!) in a 25 fps video stream.
ACK strategies should be defined accordingly to work properly with ACK strategies MUST be defined accordingly to work properly with
these bandwidth limitations. these bandwidth limitations. An indication whether or not ACKs are
allowed for a session and, if so, which ACK strategy should be used,
MAY be conveyed by out-of-band mechanisms, e.g. media-specific
attributes in a session description using SDP.
Ott et al. Expires May 2002 [Page 12]
3.6.2 NACK mode 3.6.2 NACK mode
Negative acknowledgements (or similar types of feedback) MUST be Negative acknowledgements (or similar types of feedback) MUST be
used for all groups larger than two. Of course, NACKs MAY be used used for all groups larger than two. Of course, NACKs MAY be used
for point-to-point communications as well. for point-to-point communications as well.
Whether or not the use of Immediate or Early RTCP packets should be Whether or not the use of Immediate or Early RTCP packets should be
considered depends upon a number of parameters including session considered depends upon a number of parameters including session
bandwidth, codec, special type of feedback, number of senders and bandwidth, codec, special type of feedback, number of senders and
receivers, among many others. receivers, among many others.
The crucial parameters -- to which virtually all of the above can be The crucial parameters -- to which virtually all of the above can be
reduced -- is the allowed minimal interval between two RTCP reports reduced -- is the allowed minimal interval between two RTCP reports
and the (average) number of events that presumably need reporting per and the (average) number of events that presumably need reporting per
time interval (plus their distribution over time, of course). The time interval (plus their distribution over time, of course). The
minimum interval is derived from the available RTCP bandwidth and the minimum interval is derived from the available RTCP bandwidth and the
expected average size of an RTCP packet. The number of events to
Ott et al. Expires January 2002 [Page 12] report e.g. per second may be derived from the packet loss rate and
expected average size of an RTCP packet. The number events to report sender's rate of transmitting packets. From these two values, the
e.g. per second may be derived from the packet loss rate and sender's allowable group size for the Immediate feedback mode can be
rate of transmitting packets. From these two values, the allowable calculated.
group size for the Immediate feedback mode can be calculated.
The upper bound for the Early RTCP mode then solely depends on the The upper bound for the Early RTCP mode then solely depends on the
acceptable quality degradation, i.e. how many events per time acceptable quality degradation, i.e. how many events per time
interval may go unreported. interval may go unreported.
Example: If a 256kbit/s video with 30 fps is transmitted through a Example: If a 256kbit/s video with 30 fps is transmitted through a
network with an MTU size of some 1500 bytes, then, in most cases, network with an MTU size of some 1500 bytes, then, in most cases,
each frame would fit in its own packet leading to a packet rate of 30 each frame would fit in its own packet leading to a packet rate of 30
packets per second. If 5% packet loss occurs in the network (equally packets per second. If 5% packet loss occurs in the network (equally
distributed, no inter-dependence between receivers), then each distributed, no inter-dependence between receivers), then each
receiver will have to report 3 packets lost each two seconds. receiver will have to report 3 packets lost each two seconds.
Assuming a single sender and more then three receivers, this yields Assuming a single sender and more than three receivers, this yields
3.75% of the RTCP bandwidth allocated to the receivers and thus 3.75% of the RTCP bandwidth allocated to the receivers and thus
9.6kbit/s. Assuming further a size of 120 bytes for the average 9.6kbit/s. Assuming further a size of 120 bytes for the average
compound RTCP packet allows 10 RTCP packets to be sent per second or compound RTCP packet allows 10 RTCP packets to be sent per second or
20 in two seconds. If every receiver needs to report three packets, 20 in two seconds. If every receiver needs to report three packets,
this yields a maximum group size of 6-7 receivers if all loss events this yields a maximum group size of 6-7 receivers if all loss events
shall be reported. The rules for transmission of immediate RTCP shall be reported. The rules for transmission of immediate RTCP
packets should provide sufficient flexibility for most of this packets should provide sufficient flexibility for most of this
reporting to occur in a timely fashion. reporting to occur in a timely fashion.
Extending this example to determine the upper bound for Early RTCP Extending this example to determine the upper bound for Early RTCP
mode leads to the following considerations: assume that the mode leads to the following considerations: assume that the
underlying coding scheme and the application (as well as the tolerant underlying coding scheme and the application (as well as the tolerant
users) allow in the order of one loss without repair per two seconds. users) allow on the order of one loss without repair per two seconds.
Thus the number of packets to be reported by each receiver decreases Thus the number of packets to be reported by each receiver decreases
to two per two seconds second and increases the group size to 10. to two per two seconds second and increases the group size to 10.
Assuming further that some number of packet losses are correlated, Assuming further that some number of packet losses are correlated,
feedback traffic is further reduced and group sizes of some 12 to 16 feedback traffic is further reduced and group sizes of some 12 to 16
(maybe even 20) can be reasonably well supported using Early RTCP (maybe even 20) can be reasonably well supported using Early RTCP
mode. mode.
Ott et al. Expires May 2002 [Page 13]
3.7 Summary of decision steps 3.7 Summary of decision steps
3.7.1 General Hints 3.7.1 General Hints
Before even considering whether or not to send RTCP feedback Before even considering whether or not to send RTCP feedback
information an application has to determine whether this mechanism is information an application has to determine whether this mechanism is
applicable: applicable:
1) An application has to decide whether -- for the current ratio of 1) An application has to decide whether -- for the current ratio of
packet rate with the associated (application-specific) maximum packet rate with the associated (application-specific) maximum
feedback delay and the currently observed round-trip time (if feedback delay and the currently observed round-trip time (if
available) -- feedback mechanisms can be applied at all. available) -- feedback mechanisms can be applied at all.
This decision may obviously be based upon (and dynamically revised This decision may obviously be based upon (and dynamically revised
following) regular RTCP reception statistics. following) regular RTCP reception statistics.
2) The application has to decide whether -- for a certain observed 2) The application has to decide whether -- for a certain observed
error rate, assigned bandwidth, frame rate, and group size -- (and error rate, assigned bandwidth, frame rate, and group size -- (and
which) feedback mechanisms can be applied. which) feedback mechanisms can be applied.
Ott et al. Expires January 2002 [Page 13]
Regular RTCP provides valuable input to this step, too. Regular RTCP provides valuable input to this step, too.
3) If these tests pass, the application has to follow the rules for 3) If these tests pass, the application has to follow the rules for
transmitting Early RTCP packets or regularly scheduled RTCP transmitting Early RTCP packets or regularly scheduled RTCP
packets with piggybacked feedback. packets with piggybacked feedback.
3.7.2 Session Description Attributes 3.7.2 Media Session Attributes
A number of additional SDP parameters MAY be used to describe a Media sessions are typically described using out-of-band mechanisms
session. These are defined as media level attributes. to convey transport addresses, codec information, etc. between
sender(s) and receiver(s). Such a mechanisms is composed of a format
used to describe a media session and another mechanism for
transporting this description.
3.7.2.1 Profile identification In the IETF, the Session Description Protocol (SDP) is currently used
to describe media sessions while protocols such as SIP, SAP, RTSP,
and HTTP are used to convey the description.
A present media session description format MAY include parameters to
indicate that RTCP feedback mechanisms are supported in this session
and which of the feedback mechanisms may be applied.
To do so, the profile "AVPF" MUST be indicated instead of "AVP".
Further attributes may be defined to show which type(s) of feedback
are supported.
Section 4 contains the syntax specification to support RTCP feedback
with SDP. Similar specifications for other media session description
formats are outside the scope of this specification.
4. SDP Definitions
Ott et al. Expires May 2002 [Page 14]
This section defines a number of additional SDP parameters that are
used to describe a session. All of these are defined as media level
attributes.
4.1 Profile identification
The AV profile defined in [4] is referred to as "AVP" in the context The AV profile defined in [4] is referred to as "AVP" in the context
of e.g. the Session Description Protocol (SDP) [3]. The profile of e.g. the Session Description Protocol (SDP) [3]. The profile
specified in this document is referred to as "AVPF". specified in this document is referred to as "AVPF".
Feedback information following the modified timing rules as specified Feedback information following the modified timing rules as specified
in this document MUST NOT be sent for a particular media session in this document MUST NOT be sent for a particular media session
unless the profile for this session indicates the use of the "AVPF" unless the profile for this session indicates the use of the "AVPF"
profile. profile.
Feedback information as part of regularly scheduled compound RTCP 4.2 RTCP Feedback Capability Attribute
packets following the timing rules of [1] and [2] MAY be sent for
media sessions for which the "AVP" profile is specified. In this
case, however, the receiver providing feedback MUST NOT rely on the
sender reacting to the feedback at all.
3.7.2.2 RTCP Feedback Capability Attribute
A new payload format-specific SDP attribute (for use with "a=fmtp:") A new payload format-specific SDP attribute (for use with "a=fmtp:")
is defined to indicate the capability of using RTCP feedback as is defined to indicate the capability of using RTCP feedback as
specified in this document: "rtcp-fb". The "rtcp-fb" attribute MAY specified in this document: "rtcp-fb". The "rtcp-fb" attribute MAY
only be used as an SDP media attribute and MUST NOT be provided at only be used as an SDP media attribute and MUST NOT be provided at
the session level. The rtcp-fb attribute MUST only be used in media the session level. The rtcp-fb attribute MUST only be used in media
sessions for which the "AVPF" is specified. sessions for which the "AVPF" is specified.
The rtcp-fb attribute is used to indicate which RTCP feedback The rtcp-fb attribute is used to indicate which RTCP feedback
messages MAY be used in this media session for the indicated payload messages MAY be used in this media session for the indicated payload
skipping to change at line 771 skipping to change at line 786
that the RTP senders only support generic NACKs. In addition, the that the RTP senders only support generic NACKs. In addition, the
RTP receivers MAY send feedback using other suitable RTCP feedback RTP receivers MAY send feedback using other suitable RTCP feedback
packets as defined for the respective media type. The RTP receivers packets as defined for the respective media type. The RTP receivers
MUST NOT rely on the RTP senders reacting to any of the feedback MUST NOT rely on the RTP senders reacting to any of the feedback
messages. messages.
If one or more rtcp-fb attributes are present in a media session If one or more rtcp-fb attributes are present in a media session
description, the RTP receivers for the media session(s) containing description, the RTP receivers for the media session(s) containing
the "rtcp-fb" the "rtcp-fb"
Ott et al. Expires January 2002 [Page 14]
. MUST ignore all rtcp-fb attributes of which they do not fully . MUST ignore all rtcp-fb attributes of which they do not fully
understand the semantics (i.e. understand the meaning of all understand the semantics (i.e. understand the meaning of all
values in the a=fmtp:rtcp-fb line); values in the a=fmtp:rtcp-fb line);
. SHOULD provide feedback information as specified in this document . SHOULD provide feedback information as specified in this document
using any of the RTCP feedback packets as specified in one of the using any of the RTCP feedback packets as specified in one of the
rtcp-fb attributes for this media session; and rtcp-fb attributes for this media session; and
. MUST NOT use other feedback messages than those listed in one of . MUST NOT use other feedback messages than those listed in one of
the rtcp-fb attribute lines. the rtcp-fb attribute lines.
Ott et al. Expires May 2002 [Page 15]
RTP senders MUST be prepared to receive any kind of RTCP feedback RTP senders MUST be prepared to receive any kind of RTCP feedback
messages and MUST silently discard all those RTCP feedback messages messages and MUST silently discard all those RTCP feedback messages
that they do not understand. that they do not understand.
The syntax of the rtcp-fb attribute is as follows (the feedback types The syntax of the rtcp-fb attribute is as follows (the feedback types
and optional parameters are all case sensitive): and optional parameters are all case sensitive):
rtcp-fb-syntax = "a=fmtp:" <format> WS "rtcp-fb" WS rtcp-fb-value rtcp-fb-syntax = "a=fmtp:" <format> WS "rtcp-fb" WS rtcp-fb-value
rtcp-fb-value = "ack" rtcp-fb-param rtcp-fb-value = "ack" rtcp-fb-param
skipping to change at line 827 skipping to change at line 842
is allowed to operate in ACK mode as defined in 3.6.1.2. is allowed to operate in ACK mode as defined in 3.6.1.2.
Parameters may be provided to further distinguish different Parameters may be provided to further distinguish different
types of positive acknowledgement feedback. If no parameters types of positive acknowledgement feedback. If no parameters
are present, the Generic ACK as specified in section 4.1.2 is are present, the Generic ACK as specified in section 4.1.2 is
implied. implied.
If the parameter "app" is specified, this indicates the use of If the parameter "app" is specified, this indicates the use of
application layer feedback. In this case, additional parameters application layer feedback. In this case, additional parameters
following "app" MAY be used to further differentiate various following "app" MAY be used to further differentiate various
Ott et al. Expires January 2002 [Page 15]
types of application layer feedback. This document does not types of application layer feedback. This document does not
define any parameters specific to "app". define any parameters specific to "app".
Further parameters for "ack" MAY be defined in other documents. Further parameters for "ack" MAY be defined in other documents.
Feedback type "nack": Feedback type "nack":
This feedback type indicates that negative acknowledgements for This feedback type indicates that negative acknowledgements for
feedback are supported. feedback are supported.
Ott et al. Expires May 2002 [Page 16]
The feedback type "nack", without parameters, indicates use of The feedback type "nack", without parameters, indicates use of
the General NACK feedback format as defined in section 4.2.1. the General NACK feedback format as defined in section 4.2.1.
The following three parameters are defined in this document for The following three parameters are defined in this document for
use with "nack" in conjunction with the media type "video": use with "nack" in conjunction with the media type "video":
. "pli" indicates the use of Picture Loss Indication feedback . "pli" indicates the use of Picture Loss Indication feedback
as defined in section 4.3.1. as defined in section 4.3.1.
. "sli" indicates the use of Slice Loss Indication feedback as . "sli" indicates the use of Slice Loss Indication feedback as
defined in section 4.3.2. defined in section 4.3.2.
skipping to change at line 879 skipping to change at line 893
conveyed as feedback types and parameters defined elsewhere. Hence, conveyed as feedback types and parameters defined elsewhere. Hence,
no further provision for any types and parameters is made in this no further provision for any types and parameters is made in this
document. document.
Further types of feedback as well as further parameters may be Further types of feedback as well as further parameters may be
defined in other documents. defined in other documents.
It is up to the recipients whether or not they send feedback It is up to the recipients whether or not they send feedback
information and up to the sender(s) to make use of feedback provided. information and up to the sender(s) to make use of feedback provided.
3.7.2.3 Unicasting 4.3 Unicasting
If an m= line in the SDP describing a session indicates unicast If an m= line in the SDP describing a session indicates unicast
addresses for a particular media type (and does not operate in multi- addresses for a particular media type (and does not operate in multi-
unicast mode with all recipients listed explicitly but still unicast mode with all recipients listed explicitly but still
Ott et al. Expires January 2002 [Page 16]
addressed via unicast), the RTCP feedback MAY operate in ACK feedback addressed via unicast), the RTCP feedback MAY operate in ACK feedback
mode. mode.
3.7.2.4 RTCP Bandwidth Modifiers 4.4 RTCP Bandwidth Modifiers
The standard RTCP bandwidth assignments as defined in [1] and [2] may The standard RTCP bandwidth assignments as defined in [1] and [2] may
be overridden by bandwidth modifiers as specified in [4]: b=RS:<bw> be overridden by bandwidth modifiers as specified in [4]: b=RS:<bw>
Ott et al. Expires May 2002 [Page 17]
and b=RR:<bw> MAY be used to assign a different bandwidth (measured and b=RR:<bw> MAY be used to assign a different bandwidth (measured
in bits per second) to RTP senders and receivers, respectively. The in bits per second) to RTP senders and receivers, respectively. The
precedence rules of [4] apply to determine the actual bandwidth to be precedence rules of [4] apply to determine the actual bandwidth to be
used by senders and receivers. used by senders and receivers.
Applications operating knowingly over highly asymmetric links (such Applications operating knowingly over highly asymmetric links (such
as satellite links) SHOULD use this mechanism to reduce the feedback as satellite links) SHOULD use this mechanism to reduce the feedback
rate for high bandwidth streams to prevent deterministic congestion rate for high bandwidth streams to prevent deterministic congestion
of the feedback path(s). of the feedback path(s).
3.7.2.5 Examples 4.5 Examples
Example 1: The following session description indicates a session made Example 1: The following session description indicates a session made
up from an audio and a DTMF for point-to-point communication in which up from an audio and a DTMF for point-to-point communication in which
the DTMF stream uses Generic ACKs. This session description could be the DTMF stream uses Generic ACKs. This session description could be
contained in a SIP INVITE, 200 OK, or ACK message to indicate that contained in a SIP INVITE, 200 OK, or ACK message to indicate that
its sender is capable of and willing to receive feedback for the DTMF its sender is capable of and willing to receive feedback for the DTMF
stream it transmits. stream it transmits.
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com o=alice 3203093520 3203093520 IN IP4 host.example.com
skipping to change at line 935 skipping to change at line 949
Generic NACKs and Reference Picture Selection. Such a description Generic NACKs and Reference Picture Selection. Such a description
may have been conveyed using the Session Announcement Protocol (SAP). may have been conveyed using the Session Announcement Protocol (SAP).
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback s=Multicast video with feedback
t=3203130148 3203137348 t=3203130148 3203137348
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
c=IN IP4 224.2.1.183 c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 98 m=video 51372 RTP/AVPF 98
c=IN IP4 224.2.1.184 c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=fmtp:98 rtcp-fb nack a=fmtp:98 rtcp-fb nack
a=fmtp:98 rtcp-fb nack rpsi a=fmtp:98 rtcp-fb nack rpsi
Ott et al. Expires January 2002 [Page 17] 5. Interworking and Co-Existence of AVP and AVPF Entities
4. Format of RTCP Feedback messages
The AVPF profile defined in this document is an extension of the AVP
profile as defined in [2]. Both profiles follow the same basic rules
Ott et al. Expires May 2002 [Page 18]
(including the upper bandwidth limit for RTCP and the bandwidth
assignments to senders and receivers. Therefore, senders and
receivers of using either of the two profiles can be mixed in a
single session.
AVP and AVPF are defined in a way that, from a robustness point of
view,, the RTP entities do not need to be aware of entities of the
respective other profile: they will not disturb each other's
functioning. However, the quality of the media presented may suffer.
The following considerations apply to senders and receivers when used
in a combined session.
. AVP entities (senders and receivers)
AVP senders will receive RTCP feedback packets from AVPF receivers
and ignore these packets. They will see occasional closer spacing
of RTCP messages (e.g. violating the 5s rule) by AVPF entities.
As the overall bandwidth constraints are adhered to by both types
of entities, they will still get their share of the RTCP
bandwidth. However, while AVP entities are bound by the 5s rule,
depending on the group size and session bandwidth, AVPF entities
may provide more frequent RTCP reports than AVP ones will. Also,
the overall reporting may decrease slightly as AVPF entities are
may to send bigger RTCP packets (due to the extra fields).
. AVPF senders
AVPF senders will receive feedback information only from AVPF
receivers. If they rely on feedback to provide the target media
quality, the quality achieved for AVP receivers may be sub-
optimal.
. AVPF receivers
AVPF receivers SHOULD send immediate or early RTCP feedback
packets only if all (sending) entities in the media session
support AVPF. AVPF receivers MAY send feedback information as
part of regularly scheduled compound RTCP packets following the
timing rules of [1] and [2] also in media sessions operating in
mixed mode. In this case, however, the receiver providing
feedback MUST NOT rely on the sender reacting to the feedback at
all.
6. Format of RTCP Feedback Messages
This section defines the format of the low delay RTCP feedback This section defines the format of the low delay RTCP feedback
messages. These messages classified into three categories as messages. These messages classified into three categories as
follows: follows:
- Transport layer feedback messages - Transport layer feedback messages
- Payload-specific feedback messages - Payload-specific feedback messages
- Application layer feedback messages - Application layer feedback messages
Ott et al. Expires May 2002 [Page 19]
Transport layer feedback messages are intended to transmit general Transport layer feedback messages are intended to transmit general
purpose feedback information, i.e. information independent of the purpose feedback information, i.e. information independent of the
particular codec or the application in use. The information is particular codec or the application in use. The information is
expected to be generated and processed at the transport/RTP layer. expected to be generated and processed at the transport/RTP layer.
Currently, only a general positive acknowledgement (ACK) and negative Currently, only a general positive acknowledgement (ACK) and negative
acknowledgement (NACK) message are defined. acknowledgement (NACK) message are defined.
Payload-specific feedback messages transport information that is Payload-specific feedback messages transport information that is
specific to a certain payload and will be generated and acted upon at specific to a certain payload and will be generated and acted upon at
the codec "layer". This document defines a common header to be used the codec "layer". This document defines a common header to be used
skipping to change at line 987 skipping to change at line 1051
This document defines two transport layer feedback and three (video) This document defines two transport layer feedback and three (video)
payload-specific feedback messages as well as a container for payload-specific feedback messages as well as a container for
application layer feedback messages. Additional transport layer and application layer feedback messages. Additional transport layer and
payload specific feedback messages may be defined in other documents payload specific feedback messages may be defined in other documents
and are registered through IANA (see section IANA considerations). and are registered through IANA (see section IANA considerations).
The general syntax and semantics for the above RTCP feedback message The general syntax and semantics for the above RTCP feedback message
types is described in the following subsections. types is described in the following subsections.
4.1 Common Packet Format for Feedback Message 6.1 Common Packet Format for Feedback Message
All feedback message share a common packet format that is depicted in All feedback message share a common packet format that is depicted in
figure 3: figure 3:
Ott et al. Expires January 2002 [Page 18]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|E| FMT | PT | length | |V=2|P|0| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender | | SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source | | SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) : : Feedback Control Information (FCI) :
: : : :
Figure 3: Common Packet Format for Feedback Messages Figure 3: Common Packet Format for Feedback Messages
Ott et al. Expires May 2002 [Page 20]
The various fields V, P, SSRC and length are defined in the RTP The various fields V, P, SSRC and length are defined in the RTP
specification [2], the respective meaning being summarized below: specification [2], the respective meaning being summarized below:
version (V): 2 bits version (V): 2 bits
This field identifies the RTP version. The current version is 2. This field identifies the RTP version. The current version is 2.
padding (P): 1 bit padding (P): 1 bit
If set, the padding bit indicates that the packet contains If set, the padding bit indicates that the packet contains
additional padding octets at the end which are not part of the additional padding octets at the end which are not part of the
control information but are included in the length field. control information but are included in the length field.
Early RTCP (E): 1 bit
This bit MUST be set if the packet is sent as an Immediate
Feedback or as an Early RTCP packet.
Feedback message type (FMT): 4 bits Feedback message type (FMT): 4 bits
This field identifies the type of the feedback message and is This field identifies the type of the feedback message and is
interpreted relative to the RTCP message type (transport, interpreted relative to the RTCP message type (transport,
payload-specific, or application feedback). The values for each payload-specific, or application feedback). The values for each
of the three feedback types are defined in the respective of the three feedback types are defined in the respective
sections below. sections below.
Payload type (PT): 8 bits Payload type (PT): 8 bits
This is the RTCP packet type which identifies the packet as being This is the RTCP packet type which identifies the packet as being
an RTCP Feedback Message. Two values are defined (TBA. By IANA): an RTCP Feedback Message. Two values are defined (TBA. By IANA):
skipping to change at line 1047 skipping to change at line 1107
Length: 16 bits Length: 16 bits
The length of this packet in 32-bit words minus one, including The length of this packet in 32-bit words minus one, including
the header and any padding. This is in line with the definition the header and any padding. This is in line with the definition
of the length field used in RTCP sender and receiver reports [3]. of the length field used in RTCP sender and receiver reports [3].
SSRC of packet sender: 32 bits SSRC of packet sender: 32 bits
The synchronization source identifier for the originator of this The synchronization source identifier for the originator of this
packet. packet.
Ott et al. Expires January 2002 [Page 19]
SSRC of media source: 32 bits SSRC of media source: 32 bits
The synchronization source identifier of the media source that The synchronization source identifier of the media source that
this piece of feedback information is related to. this piece of feedback information is related to.
Feedback Control Information (FCI): variable length Feedback Control Information (FCI): variable length
The following three sections define which additional information The following three sections define which additional information
is included in the feedback message for each type of feedback. is included in the feedback message for each type of feedback.
Each RTCP feedback packet MUST contain exactly one FCI field of
the types defined in sections 6.2 and 6.3. If multiple FCI
fields (even of the same type) need to be conveyed, then several
RTCP feedback packets MUST be generated and concatenated in the
same compound RTCP packet.
4.2 Transport Layer Feedback Messages 6.2 Transport Layer Feedback Messages
Transport Layer Feedback messages are identified by the value RTPFB Transport Layer Feedback messages are identified by the value RTPFB
as RTCP message type. as RTCP message type.
Ott et al. Expires May 2002 [Page 21]
Two general purpose transport layer feedback messages are defined so Two general purpose transport layer feedback messages are defined so
far: General ACK and General NACK. They are identified by means of far: General ACK and General NACK. They are identified by means of
the FMT parameter as follows: the FMT parameter as follows:
0: forbidden 0: forbidden
1: General NACK 1: Generic NACK
2: General ACK 2: Generic ACK
3-15: reserved 3: Generic INFO
4-15: reserved
The following two subsections define the packet formats for these The following two subsections define the packet formats for these
messages. messages.
4.2.1 Generic NACK 6.2.1 Generic NACK
The Generic NACK message is identified by PT=RTPFB and FMT=1. The Generic NACK message is identified by PT=RTPFB and FMT=1.
The Generic NACK packet is used to indicate the loss of one or more The Generic NACK packet is used to indicate the loss of one or more
RTP packets. The lost packet(s) are identified by the means of a RTP packets. The lost packet(s) are identified by the means of a
packet identifier and a bit mask. packet identifier and a bit mask.
The Feedback control information (FCI) field has the following The Feedback control information (FCI) field has the following
Syntax (figure 4): Syntax (figure 4):
skipping to change at line 1102 skipping to change at line 1168
Packet ID (PID): 16 bits Packet ID (PID): 16 bits
The PID field is used to specify a lost packet. Typically, the The PID field is used to specify a lost packet. Typically, the
RTP sequence number is used for PID as the default format, but RTP sequence number is used for PID as the default format, but
RTP Payload Formats may decide to identify a packet differently. RTP Payload Formats may decide to identify a packet differently.
bitmask of following lost packets (BLP): 16 bits bitmask of following lost packets (BLP): 16 bits
The BLP allows for reporting losses of any of the 16 RTP packets The BLP allows for reporting losses of any of the 16 RTP packets
immediately following the RTP packet indicated by the PID. The immediately following the RTP packet indicated by the PID. The
BLP's definition is identical to that given in [10]. Denoting BLP's definition is identical to that given in [10]. Denoting
the BLP's least significant bit as bit 1, and its most the BLP's least significant bit as bit 1, and its most
Ott et al. Expires January 2002 [Page 20]
significant bit as bit 16, then bit i of the bit mask is set to 1 significant bit as bit 16, then bit i of the bit mask is set to 1
if the sender has not received RTP packet number PID+i (modulo if the sender has not received RTP packet number PID+i (modulo
2^16) and the receiver decides this packet is lost; bit i is set 2^16) and the receiver decides this packet is lost; bit i is set
to 0 otherwise. Note that the sender MUST NOT assume that a to 0 otherwise. Note that the sender MUST NOT assume that a
receiver has received a packet because its bit mask was set to 0. receiver has received a packet because its bit mask was set to 0.
For example, the least significant bit of the BLP would be set to For example, the least significant bit of the BLP would be set to
1 if the packet corresponding to the PID and the following packet 1 if the packet corresponding to the PID and the following packet
have been lost. However, the sender cannot infer that packets have been lost. However, the sender cannot infer that packets
PID+2 through PID+16 have been received simply because bits 2 PID+2 through PID+16 have been received simply because bits 2
Ott et al. Expires May 2002 [Page 22]
through 15 of the BLP are 0; all the sender knows is that the through 15 of the BLP are 0; all the sender knows is that the
receiver has not reported them as lost at this time. receiver has not reported them as lost at this time.
4.2.2 Generic ACK 6.2.2 Generic ACK
The Generic ACK message is identified by PT=RTPFB and FMT=2. The Generic ACK message is identified by PT=RTPFB and FMT=2.
The Generic ACK packet is used to indicate that one or several RTP The Generic ACK packet is used to indicate that one or several RTP
packets were received correctly. The received packet(s) are packets were received correctly. The received packet(s) are
identified by the means of a packet identifier and a bit mask. identified by the means of a packet identifier and a bit mask.
ACKing of a range of consecutive packets is also possible. ACKing of a range of consecutive packets is also possible.
The Feedback control information (FCI) field has the following The Feedback control information (FCI) field has the following
syntax: syntax:
skipping to change at line 1156 skipping to change at line 1222
carry the number of packets being acknowledged. If R=0 then PID carry the number of packets being acknowledged. If R=0 then PID
specifies the first packet to be acknowledged and BLP/#packets specifies the first packet to be acknowledged and BLP/#packets
provides a bit mask to selectively indicate individual packets provides a bit mask to selectively indicate individual packets
that are acknowledged. that are acknowledged.
Bit mask of lost packets (BLP)/#packets (PID): 15 bits Bit mask of lost packets (BLP)/#packets (PID): 15 bits
The semantics of this field depends on the value of the R-bit. The semantics of this field depends on the value of the R-bit.
If R=1, this field is used to identify the number of additional If R=1, this field is used to identify the number of additional
packets of to be acknowledged: packets of to be acknowledged:
#packets = <highest seq# to be ACKed> - <PID> #packets = <highest seq# to be ACKed> - <PID>
Ott et al. Expires January 2002 [Page 21]
That is, #packets MUST indicate the number of packet to be ACKed That is, #packets MUST indicate the number of packet to be ACKed
minus one. In particular, if only a single packet is to be ACKed minus one. In particular, if only a single packet is to be ACKed
and R=1 then #packets MUST be set to 0x0000. and R=1 then #packets MUST be set to 0x0000.
Example: If all packets between and including PIDx=380 and PIDy = Example: If all packets between and including PIDx=380 and PIDy =
422 have been received, the Generic ACK would contain PID = PIDx 422 have been received, the Generic ACK would contain PID = PIDx
= 380 and #packets = PIDy Ż PID = 42. In case the PID wraps = 380 and #packets = PIDy Ż PID = 42. In case the PID wraps
Ott et al. Expires May 2002 [Page 23]
around, modulo arithmetic is used to calculate the number of around, modulo arithmetic is used to calculate the number of
packets. packets.
If R=0, this field carries a bit mask. The BLP allows for If R=0, this field carries a bit mask. The BLP allows for
reporting reception of any of the 15 RTP packets immediately reporting reception of any of the 15 RTP packets immediately
following the RTP packet indicated by the PID. The BLP's following the RTP packet indicated by the PID. The BLP's
definition is identical to that given in [10] except that, here, definition is identical to that given in [10] except that, here,
BLP is only 15 bits wide. Denoting the BLP's least significant BLP is only 15 bits wide. Denoting the BLP's least significant
bit as bit 1, and its most significant bit as bit 15, then bit i bit as bit 1, and its most significant bit as bit 15, then bit i
of the bitmask is set to 1 if the sender has received RTP packet of the bitmask is set to 1 if the sender has received RTP packet
number PID+i (modulo 2^16) and the receiver decides to ACK this number PID+i (modulo 2^16) and the receiver decides to ACK this
packet; bit i is set to 0 otherwise. If only the packet packet; bit i is set to 0 otherwise. If only the packet
indicated by PID is to be ACKed and R=0 then BLP MUST be set to indicated by PID is to be ACKed and R=0 then BLP MUST be set to
0x0000. 0x0000.
4.3 Payload Specific Feedback Messages 6.2.3 Generic INFO
The Generic INFO message is identified by PT=RTPFB and FMT=3.
The Generic INFO packet MUST only be used in conjunction with an
application-specific feedback message. The Generic INFO message
indicates which RTP packets the payload-specific message is about.
The packet(s) in question are identified by the means of a packet
identifier and a bit mask.
The sole purpose of the Generic INFO packet is to avoid unnecessary
feedback suppression when payload-specific feedback messages are
mixed with generic ones.
The packet format is the same as for the Generic NACK message defined
in section 6.2.3.
6.3 Payload Specific Feedback Messages
Payload-Specific Feedback Messages are identified by the value PSFB Payload-Specific Feedback Messages are identified by the value PSFB
as RTCP message type. as RTCP message type.
Three payload-specific feedback messages are defined so far. They Three payload-specific feedback messages are defined so far. They
are identified by means of the FMT parameter as follows: are identified by means of the FMT parameter as follows:
0: forbidden 0: forbidden
1: Picture Loss Indication (PLI) 1: Picture Loss Indication (PLI)
2: Slice Lost Indication (SLI) 2: Slice Lost Indication (SLI)
3: Reference Picture Selection Indication (RPSI) 3: Reference Picture Selection Indication (RPSI)
4-14: reserved 4-14: reserved
15: Application layer feedback message 15: Application layer feedback message
The following subsections define the packet formats for these The following subsections define the packet formats for these
messages. messages.
4.3.1 Picture Loss Indication (PLI) AVPF entities MUST include Generic INFO messages along with any
payload-specific ones in compound RTCP packets (early as well as
regularly scheduled ones). The INFO message(s) MUST cover all the
Ott et al. Expires May 2002 [Page 24]
RTP packets to which the payload-specific message(s) apply. This is
to avoid that AVPF entities that do not understand the payload-
specific messages unnecessarily suppress their feedback messages.
6.3.1 Picture Loss Indication (PLI)
The PLI feedback message is identified by PT=PSFB and FMT=1. The PLI feedback message is identified by PT=PSFB and FMT=1.
4.3.1.1 Semantics 6.3.1.1 Semantics
With the Picture Loss Indication message a decoder informs the With the Picture Loss Indication message a decoder informs the
encoder about the loss of one or more full pictures. encoder about the loss of one or more full pictures.
4.3.1.2 Message Format 6.3.1.2 Message Format
PLI does not require parameters. Therefore, the length field MUST be PLI does not require parameters. Therefore, the length field MUST be
2, and there MUST NOT be any Feedback Control Information. 2, and there MUST NOT be any Feedback Control Information.
Ott et al. Expires January 2002 [Page 22] 6.3.1.3 Timing Rules
4.3.1.3 Timing Rules
The timing follows the rules outlined in section 3. In systems that The timing follows the rules outlined in section 3. In systems that
employ both PLI and other types of feedback it may be advisable to employ both PLI and other types of feedback it may be advisable to
follow the regular RTCP RR timing rules for PLI, since PLI is not as follow the regular RTCP RR timing rules for PLI, since PLI is not as
delay critical as other FB types. delay critical as other FB types.
4.3.1.4 Remarks 6.3.1.4 Remarks
PLI messages typically trigger the sending of full Intra pictures. PLI messages typically trigger the sending of full Intra pictures.
Intra Pictures are several times larger then predicted (Inter) Intra Pictures are several times larger then predicted (Inter)
pictures. Their size is independent of the time they are generated. pictures. Their size is independent of the time they are generated.
In most environments, especially when employing bandwidth-limited In most environments, especially when employing bandwidth-limited
links, the use of an Intra picture implies an allowed delay that is a links, the use of an Intra picture implies an allowed delay that is a
significant multitude of the typical frame duration. An example: If significant multitude of the typical frame duration. An example: If
the sending frame rate is 10 fps, and an Intra picture is assumed to the sending frame rate is 10 fps, and an Intra picture is assumed to
be 10 times as big as an Inter picture (not an unrealistic be 10 times as big as an Inter picture (not an unrealistic
assumption, see [14] for details), then a full second of latency has assumption, see [14] for details), then a full second of latency has
to be accepted. In such an environment there is no need for a to be accepted. In such an environment there is no need for a
particular short delay in sending the feedback message. Hence particular short delay in sending the feedback message. Hence
waiting for the next possible time slot allowed by RTCP timing rules waiting for the next possible time slot allowed by RTCP timing rules
as per [2] does not have a negative impact on the system performance. as per [2] does not have a negative impact on the system performance.
4.3.2 Slice Lost Indication (SLI) 6.3.2 Slice Lost Indication (SLI)
The SLI feedback message is identified by PT=PSFB and FMT=2. The SLI feedback message is identified by PT=PSFB and FMT=2.
4.3.2.1 Semantics Ott et al. Expires May 2002 [Page 25]
6.3.2.1 Semantics
With the Slice Lost Indication a decoder can inform an encoder that With the Slice Lost Indication a decoder can inform an encoder that
it was unable to decode one, or several consecutive, macroblocks. it was unable to decode one, or several consecutive, macroblocks.
The encoder can take appropriate action in order to re-synchronize The encoder can take appropriate action in order to re-synchronize
encoder and decoder by means of its choice, typically by sending the encoder and decoder by means of its choice, typically by sending the
lost macroblocks in Intra mode. This feedback message SHALL NOT be lost macroblocks in Intra mode. This feedback message SHALL NOT be
used for video codecs with non-uniform, dynamically changeable used for video codecs with non-uniform, dynamically changeable
macroblock sizes such as H.263 with enabled Annex Q. In such a case, macroblock sizes such as H.263 with enabled Annex Q. In such a case,
an encoder cannot always identify the corrupted spatial region. an encoder cannot always identify the corrupted spatial region.
4.3.2.2 Format 6.3.2.2 Format
When FBT indicates a Slice Lost Indication, then there is one When FBT indicates a Slice Lost Indication, then there is one
additional PCI field the content of which is depicted in figure 6. additional PCI field the content of which is depicted in figure 6.
The length of the feedback message MUST be set to 3. The length of the feedback message MUST be set to 3.
Ott et al. Expires January 2002 [Page 23]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First | Number | TR | | First | Number | TR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Syntax of the Slice Lost Indication (SLI) Figure 6: Syntax of the Slice Lost Indication (SLI)
First: 13 bits First: 13 bits
The macroblock (MB) address of the first lost macroblock. The MB The macroblock (MB) address of the first lost macroblock. The MB
skipping to change at line 1283 skipping to change at line 1376
total of N macroblocks in a picture, the bottom right macroblock total of N macroblocks in a picture, the bottom right macroblock
is considered macroblock number N). is considered macroblock number N).
Number: 13 bits Number: 13 bits
The number of lost macroblocks, in scan order as discussed above. The number of lost macroblocks, in scan order as discussed above.
TR: 6 bits TR: 6 bits
The six least significant bits of the Temporal Reference of the The six least significant bits of the Temporal Reference of the
picture. picture.
4.3.2.3 Timing Rules 6.3.2.3 Timing Rules
The efficiency of algorithms using the Slice Lost Indication is The efficiency of algorithms using the Slice Lost Indication is
reduced greatly when the Indication is not transmitted in a timely reduced greatly when the Indication is not transmitted in a timely
fashion. Motion compensation propagates corrupted pixels that are fashion. Motion compensation propagates corrupted pixels that are
not reported as being corrupted. Therefore, the use of the algorithm not reported as being corrupted. Therefore, the use of the algorithm
discussed in section 3 is highly recommended. discussed in section 3 is highly recommended.
4.3.2.4 Remarks Ott et al. Expires May 2002 [Page 26]
6.3.2.4 Remarks
The First field of the UCI defines the first macroblock of a picture The First field of the UCI defines the first macroblock of a picture
as 1 and not, as one could suspect, as 0. This was done to align as 1 and not, as one could suspect, as 0. This was done to align
this specification with the comparable mechanism available in H.245. this specification with the comparable mechanism available in H.245.
The maximum number of macroblocks in a picture (2**13 or 8192) The maximum number of macroblocks in a picture (2**13 or 8192)
corresponds to the maximum picture sizes of the ITU-T and ISO/IEC corresponds to the maximum picture sizes of the ITU-T and ISO/IEC
video codecs. If future video codecs offer larger picture sizes video codecs. If future video codecs offer larger picture sizes
and/or smaller macroblock sizes, then an additional feedback message and/or smaller macroblock sizes, then an additional feedback message
has to be defined. The six least significant bits of the Temporal has to be defined. The six least significant bits of the Temporal
Reference field are deemed to be sufficient to indicate the picture Reference field are deemed to be sufficient to indicate the picture
skipping to change at line 1313 skipping to change at line 1407
Algorithms were reported that keep track of the regions effected by Algorithms were reported that keep track of the regions effected by
motion compensation, in order to allow for a transmission of Intra motion compensation, in order to allow for a transmission of Intra
macroblocks to all those areas, regardless of the timing of the FB macroblocks to all those areas, regardless of the timing of the FB
(see H.263 (2000) Appendix I [13]] and [15]. While, when those (see H.263 (2000) Appendix I [13]] and [15]. While, when those
algorithms are used, the timing of the FB is less critical then algorithms are used, the timing of the FB is less critical then
without, it has to be observed that those algorithms correct large without, it has to be observed that those algorithms correct large
parts of the picture and, therefore, have to transmit many for bits parts of the picture and, therefore, have to transmit many for bits
in case of delayed FBs. in case of delayed FBs.
Ott et al. Expires January 2002 [Page 24] 6.3.3 Reference Picture Selection Indication (RPSI)
4.3.3 Reference Picture Selection Indication (RPSI)
The RPSI feedback message is identified by PT=PSFB and FMT=3. The RPSI feedback message is identified by PT=PSFB and FMT=3.
4.3.3.1 Semantics 6.3.3.1 Semantics
Modern video coding standards such as MPEG-4 visual version 2 [12] or Modern video coding standards such as MPEG-4 visual version 2 [12] or
H.263 version 2 [13] allow the use of older reference pictures then H.263 version 2 [13] allow the use of older reference pictures then
the most recent one. Typically, a first-in-first-out queue of the most recent one. Typically, a first-in-first-out queue of
reference pictures is maintained. If an encoder has learned about a reference pictures is maintained. If an encoder has learned about a
loss of encoder-decoder synchronicity, a known-as-correct reference loss of encoder-decoder synchronicity, a known-as-correct reference
picture can be used. As this reference picture is temporally further picture can be used. As this reference picture is temporally further
away then usual, the resulting predictively coded picture will use away then usual, the resulting predictively coded picture will use
more bits. more bits.
skipping to change at line 1345 skipping to change at line 1438
Note that both MPEG-4 and H.263 allow the use of RPSI with positive Note that both MPEG-4 and H.263 allow the use of RPSI with positive
feedback information as well. That is, all corrected pictures are feedback information as well. That is, all corrected pictures are
reported. Any form of positive feedback MUST NOT be used when in a reported. Any form of positive feedback MUST NOT be used when in a
multicast environment (reporting positive feedback about individual multicast environment (reporting positive feedback about individual
reference pictures at RTCP intervals is not expected to be of much reference pictures at RTCP intervals is not expected to be of much
use anyway). For point-to-point communication, positive feedback MAY use anyway). For point-to-point communication, positive feedback MAY
be used but, again, the bit rate budget of RTCP feedback will prevent be used but, again, the bit rate budget of RTCP feedback will prevent
the use in most scenarios anyway. the use in most scenarios anyway.
4.3.3.2 Format Ott et al. Expires May 2002 [Page 27]
6.3.3.2 Format
When FB indicates an RPSI, then the length field is set to the number When FB indicates an RPSI, then the length field is set to the number
of bits of the following bit string that contains the RPS of bits of the following bit string that contains the RPS
information. This bit string follows byte aligned in the UCI field. information. This bit string follows byte aligned in the UCI field.
Bit padding is used to achieve 32-bit word alignment of the UCI Bit padding is used to achieve 32-bit word alignment of the UCI
message (and the whole packet). message (and the whole packet).
4.3.3.3 Timing Rules 6.3.3.3 Timing Rules
RPS is even more critical to delay then algorithms using SLI. This RPS is even more critical to delay then algorithms using SLI. This
is due to the fact that the older the RPS message is, the more bits is due to the fact that the older the RPS message is, the more bits
the encoder has to spend to achieve encoder-decoder synchronicity. the encoder has to spend to achieve encoder-decoder synchronicity.
See [14] and [15] for some information about the overhead of RPS for See [14] and [15] for some information about the overhead of RPS for
certain bit rate/frame rate/loss rate scenarios. certain bit rate/frame rate/loss rate scenarios.
Therefore, RPS messages should typically be sent as soon as possible, Therefore, RPS messages should typically be sent as soon as possible,
employing the algorithm of section 3. employing the algorithm of section 3.
Ott et al. Expires January 2002 [Page 25] 6.4 Application Layer Feedback Messages
4.4 Application Layer Feedback Messages
Payload-Specific Feedback Messages are a special case of payload- Payload-Specific Feedback Messages are a special case of payload-
specific messages and identified by PT=PSFB and FMT=15. specific messages and identified by PT=PSFB and FMT=15.
These messages are used to transport application defined data These messages are used to transport application defined data
directly from the receiver's to the sender's application. The data directly from the receiver's to the sender's application. The data
that is transported is not identified by the feedback message. that is transported is not identified by the feedback message.
Therefore the application must be able to identify the messages Therefore the application must be able to identify the messages
payload. payload.
skipping to change at line 1389 skipping to change at line 1482
message. Thus the application message is simply placed into the FCI message. Thus the application message is simply placed into the FCI
field as follows and the length field is set accordingly. field as follows and the length field is set accordingly.
Application Message (FCI): variable length Application Message (FCI): variable length
This field contains the original application message that should This field contains the original application message that should
be transported from the receiver to the source. The format is be transported from the receiver to the source. The format is
application dependent. The length of this field is variable. If application dependent. The length of this field is variable. If
the application data is not four-byte aligned, padding must be the application data is not four-byte aligned, padding must be
added. added.
As there is no need for additional identification at the RTCP level, 7. Early Feedback and Congestion Control
the FMT field is unused and MUST be set to zero:
5. Early Feedback and Congestion Control
In the previous sections, the feedback messages were defined as well In the previous sections, the feedback messages were defined as well
as the timing rules according to which to send these messages. The as the timing rules according to which to send these messages. The
way to react to the feedback received depends on the application way to react to the feedback received depends on the application
using the feedback mechanisms and hence is beyond the scope of this using the feedback mechanisms and hence is beyond the scope of this
document. document.
Ott et al. Expires May 2002 [Page 28]
However, across all applications, there is a common requirement for However, across all applications, there is a common requirement for
(TCP-friendly) congestion control on the media stream as defined in (TCP-friendly) congestion control on the media stream as defined in
[1] and [2] when operating in a best-effort network environment. [1] and [2] when operating in a best-effort network environment.
Low delay feedback supports the use of congestion control algorithms Low delay feedback supports the use of congestion control algorithms
in two ways: in two ways:
. The potentially more frequent RTCP messagesallow the sender to . The potentially more frequent RTCP messagesallow the sender to
monitor the network state more closely than with regular RTCP monitor the network state more closely than with regular RTCP
and therefore enable reacting to upcoming congestion in a more and therefore enable reacting to upcoming congestion in a more
timely fashion. timely fashion.
. The feedback messages themselves may convey additional . The feedback messages themselves may convey additional
information as input to congestion control algorithms and thus information as input to congestion control algorithms and thus
improve reaction over conventional RTCP. (For example, ACK-based improve reaction over conventional RTCP. (For example, ACK-based
feedback may even allow to construct closed loop algorithms and feedback may even allow to construct closed loop algorithms and
Ott et al. Expires January 2002 [Page 26]
NACK-based systems may provide further information on the packet NACK-based systems may provide further information on the packet
loss distribution.) loss distribution.)
A congestion control algorithm that shares the available bandwidth A congestion control algorithm that shares the available bandwidth
fair with competing TCP connections, e.g. TFRC [16], SHOULD be used fair with competing TCP connections, e.g. TFRC [16], SHOULD be used
to determine the data rate for the media stream (if the low delay RTP to determine the data rate for the media stream (if the low delay RTP
session is transmitted in a best effort environment). session is transmitted in a best effort environment).
RTCP feedback messages or RTCP SR/RR packets that indicate recent RTCP feedback messages or RTCP SR/RR packets that indicate recent
packet loss MUST NOT lead to a (mid-term) increase in the packet loss MUST NOT lead to a (mid-term) increase in the
transmission data rate and SHOULD lead to a (short-term) decrease of transmission data rate and SHOULD lead to a (short-term) decrease of
the transmission data rate. Such messages SHOULD cause the sender to the transmission data rate. Such messages SHOULD cause the sender to
adjust the transmission data rate to the order of the throughput TCP adjust the transmission data rate to the order of the throughput TCP
would achieve under similar conditions (e.g. using TFRC). would achieve under similar conditions (e.g. using TFRC).
RTCP feedback messages or RTCP SR/RR packets that indicate no recent RTCP feedback messages or RTCP SR/RR packets that indicate no recent
packet loss MAY cause the sender to increase the transmission data packet loss MAY cause the sender to increase the transmission data
rate to roughly the throughput TCP would achieve under similar rate to roughly the throughput TCP would achieve under similar
conditions (e.g. using TFRC). conditions (e.g. using TFRC).
6. Security Considerations 8. Security Considerations
RTP packets transporting information with the proposed payload for RTP packets transporting information with the proposed payload for
mat are subject to the security considerations discussed in the RTP mat are subject to the security considerations discussed in the RTP
specification [1]. This implies that confidentiality of the media specification [1] and in the RTP/AVP profile specification [2].
streams is achieved by encryption. This profile does not specify any different security services.
If the entire stream (extension data and AU data) is to be secured This profile modifies the timing behavior of RTCP and eliminates the
and all the participants are expected to have the keys to decode the minimum RTCP interval of 5 seconds and allows for earlier feedback to
entire stream, then the encryption is performed in the usual manner, be provided by receivers. This approach does not increase the
and there is no conflict between the two operations (encapsulation potential for denial-of-service attacks beyond those discussed in [1]
and encryption). and [2].
The need for a portion of stream (e.g. extension data) to be Feedback information is suppressed if unknown RTCP feedback packets
encrypted with a different key, or not to be encrypted, would require are received. This introduces the risk of a malicious group member
application level signaling protocols to be aware of the usage of eliminating all early feedback by simply transmitting payload-
the XT field, and to exchange keys and negotiate their usage on the specific RTCP feedback packets with random contents that are neither
media and extension data separately.
7. IANA Considerations Ott et al. Expires May 2002 [Page 29]
recognized by any receiver (so they will suppress feedback) nor by
the sender (so no repair actions will be taken).
A malicious group member can also report arbitrary high loss rates in
the feedback information to make the sender throttle the data
transmission and increase the amount of redundancy information or
take other action to deal with the pretended packet loss. This may
result in a degradation of the quality of the reproduced media
stream.
Finally, a malicious group member can act as a large number of group
members and thereby obtain an artificially large share of the early
feedback bandwidth and reduce the reactivity of the other group
members -- possibly even causing them to no longer operate in
immediate or early feedback mode and thus undermining the whole
purpose of this profile.
9. IANA Considerations
The feedback profile as an extension to the profile for audio-visual The feedback profile as an extension to the profile for audio-visual
conferences with minimal control needs to be registered: "AVPF". conferences with minimal control needs to be registered: "RTP/AVPF".
For the Session Description Protocol, the following "fmtp:" attribute For the Session Description Protocol, the following "fmtp:" attribute
needs to be registered: "rtcp-fb". needs to be registered: "rtcp-fb".
Along with "rtcp-fb", the feedback types "ack" and "nack" need to be Along with "rtcp-fb", the feedback types "ack" and "nack" need to be
registered. registered.
Along with "nack", the feedback type parameters "sli", "pli", and Along with "nack", the feedback type parameters "sli", "pli", and
"rpsi" need to be registered. "rpsi" need to be registered.
Ott et al. Expires January 2002 [Page 27]
Two RTCP Control Packet Types: for the class of transport layer Two RTCP Control Packet Types: for the class of transport layer
feedback messages ("RTPFB") and for the class of payload-specific feedback messages ("RTPFB") and for the class of payload-specific
feedback messages ("PSFB"). feedback messages ("PSFB").
Within the RTPFB range, three format (FMT) values need to be Within the RTPFB range, three format (FMT) values need to be
registered: registered:
0: forbidden 0: forbidden
1: General NACK 1: General NACK
2: General ACK 2: General ACK
Within the PSFB range, five format (FMT) values need to be Within the PSFB range, five format (FMT) values need to be
registered: registered:
0: forbidden 0: forbidden
1: Picture Loss Indication (PLI) 1: Picture Loss Indication (PLI)
2: Slice Loss Indication (SLI) 2: Slice Loss Indication (SLI)
3: Reference Picture Selection Indication (SLI) 3: Reference Picture Selection Indication (SLI)
15: Application layer feedback (AFB) 15: Application layer feedback (AFB)
8. Acknowledgements Ott et al. Expires May 2002 [Page 30]
10. Acknowledgements
This document is a product of the Audio-Visual Transport (AVT) This document is a product of the Audio-Visual Transport (AVT)
Working Group of the IETF. The authors would like to thank Steve Working Group of the IETF. The authors would like to thank Steve
Casner and Colin Perkins for their comments and suggestions as well Casner and Colin Perkins for their comments and suggestions as well
as for their responsiveness to numerous questions. as for their responsiveness to numerous questions.
9. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. included on all such copies and derivative works.
skipping to change at line 1528 skipping to change at line 1633
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Ott et al. Expires January 2002 [Page 28] 12. Authors' Addresses
10. Authors' Addresses
Jųrg Ott {sip,mailto}:jo@tzi.uni-bremen.de Jųrg Ott {sip,mailto}:jo@tzi.org
UniversitĄt Bremen TZI UniversitĄt Bremen TZI
MZH 5180 MZH 5180
Bibliothekstr. 1 Bibliothekstr. 1
D-28359 Bremen D-28359 Bremen
Germany Germany
Stephan Wenger stewe@cs.tu-berlin.de Stephan Wenger stewe@cs.tu-berlin.de
TU Berlin TU Berlin
Sekr. FR 6-3 Sekr. FR 6-3
Franklinstr. 28-29 Franklinstr. 28-29
D-10587 Berlin D-10587 Berlin
Germany Germany
Ott et al. Expires May 2002 [Page 31]
Shigeru Fukunaga Shigeru Fukunaga
Oki Electric Industry Co., Ltd. Oki Electric Industry Co., Ltd.
1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan
Tel. +81 6 6949 5101 Tel. +81 6 6949 5101
Fax. +81 6 6949 5108 Fax. +81 6 6949 5108
Mail fukunaga444@oki.co.jp Mail fukunaga444@oki.com
Noriyuki Sato Noriyuki Sato
Oki Electric Industry Co., Ltd. Oki Electric Industry Co., Ltd.
1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan
Tel. +81 6 6949 5101 Tel. +81 6 6949 5101
Fax. +81 6 6949 5108 Fax. +81 6 6949 5108
Mail sato652@oki.co.jp Mail sato652@oki.com
Koichi Yano Koichi Yano
FastForward Networks, FastForward Networks,
75 Hawthorne St. #601 75 Hawthorne St. #601
San Francisco, CA 94105 San Francisco, CA 94105
Tel. +1.415.430.2500 Tel. +1.415.430.2500
Akihiro Miyazaki Akihiro Miyazaki
Matsushita Electric Industrial Co., Ltd Matsushita Electric Industrial Co., Ltd
1006, Kadoma, Kadoma City, Osaka, Japan 1006, Kadoma, Kadoma City, Osaka, Japan
skipping to change at line 1579 skipping to change at line 1684
Fax. +81-6-6900-9193 Fax. +81-6-6900-9193
Mail akihiro@isl.mei.co.jp Mail akihiro@isl.mei.co.jp
Koichi Hata Koichi Hata
Matsushita Electric Industrial Co., Ltd Matsushita Electric Industrial Co., Ltd
1006, Kadoma, Kadoma City, Osaka, Japan 1006, Kadoma, Kadoma City, Osaka, Japan
Tel. +81-6-6900-9192 Tel. +81-6-6900-9192
Fax. +81-6-6900-9193 Fax. +81-6-6900-9193
Mail hata@isl.mei.co.jp Mail hata@isl.mei.co.jp
Ott et al. Expires January 2002 [Page 29]
Rolf Hakenberg Rolf Hakenberg
Panasonic European Laboratories GmbH Panasonic European Laboratories GmbH
Monzastr. 4c, 63225 Langen, Germany Monzastr. 4c, 63225 Langen, Germany
Tel. +49-(0)6103-766-162 Tel. +49-(0)6103-766-162
Fax. +49-(0)6103-766-166 Fax. +49-(0)6103-766-166
Mail hakenberg@panasonic.de Mail hakenberg@panasonic.de
Carsten Burmeister Carsten Burmeister
Panasonic European Laboratories GmbH Panasonic European Laboratories GmbH
Monzastr. 4c, 63225 Langen, Germany Monzastr. 4c, 63225 Langen, Germany
Tel. +49-(0)6103-766-263 Tel. +49-(0)6103-766-263
Fax. +49-(0)6103-766-166 Fax. +49-(0)6103-766-166
Mail burmeister@panasonic.de Mail burmeister@panasonic.de
11. Bibliography 11. Bibliography
[1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP - [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP -
A Transport Protocol for Real-time Applications," Internet A Transport Protocol for Real-time Applications," Internet
Draft, draft-ietf-avt-rtp-new-09.txt, Work in Progress, March Draft, draft-ietf-avt-rtp-new-10.txt, Work in Progress, July
2001. 2001.
Ott et al. Expires May 2002 [Page 32]
[2] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video [2] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control," Internet Draft draft-ietf- Conferences with Minimal Control," Internet Draft draft-ietf-
avt-profile-new-10.txt, March 2001. avt-profile-new-11.txt, July 2001.
[3] M. Handley and V. Jacobson, "SDP: Session Description Protocol", [3] M. Handley and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998. RFC 2327, April 1998.
[4] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", [4] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth",
Internet Draft draft-ietf-avt-rtcp-bw-03.txt, March 2001. Internet Draft draft-ietf-avt-rtcp-bw-03.txt, July 2001.
[5] C. Perkins and O. Hodson, "2354 Options for Repair of Streaming [5] C. Perkins and O. Hodson, "2354 Options for Repair of Streaming
Media," RFC 2354, June 1998. Media," RFC 2354, June 1998.
[6] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for [6] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction,", RFC 2733, December 1999. Generic Forward Error Correction,", RFC 2733, December 1999.
[7] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. [7] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C.
Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload for Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload for
Redundant Audio Data," RFC 2198, September 1997. Redundant Audio Data," RFC 2198, September 1997.
skipping to change at line 1635 skipping to change at line 1740
Telephony Tones and Telephony Signals," RFC 2833, May 2000. Telephony Tones and Telephony Signals," RFC 2833, May 2000.
[10] T. Turletti and C. Huitema, "RTP Payload Format for H.261 Video [10] T. Turletti and C. Huitema, "RTP Payload Format for H.261 Video
Streams, RFC 2032, October 1996. Streams, RFC 2032, October 1996.
[11] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. [11] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D.
Newell, J. Ott, G. Sullivan, S. Wenger, and C. Zhu, "RTP Payload Newell, J. Ott, G. Sullivan, S. Wenger, and C. Zhu, "RTP Payload
Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)," Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+),"
RFC 2429, October 1998. RFC 2429, October 1998.
Ott et al. Expires January 2002 [Page 30]
[12] ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology - [12] ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology -
Coding of audio-visual objects - Part2: Visual", July 2000. Coding of audio-visual objects - Part2: Visual", July 2000.
[13] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate [13] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate
Communication," November 2000. Communication," November 2000.
[14] S. Wenger, "Media-aware Protocols -- transport aware Media [14] S. Wenger, "Media-aware Protocols -- transport aware Media
Coding," Habilitation thesis, in preparation, 2001. Coding," Habilitation thesis, in preparation, 2001.
[15] B. Girod, N. Faerber, "Feedback-based error control for mobile [15] B. Girod, N. Faerber, "Feedback-based error control for mobile
video transmission," Proceedings IEEE, Vol. 87, No. 10, pp. 1707 video transmission," Proceedings IEEE, Vol. 87, No. 10, pp. 1707
Ż 1723, October, 1999. Ż 1723, October, 1999.
[16] M. Handley, J. Padhye, S. Floyd, J. Widmer, "TCP friendly Rate [16] M. Handley, J. Padhye, S. Floyd, J. Widmer, "TCP friendly Rate
Control (TFRC): Protocol Specification," Internet Draft, draft- Control (TFRC): Protocol Specification," Internet Draft, draft-
ietf-tsvwg-02.txt, Work in Progress, May 2001. ietf-tsvwg-02.txt, Work in Progress, May 2001.
Ott et al. Expires January 2002 [Page 31] Ott et al. Expires May 2002 [Page 33]
Appendix A. Some Background and Motivation (Informative) Appendix A. Some Background and Motivation (Informative)
A.1 Example: Predictive Video Coding A.1 Example: Predictive Video Coding
A.1.1 Video Encoder-decoder synchronicity A.1.1 Video Encoder-decoder synchronicity
Most current video coding schemes for compressed video, such as the Most current video coding schemes for compressed video, such as the
ITU-T H.261 and H.263 and ISO/IEC MPEG[124] employ a mechanism known ITU-T H.261 and H.263 and ISO/IEC MPEG[124] employ a mechanism known
as Inter Picture Prediction. Each picture is divided into as Inter Picture Prediction. Each picture is divided into
macroblocks of uniform size. For each macroblock, one or more macroblocks of uniform size. For each macroblock, one or more
skipping to change at line 1708 skipping to change at line 1812
an even better one but is inappropriate for low-delay (interactive) an even better one but is inappropriate for low-delay (interactive)
real-time systems.) FEC schemes, interleaving, and other means for real-time systems.) FEC schemes, interleaving, and other means for
repairing real-time media streams may also add additional delay and repairing real-time media streams may also add additional delay and
significant bit rate overhead without being able to guarantee significant bit rate overhead without being able to guarantee
compensation of virtually all packet losses. compensation of virtually all packet losses.
Once the encoder-decoder synchronicity is lost, only source coding Once the encoder-decoder synchronicity is lost, only source coding
oriented mechanisms can help to regain it. One common way is to send oriented mechanisms can help to regain it. One common way is to send
a non-predictively coded picture (known as Intra picture). Intra a non-predictively coded picture (known as Intra picture). Intra
pictures have the disadvantage of being several times bigger than pictures have the disadvantage of being several times bigger than
Ott et al. Expires May 2002 [Page 34]
predictively coded pictures (Inter pictures). Therefore, sending predictively coded pictures (Inter pictures). Therefore, sending
Intra pictures has negative implications both on the bandwidth and Intra pictures has negative implications both on the bandwidth and
Ott et al. Expires January 2002 [Page 32]
(in bandwidth limited environments) delay. Another way is to use (in bandwidth limited environments) delay. Another way is to use
Intra macroblock refresh. Here, certain parts of the picture (those Intra macroblock refresh. Here, certain parts of the picture (those
affected by a packet loss) are coded non-predictively in order to affected by a packet loss) are coded non-predictively in order to
resynchronize the encoder and decoder over time. Intra macroblock resynchronize the encoder and decoder over time. Intra macroblock
refresh has better delay characteristics then full Intra pictures refresh has better delay characteristics then full Intra pictures
because the picture size can be kept constant, but is less efficient because the picture size can be kept constant, but is less efficient
in terms of bit rate/distortion than full Intra pictures. More in terms of bit rate/distortion than full Intra pictures. More
sophisticated means such as Reference Picture Selection (RPS) are sophisticated means such as Reference Picture Selection (RPS) are
also available in modern video coding standards. also available in modern video coding standards.
skipping to change at line 1763 skipping to change at line 1867
and/or multicast environments is a complex matter and subject of a and/or multicast environments is a complex matter and subject of a
lot of engineering and research in and outside of the IETF. This lot of engineering and research in and outside of the IETF. This
specification is not concerned with pure transport-based feedback. specification is not concerned with pure transport-based feedback.
Source coding based mechanisms may react upon the arrival of a Source coding based mechanisms may react upon the arrival of a
feedback message indicating a loss situation by adding bits that feedback message indicating a loss situation by adding bits that
restore, or at least make an effort to restore, the encoder-decoder restore, or at least make an effort to restore, the encoder-decoder
synchronicity. This process has to be performed by a real-time synchronicity. This process has to be performed by a real-time
encoder. However, schemes were reported, that allow the use of encoder. However, schemes were reported, that allow the use of
feedback also for non-real-time encoders by storing multiple feedback also for non-real-time encoders by storing multiple
Ott et al. Expires May 2002 [Page 35]
representations of the same data (e.g. Inter and Intra coded), and representations of the same data (e.g. Inter and Intra coded), and
dynamically switching between those representations. dynamically switching between those representations.
Several types of feedback messages, called Feedback Messages or FB Several types of feedback messages, called Feedback Messages or FB
messages, can be defined for such a case. An FB message can be as messages, can be defined for such a case. An FB message can be as
Ott et al. Expires January 2002 [Page 33]
simple as a Boolean condition, indicating for example the loss of a simple as a Boolean condition, indicating for example the loss of a
full picture (and, therefore, the need of a full Intra picture full picture (and, therefore, the need of a full Intra picture
transmission). Other feedback messages may contain more complex transmission). Other feedback messages may contain more complex
information such as information about the damage of a spatial region information such as information about the damage of a spatial region
of the picture. A special form consists of a message the format and of the picture. A special form consists of a message the format and
semantics of which are not known at the transport level, because they semantics of which are not known at the transport level, because they
are defined in the video codec standards. are defined in the video codec standards.
A.2 Feedback Messages A.2 Feedback Messages
skipping to change at line 1817 skipping to change at line 1921
problem on the forward channel. Any reaction to negative feedback problem on the forward channel. Any reaction to negative feedback
generates additional bits, which have to be conveyed but this is generates additional bits, which have to be conveyed but this is
taken from the sender∆s total bit rate budget. The encoder can take taken from the sender∆s total bit rate budget. The encoder can take
this into account by, for example, changing the encoding mode, packet this into account by, for example, changing the encoding mode, packet
size, and so forth. The sender is also free to simply ignore size, and so forth. The sender is also free to simply ignore
feedback messages. Adjusting the tradeoff between the reproduced feedback messages. Adjusting the tradeoff between the reproduced
media quality of all receivers of a multicast group and the amount of media quality of all receivers of a multicast group and the amount of
additional repair traffic is a media-dependent, very complex task and additional repair traffic is a media-dependent, very complex task and
is not covered in this specification. is not covered in this specification.
Ott et al. Expires May 2002 [Page 36]
Finally, frequent RTCP-based feedback messages may provide additional Finally, frequent RTCP-based feedback messages may provide additional
input to the sender(s)'s congestion control algorithms and thus input to the sender(s)'s congestion control algorithms and thus
improve its reactivity towards network congestion. improve its reactivity towards network congestion.
Feedback messages as well as sender and receiver behavior are to be Feedback messages as well as sender and receiver behavior are to be
specified in separate documents (such as [7]). Such specifications specified in separate documents (such as [7]). Such specifications
need to consider that, frequently, packet loss is an indication of need to consider that, frequently, packet loss is an indication of
network congestion and thus define mechanisms for media-specific network congestion and thus define mechanisms for media-specific
Ott et al. Expires January 2002 [Page 34]
congestion control in the presence of feedback as defined in this congestion control in the presence of feedback as defined in this
memo. memo.
A.3. Applications and Relationships to other Standards A.3. Applications and Relationships to other Standards
This specification is based on RTCP, which implies its use in an RTP This specification is based on RTCP, which implies its use in an RTP
environment. RTP itself is used in a variety of systems such as in environment. RTP itself is used in a variety of systems such as in
SIP- or H.323-based multimedia conferencing/telephony, SAP-announced SIP- or H.323-based multimedia conferencing/telephony, SAP-announced
Mbone conferences, and RTSP-based media streaming. Mbone conferences, and RTSP-based media streaming.
skipping to change at line 1872 skipping to change at line 1975
A.4 Remarks on the size of the multicast group A.4 Remarks on the size of the multicast group
This specification prevents traffic explosion on the feedback channel This specification prevents traffic explosion on the feedback channel
in a very similar way as RTP does, with the exception of allowing in a very similar way as RTP does, with the exception of allowing
individual receivers to overdraft their bit rate budget from time to individual receivers to overdraft their bit rate budget from time to
time. This is necessary in order to allow for low delay, which is time. This is necessary in order to allow for low delay, which is
needed by the algorithms reacting to Feedback messages. needed by the algorithms reacting to Feedback messages.
This scaling, however, limits the usefulness of this mechanism in This scaling, however, limits the usefulness of this mechanism in
multicast groups from a certain size upwards (where the size multicast groups from a certain size upwards (where the size
Ott et al. Expires May 2002 [Page 37]
threshold depends on a number of parameters including loss rate, threshold depends on a number of parameters including loss rate,
frame rate, number of packets per frame, and session bandwidth). The frame rate, number of packets per frame, and session bandwidth). The
maximum size of the multicast group is soft and also depends on maximum size of the multicast group is soft and also depends on
application requirements and is therefore not specified here. application requirements and is therefore not specified here.
Considerations on the multicast group sizes are presented in section Considerations on the multicast group sizes are presented in section
3.5. 3.5.
Ott et al. Expires January 2002 [Page 35] Ott et al. Expires May 2002 [Page 38]
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/