draft-ietf-avt-rtcp-feedback-03.txt   draft-ietf-avt-rtcp-feedback-04.txt 
INTERNET-DRAFT Joerg Ott/Uni Bremen TZI INTERNET-DRAFT Joerg Ott/Uni Bremen TZI
draft-ietf-avt-rtcp-feedback-03.txt Stephan Wenger/TU Berlin draft-ietf-avt-rtcp-feedback-04.txt Stephan Wenger/TU Berlin
Shigeru Fukunaga/Oki
Noriyuki Sato/Oki Noriyuki Sato/Oki
Koichi Yano/Fast Forward Networks
Akihiro Miyazaki/Matsushita
Koichi Hata/Matsushita
Rolf Hakenberg/Matsushita
Carsten Burmeister/Matsushita Carsten Burmeister/Matsushita
Jose Rey/Matsushita Jose Rey/Matsushita
29 June 2002 31 October 2002
Expires December 2002 Expires April 2003
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 2, line 9 skipping to change at page 2, line 7
specific mechanisms). This document defines an extension to the specific mechanisms). This document defines an extension to the
Audio-visual Profile (AVP) that enables receivers to provide, Audio-visual Profile (AVP) that enables receivers to provide,
statistically, more immediate feedback to the senders and thus statistically, more immediate feedback to the senders and thus
allow for short-term adaptation and efficient feedback-based repair allow for short-term adaptation and efficient feedback-based repair
mechanisms to be implemented. This early feedback profile (AVPF) mechanisms to be implemented. This early feedback profile (AVPF)
maintains the AVP bandwidth constraints for RTCP and preserves maintains the AVP bandwidth constraints for RTCP and preserves
scalability to large groups. scalability to large groups.
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
packet losses. RTP [1] provides all the necessary mechanisms to losses. RTP [1] provides all the necessary mechanisms to restore
restore ordering and timing present at the sender to properly ordering and timing present at the sender to properly reproduce a
reproduce a media stream at a recipient. RTP also provides media stream at a recipient. RTP also provides continuous feedback
continuous feedback about the overall reception quality from all about the overall reception quality from all receivers -- thereby
receivers -- thereby allowing the sender(s) in the mid-term (in the allowing the sender(s) in the mid-term (in the order of several
order of several seconds to minutes) to adapt their coding scheme seconds to minutes) to adapt their coding scheme and transmission
and transmission behavior to the observed network QoS. However, behavior to the observed network QoS. However, except for a few
except for a few payload specific mechanisms [10], RTP makes no payload specific mechanisms [10], RTP makes no provision for timely
provision for timely feedback that would allow a sender to repair feedback that would allow a sender to repair the media stream
the media stream immediately: through retransmissions, retro-active immediately: through retransmissions, retro-active FEC control, or
FEC control, or media-specific mechanisms for some video codecs, media-specific mechanisms for some video codecs, such as reference
such as reference picture selection. 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
skipping to change at page 8, line 42 skipping to change at page 4, line 227
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 group size threshold can be specified at which this mode No group size threshold can be specified at which this mode
starts. 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 soft.
fluent.
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
:<=============>||<=============>//<=================> :<=============>||<=============>//<=================>
: || : ||
skipping to change at page 9, line 44 skipping to change at page 4, line 268
a) Let "senders" be the number of active senders in the RTP a) Let "senders" be the number of active senders in the RTP
session. 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 Tmin be the minimal interval between RTCP packets as per 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 [1]. Unlike [1], the initial Tmin is set to 1 second (to allow
is set to 0. for some group size sampling before sending the first RTCP
packet), then it is set to 0.
e) Let T_rr be the interval after which, having just sent a 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 regular RTCP packet following the rules transmission of its next regular RTCP packet following the rules
of [1]: T_rr = T (the "calculated interval") with tn = tp + T. of [1]: T_rr = T (the "calculated interval") with tn = tp + T.
Note that a different Tmin is used to compute the "calculated Note that Tmin as defined in this specification is used to
interval T". T_rr refers to the last value of T that has been compute the "calculated interval T". T_rr refers to the last
computed (because of reconsideration or to determine tn). value of T that has been computed (because of reconsideration or
to determine tn).
f) 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.
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). For point-to-point sessions, T_dither_max is set
to 0 and hence no additional delay is introduced.
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. Note that this value is application-specific. 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.
j) 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 at time t0.
packet P caused.
k) 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 has occurred. RTCP transmission has occurred.
l) 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
skipping to change at page 11, line 7 skipping to change at page 4, line 331
T_rr_interval). T_rr_interval).
NOTE: Providing T_rr_interval as an independent variable is NOTE: Providing T_rr_interval as an independent variable is
meant to minimize regular feedback (and thus bandwidth meant to minimize regular feedback (and thus bandwidth
consumption) as needed by the application but still allow for consumption) as needed by the application but still allow for
more frequent use of Early RTCP packets to provide timely more frequent use of Early RTCP packets to provide timely
feedback. This goal could not be achieved by reducing the feedback. This goal could not be achieved by reducing the
overall RTCP bandwidth as RTCP bandwidth reduction would also overall RTCP bandwidth as RTCP bandwidth reduction would also
impact the Early feedback. impact the Early feedback.
o) Let T_retention be the time window for which past RTCP feedback
messages are stored by an AVPF entity. This is to ensure that
feedback suppression also works for entities that have received
feedback messages from other entities prior to noticing the
feedback event itself. T_retention MUST be set to at least 2
seconds.
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 in multicast
MUST delay the transmission of the RTCP feedback packet by a random sessions, the receiver MUST delay the transmission of the RTCP
amount T_fd (with the random number evenly distributed in the feedback packet by a random amount T_fd (with the random number
interval [0, T_dither_max]). Transmission of the compound RTCP evenly distributed in the interval [0, T_dither_max]).
packet MUST then be scheduled for te = t0 + T_fd. Transmission of the compound RTCP packet MUST then be scheduled for
te = t0 + T_fd.
The T_dither_max parameter is derived from the regular RTCP The T_dither_max parameter is derived from the regular RTCP
interval (which, in turn, is based upon the group size). interval (which, in turn, is based upon the group size).
For a certain application scenario, a receiver may determine an For a certain application scenario, a receiver may determine an
upper bound for the acceptable local delay of feedback messages: upper bound for the acceptable local delay of feedback messages:
T_max_fb_delay. If an a priori estimation or the actual T_max_fb_delay. If an a priori estimation or the actual
calculation of T_dither_max indicates that this upper bound MAY be calculation of T_dither_max indicates that this upper bound MAY be
violated (e.g. because T_dither_max > T_max_fb_delay), the receiver violated (e.g. because T_dither_max > T_max_fb_delay), the receiver
MAY decide not to send any feedback at all because the achievable MAY decide not to send any feedback at all because the achievable
skipping to change at page 12, line 44 skipping to change at page 4, line 409
then denotes the minimal interval between regular RTCP packets. 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:
3.5.1 Initialization 3.5.1 Initialization
Initially, R MUST set allow_early = TRUE and t_rr_last = NaN. Initially, R MUST set allow_early = TRUE and t_rr_last = NaN.
Furthermore, the initialization of the RTCP variables as per [1] Furthermore, the initialization of the RTCP variables as per [1]
applies except that the initial value for Tmin is 1.0 seconds. applies except that the initial value for Tmin. For a unicast
session, the initial Tmin is set to 0. For a multicast session,
Tmin is initialized to 1.0 seconds.
3.5.2 Early Feedback Transmission 3.5.2 Early Feedback Transmission
Assume that R has scheduled the last RTCP RR packet for Assume that R has scheduled the last RTCP RR packet for
transmission at tp and has scheduled the next transmission transmission at tp and has scheduled the next transmission
(including possible reconsideration) for tn = tp + T_rr. Assume (including possible reconsideration) for tn = tp + T_rr. Assume
also that the last T_rr_interval-based transmission (if any) has also that the last T_rr_interval-based transmission (if any) has
occurred at t_rr_last (if defined). occurred at t_rr_last (if defined).
1. At time t0, R detects the need to transmit one or more RTCP 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.
2. R first checks whether there is still a compound RTCP feedback 2. R first checks whether there is already a compound RTCP packet
packet waiting for transmission (scheduled as early or regular RTCP containing an RTCP feedback message scheduled for transmission (as
packet). early or regular RTCP packet).
2.a) If so, the new feedback message MUST be appended to the 2.a) If so, the new feedback message MUST be included in the
packet; the scheduling of the waiting RTCP feedback packet scheduled packet; the scheduling of the waiting RTCP feedback
MUST remain unchanged. When appending, the feedback packet MUST remain unchanged. When doing so, the feedback
information of several RTCP feedback packets SHOULD be merged information of several RTCP feedback packets SHOULD be merged
to produce as few feedback messages as possible. This to produce as few feedback messages as possible. This
completes the course of immediate actions to be taken. completes the course of immediate actions to be taken.
2.b) If no RTCP feedback message is already awaiting 2.b) If no RTCP feedback message is already scheduled for
transmission, a new (minimal or full) compound RTCP feedback transmission, a new (minimal or full) compound RTCP feedback
packet MUST be created and the minimal interval for packet MUST be created and the minimal interval for
T_dither_max MUST be chosen as follows: 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 ii) If the session is a multicast session with potentially
more 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 Application-specific feedback considerations may make it
worthwhile to increase T_dither_max beyond this value. This worthwhile to increase T_dither_max beyond this value. This
is up to the discretion of the implementer. is up to the discretion of the implementer.
3. Then, R MUST check whether its next regularly scheduled RTCP 3. Then, R MUST check whether its next regularly scheduled RTCP
packet is within the time bounds for the RTCP FB (t0 + T_dither_max packet would be within the time bounds for the RTCP FB (t0 +
> tn). T_dither_max > tn).
3.a) If so, an Early RTCP packet MUST NOT be scheduled; 3.a) If so, an Early RTCP packet MUST NOT be scheduled;
instead the FB message(s) MUST be stored to be appended to the instead the FB message(s) MUST be stored to be appended to the
regular RTCP packet scheduled for tn. This completes the regular RTCP packet scheduled for tn. This completes the
course of immediate actions to be taken. course of immediate actions to be taken.
3.b) Otherwise, the following steps are carried out. 3.b) Otherwise, the following steps are carried out.
4. R MUST check whether it is allowed to transmit an Early RTCP 4. R MUST check whether it is allowed to transmit an Early RTCP
packet (allow_early == TRUE). packet (allow_early == TRUE).
skipping to change at page 14, line 24 skipping to change at page 4, line 487
transmission along with the RTCP packet at tn. transmission along with the RTCP packet at tn.
2. Otherwise, R MUST discard the RTCP feedback message. 2. Otherwise, R MUST discard the RTCP feedback message.
This completes the immediate course of actions to be taken. This completes the immediate course of actions to be taken.
4.b) If allow_early == TRUE then R MUST schedule an Early RTCP 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 packet for te = t0 + RND * T_dither_max with RND being a pseudo
random function evenly distributed between 0 and 1. random function evenly distributed between 0 and 1.
5. If, while waiting for te, R receives RTCP feedback packets 5. R MUST continuously monitor the received RTCP feedback packets
contained in one or more (minimal) compound RTCP packets, R MUST contained in one or more (minimal) compound RTCP packets and keep
act as follows for each of the RTCP feedback messages in the one or each of these packets for at least T_retention. When scheduling
more compound RTCP packets received in the interval [t0 - 1s ; te]: the transmission of an RTCP feedback message, R MUST check each of
the RTCP feedback messages in the one or more compound RTCP packets
received in the interval [t0 - T_retention ; te] and act as
follows:
5.a) 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 wanted and the message contents is a superset of the feedback R wanted
to send then R MUST discard its own feedback message and MUST to send then R MUST discard its own feedback message and MUST
re-schedule the next regular RTCP message transmission for tn re-schedule the next regular RTCP message transmission for tn
(as calculated before). (as calculated before).
5.b) 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 message wanted to send then R SHOULD transmit its own feedback message
skipping to change at page 16, line 13 skipping to change at page 4, line 576
RTCP transmission has occurred). Timer reconsideration takes place RTCP transmission has occurred). Timer reconsideration takes place
when tn is reached as per [1]. After timer reconsideration, the when tn is reached as per [1]. After timer reconsideration, the
following actions are taken: following actions are taken:
If no full compound RTCP packet has been sent before (i.e. if 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 t_rr_last == NaN) then a full compound RTCP packet MUST be
scheduled. Stored RTCP feedback messages MAY be included in scheduled. Stored RTCP feedback messages MAY be included in
the full compound RTCP packet. t_rr_last MUST be set to tn. the full compound RTCP packet. t_rr_last MUST be set to tn.
Tmin MUST be set to 0. Tmin MUST be set to 0.
If t_rr_last + T_rr_interval <= tn then a full compound RTCP Otherwise, an temporary value T_rr_current_interval is
packet MUST be scheduled. Stored RTCP feedback messages MAY calculated as follows:
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 T_rr_current_interval = RND*T_rr_interval
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 with RND being a pseudo random function evenly distributed
RTCP feedback messages are awaiting transmission), no compound between 0.5 and 1.5. This dithered value is used for the
RTCP packet MUST be scheduled. following alternatives:
If t_rr_last + T_rr_current_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_current_interval > tn and RTCP feedback
messages have been stored and are awaiting transmission, an
RTCP packet MUST be scheduled for transmission at tn. 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_current_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 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 and tn MUST be updated following the rules of [1] except for the
five second minimum. five second minimum.
3.5.4 Other Considerations 3.5.4 Other Considerations
Furthermore, if T_rr_interval != 0 then the timeout calculation for 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 RTP/AVPF entities (section 6.3.5 of [1]) MUST be modified to use
T_rr_interval instead of Tmin for computing Td. 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 subsequent
calculated using the new avg_rtcp_size. computations of tn MUST use 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
skipping to change at page 20, line 24 skipping to change at page 4, line 789
context of e.g. the Session Description Protocol (SDP) [3]. The context of e.g. the Session Description Protocol (SDP) [3]. The
profile specified in this document is referred to as "AVPF". profile specified in this document is referred to as "AVPF".
Feedback information following the modified timing rules as Feedback information following the modified timing rules as
specified in this document MUST NOT be sent for a particular media specified in this document MUST NOT be sent for a particular media
session unless the profile for this session indicates the use of session unless the profile for this session indicates the use of
the "AVPF" profile (exclusively or jointly with other AV profiles). the "AVPF" profile (exclusively or jointly with other AV profiles).
4.2 RTCP Feedback Capability Attribute 4.2 RTCP Feedback Capability Attribute
A new payload format-specific SDP attribute (for use with A new payload format-specific SDP attribute is defined to indicate
"a=fmtp:") is defined to indicate the capability of using RTCP the capability of using RTCP feedback as specified in this
feedback as specified in this document: "rtcp-fb". The "rtcp-fb" document: "a=rtcp-fb". The "rtcp-fb" attribute MUST only be used
attribute MUST only be used as an SDP media attribute and MUST NOT as an SDP media attribute and MUST NOT be provided at the session
be provided at the session level. The "rtcp-fb" attribute MUST level. The "rtcp-fb" attribute MUST only be used in media sessions
only be used in media sessions for which the "AVPF" is specified. for which the "AVPF" is specified.
The "rtcp-fb" attribute SHOULD be used to indicate which RTCP The "rtcp-fb" attribute SHOULD be used to indicate which RTCP
feedback messages MAY be used in this media session for the feedback messages MAY be used in this media session for the
indicated payload type. If several types of feedback are indicated payload type. A wildcard payload type ("*") MAY be used
supported, several "a=rtcp-fb:" lines MUST be used. to indicate that the RTCP feedback attribute applies to all payload
types. If several types of feedback are supported and/or the same
feedback shall be specified for a subset of the payload types,
several "a=rtcp-fb:" lines MUST be used.
If no "rtcp-fb" attribute is specified the RTP receivers SHOULD If no "rtcp-fb" attribute is specified the RTP receivers SHOULD
assume that the RTP senders only support generic NACKs. In assume that the RTP senders only support generic NACKs. In
addition, the RTP receivers MAY send feedback using other suitable addition, the RTP receivers MAY send feedback using other suitable
RTCP feedback packets as defined for the respective media type. RTCP feedback packets as defined for the respective media type.
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=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 When used in conjunction with the offer/answer model [18], the
offerer MAY present a set of these AVPF attributes to its peer. offerer MAY present a set of these AVPF attributes to its peer.
The answerer MUST remove all attributes it does not understand as The answerer MUST remove all attributes it does not understand as
skipping to change at page 21, line 29 skipping to change at page 4, line 844
mechanisms negotiated in this way. 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):
(In the following ABNF, SP and CRLF are used as defined in [3].) (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-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF
rtcp-fb-pt = "*" ; wildcard: applies to all formats
/ fmt ; as defined in SDP spec
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 / "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 = SP "app" rtcp-fb-param = SP "app" [SP byte-string]
| SP byte-string / SP token [SP byte-string]
| ; empty / ; empty
rtcp-fb-ack-param = SP "rpsi" rtcp-fb-ack-param = SP "rpsi"
| SP "app" / SP "app" [SP byte-string]
| SP byte-string / SP token [SP byte-string]
| ; empty / ; empty
rtcp-fb-nack-param = SP "pli" rtcp-fb-nack-param = SP "pli"
| SP "sli" / SP "sli"
| SP "rpsi" / SP "rpsi"
| SP "app" / SP "app" [SP byte-string]
| SP byte-string / SP token [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 24, line 38 skipping to change at page 4, line 1001
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback s=Media with feedback
t=0 0 t=0 0
c=IN IP4 host.example.com c=IN IP4 host.example.com
m=audio 49170 RTP/AVPF 0 96 m=audio 49170 RTP/AVPF 0 96
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000 a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16 a=fmtp:96 0-16
a=fmtp:96 rtcp-fb ack a=rtcp-fb:96 ack
Example 2: The following session description indicates a multicast Example 2: The following session description indicates a multicast
video-only session (using H.263+) with the video source accepting video-only session (using either H.261 or H.263+) with the video
Generic NACKs and Reference Picture Selection. Such a description source accepting Generic NACKs for both codecs and Reference
may have been conveyed using the Session Announcement Protocol Picture Selection for H.263. Such a description may have been
(SAP). 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/AVPF 98 m=video 51372 RTP/AVPF 98 99
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=rtpmap:99 H261/90000
a=fmtp:98 rtcp-fb nack rpsi a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi
Example 3: The following session description defines the same media Example 3: The following session description defines the same media
session as example 2 but allows for mixed mode operation of AVP and session as example 2 but allows for mixed mode operation of AVP and
AVPF RTP entities (see also next section). Note that both media AVPF RTP entities (see also next section). Note that both media
descriptions use the same addresses; however, two m= lines are descriptions use the same addresses; however, two m= lines are
needed to convey information about both applicable RTP profiles. needed to convey information about both applicable RTP profiles.
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/AVP 98 99
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
m=video 51372 RTP/AVPF 98 a=rtpmap:99 H261/90000
m=video 51372 RTP/AVPF 98 99
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=rtpmap:99 H261/90000
a=fmtp:98 rtcp-fb nack rpsi a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi
Note that these two m= lines SHOULD be grouped by some appropriate Note that these two m= lines SHOULD be grouped by some appropriate
mechanisms to indicate that both are alternatives actually mechanisms to indicate that both are alternatives actually
conveying the same contents. A sample mechanism by which this can conveying the same contents. A sample mechanism by which this can
be achieved is defined in [14]. be achieved is defined in [14].
5. Interworking and Co-Existence of AVP and AVPF Entities 5. Interworking and Co-Existence of AVP and AVPF Entities
The AVPF profile defined in this document is an extension of the The AVPF profile defined in this document is an extension of the
AVP profile as defined in [2]. Both profiles follow the same basic AVP profile as defined in [2]. Both profiles follow the same basic
skipping to change at page 26, line 25 skipping to change at page 4, line 1090
RTCP reports than AVP ones will. Also, the overall reporting RTCP reports than AVP ones will. Also, the overall reporting
may decrease slightly as AVPF entities may send bigger compound may decrease slightly as AVPF entities may send bigger compound
RTCP packets (due to the extra RTCP packets). RTCP packets (due to the extra RTCP packets).
If T_rr_interval is used as lower bound between regular RTCP If T_rr_interval is used as lower bound between regular RTCP
packets, T_rr_interval is sufficiently large (e.g. T_rr_interval 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 > 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 are sent by AVPF entities, AVP entities MAY accidentally time
out those AVPF group members and hence under-estimate the group out those AVPF group members and hence under-estimate the group
size. Therefore, if AVP entities may be involved in a media size. Therefore, if AVP entities may be involved in a media
session, T_rr_interval SHOULD NOT be used. session, T_rr_interval SHOULD NOT be larger than five seconds .
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 27, line 24 skipping to change at page 4, line 1140
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 specification and thus
thus can be identified by the application so that there is no need can be identified by the application so that there is no need for
for additional external information. Hence, this document defines additional external information. Hence, this document defines only
only a common header to be used along with all application layer a common header to be used along with all application layer
feedback messages. From a protocol point of view, an application feedback messages. From a protocol point of view, an application
layer feedback message is treated as a special case of a payload- layer feedback message is treated as a special case of a payload-
specific feedback message. specific feedback message.
NOTE: Proper processing of some feedback messages at the media
sender side may require the sender to know which payload type
the feedback message refers to. Most of the time, this
knowledge can likely be derived from a media stream using only
a single payload type. However, if several codecs are used
simultaneously (e.g. with audio and DTFM) or when codec
changes occur, the payload type information may need to be
conveyed explicitly as part of the feedback message. This
applies to all payload-specific as well as application layer
feedback messages. It is up to the specification of a
feedback message to define how payload type information is
transmitted.
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 are described in the following subsections. message types are described in the following subsections.
skipping to change at page 27, line 43 skipping to change at page 4, line 1172
(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 are 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| 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
skipping to change at page 28, line 31 skipping to change at page 4, line 1201
version (V): 2 bits version (V): 2 bits
This field identifies the RTP version. The current version is This field identifies the RTP version. The current version is
2. 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.
Feedback message type (FMT): 4 bits Feedback message type (FMT): 5 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 layer feedback). The values payload-specific, or application layer feedback). The values
for each of the three feedback types are defined in the for each of the three feedback types are defined in the
respective sections below. respective sections below.
Payload type (PT): 8 bits Payload type (PT): 8 bits
This is the RTCP packet type which identifies the packet as This is the RTCP packet type which identifies the packet as
being an RTCP Feedback Message. Two values are defined (TBA. being an RTCP Feedback Message. Two values are defined (TBA.
by IANA): by IANA):
skipping to change at page 29, line 17 skipping to change at page 4, line 1236
this packet. this packet.
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 The following three sections define which additional
information MAY be included in the feedback message for each information MAY be included in the feedback message for each
type of feedback (further FCI contents MAY be specified in type of feedback (further FCI contents MAY be specified in
further documents). Each RTCP feedback packet MUST contain further documents).
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 Each RTCP feedback packet MUST contain at least one feedback
conveyed, then several RTCP feedback packets MUST be generated message in the FCI field. Sections 6.2 and 6.3 define for each
and concatenated in the same compound RTCP packet. FCI type, whether or not multiple feedback messages MAY be
contained in a single FCI field. If multiple feedback messages
are contained in one FCI field, they MUST be of the same type
as. If multiple types of feedback need to be conveyed, then
several RTCP feedback packets MUST be generated and SHOULD
concatenated in the same compound RTCP packet.
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: reserved 0: unassigned
1: Generic NACK 1: Generic NACK
2: Generic ACK 2: Generic ACK
3-15: reserved 3-30: unassigned
31: reserved for future expansion of the sequence number space
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.
The FCI field MUST contain at least one and MAY contain more than
one Generic NACK.
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):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 30, line 25 skipping to change at page 4, line 1299
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 receiver has not received RTP packet number PID+i 1 if the receiver has not received RTP packet number (PID+i)
(modulo 2^16) and indicates this packet is lost; bit i is set (modulo 2^16) and indicates 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 receiver has received a packet because its bit mask was set to
0. For example, the least significant bit of the BLP would be 0. For example, the least significant bit of the BLP would be
set to 1 if the packet corresponding to the PID and the set to 1 if the packet corresponding to the PID and the
following packet have been lost. However, the sender cannot following packet have been lost. However, the sender cannot
infer that packets PID+2 through PID+16 have been received infer that packets PID+2 through PID+16 have been received
simply because bits 2 through 15 of the BLP are 0; all the simply because bits 2 through 15 of the BLP are 0; all the
sender knows is that the receiver has not reported them as lost sender knows is that the receiver has not reported them as lost
at this time. at this time.
The length of the feedback message MUST be set to 2+n, with n being
the number of Generic NACKs contained in the FCI field.
The Generic NACK message implicitly references the payload type
through the sequence number(s).
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 FCI field MUST contain at least one and MAY contain more than
one Generic ACK.
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:
0 1 2 3 0 1 2 3
skipping to change at page 31, line 53 skipping to change at page 4, line 1379
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 receiver 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 decides to received RTP packet number (PID+i) (modulo 2^16) and decides to
ACK this packet; bit i is set to 0 otherwise. If only the ACK this 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 packet indicated by PID is to be ACKed and R=0 then BLP MUST be
set to 0x0000. set to 0x0000.
The length of the feedback message MUST be set to 2+n, with n being
the number of Generic ACKs contained in the FCI field.
The Generic ACK message implicitly references the payload type
through the sequence number(s).
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: reserved 0: unassigned
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
16-30: unassigned
31: reserved for future expansion of the sequence number space
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.
6.3.1 Picture Loss Indication (PLI) 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.
There MUST be exactly one PLI contained in the FCI field.
6.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 an undefined amount of coded video data encoder about the loss of an undefined amount of coded video data
belonging to one or more pictures. When used in conjunction with belonging to one or more pictures. When used in conjunction with
any video coding scheme that is based on inter-picture prediction, any video coding scheme that is based on inter-picture prediction,
an encoder that receives a PLI becomes aware that the prediction an encoder that receives a PLI becomes aware that the prediction
chain may be broken. The sender MAY react to a PLI by transmitting chain may be broken. The sender MAY react to a PLI by transmitting
an intra-picture to achieve resynchronization (making effectively an intra-picture to achieve resynchronization (making effectively
skipping to change at page 33, line 12 skipping to change at page 4, line 1444
compatibility reasons, such an application SHOULD also be capable compatibility reasons, such an application SHOULD also be capable
to receive and react to the feedback scheme defined in the to receive and react to the feedback scheme defined in the
respective RTP payload format, if this is required by that payload respective RTP payload format, if this is required by that payload
format. format.
6.3.1.2 Message Format 6.3.1.2 Message Format
PLI does not require parameters. Therefore, the length field MUST PLI does not require parameters. Therefore, the length field MUST
be 2, and there MUST NOT be any Feedback Control Information. be 2, and there MUST NOT be any Feedback Control Information.
The semantics of this feedback message is independent of the
payload type.
6.3.1.3 Timing Rules 6.3.1.3 Timing Rules
The timing follows the rules outlined in section 3. In systems The timing follows the rules outlined in section 3. In systems
that employ both PLI and other types of feedback it may be that employ both PLI and other types of feedback it may be
advisable to follow the regular RTCP RR timing rules for PLI, since advisable to follow the regular RTCP RR timing rules for PLI, since
PLI is not as delay critical as other FB types. PLI is not as delay critical as other FB types.
6.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.
skipping to change at page 33, line 38 skipping to change at page 4, line 1473
intra picture is assumed to be 10 times as big as an inter picture, intra picture is assumed to be 10 times as big as an inter picture,
then a full second of latency has to be accepted. In such an then a full second of latency has to be accepted. In such an
environment there is no need for a particular short delay in environment there is no need for a particular short delay in
sending the feedback message. Hence waiting for the next possible sending the feedback message. Hence waiting for the next possible
time slot allowed by RTCP timing rules as per [2] does not have a time slot allowed by RTCP timing rules as per [2] does not have a
negative impact on the system performance. negative impact on the system performance.
6.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.
The FCI field MUST contain at least one and MAY contain more than
one SLI.
6.3.2.1 Semantics 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 has detected the loss or corruption of one or several it has detected the loss or corruption of one or several
consecutive macroblock(s) in scan order (see below). This feedback consecutive macroblock(s) in scan order (see below). This feedback
message MUST NOT be used for video codecs with non-uniform, message MUST NOT be used for video codecs with non-uniform,
dynamically changeable macroblock sizes such as H.263 with enabled dynamically changeable macroblock sizes such as H.263 with enabled
Annex Q. In such a case, an encoder cannot always identify the Annex Q. In such a case, an encoder cannot always identify the
corrupted spatial region. corrupted spatial region.
6.3.2.2 Format 6.3.2.2 Format
The Slice Lost Indication uses one additional PCI field the The Slice Lost Indication uses one additional PCI field the
content of which is depicted in figure 6. The length of the content of which is depicted in figure 6. The length of the
feedback message MUST be set to 3. feedback message MUST be set to 2+n, with n being the number of
SLIs contained in the FCI field.
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 | PictureID | |0| Payload Type| MBZ | First |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number | PictureId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Syntax of the Slice Lost Indication (SLI) Figure 6: Syntax of the Slice Lost Indication (SLI)
First: 13 bits 0: 1 bit
MUST be set to '0' upon transmission and MUST be ignored upon
reception.
Payload Type: 7 bits
This field contains the Payload Type of the RTP packet (i.e.
the codec) the SLI message refers to.
MBZ: 8 bits
MUST be set to '0' upon transmission and MUST be ignored upon
reception.
First: 16 bits
The macroblock (MB) address of the first lost macroblock. The The macroblock (MB) address of the first lost macroblock. The
MB numbering is done such that the macroblock in the upper left MB numbering is done such that the macroblock in the upper left
corner of the picture is considered macroblock number 1 and the corner of the picture is considered macroblock number 1 and the
number for each macroblock increases from left to right and number for each macroblock increases from left to right and
then from top to bottom in raster-scan order (such that if then from top to bottom in raster-scan order (such that if
there is a total of N macroblocks in a picture, the bottom there is a total of N macroblocks in a picture, the bottom
right macroblock is considered macroblock number N). right macroblock is considered macroblock number N).
Number: 13 bits Number: 16 bits
The number of lost macroblocks, in scan order as discussed The number of lost macroblocks, in scan order as discussed
above. above.
PictureID: 6 bits PictureID: 16 bits
The six least significant bits of the a codec-specific The six least significant bits of the a codec-specific
identifier that is used to reference the picture in which the identifier that is used to reference the picture in which the
loss of the macroblock (s) has occurred. For many video loss of the macroblock (s) has occurred. For many video
codecs, the PictureID is identical to the Temporal Reference.. codecs, the PictureID is identical to the Temporal Reference.
6.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 not reported as being corrupted. Therefore, the use of the
algorithm discussed in section 3 is highly recommended. algorithm discussed in section 3 is highly recommended.
6.3.2.4 Remarks 6.3.2.4 Remarks
skipping to change at page 35, line 37 skipping to change at page 4, line 1579
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 much higher parts of the picture and, therefore, have to transmit much higher
data volume in case of delayed FBs. data volume in case of delayed FBs.
6.3.3 Reference Picture Selection Indication (RPSI) 6.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.
There MUST be exactly one RPSI contained in the FCI field.
6.3.3.1 Semantics 6.3.3.1 Semantics
Modern video coding standards such as MPEG-4 visual version 2 [12] Modern video coding standards such as MPEG-4 visual version 2 [12]
or H.263 version 2 [13] allow to use older reference pictures than or H.263 version 2 [13] allow to use older reference pictures than
the most recent one for predictive coding. Typically, a first-in- the most recent one for predictive coding. Typically, a first-in-
first-out queue of reference pictures is maintained. If an encoder first-out queue of reference pictures is maintained. If an encoder
has learned about a loss of encoder-decoder synchronicity, a known- has learned about a loss of encoder-decoder synchronicity, a known-
as-correct reference picture can be used. As this reference picture as-correct reference picture can be used. As this reference picture
is temporally further away then usual, the resulting predictively is temporally further away then usual, the resulting predictively
skipping to change at page 36, line 23 skipping to change at page 4, line 1614
RTCP intervals is not expected to be of much use anyway). RTCP intervals is not expected to be of much use anyway).
6.3.3.2 Format 6.3.3.2 Format
The FCI for the RPSI message follows the format depicted in figure The FCI for the RPSI message follows the format depicted in figure
7: 7:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB | Native RPSI bit string defined per codec | | PB |0| Payload Type| Native RPSI bit string |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding (0)| | as defined per codec ... | Padding (0)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Syntax of the Reference Picture Selection Indication Figure 7: Syntax of the Reference Picture Selection Indication
(RPSI) (RPSI)
PB: 8 bits PB: 8 bits
The number of unused bits required to pad the length of the The number of unused bits required to pad the length of the
RPSI message to a multiple of 32 bits. RPSI message to a multiple of 32 bits.
0: 1 bit
MUST be set to zero upon transmission and ignored upon
reception.
Payload Type: 8 bits
Indicates the RTP payload type in the context of which the
native RPSI bit string MUST be interpreted.
Native RPSI bit string: variable length Native RPSI bit string: variable length
The RPSI information as natively defined by the video codec. The RPSI information as natively defined by the video codec.
Padding: #PB bits Padding: #PB bits
A number of bits set to zero to fill up the contents of the A number of bits set to zero to fill up the contents of the
RPSI message to the next 32 bit boundary. The number of RPSI message to the next 32 bit boundary. The number of
padding bits MUST be indicated by the PB field. padding bits MUST be indicated by the PB field.
6.3.3.3 Timing Rules 6.3.3.3 Timing Rules
skipping to change at page 37, line 12 skipping to change at page 4, line 1657
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
Application Layer 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.
There MUST be exactly one Application Layer Feedback message
contained in the FCI field.
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,
U. These messages do not need any additional information from the U. These messages do not need any additional information from the
RTCP message. Thus the application message is simply placed into RTCP message. Thus the application message is simply placed into
the FCI field as follows and the length field is set accordingly. the FCI 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 This field contains the original application message that
should be transported from the receiver to the source. The should be transported from the receiver to the source. The
format is application dependent. The length of this field is format is application dependent. The length of this field is
variable. If the application data is not byte aligned, padding variable. If the application data is not 32-bit-aligned,
bits must be added. Identification of padding bits is up to padding bits and bytes must be added. Identification of
the application layer and not defined in this specification. padding is up to the application layer and not defined in this
specification.
The application layer feedback message specification MUST define
whether or not the message needs to be interpreted specifically in
the context of a certain codec (identified by the RTP payload
type). If a reference to the payload type is required for proper
processing, the application layer feedback message specification
MUST define a way to communicate the payload type information as
part of the application layer feedback message itself.
7. Early Feedback and Congestion Control 7. Early Feedback and Congestion Control
In the previous sections, the feedback messages were defined as In the previous sections, the feedback messages were defined as
well as the timing rules according to which to send these messages. well as the timing rules according to which to send these messages.
The way to react to the feedback received depends on the The way to react to the feedback received depends on the
application using the feedback mechanisms and hence is beyond the application using the feedback mechanisms and hence is beyond the
scope of this document. scope of this document.
However, across all applications, there is a common requirement for However, across all applications, there is a common requirement for
skipping to change at page 39, line 34 skipping to change at page 4, line 1787
SHOULD still adhere to the maximum RTCP bandwidth but make sure SHOULD still adhere to the maximum RTCP bandwidth but make sure
that they are capable of transmitting at least regularly scheduled that they are capable of transmitting at least regularly scheduled
RTCP packets. Senders SHOULD carefully consider how to adjust RTCP packets. Senders SHOULD carefully consider how to adjust
their transmission bandwidth when encountering strange reporting their transmission bandwidth when encountering strange reporting
behavior; they MUST NOT increase their transmission bandwidth even behavior; they MUST NOT increase their transmission bandwidth even
if ignoring suspicious feedback. if ignoring suspicious feedback.
Attacks using false RTCP packets (regular as well as early ones) Attacks using false RTCP packets (regular as well as early ones)
can be avoided by authenticating all RTCP messages. This can be can be avoided by authenticating all RTCP messages. This can be
achieved by using the AVPF profile together with the Secure RTP achieved by using the AVPF profile together with the Secure RTP
profile as defined in [17]. profile as defined in [17]; as a prerequisite, an appropriate
combination of those two profiles (an "SAVPF") needs to be
specified.
9. IANA Considerations 9. IANA Considerations
The following contact information shall be used for all
registrations included here:
Contact: Joerg Ott
mailto:jo@acm.org
tel:+49-421-201-7028
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 for
the Session Description Protocol (specifically the type "proto"):
"RTP/AVPF". "RTP/AVPF".
For the Session Description Protocol, the following "fmtp:" SDP Protocol ("proto"):
attribute needs to be registered: "rtcp-fb".
Along with "rtcp-fb", the feedback types "ack" and "nack" need to Name: RTP/AVPF
be registered. Also, the value "trr-int" needs to be registered. Long form: Extended RTP Profile with RTCP-based Feedback
Type of name: proto
Type of attribute: Media level only
Purpose: See this document
Reference: This document
Along with "nack", the feedback type parameters "sli" and "pli" SDP Attribute ("att-field"):
need to be registered.
Along with "ack" and "nack", the feedback type parameters "rpsi" Attribute name: rtcp-fb
and "app" need to be registered. Long form: RTCP Feedback parameter
Type of name: att-field
Type of attribute: Media level only
Subject to charset: No
Purpose: See this document
Reference: This document
Values: See this document and registrations below
A new registry needs to be set up for the "rtcp-fb" attribute, with
the following registrations created initially: "ack", "nack", "trr-
int", and "app" as defined in this document.
Initial value registration for the attribute "rtcp-fb"
Value name: ack
Long name: Positive acknowledgement
Reference: This document.
Value name: nack
Long name: Negative Acknowledgement
Reference: This document.
Value name: trr-int
Long name: Minimal receiver report interval
Reference: This document.
Value name: app
Long name: Application-defined paramater
Reference: This document.
Further entries may be registered on a first-come first serve
basis. Each new registration needs to indicate the parameter name
and the syntax of possible additional arguments. For each new
registration, it is mandatory that a permanent, stable, and
publicly accessible document exists that specifies the semantics of
the registered parameter, the syntax and semantics of its
parameters as well as corresponding feedback packet formats (if
needed). The general registration procedures of [3] apply.
For use with both "ack" and "nack", a joint sub-registry needs to
be set up that initially registers the following values:
Initial value registration for the attribute values "ack" and
"nack":
Value name: sli
Long name: Slice Loss Indication
Usable with: nack
Reference: This document.
Value name: pli
Long name: Picture Loss Indication
Usable with: nack
Reference: This document.
Value name: rpsi
Long name: Reference Picture Selection Indication
Usable with: ack, nack
Reference: This document.
Value name: app
Long name: Application layer feedback
Usable with: ack, nack
Reference: This document.
Further entries may be registered on a first-come first serve
basis. Each registrations needs to indicate the parameter name,
the syntax of possible additional arguments, and whether the
parameter is applicable to "ack" or "nack" feedback or both or some
different "rtcp-fb" attribute parameter. For each new
registration, it is mandatory that a permanent, stable, and
publicly accessible document exists that specifies the semantics of
the registered parameter, the syntax and semantics of its
parameters as well as corresponding feedback packet formats (if
needed). The general registration procedures of [3] apply.
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 RTP RTCP Control Packet types (PT):
registered:
1: General NACK Name: RTPFB
2: General ACK Long name: Generic RTP Feedback
Value: 205
Reference: This document.
Within the PSFB range, five format (FMT) values need to be Name: PSFB
registered: Long name: Payload-specific
Value: 206
Reference: This document.
1: Picture Loss Indication (PLI) As AVPF defines additional RTCP payload types, the corresponding
2: Slice Loss Indication (SLI) "reserved" RTP payload type space (72--76, as defined in [2]),
3: Reference Picture Selection Indication (SLI) needs to be expanded accordingly (to cover the range 72--78).
15: Application layer feedback (AFB)
A new sub-registry needs to be set up for the FMT values for both
the RTPFB payload type and the PSFB payload type, with the
following registrations created initially:
Within the RTPFB range, the following three format (FMT) values are
initially registered:
Name: Generic NACK
Long name: Generic negative acknowledgement
Value: 1
Reference: This document.
Name: Generic ACK
Long name: Generic positive acknowledgement
Value: 2
Reference: This document.
Name: Extension
Long name: Reserved for future extensions
Value: 31
Reference: This document.
Within the PSFB range, the following five format (FMT) values are
initially registered:
Name: PLI
Long name: Picture Loss Indication
Value: 1
Reference: This document.
Name: SLI
Long name: Slice Loss Indication
Value: 2
Reference: This document.
Name: RPSI
Long name: Reference Picture Selection Indication
Value: 3
Reference: This document.
Name: AFB
Long name: Application Layer Feedback
Value: 1
Reference: This document.
Name: Extension
Long name: Reserved for future extensions.
Value: 31
Reference: This document.
Further entries may be registered on a first-come first serve
basis. Each registration needs to indicate the FMT value, if there
is a specific feedback message to go into the FCI field, and
whether or not multiple feedback messages may be stacked in a
single FCI field. For each new registration, it is mandatory that
a permanent, stable, and publicly accessible document exists that
specifies the semantics of the registered parameter as well as the
syntax and semantics of the associated feedback message (if any).
The general registration procedures of [3] apply.
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
as for their responsiveness to numerous questions. as for their responsiveness to numerous questions. The authors
would also like to thank Magnus Westerlund for his review and his
valuable suggestions; Shigeru Fukunaga, Koichi Yano, Akihiro
Miyazaki, and Rolf Hakenberg for the contributions on for feedback
message formats and semantics; and Andreas Buesching for his
feedback based upon implementation and testing.
11. 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 others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works. paragraph are included on all such copies and derivative works.
skipping to change at page 41, line 28 skipping to change at page 4, line 2029
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
Shigeru Fukunaga
Oki Electric Industry Co., Ltd.
1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan
Tel. +81 6 6949 5101
Fax. +81 6 6949 5108
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.com Mail sato652@oki.com
Koichi Yano Carsten Burmeister
FastForward Networks,
75 Hawthorne St. #601
San Francisco, CA 94105
Tel. +1.415.430.2500
Akihiro Miyazaki
Matsushita Electric Industrial Co., Ltd
1006, Kadoma, Kadoma City, Osaka, Japan
Tel. +81-6-6900-9192
Fax. +81-6-6900-9193
Mail akihiro@isl.mei.co.jp
Koichi Hata
Matsushita Electric Industrial Co., Ltd
1006, Kadoma, Kadoma City, Osaka, Japan
Tel. +81-6-6900-9192
Fax. +81-6-6900-9193
Mail hata@isl.mei.co.jp
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-263
Fax. +49-(0)6103-766-166 Fax. +49-(0)6103-766-166
Mail hakenberg@panasonic.de Mail burmeister@panasonic.de
Carsten Burmeister Jose Rey
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-134
Fax. +49-(0)6103-766-166 Fax. +49-(0)6103-766-166
Mail burmeister@panasonic.de Mail hakenberg@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-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-
skipping to change at page 43, line 46 skipping to change at page 4, line 2112
[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-04.txt, Work in Progress, Internet Draft, draft-ietf-avt-srtp-05.txt, Work in Progress,
May 2002. June 2002.
[18] J. Rosenberg and H. Schulzrinne, "An offer/answer model with [18] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
SDP," Internet Draft draft-ietf-mmusic-sdp-offer-answer- SDP," Internet Draft draft-ietf-mmusic-sdp-offer-answer-
02.txt, February 2002. 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/