draft-ietf-avt-rtcp-feedback-02.txt   draft-ietf-avt-rtcp-feedback-03.txt 
INTERNET-DRAFT Joerg Ott/Uni Bremen TZI INTERNET-DRAFT Joerg Ott/Uni Bremen TZI
draft-ietf-avt-rtcp-feedback-02.txt Stephan Wenger/TU Berlin draft-ietf-avt-rtcp-feedback-03.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
Jose Rey/Matsushita
1 March 2002 29 June 2002
Expires September 2002 Expires December 2002
Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) 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, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 1, line 40 skipping to change at page 1, line 41
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Real-time media streams that use RTP are not resilient against Real-time media streams that use RTP are not resilient against
packet losses. RTP [1] provides all the necessary mechanisms to packet losses. Receivers may use the base mechanisms of RTCP to
restore ordering and timing to properly reproduce a media stream at report packet reception statistics and thus allow a sender to adapt
the recipient. RTP also provides continuous feedback about the its transmission behavior in the mid-term as sole means for
overall reception quality from all receivers -- thereby allowing feedback and feedback-based error repair (besides a few codec-
the sender(s) in the mid-term (in the order of several seconds to specific mechanisms). This document defines an extension to the
minutes) to adapt their coding scheme and transmission behavior to Audio-visual Profile (AVP) that enables receivers to provide,
the observed network QoS. However, except for a few payload statistically, more immediate feedback to the senders and thus
specific mechanisms [10], RTP makes no provision for timely allow for short-term adaptation and efficient feedback-based repair
feedback that would allow a sender to repair the media stream mechanisms to be implemented. This early feedback profile (AVPF)
immediately: through retransmissions, retro-active FEC, or media- maintains the AVP bandwidth constraints for RTCP and preserves
specific mechanisms such as reference picture selection for some scalability to large groups.
video codecs.
Generally, real-time transport of media streams across IP
networks follows RTP[1] in conjunction with the RTP Profile for
Audio and Video Conferences with Minimal Control [2]. This
document modifies the profile defined in [2] in two ways:
o by providing additional RTCP messages that enable a receiver to
convey more precise feedback to a sender and
o by adapting the timing algorithm for scheduling RTCP packets in
order to allow for occasional timely feedback about events
observed by a receiver (such as lost packets).
The result is an RTP Profile for Audio and Video Conferences with
Minimal Control that allows for more explicit and more immediate
receiver feedback but shares all other properties (including all
other message types and formats, all code points for codecs,
payload formats, scaling capabilities, etc. of [2]). Therefore,
this document only specifies the additions and modifications to [2]
rather than the repeating the entire specification.
1. Introduction 1. Introduction
Real-time media streams that use RTP are not resilient against Real-time media streams that use RTP are not resilient against
packet losses. RTP [1] provides all the necessary mechanisms to packet losses. RTP [1] provides all the necessary mechanisms to
restore ordering and timing present at the sender to properly restore ordering and timing present at the sender to properly
reproduce a media stream at a recipient. RTP also provides reproduce a media stream at a recipient. RTP also provides
continuous feedback about the overall reception quality from all continuous feedback about the overall reception quality from all
receivers -- thereby allowing the sender(s) in the mid-term (in the receivers -- thereby allowing the sender(s) in the mid-term (in the
order of several seconds to minutes) to adapt their coding scheme order of several seconds to minutes) to adapt their coding scheme
and transmission behavior to the observed network QoS. However, and transmission behavior to the observed network QoS. However,
except for a few payload specific mechanisms [10], RTP makes no except for a few payload specific mechanisms [10], RTP makes no
provision for timely feedback that would allow a sender to repair provision for timely feedback that would allow a sender to repair
the media stream immediately: through retransmissions, retro-active the media stream immediately: through retransmissions, retro-active
FEC, or media-specific mechanisms such as reference picture FEC control, or media-specific mechanisms for some video codecs,
selection for some video codecs. such 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]. These mechanisms may be applied pro- streams transmission [6]. These mechanisms may be applied pro-
actively (thereby increasing the bandwidth of a given media actively (thereby increasing the bandwidth of a given media
stream). Alternatively, in sufficiently small groups with small stream). Alternatively, in sufficiently small groups with small
RTTs, the senders may perform repair on-demand, using the above RTTs, the senders may perform repair on-demand, using the above
mechanisms and/or media-encoding-specific approaches. Note that mechanisms and/or media-encoding-specific approaches. Note that
"small group" and "sufficiently small RTT" are both highly "small group" and "sufficiently small RTT" are both highly
application dependent. application dependent.
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 of conferences with minimal control based upon [1] and [2] by means of
two modifications/additions: To achieve timely feedback, the two modifications/additions: to achieve timely feedback, the
concepts of Immediate Feedback messages and Early RTCP messages as concepts of Immediate Feedback messages and Early RTCP messages as
well as algorithms allowing for low delay feedback in small well as algorithms allowing for low delay feedback in small
multicast groups (and preventing feedback implosion in large ones) multicast groups (and preventing feedback implosion in large ones)
are introduced. Special consideration is given to point-to-point are introduced. Special consideration is given to point-to-point
scenarios. And a small number of general-purpose feedback messages scenarios. A small number of general-purpose feedback messages as
as well as a format for codec and application-specific feedback well as a format for codec and application-specific feedback
information are defined as specific RTCP payloads. information are defined as 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
their occurrence. In Early RTCP mode, RTCP feedback their occurrence. In Early RTCP mode, RTCP feedback
messages are transmitted according to the timing rules messages are transmitted according to the timing rules
defined in this document. defined in this document.
Early RTCP packet: Early RTCP packet:
An Early RTCP packet is a packet which is transmitted An Early RTCP packet is a packet which is transmitted
earlier than would be allowed following the scheduling earlier than would be allowed if following the scheduling
algorithm of [1], the reason being an "event" observed by a algorithm of [1], the reason being an "event" observed by a
receiver. Early RTCP packets may be sent in Immediate receiver. Early RTCP packets may be sent in Immediate
feedback and in Early RTCP mode. feedback and in Early RTCP mode.
Event: Event:
An observation made by the receiver of a media stream that An observation made by the receiver of a media stream that
is (potentially) of interest to the sender -- such as a is (potentially) of interest to the sender -- such as a
packet loss or packet reception, frame loss, etc. -- and packet loss or packet reception, frame loss, etc. -- and
thus useful to be reported back to the sender by means of a thus useful to be reported back to the sender by means of a
Feedback message. Feedback message.
skipping to change at page 4, line 11 skipping to change at page 3, line 44
Feedback (FB) threshold: Feedback (FB) threshold:
The FB threshold indicates the transition between Immediate The FB threshold indicates the transition between Immediate
Feedback and Early RTCP mode. For a multicast scenario, Feedback and Early RTCP mode. For a multicast scenario,
the FB threshold indicates the maximum group size at which, the FB threshold indicates the maximum group size at which,
on average, each receiver is able to report each event back on average, each receiver is able to report each event back
to the sender(s) immediately, i.e. by means of an Early to the sender(s) immediately, i.e. by means of an Early
RTCP packet without having to wait for its regularly RTCP packet without having to wait for its regularly
scheduled RTCP interval. This threshold is highly scheduled RTCP interval. This threshold is highly
dependent on the type of feedback to be provided, network dependent on the type of feedback to be provided, network
QoS (e.g. packet loss probability and distribution), codec QoS (e.g. packet loss probability and distribution), codec
and packetization in use, the session bandwidth, and and packetization scheme in use, the session bandwidth, and
application requirements. Note that the algorithms do application requirements. Note that the algorithms do not
not depend on all senders and receivers agreeing on the depend on all senders and receivers agreeing on the same
same value for this threshold. It is merely intended to value for this threshold. It is merely intended to provide
provide conceptual guidance to application designers and is conceptual guidance to application designers and is not
not used in any calculations. used in any calculations.
Immediate Feedback mode: Immediate Feedback mode:
A mode of operation in which each receiver of a media A mode of operation in which each receiver of a media
stream is, statistically, capable of reporting each event stream is, statistically, capable of reporting each event
of interest immediately back to the media stream sender. of interest immediately back to the media stream sender.
In Immediate Feedback mode, RTCP feedback messages are In Immediate Feedback mode, RTCP feedback messages are
transmitted according to the timing rules defined in this transmitted according to the timing rules defined in this
document. document.
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]. Such RTCP messages may sent following the rules of [1]. Nevertheless, such RTCP
contain feedback information as defined in this document. messages may contain feedback 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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119 in this document are to be interpreted as described in RFC 2119
[8] [8]
2. RTP and RTCP Packet Formats and Protocol Behavior 2. RTP and RTCP Packet Formats and Protocol Behavior
The rules defined in [2] also apply to this profile except for The rules defined in [2] also apply to this profile except for
those rules mentioned in the following: those rules mentioned in the following:
RTCP packet types: RTCP packet types:
Three additional RTCP packet types to convey feedback Two additional RTCP packet types to convey feedback
information are defined in section 4. information are defined in section 6.
RTCP report intervals: RTCP report intervals:
This memo describes three modes of operation which This memo describes three modes of operation which
influence the RTCP report intervals (see section 3.2). In influence the RTCP report intervals (see section 3.2). In
regular RTCP mode, all rules from [1] apply. In both regular RTCP mode, all rules from [1] apply. In both
Immediate Feedback and Early RTCP modes the minimal Immediate Feedback and Early RTCP modes the minimal
interval of 5 seconds between 2 RTCP reports is dropped and interval of five seconds between two RTCP reports is
the rules specified in section 3 apply if RTCP packets dropped and the rules specified in section 3 apply if RTCP
containing feedback messages (defined in section 4) are to packets containing feedback messages (defined in section 4)
be transmitted. are to be transmitted.
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 The same basic rules as detailed in [2] apply. Beyond
this, in section 5, further consideration is given to the this, in section 5, further consideration is given to the
skipping to change at page 7, line 19 skipping to change at page 7, line 4
RTP [1] and the commonly used RTP profile [2] specify rules when RTP [1] and the commonly used RTP profile [2] specify rules when
compound RTCP packets should be sent. This document modifies those compound RTCP packets should be sent. This document modifies those
rules in order to allow applications to timely report events (e.g. rules in order to allow applications to timely report events (e.g.
loss or reception of media packets) to accommodate algorithms that loss or reception of media packets) to accommodate algorithms that
use FB messages and are sensitive to the feedback timing. use FB messages and are sensitive to the feedback timing.
The modified RTCP transmission algorithm can be outlined as The modified RTCP transmission algorithm can be outlined as
follows: Normally, when no FB messages have to be conveyed, follows: Normally, when no FB messages have to be conveyed,
compound RTCP packets are sent following the rules of RTP [1] -- compound RTCP packets are sent following the rules of RTP [1] --
except that the 5s minimum interval between RTCP reports is not except that the five second minimum interval between RTCP reports
enforced and the interval between RTCP reports is only derived from is not enforced and the interval between RTCP reports is only
the average RTCP packet size and the RTCP bandwidth share available derived from the average RTCP packet size and the RTCP bandwidth
to the RTP/RTCP entity. If a receiver detects the need to send an share available to the RTP/RTCP entity; in addition, a minimum
FB message, the receiver waits for a short, random dithering interval between regular RTCP packets may be enforced. If a
interval (in case of multicast) and then checks whether it has receiver detects the need to send an FB message, the receiver waits
already seen a corresponding FB message from any other receiver for a short, random dithering interval (in case of multicast) and
(which it can do with all FB messages that are transmitted via then checks whether it has already seen a corresponding FB message
multicast; for unicast sessions, there is no such delay). If this from any other receiver (which it can do with all FB messages that
is the case then the receiver refrains from sending the FB message are transmitted via multicast; for unicast sessions, there is no
and continues to follow the regular RTCP sending schedule. If the such delay). If this is the case then the receiver refrains from
receiver has not yet seen a similar FB message from any other sending the FB message and continues to follow the regular RTCP
receiver, it checks whether it has recently exceeded its RTCP bit transmission schedule. If the receiver has not yet seen a similar
rate budget to transmit another FB message (without waiting for its FB message from any other receiver, it checks whether it has
regularly scheduled RTCP transmission time). Only if this is not recently sent another FB message (without waiting for its regularly
the case, it sends the FB message as part of a (minimal) compound scheduled RTCP transmission time). Only if this is not the case,
RTCP packet. it sends the FB message as part of a (minimal) compound RTCP
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] (except for the five second lower which are interspersed as per [1] (except for the five second lower
bound) in regular intervals. bound) 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) as RTCP-based feedback may operate in one of three modes (figure 1) as
described below. The mode is a hint whether or not a receiver described below. The mode is a hint whether or not a receiver
should send early feedback at all and, if so, whether, should send early feedback at all and, if so, whether,
skipping to change at page 8, line 48 skipping to change at page 8, line 36
events to be reported. This information can be used as a hint events to be reported. This information can be used as a hint
to determine whether or not early transmission of RTCP packets to determine whether or not early transmission of RTCP packets
is useful. is useful.
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 feedback from individual receivers at all -- because of the
time scale in which the feedback could be provided and/or time scale in which the feedback could be provided and/or
because in large groups the sender(s) have no chance to react because in large groups the sender(s) have no chance to react
to individual feedback anymore. to individual feedback anymore.
No threshold can be specified when this occurs. No group size threshold can be specified at which this mode
starts.
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 among the participants on the there is no need for an agreement among the participants on the
precise values of the respective "thresholds" within the group. precise values of the respective "thresholds" within the group.
Hence the borders between all these modes are allowed to be Hence the borders between all these modes are allowed to be
fluent. fluent.
ACK ACK
feedback feedback
V V
skipping to change at page 9, line 32 skipping to change at page 9, line 32
technical parameters (of the codec, the transport, the type of technical parameters (of the codec, the transport, the type of
feedback used, etc.) but also on the respective application feedback used, etc.) but also on the respective application
scenarios. Section 3.6 provides some useful hints (but no precise scenarios. Section 3.6 provides some useful hints (but no precise
calculations) on estimating these thresholds. calculations) on estimating these thresholds.
3.4 Definitions 3.4 Definitions
The following pieces of state information need to be maintained per The following pieces of state information need to be maintained per
receiver (largely taken from [1]). Note that all variables (except receiver (largely taken from [1]). Note that all variables (except
for g) are calculated independently at each receiver and so their for g) are calculated independently at each receiver and so their
local values may differ at a given point in time. local values may differ at any 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 tn and tp be the time for the next (last) scheduled c) 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.
d) Let T_rr be the interval after which, having just sent a d) Let Tmin be the minimal interval between RTCP packets as per
[1]. Unlike [1], the initial Tmin is set to 1 second, then it
is set to 0.
e) Let T_rr be the interval after which, having just sent a
regularly scheduled RTCP packet, a receiver would schedule the regularly scheduled RTCP packet, a receiver would schedule the
transmission of its next RTCP packet following the rules of [1]: transmission of its next regular RTCP packet following the rules
T_rr = tn - tp. Note that the 5s minimum interval between two of [1]: T_rr = T (the "calculated interval") with tn = tp + T.
report as defined in [1] SHOULD NOT be enforced. Note that a different Tmin is used to compute the "calculated
interval T". T_rr refers to the last value of T that has been
computed (because of reconsideration or to determine tn).
e) Let t0 be the time at which an event that is to be reported is f) Let t0 be the time at which an event that is to be reported is
detected by a receiver. detected by a receiver.
f) 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).
g) 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. Note that this value is application-specific. all. Note that this value is application-specific.
h) 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.
i) Let T_fd be the actual (randomized) delay for the transmission j) Let T_fd be the actual (randomized) delay for the transmission
of feedback message in response to an event that a certain of feedback message in response to an event that a certain
packet P caused. packet P caused.
j) Let allow_early be a Boolean variable that indicates whether the k) Let allow_early be a Boolean variable that indicates whether the
receiver currently may transmit feedback messages prior to its receiver currently may transmit feedback messages prior to its
next regularly scheduled RTCP interval tn. This variable is next regularly scheduled RTCP interval tn. This variable is
used to throttle the feedback sent by a single receiver. used to throttle the feedback sent by a single receiver.
allow_early is adjusted (set to FALSE) after early feedback allow_early is adjusted (set to FALSE) after early feedback
transmission and is reset to TRUE as soon as the next regular transmission and is reset to TRUE as soon as the next regular
RTCP transmission is scheduled. RTCP transmission has occurred.
k) Let avg_rtcp_size be the moving average on the RTCP packet size l) Let avg_rtcp_size be the moving average on the RTCP packet size
as defined in [1]. as defined in [1].
m) Let T_rr_interval be an (optional) minimal interval to be used
between regular RTCP packets. If T_rr_interval != 0 then
regular RTCP packets will not be scheduled T_rr after the last
regular RTCP transmission (at tp+T_rr) but only at least
T_rr_interval after the last regular RTCP transmission (later
than or at tp+T_rr). T_rr_interval does not affect the
calculation of T_rr and tp but may lead to regular RTCP packets
being suppressed. T_rr_interval does not affect transmission
scheduling for Early RTCP packets.
n) Let t_rr_last be the point in time at which the last RTCP packet
has been scheduled and sent (i.e. has not been suppressed due to
T_rr_interval).
NOTE: Providing T_rr_interval as an independent variable is
meant to minimize regular feedback (and thus bandwidth
consumption) as needed by the application but still allow for
more frequent use of Early RTCP packets to provide timely
feedback. This goal could not be achieved by reducing the
overall RTCP bandwidth as RTCP bandwidth reduction would also
impact the Early feedback.
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 depicted in figure 2 below. At time t0, such an event (e.g. a
packet loss) is detected at the receiver. The receiver decides -- packet loss) is detected at the receiver. The receiver decides --
based upon current bandwidth, group size, and other (application- based upon current bandwidth, group size, and other (application-
specific) parameters -- that a feedback message needs to be sent specific) parameters -- that a feedback message needs to be sent
back to the sender. back to the 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 RTCP feedback packet by a random MUST delay the transmission of the RTCP feedback packet by a random
amount T_fd (with the random number evenly distributed in the amount T_fd (with the random number evenly distributed in the
skipping to change at page 11, line 38 skipping to change at page 12, line 31
3.5 Early RTCP Algorithm 3.5 Early RTCP Algorithm
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 Assume further that R has verified that using feedback mechanisms
is reasonable at the current constellation (which is highly is reasonable at the current constellation (which is highly
application specific and hence not specified in this memo). application specific and hence not specified in this memo).
Assume that T_rr_interval is 0 ,if no minimal interval between
regular RTCP packets is to be enforced, or T_rr_interval is set to
some meaningful value, as given by the application. This value
then denotes the minimal interval between regular RTCP packets.
Then, receiver R MUST use the following rules for transmitting one Then, receiver R MUST use the following rules for transmitting one
or more Feedback messages as minimal or full compound RTCP packet: or more Feedback messages as minimal or full compound RTCP packet:
Initially, R MUST set allow_early = TRUE. 3.5.1 Initialization
Assume that R has transmitted the last RTCP RR packet at tp and has Initially, R MUST set allow_early = TRUE and t_rr_last = NaN.
scheduled the next transmission (prior to reconsideration) for tn.
At time t0, R detects the need to transmit one or more RTCP Furthermore, the initialization of the RTCP variables as per [1]
applies except that the initial value for Tmin is 1.0 seconds.
3.5.2 Early Feedback Transmission
Assume that R has scheduled the last RTCP RR packet for
transmission at tp and has scheduled the next transmission
(including possible reconsideration) for tn = tp + T_rr. Assume
also that the last T_rr_interval-based transmission (if any) has
occurred at t_rr_last (if defined).
1. At time t0, R detects the need to transmit one or more RTCP
feedback messages (e.g. because media "units" needs to be ACKed or feedback messages (e.g. because media "units" needs to be ACKed or
NACKed) and finds that sending the feedback information is useful NACKed) and finds that sending the feedback information is useful
for the sender. for the sender.
R first checks whether there is still a compound RTCP feedback 2. R first checks whether there is still a compound RTCP feedback
packet waiting for transmission (scheduled as early or regular RTCP packet waiting for transmission (scheduled as early or regular RTCP
packet). If so, the new feedback message MUST be appended to the packet).
packet; the schedule for the waiting RTCP feedback packet MUST
remain unchanged. When appending, the feedback information of
several RTCP feedback packets SHOULD be merged to produce as few
packets as possible.
If no RTCP feedback message is already awaiting transmission, a new 2.a) If so, the new feedback message MUST be appended to the
(minimal or full) compound RTCP feedback packet MUST be created and packet; the scheduling of the waiting RTCP feedback packet
the minimal interval for T_dither_max MUST be chosen as follows: MUST remain unchanged. When appending, the feedback
information of several RTCP feedback packets SHOULD be merged
to produce as few feedback messages as possible. This
completes the course of immediate actions to be taken.
2.b) If no RTCP feedback message is already awaiting
transmission, a new (minimal or full) compound RTCP feedback
packet MUST be created and the minimal interval for
T_dither_max MUST be chosen 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 session is a multicast session with potentially more ii) If the session is a multicast session with potentially
than two group members then more than two group members then
T_dither_max = l * T_rr T_dither_max = l * T_rr
with l=0.5. with l=0.5.
The values given above for T_dither_max are minimal values. The values given above for T_dither_max are minimal values.
Application-specific feedback considerations may make it worthwhile Application-specific feedback considerations may make it
to increase T_dither_max beyond this value. This is up to the worthwhile to increase T_dither_max beyond this value. This
discretion of the implementer. is up to the discretion of the implementer.
Then, R MUST check whether its next regularly scheduled RTCP packet 3. Then, R MUST check whether its next regularly scheduled RTCP
is within the time bounds for the RTCP FB (t0 + T_dither_max > tn). packet is within the time bounds for the RTCP FB (t0 + T_dither_max
If so, an Early RTCP packet MUST NOT be scheduled; instead the FB > tn).
message(s) MUST be stored to be appended to the regular RTCP packet
scheduled for tn.
Otherwise, R MUST check whether it is allowed to transmit an Early 3.a) If so, an Early RTCP packet MUST NOT be scheduled;
RTCP packet (allow_early == TRUE). instead the FB message(s) MUST be stored to be appended to the
regular RTCP packet scheduled for tn. This completes the
course of immediate actions to be taken.
If so, R MUST schedule an Early RTCP packet for te = t0 + RND * 3.b) Otherwise, the following steps are carried out.
T_dither_max with RND being a pseudo random function evenly
distributed between 0 and 1.
If, while waiting for te, R receives RTCP feedback packets 4. R MUST check whether it is allowed to transmit an Early RTCP
packet (allow_early == TRUE).
4.a) If allow_early == FALSE then R MUST check the time for the
next scheduled RR:
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 an RTCP FB message for
transmission along with the RTCP packet at tn.
2. Otherwise, R MUST discard the RTCP feedback message.
This completes the immediate course of actions to be taken.
4.b) If allow_early == TRUE then R MUST schedule an Early RTCP
packet for te = t0 + RND * T_dither_max with RND being a pseudo
random function evenly distributed between 0 and 1.
5. If, while waiting for te, R receives RTCP feedback packets
contained in one or more (minimal) compound RTCP packets, R MUST contained in one or more (minimal) compound RTCP packets, R MUST
act as follows for each of the RTCP feedback packets in the one act as follows for each of the RTCP feedback messages in the one or
or more compound RTCP packets received: more compound RTCP packets received in the interval [t0 - 1s ; te]:
1. If R understands the received feedback message's semantics 5.a) If R understands the received feedback message's semantics
and the message contents is a superset of the feedback R and the message contents is a superset of the feedback R wanted
wanted to send then R MUST discard its own feedback message to send then R MUST discard its own feedback message and MUST
and MUST re-schedule the next regular RTCP message re-schedule the next regular RTCP message transmission for tn
transmission for tn (as calculated before). (as calculated before).
2. If R understands the received feedback message's semantics 5.b) If R understands the received feedback message's semantics
and the message contents is not a superset of the feedback R and the message contents is not a superset of the feedback R
wanted to send then R SHOULD transmit its own feedback wanted to send then R SHOULD transmit its own feedback message
message as scheduled. If there is an overlap between the as scheduled. If there is an overlap between the feedback
feedback information to send and the feedback information information to send and the feedback information received, the
received, the amount of feedback transmitted is up to R: R amount of feedback transmitted is up to R: R MAY send its
MAY send its feedback information unchanged, R MAY as well feedback information unchanged, R MAY as well eliminate any
eliminate any redundancy between its own feedback and the redundancy between its own feedback and the feedback received
feedback received so far. so far.
3. If R does not understand the received feedback message's 5.c) If R does not understand the received feedback message's
semantics, R MAY send its own feedback message as Early RTCP semantics, R MAY send its own feedback message as Early RTCP
packet, or R MAY re-schedule the next regular RTCP message packet, or R MAY re-schedule the next regular RTCP message
transmission for tn (as calculated before) and MAY append transmission for tn (as calculated before) and MAY append the
the feedback message to the now regularly scheduled RTCP feedback message to the now regularly scheduled RTCP message.
message.
Note: With rule #3, receiving unknown feedback packets may Note: With rule #3, receiving unknown feedback packets may not
not lead to feedback suppression at a particular receiver. lead to feedback suppression at a particular receiver. As a
As a consequence, a given event may cause M different types consequence, a given event may cause M different types of
of feedback packets (which are all appropriate but not the feedback packets (which are all appropriate but not the same
same and mutually not understood) to be scheduled, and a and mutually not understood) to be scheduled, and a "large"
"large" receiver group may be partitioned into at most M receiver group may be partitioned into at most M groups. Among
groups. Among members of each of these M groups, feedback members of each of these M groups, feedback suppression will
suppression will occur following the rules #1 and #2 but no occur following the rules #1 and #2 but no suppression will
suppression will happen across groups. As a result, O(M) happen across groups. As a result, O(M) RTCP feedback messages
RTCP feedback messages may be received by the sender. Given may be received by the sender. Given that these M groups
that these M groups consist of receivers for the same consist of receivers for the same application using the same
application using the same (set of) codecs in the same RTP (set of) codecs in the same RTP session, M is assumed to be
session, M is assumed to be small in the general case. small in the general case. Given further that the O(M)
Given further that the O(M) feedback packets are randomly feedback packets are randomly distributed over a time interval
distributed over a time interval of T_dither_max, the of T_dither_max, the resulting limited number of extra feedback
resulting limited number of extra feedback packets (a) is packets (a) is assumed not to overwhelm the sender and (b)
assumed not to overwhelm the sender and (b) should be should be conveyed as all contain complementary pieces of
conveyed as all contain complementary pieces of information. information.
Refer to section 4 on the comparison of feedback messages and Refer to section 4 on the comparison of feedback messages and
for which feedback messages MUST be understood by a receiver. for which feedback messages MUST be understood by a receiver.
Otherwise, when te is reached, R MUST transmit the RTCP packet 6. 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. The value from the last MUST recalculate tn = tp + 2*T_rr, and MUST set tp to the previous
calculation of T_rr SHOULD be used. As soon as R sends its next tn. As soon as the newly calculated tn is reached and R sends its
regularly scheduled RTCP RR (at the new tn), it MUST set next regularly scheduled RTCP RR or suppresses it because of
allow_early = TRUE again. T_rr_interval, it MUST set allow_early = TRUE again.
If allow_early == FALSE then R MUST check the time for the next 3.5.3 Regular RTCP Transmission
scheduled RR:
1. If tn - t0 < T_max_fb_delay (i.e. if, despite late reception, In regular intervals full compound RTCP packets MUST be sent.
the feedback could still be useful for the sender) then R MAY These packets MAY also contain one or more feedback messages.
create an RTCP FB message for transmission along with the RTCP Transmission of regular RTCP packets is scheduled as follows:
packet at tn.
2. Otherwise, R MUST discard the RTCP feedback message. If T_rr_interval == 0 then the transmission MUST follow the rules
as specified by [1] (except for the different Tmin) and MUST adhere
to the adjustments of tn specified in section 3.5.2 (i.e. skip one
regular transmission if an Early RTCP transmission has occurred).
Timer reconsideration takes place when tn is reached as per [1] and
the regular RTCP packet is transmitted after timer reconsideration.
Whenever a regular RTCP message is sent, allow_early MUST be set to
TRUE and tp, tn MUST be updated as per [1]. If this was the first
transmission of an RTCP packet, Tmin MUST be set to 0.
In regular RTCP intervals as specified by [1] (except for the five If T_rr_interval != 0 then the calculation for the transmission
second minimum), a full compound RTCP packet MUST be sent (which times MUST follow the rules as specified in [1] (except for the
MAY also contain a feedback message if one has been created different Tmin) and MUST adhere to the adjustments of tn specified
according to the above rules and scheduled for transmission along in section 3.5.2 (i.e. skip one regular transmission if an Early
the full compound RTCP message). RTCP transmission has occurred). Timer reconsideration takes place
when tn is reached as per [1]. After timer reconsideration, the
following actions are taken:
If no full compound RTCP packet has been sent before (i.e. if
t_rr_last == NaN) then a full compound RTCP packet MUST be
scheduled. Stored RTCP feedback messages MAY be included in
the full compound RTCP packet. t_rr_last MUST be set to tn.
Tmin MUST be set to 0.
If t_rr_last + T_rr_interval <= tn then a full compound RTCP
packet MUST be scheduled. Stored RTCP feedback messages MAY
be included in the full compound RTCP packet. t_rr_last MUST
be set to tn.
If t_rr_last + T_rr_interval > tn and RTCP feedback messages
have been stored and are awaiting transmission, an RTCP packet
MUST be scheduled. This RTCP packet MAY be a minimal or a
full compound RTCP packet (at the discretion of the
implementer) and the compound RTCP packet MUST include the
stored RTCP feedback message. t_rr_last MUST remain
unchanged.
Otherwise (if t_rr_last + T_rr_interval > tn but no stored
RTCP feedback messages are awaiting transmission), no compound
RTCP packet MUST be scheduled.
In all the four cases above, allow early MUST be set to TRUE and tp
and tn MUST be updated following the rules of [1] except for the
five second minimum.
3.5.4 Other Considerations
Furthermore, if T_rr_interval != 0 then the timeout calculation for
RTP/AVPF entities (section 6.3.5 of [1]) MUST be modified to use
T_rr_interval instead of Tmin for computing Td.
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 compound, early or regularly scheduled -- the avg_rtcp_size
variable MUST be updated accordingly (see [1]) and the tn MUST be variable MUST be updated accordingly (see [1]) and the tn MUST be
calculated using the new avg_rtcp_size. calculated using the new avg_rtcp_size.
3.6 Considerations on the Group Size 3.6 Considerations on the Group Size
This section provides some guidelines to the group sizes at which This section provides some guidelines to the group sizes at which
the various feedback modes may be used. the 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- The group size MUST be exactly two participants, i.e. point-to-
point communications. Unicast addresses MUST be used in the point communications. Unicast addresses MUST be used in the
session description. session 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 two parties, 2.5% of the RTP session bandwidth are available for
RTCP traffic from the receivers including feedback. For a 64 RTCP traffic from the receivers including feedback. For a 64
kbit/s stream this yields 1600 bit/s for RTCP. As every other RTCP kbit/s stream this yields 1,600 bit/s for RTCP. If we assume an
packet needs to be a full compound packet, we assume an average of average of 96 bytes (=768 bits) per RTCP packet a receiver can
96 bytes (=768 bits) per RTCP packet so that a receiver can report report 2 events per second back to the sender. If acknowledgments
2 events per second back to the sender. If acknowledgments for 10 for 10 events are collected in each feedback message then 20 events
events are collected in each feedback message then 20 events can be can be acknowledged per second. At 256 kbit/s 8 events could be
acknowledged per second. At 256 kbit/s 8 events could be reported reported per second; thus the ACKs may be sent in a finer
per second; thus the ACKs may be sent in a finer granularity (e.g. granularity (e.g. only combining three ACKs per RTCP feedback
only combining only three ACKs per RTCP feedback message). message).
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 30 fps video stream. individual frame (not packet!) in a 30 fps video stream.
ACK strategies MUST be defined accordingly to work properly with ACK strategies MUST be defined to work properly with these
these bandwidth limitations. An indication whether or not ACKs are bandwidth limitations. An indication whether or not ACKs are
allowed for a session and, if so, which ACK strategy should be allowed for a session and, if so, which ACK strategy should be
used, MAY be conveyed by out-of-band mechanisms, e.g. media- used, MAY be conveyed by out-of-band mechanisms, e.g. media-
specific attributes in a session description using SDP. specific attributes in a session description using SDP.
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.
skipping to change at page 15, line 48 skipping to change at page 18, line 24
Using the above notation, Early RTCP mode can be roughly Using the above notation, Early RTCP mode can be roughly
characterized by N > B*T/R as "lower bound". An estimate for characterized by N > B*T/R as "lower bound". An estimate for
an upper bound is more difficult. Setting N=1, we obtain for a an upper bound is more difficult. Setting N=1, we obtain for a
given R and B the interval T = R/B as average interval between given R and B the interval T = R/B as average interval between
events to be reported. This information can be used as a hint events to be reported. This information can be used as a hint
to determine whether or not early transmission of RTCP packets to determine whether or not early transmission of RTCP packets
is useful. is useful.
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 1,500 bytes, then, in most cases,
each frame would fit in its own packet leading to a packet rate of 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 30 packets per second. If 5% packet loss occurs in the network
(equally distributed, no inter-dependence between receivers), then (equally distributed, no inter-dependence between receivers), then
each receiver will have to report 3 packets lost each two seconds. each receiver will have to report 3 packets lost each two seconds.
Assuming a single sender and more than 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 compound RTCP packet allows 10 RTCP packets to be sent per second
or 20 in two seconds. If every receiver needs to report three or 20 in two seconds. If every receiver needs to report three
packets, this yields a maximum group size of 6-7 receivers if all packets, this yields a maximum group size of 6-7 receivers if all
loss events shall be reported. The rules for transmission of loss events shall be reported. The rules for transmission of
immediate RTCP packets should provide sufficient flexibility for immediate RTCP packets should provide sufficient flexibility for
most of this reporting to occur in a timely fashion. most of this reporting to occur in a timely fashion.
skipping to change at page 18, line 28 skipping to change at page 21, line 4
The RTP receivers MUST NOT rely on the RTP senders reacting to any The RTP receivers MUST NOT rely on the RTP senders reacting to any
of the feedback messages. of the feedback 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 RTCP receivers for the media session(s) containing description, the RTCP receivers for the media session(s) containing
the "rtcp-fb" the "rtcp-fb"
o MUST ignore all "rtcp-fb" attributes of which they do not fully o MUST ignore all "rtcp-fb" attributes of which they do not fully
understand the semantics (i.e. where they do not understand the understand the semantics (i.e. where they do not understand the
meaning of all values in the a=fmtp:rtcp-fb line); meaning of all values in the a=fmtp:rtcp-fb line);
o SHOULD provide feedback information as specified in this o SHOULD provide feedback information as specified in this
document using any of the RTCP feedback packets as specified in document using any of the RTCP feedback packets as specified in
one of the "rtcp-fb" attributes for this media session; and one of the "rtcp-fb" attributes for this media session; and
o MUST NOT use other feedback messages than those listed in one of o MUST NOT use other feedback messages than those listed in one of
the "rtcp-fb" attribute lines. the "rtcp-fb" attribute lines.
When used in conjunction with the offer/answer model [18], the
offerer MAY present a set of these AVPF attributes to its peer.
The answerer MUST remove all attributes it does not understand as
well as those it does not support in general or does not wish to
use in this particular media session. The answerer MUST NOT add
feedback parameters to the media description and MUST NOT alter
values of such parameters. The answer is binding for the media
session and both offerer and answerer MUST only use feedback
mechanisms negotiated in this way.
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 The syntax of the "rtcp-fb" attribute is as follows (the feedback
types and optional parameters are all case sensitive): types and optional parameters are all case sensitive):
rtcp-fb-syntax = "a=fmtp:" <format> WS "rtcp-fb" WS rtcp-fb-val (In the following ABNF, SP and CRLF are used as defined in [3].)
rtcp-fb-syntax = "a=fmtp:" <format> SP "rtcp-fb" SP rtcp-fb-val
CRLF
rtcp-fb-val = "ack" rtcp-fb-ack-param rtcp-fb-val = "ack" rtcp-fb-ack-param
| "nack" rtcp-fb-nack-param | "nack" rtcp-fb-nack-param
| "trr-int" SP 1*DIGIT
| rtcp-fb-id rtcp-fb-param | rtcp-fb-id rtcp-fb-param
rtcp-fb-id = 1*(alpha-numeric | "-" | "_") rtcp-fb-id = 1*(alpha-numeric | "-" | "_")
rtcp-fb-param = "app" rtcp-fb-param = SP "app"
| byte-string | SP byte-string
| ; empty | ; empty
rtcp-fb-ack-param = "rpsi" rtcp-fb-ack-param = SP "rpsi"
| "app" | SP "app"
| byte-string | SP byte-string
| ; empty | ; empty
rtcp-fb-nack-param = "pli" rtcp-fb-nack-param = SP "pli"
| "sli" | SP "sli"
| "rpsi" | SP "rpsi"
| "app" | SP "app"
| byte-string | SP byte-string
| ; empty | ; empty
The literals of the above grammar have the following semantics: The literals of the above grammar have the following semantics:
Feedback type "ack": Feedback type "ack":
This feedback type indicates that positive acknowledgements This feedback type indicates that positive acknowledgements
for feedback are supported. for feedback are supported.
The feedback type "ack" MUST only be used if the media session The feedback type "ack" MUST only be used if the media session
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.
skipping to change at page 20, line 33 skipping to change at page 23, line 22
Other feedback types <rtcp-fb-id>: Other feedback types <rtcp-fb-id>:
Other documents MAY define additional types of feedback; to Other documents MAY define additional types of feedback; to
keep the grammar extensible for those cases, the rtcp-fb-id is keep the grammar extensible for those cases, the rtcp-fb-id is
introduced as a placeholder. A new feedback scheme name MUST introduced as a placeholder. A new feedback scheme name MUST
to be unique (and thus MUST be registered with IANA). Along to be unique (and thus MUST be registered with IANA). Along
with a new name, its semantics, packet formats (if necessary), with a new name, its semantics, packet formats (if necessary),
and rules for its operation MUST be specified. and rules for its operation MUST be specified.
Regular RTCP minimum interval "trr-int":
The attribute "trr-int" is used to specify the minimum
interval T_rr_interval between two regular (full compound)
RTCP packets in milliseconds for this media session. If "trr-
int" is not specified, a default value of 0 is assumed.
Note that it is assumed that more specific information about Note that it is assumed that more specific information about
application layer feedback (as defined in section 6.4) will be application layer feedback (as defined in section 6.4) will be
conveyed as feedback types and parameters defined elsewhere. conveyed as feedback types and parameters defined elsewhere.
Hence, no further provision for any types and parameters is made in Hence, no further provision for any types and parameters is made in
this document. this 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
skipping to change at page 23, line 14 skipping to change at page 26, line 9
functioning. However, the quality of the media presented may functioning. However, the quality of the media presented may
suffer. suffer.
The following considerations apply to senders and receivers when The following considerations apply to senders and receivers when
used in a combined session. used in a combined session.
o AVP entities (senders and receivers) o AVP entities (senders and receivers)
AVP senders will receive RTCP feedback packets from AVPF AVP senders will receive RTCP feedback packets from AVPF
receivers and ignore these packets. They will see occasional receivers and ignore these packets. They will see occasional
closer spacing of RTCP messages (e.g. violating the 5s rule) by closer spacing of RTCP messages (e.g. violating the five second
AVPF entities. As the overall bandwidth constraints are adhered rule) by AVPF entities. As the overall bandwidth constraints
to by both types of entities, they will still get their share of are adhered to by both types of entities, they will still get
the RTCP bandwidth. However, while AVP entities are bound by their share of the RTCP bandwidth. However, while AVP entities
the 5s rule, depending on the group size and session bandwidth, are bound by the five second rule, depending on the group size
AVPF entities may provide more frequent RTCP reports than AVP and session bandwidth, AVPF entities may provide more frequent
ones will. Also, the overall reporting may decrease slightly as RTCP reports than AVP ones will. Also, the overall reporting
AVPF entities may send bigger compound RTCP packets (due to the may decrease slightly as AVPF entities may send bigger compound
extra RTCP packets). RTCP packets (due to the extra RTCP packets).
If T_rr_interval is used as lower bound between regular RTCP
packets, T_rr_interval is sufficiently large (e.g. T_rr_interval
> M*Td as per section 6.3.5 of [1]), and no Early RTCP packets
are sent by AVPF entities, AVP entities MAY accidentally time
out those AVPF group members and hence under-estimate the group
size. Therefore, if AVP entities may be involved in a media
session, T_rr_interval SHOULD NOT be used.
o AVPF senders o AVPF senders
AVPF senders will receive feedback information only from AVPF AVPF senders will receive feedback information only from AVPF
receivers. If they rely on feedback to provide the target media receivers. If they rely on feedback to provide the target media
quality, the quality achieved for AVP receivers may be sub- quality, the quality achieved for AVP receivers may be sub-
optimal. optimal.
o AVPF receivers o AVPF receivers
skipping to change at page 23, line 50 skipping to change at page 27, line 4
6. Format of RTCP Feedback Messages 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
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 Currently, only a general positive acknowledgement (ACK) and a
negative acknowledgement (NACK) message are defined. negative 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 type and will be generated and acted specific to a certain payload type and will be generated and acted
upon at the codec "layer". This document defines a common header upon at the codec "layer". This document defines a common header
to be used in conjunction with all payload-specific feedback to be used in conjunction with all payload-specific feedback
messages. The definition of specific messages is left to either messages. The definition of specific messages is left to either
RTP Payload Format specifications or to additional feedback format RTP payload format specifications or to additional feedback format
documents. documents.
Application layer feedback messages provide a means to Application layer feedback messages provide a means to
transparently convey feedback from the receiver's to the sender's transparently convey feedback from the receiver's to the sender's
application. The information contained in such a message is not application. The information contained in such a message is not
expected to be acted upon at the transport/RTP or the codec layer. expected to be acted upon at the transport/RTP or the codec layer.
The data to be exchanged between two application instances is The data to be exchanged between two application instances is
usually defined in the application protocol's specification and usually defined in the application protocol's specification and
thus can be identified by the application so that there is no need thus can be identified by the application so that there is no need
for additional external information. Hence, this document defines for additional external information. Hence, this document defines
skipping to change at page 24, line 38 skipping to change at page 27, line 40
specific feedback message. specific feedback message.
This document defines two transport layer feedback and three This document defines two transport layer feedback and three
(video) payload-specific feedback messages as well as a single (video) payload-specific feedback messages as well as a single
container for application layer feedback messages. Additional container for application layer feedback messages. Additional
transport layer and payload specific feedback messages MAY be transport layer and payload specific feedback messages MAY be
defined in other documents and MUST be registered through IANA (see defined in other documents and MUST be registered through IANA (see
section IANA considerations). section IANA considerations).
The general syntax and semantics for the above RTCP feedback The general syntax and semantics for the above RTCP feedback
message types is described in the following subsections. message types are described in the following subsections.
6.1 Common Packet Format for Feedback Message 6.1 Common Packet Format for Feedback Message
All feedback message MUST use a common packet format that is All feedback message MUST use a common packet format that is
depicted in figure 3: depicted in figure 3:
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|0| FMT | PT | length | |V=2|P|0| FMT | PT | length |
skipping to change at page 26, line 32 skipping to change at page 29, line 32
6.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.
Two general purpose transport layer feedback messages are defined Two general purpose transport layer feedback messages are defined
so far: General ACK and General NACK. They are identified by means so far: General ACK and General NACK. They are identified by means
of the FMT parameter as follows: of the FMT parameter as follows:
0: forbidden 0: reserved
1: Generic NACK 1: Generic NACK
2: Generic ACK 2: Generic ACK
3-15: reserved 3-15: reserved
The following two subsections define the packet formats for these The following two subsections define the packet formats for these
messages. messages.
6.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.
skipping to change at page 27, line 25 skipping to change at page 30, line 25
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 RTP Payload Formats may decide to identify a packet
differently. 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 The BLP allows for reporting losses of any of the 16 RTP
packets immediately following the RTP packet indicated by the packets immediately following the RTP packet indicated by the
PID. The BLP's definition is identical to that given in [10]. PID. The BLP's definition is identical to that given in [10].
Denoting the BLP's least significant bit as bit 1, and its most Denoting the BLP's least significant bit as bit 1, and its most
significant bit as bit 16, then bit i of the bit mask is set to 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 1 if the receiver has not received RTP packet number PID+i
(modulo 2^16) and the receiver decides this packet is lost; bit (modulo 2^16) and indicates this packet is lost; bit i is set
i is set to 0 otherwise. Note that the sender MUST NOT assume to 0 otherwise. Note that the sender MUST NOT assume that a
that a receiver has received a packet because its bit mask was receiver has received a packet because its bit mask was set to
set to 0. For example, the least significant bit of the BLP 0. For example, the least significant bit of the BLP would be
would be set to 1 if the packet corresponding to the PID and set to 1 if the packet corresponding to the PID and the
the following packet have been lost. However, the sender following packet have been lost. However, the sender cannot
cannot infer that packets PID+2 through PID+16 have been infer that packets PID+2 through PID+16 have been received
received simply because bits 2 through 15 of the BLP are 0; all simply because bits 2 through 15 of the BLP are 0; all the
the sender knows is that the receiver has not reported them as sender knows is that the receiver has not reported them as lost
lost at this time. at this time.
6.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.
skipping to change at page 28, line 52 skipping to change at page 31, line 52
PID = PIDx = 380 and #packets = PIDy - PID = 42. In case the PID = PIDx = 380 and #packets = PIDy - PID = 42. In case the
PID wraps around, modulo arithmetic is used to calculate the PID wraps around, modulo arithmetic is used to calculate the
number of packets. number of 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, definition is identical to that given in [10] except that,
here, BLP is only 15 bits wide. Denoting the BLP's least here, BLP is only 15 bits wide. Denoting the BLP's least
significant bit as bit 1, and its most significant bit as bit significant 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 15, then bit i of the bitmask is set to 1 if the receiver has
received RTP packet number PID+i (modulo 2^16) and the receiver received RTP packet number PID+i (modulo 2^16) and decides to
decides to ACK this packet; bit i is set to 0 otherwise. If ACK this packet; bit i is set to 0 otherwise. If only the
only the packet indicated by PID is to be ACKed and R=0 then packet indicated by PID is to be ACKed and R=0 then BLP MUST be
BLP MUST be set to 0x0000. set to 0x0000.
6.3 Payload Specific Feedback Messages 6.3 Payload Specific Feedback Messages
Payload-Specific Feedback Messages are identified by the value Payload-Specific Feedback Messages are identified by the value
PT=PSFB as RTCP message type. PT=PSFB as RTCP message type.
Three payload-specific feedback messages are defined so far plus an Three payload-specific feedback messages are defined so far plus an
application layer feedback message. They are identified by means application layer feedback message. They are identified by means
of the FMT parameter as follows: of the FMT parameter as follows:
0: forbidden 0: reserved
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 the The following subsections define the packet formats for the
payload-specific messages, section 6.4 defines the application payload-specific messages, section 6.4 defines the application
layer feedback message. layer feedback message.
skipping to change at page 34, line 10 skipping to change at page 37, line 10
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 re-establish encoder-decoder the encoder has to spend to re-establish encoder-decoder
synchronicity. See [15] for some information about the overhead of synchronicity. See [15] for some information about the overhead of
RPS for certain bit rate/frame rate/loss rate scenarios. RPS for certain bit rate/frame rate/loss rate scenarios.
Therefore, RPS messages should typically be sent as soon as Therefore, RPS messages should typically be sent as soon as
possible, employing the algorithm of section 3. possible, employing the algorithm of section 3.
6.4 Application Layer Feedback Messages 6.4 Application Layer Feedback Messages
Payload-Specific Feedback Messages are a special case of payload- Application Layer 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.
Usually, applications define their own set of messages, e.g. Usually, applications define their own set of messages, e.g.
NEWPRED messages in MPEG-4 or feedback messages in H.263/Annex N, NEWPRED messages in MPEG-4 or feedback messages in H.263/Annex N,
skipping to change at page 35, line 38 skipping to change at page 38, line 38
under similar conditions (e.g. using TFRC). under similar conditions (e.g. using TFRC).
8. Security Considerations 8. Security Considerations
RTP packets transporting information with the proposed payload RTP packets transporting information with the proposed payload
format are subject to the security considerations discussed in the format are subject to the security considerations discussed in the
RTP specification [1] and in the RTP/AVP profile specification [2]. RTP specification [1] and in the RTP/AVP profile specification [2].
This profile does not specify any additional security services. This profile does not specify any additional security services.
This profile modifies the timing behavior of RTCP and eliminates This profile modifies the timing behavior of RTCP and eliminates
the minimum RTCP interval of 5 seconds and allows for earlier the minimum RTCP interval of five seconds and allows for earlier
feedback to be provided by receivers. Group members of the feedback to be provided by receivers. Group members of the
associated RTP session (possibly pretending to represent a large associated RTP session (possibly pretending to represent a large
number of entities) may disturb the operation of RTCP by sending number of entities) may disturb the operation of RTCP by sending
large numbers of RTCP packets thereby reducing the RTCP bandwidth large numbers of RTCP packets thereby reducing the RTCP bandwidth
available for regular RTCP reporting as well as for early feedback available for regular RTCP reporting as well as for early feedback
messages. (Note that an entity need not be member of a multicast messages. (Note that an entity need not be member of a multicast
group to cause these effects.) group to cause these effects.)
Feedback information may be suppressed if unknown RTCP feedback Feedback information may be suppressed if unknown RTCP feedback
packets are received. This introduces the risk of a malicious packets are received. This introduces the risk of a malicious
skipping to change at page 36, line 46 skipping to change at page 39, line 46
9. IANA Considerations 9. IANA Considerations
The feedback profile as an extension to the profile for audio- The feedback profile as an extension to the profile for audio-
visual conferences with minimal control needs to be registered: visual conferences with minimal control needs to be registered:
"RTP/AVPF". "RTP/AVPF".
For the Session Description Protocol, the following "fmtp:" For the Session Description Protocol, the following "fmtp:"
attribute needs to be registered: "rtcp-fb". attribute needs to be registered: "rtcp-fb".
Along with "rtcp-fb", the feedback types "ack" and "nack" need to Along with "rtcp-fb", the feedback types "ack" and "nack" need to
be registered. be registered. Also, the value "trr-int" needs to be registered.
Along with "nack", the feedback type parameters "sli" and "pli" Along with "nack", the feedback type parameters "sli" and "pli"
need to be registered. need to be registered.
Along with "ack" and "nack", the feedback type parameters "rpsi" Along with "ack" and "nack", the feedback type parameters "rpsi"
and "app" need to be registered. and "app" need to be registered.
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"). Section 6 suggests RTPFB=205 and feedback messages ("PSFB"). Section 6 suggests RTPFB=205 and
PSFB=206 to be added to the RTCP registry. PSFB=206 to be added to the RTCP registry.
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
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
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)
10. Acknowledgements 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
skipping to change at page 39, line 43 skipping to change at page 42, line 43
[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-11.txt, Work in Progress, Draft, draft-ietf-avt-rtp-new-11.txt, Work in Progress,
November 2001. November 2001.
[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-12.txt, November 2001. avt-profile-new-12.txt, November 2001.
[3] M. Handley and V. Jacobson, "SDP: Session Description [3] M. Handley, V. Jacobson, and Colin Perkins, "SDP: Session
Protocol", RFC 2327, April 1998. Description Protocol", Internet Draft draft-ietf-mmusic-sdp-
new-10.txt, May 2002.
[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-05.txt, November 2001. Internet Draft draft-ietf-avt-rtcp-bw-05.txt, November 2001.
[5] C. Perkins and O. Hodson, "2354 Options for Repair of [5] C. Perkins and O. Hodson, "2354 Options for Repair of
Streaming Media," RFC 2354, June 1998. Streaming 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.
skipping to change at page 40, line 46 skipping to change at page 43, line 46
[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. video transmission," Proceedings IEEE, Vol. 87, No. 10, pp.
1707 - 1723, October, 1999. 1707 - 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, Control (TFRC): Protocol Specification," Internet Draft,
draft-ietf-tsvwg-tfrc-03.txt, Work in Progress, July 2001. draft-ietf-tsvwg-tfrc-03.txt, Work in Progress, July 2001.
[17] M. Baugher, R. Blom, E. Carrarra, D. McGrew, M. Naslund, K. [17] M. Baugher, R. Blom, E. Carrarra, D. McGrew, M. Naslund, K.
Norrman, D. Oran, "The Secure Real-Time Transport Protocol," Norrman, D. Oran, "The Secure Real-Time Transport Protocol,"
Internet Draft, draft-ietf-avt-srtp-02.txt, Work in Progress, Internet Draft, draft-ietf-avt-srtp-04.txt, Work in Progress,
November 2001. May 2002.
[18] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
SDP," Internet Draft draft-ietf-mmusic-sdp-offer-answer-
02.txt, February 2002.
 End of changes. 

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