draft-ietf-avt-rtcp-feedback-04.txt   draft-ietf-avt-rtcp-feedback-05.txt 
INTERNET-DRAFT Joerg Ott/Uni Bremen TZI INTERNET-DRAFT Joerg Ott/Uni Bremen TZI
draft-ietf-avt-rtcp-feedback-04.txt Stephan Wenger/TU Berlin draft-ietf-avt-rtcp-feedback-05.txt Stephan Wenger/TU Berlin
Noriyuki Sato/Oki Noriyuki Sato/Oki
Carsten Burmeister/Matsushita Carsten Burmeister/Matsushita
Jose Rey/Matsushita Jose Rey/Matsushita
31 October 2002 28 February 2003
Expires April 2003 Expires August 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
provisions of Section 10 of RFC 2026. Internet-Drafts are working all provisions of Section 10 of RFC 2026. Internet-Drafts are
documents of the Internet Engineering Task Force (IETF), its areas, working documents of the Internet Engineering Task Force (IETF),
and its working groups. Note that other groups may also distribute its areas, and its working groups. Note that other groups may also
working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet- Drafts as reference documents at any time. It is inappropriate to use Internet- Drafts
material or to cite them other than as "work in progress." as reference material or to cite them other than as "work in
progress."
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
skipping to change at page 2, line 5 skipping to change at page 2, line 5
its transmission behavior in the mid-term as sole means for its transmission behavior in the mid-term as sole means for
feedback and feedback-based error repair (besides a few codec- feedback and feedback-based error repair (besides a few codec-
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 Table of Contents
Real-time media streams that use RTP are not resilient against packet 1 Introduction..................................................3
losses. RTP [1] provides all the necessary mechanisms to restore 1.1 Definitions.............................................4
ordering and timing present at the sender to properly reproduce a 1.2 Terminology.............................................5
media stream at a recipient. RTP also provides continuous feedback 2 RTP and RTCP Packet Formats and Protocol Behavior.............6
about the overall reception quality from all receivers -- thereby 3 Rules for RTCP Feedback.......................................6
allowing the sender(s) in the mid-term (in the order of several 3.1 Compound RTCP Feedback Packets..........................6
seconds to minutes) to adapt their coding scheme and transmission 3.2 Algorithm Outline.......................................8
behavior to the observed network QoS. However, except for a few 3.3 Modes of Operation......................................9
payload specific mechanisms [10], RTP makes no provision for timely 3.4 Definitions and Algorithm Overview.....................10
feedback that would allow a sender to repair the media stream 3.5 Early RTCP Algorithm...................................13
immediately: through retransmissions, retro-active FEC control, or 3.5.1 Initialization........................................14
media-specific mechanisms for some video codecs, such as reference 3.5.2 Early Feedback Transmission...........................14
picture selection. 3.5.3 Regular RTCP Transmission.............................17
3.5.4 Other Considerations..................................18
3.6 Considerations on the Group Size.......................18
3.6.1 ACK mode..............................................18
3.6.2 NACK mode.............................................19
3.7 Summary of decision steps..............................20
3.7.1 General Hints.........................................21
3.7.2 Media Session Attributes..............................21
4 SDP Definitions..............................................22
4.1 Profile identification.................................22
4.2 RTCP Feedback Capability Attribute.....................22
4.3 Unicasting vs. Multicasting............................25
4.4 RTCP Bandwidth Modifiers...............................26
4.5 Examples...............................................26
5 Interworking and Co-Existence of AVP and AVPF Entities.......27
6 Format of RTCP Feedback Messages.............................29
6.1 Common Packet Format for Feedback Messages.............30
6.2 Transport Layer Feedback Messages......................31
6.2.1 Generic NACK..........................................32
6.2.2 Generic ACK...........................................33
6.3 Payload Specific Feedback Messages.....................34
6.3.1 Picture Loss Indication (PLI).........................35
6.3.1.1 Semantics..........................................35
6.3.1.2 Message Format.....................................35
6.3.1.3 Timing Rules.......................................36
6.3.1.4 Remarks............................................36
6.3.2 Slice Lost Indication (SLI)...........................36
6.3.2.1 Semantics..........................................36
6.3.2.2 Format.............................................37
6.3.2.3 Timing Rules.......................................37
6.3.2.4 Remarks............................................38
6.3.3 Reference Picture Selection Indication (RPSI).........38
6.3.3.1 Semantics..........................................38
6.3.3.2 Format.............................................39
6.3.3.3 Timing Rules.......................................40
6.4 Application Layer Feedback Messages....................40
7 Early Feedback and Congestion Control........................41
8 Security Considerations......................................42
9 IANA Considerations..........................................43
10 Acknowledgements.............................................47
11 Authors' Addresses...........................................47
12 Bibliography.................................................48
12.1 Normative references...................................48
12.2 Informative References.................................49
13 IPR Notice...................................................49
14 Full Copyright Statement.....................................50
1 Introduction
Real-time media streams that use RTP are not resilient against
packet losses. RTP [1] provides all the necessary mechanisms to
restore ordering and timing present at the sender to properly
reproduce a media stream at a recipient. RTP also provides
continuous feedback about the overall reception quality from all
receivers -- thereby allowing the sender(s) in the mid-term (in the
order of several seconds to minutes) to adapt their coding scheme
and transmission behavior to the observed network QoS. However,
except for a few payload specific mechanisms [6], RTP makes no
provision for timely feedback that would allow a sender to repair
the media stream immediately: through retransmissions, retro-active
FEC control, or media-specific mechanisms 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 [13], video redundancy coding [14],
RTP-level FEC [5], and general considerations on more robust media RTP-level FEC [11], and general considerations on more robust media
streams transmission [6]. These mechanisms may be applied pro- streams transmission [12]. 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. A small number of general-purpose feedback messages as scenarios. A small number of general-purpose feedback messages 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 for transmission in the 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 often (but not always) capable of reporting events of
reporting events of interest back to the sender close to interest back to the sender close to their occurrence. In
their occurrence. In Early RTCP mode, RTCP feedback Early RTCP mode, RTCP packets are transmitted according to
messages are transmitted according to the timing rules 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 if 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. Sending an Early RTCP
packet is also referred to as sending Early Feedback in
this document.
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.
Feedback (FB) message: Feedback (FB) message:
An RTCP message as defined in this document is used to An RTCP message as defined in this document is used to
convey information about events observed at a receiver -- convey information about events observed at a receiver --
in addition to long term receiver status information which in addition to long-term receiver status information which
is carried in RTCP RRs -- back to the sender of the media is carried in RTCP RRs -- back to the sender of the media
stream. stream. For the sake of clarity, feedback message is
referred to as FB message throughout this document.
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 scheme in use, the session bandwidth, and and packetization scheme in use, the session bandwidth, and
application requirements. Note that the algorithms do not application requirements. Note that the algorithms do not
depend on all senders and receivers agreeing on the same depend on all senders and receivers agreeing on the same
value for this threshold. It is merely intended to provide value for this threshold. It is merely intended to provide
conceptual guidance to application designers and is not conceptual guidance to application designers and is not
used in any calculations. used in any calculations. For the sake of clarity, the term
feedback threshold is referred to as FB threshold
throughout this document.
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 FB 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: Media packet:
A media packet is an RTP packet.
Mode of operation in which no preferred transmission of Regular RTCP mode:
feedback messages is allowed. Instead, RTCP messages are Mode of operation in which no preferred transmission of FB
sent following the rules of [1]. Nevertheless, such RTCP messages is allowed. Instead, RTCP messages are sent
following the rules of [1]. Nevertheless, such RTCP
messages may contain feedback information as defined in messages may contain feedback information as defined in
this document. this document.
Regularly Scheduled RTCP packet: Regular 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] [5].
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:
Two additional RTCP packet types to convey feedback Two additional RTCP packet types are registered and the
information are defined in section 6. corresponding FB messages to convey feedback information
are defined in section 6.
RTCP report intervals: RTCP report intervals:
This memo describes three modes of operation which This document 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 five seconds between two RTCP reports is interval of five seconds between two RTCP reports is
dropped and the rules specified in section 3 apply if RTCP dropped and the rules specified in section 3 apply if RTCP
packets containing feedback messages (defined in section 4) packets containing FB messages (defined in section 4) are
are to be transmitted. 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
impact of feedback and a sender's reaction to feedback impact of feedback and a sender's reaction to FB messages.
messages.
3. Rules for RTCP Feedback 3 Rules for RTCP Feedback
3.1 Compound RTCP Feedback Packets 3.1 Compound RTCP Feedback Packets
Two components constitute RTCP-based feedback as described in this Two components constitute RTCP-based feedback as described in this
memo: document:
o Status reports are contained in SR/RR messages and are o Status reports are contained in SR/RR packets and are
transmitted at regular intervals as part of compound RTCP transmitted at regular intervals as part of compound RTCP
packets (which also include SDES and possibly other messages); packets (which also include SDES and possibly other messages);
these status reports provide an overall indication for the these status reports provide an overall indication for the
recent reception quality of a media stream. recent reception quality of a media stream.
o Feedback messages as defined in this document that indicate loss o FB messages as defined in this document that indicate loss or
or reception of particular pieces of a media stream (or provide reception of particular pieces of a media stream (or provide
some other form of rather immediate feedback on the data some other form of rather immediate feedback on the data
received). Rules for the transmission of feedback messages are received). Rules for the transmission of FB messages are newly
newly introduced in this memo. introduced in this document.
RTCP Feedback (FB) messages are just another RTCP packet type (see RTCP FB messages are just another RTCP packet type (see section
section 4). Therefore, multiple FB messages MAY be combined in a 4). Therefore, multiple FB messages MAY be combined in a single
single compound RTCP packet and they MAY also be sent combined with compound RTCP packet and they MAY also be sent combined with other
other RTCP packets. RTCP packets.
RTCP packets containing Feedback packets as defined in this Compound RTCP packets containing FB messages as defined in this
document MUST contain RTCP packets in the order as defined in [1]: document MUST contain RTCP packets in the order defined in [1]:
o OPTIONAL encryption prefix that MUST be present if the RTCP o OPTIONAL encryption prefix that MUST be present if the RTCP
message is to be encrypted. packet(s) is to be encrypted.
o MANDATORY SR or RR. o MANDATORY SR or RR.
o MANDATORY SDES which MUST contain the CNAME item; all other SDES o MANDATORY SDES which MUST contain the CNAME item; all other SDES
items are OPTIONAL. items are OPTIONAL.
o One or more FB messages. o One or more FB messages.
The FB message(s) MUST be placed in the compound packet after RR The FB message(s) MUST be placed in the compound packet after RR
and SDES RTCP packets defined in [1]. The ordering with respect to and SDES RTCP packets defined in [1]. The ordering with respect to
other RTCP extensions is not defined. other RTCP extensions is not defined.
Two types of compound RTCP packets carrying feedback packets are Two types of compound RTCP packets carrying feedback packets are
used in this document: used in this document:
a) Minimal compound RTCP feedback packet a) Minimal compound RTCP feedback packet
A minimal compound RTCP feedback packet MUST contain only the A minimal compound RTCP feedback packet MUST contain only the
mandatory information as listed above: encryption prefix if mandatory information as listed above: encryption prefix if
necessary, exactly one RR or SR, exactly one SDES with only the necessary, exactly one RR or SR, exactly one SDES with only the
CNAME item present, and the feedback message(s). This is to CNAME item present, and the FB message(s). This is to minimize
minimize the size of the RTCP packet transmitted to convey the size of the RTCP packet transmitted to convey feedback and
feedback and thus to maximize the frequency at which feedback thus to maximize the frequency at which feedback can be
can be provided while still adhering to the RTCP bandwidth provided while still adhering to the RTCP bandwidth
limitations. limitations.
This packet format SHOULD be used whenever an RTCP feedback This packet format SHOULD be used whenever an RTCP FB message
message is sent as part of an Early RTCP packet. is sent as part of an Early RTCP packet. This packet type is
referred to as minimal compound RTCP packet in this document.
b) (Full) compound RTCP feedback packet b) (Full) compound RTCP feedback packet
A (full) compound RTCP feedback packet MAY contain any A (full) compound RTCP feedback packet MAY contain any
additional number of RTCP packets (additional RRs, further SDES additional number of RTCP packets (additional RRs, further SDES
items, etc.). The above ordering rules MUST be adhered to. items, etc.). The above ordering rules MUST be adhered to.
This packet format MUST be used whenever an RTCP feedback This packet format MUST be used whenever an RTCP FB message is
message is sent as part of a regularly scheduled RTCP packet or sent as part of a Regular RTCP packet or in Regular RTCP mode.
in Regular RTCP mode. It MAY also be used to send RTCP It MAY also be used to send RTCP FB messages in Immediate
feedback messages in Immediate Feedback or Early RTCP mode. Feedback or Early RTCP mode. This packet type is referred to as
full compound RTCP packet in this document.
RTCP packets that do not contain FB messages are referred to as RTCP packets that do not contain FB messages are referred to as
non-FB RTCP packets. Such packets MUST follow the format rules in non-FB RTCP packets. Such packets MUST follow the format rules in
[1]. [1].
3.2 Algorithm Outline 3.2 Algorithm Outline
FB messages are part of the RTCP control streams and are thus FB messages are part of the RTCP control streams and thus subject
subject to the same bandwidth constraints as other RTCP traffic. to the RTCP bandwidth constraints. This means, in particular, that
This means in particular that it may not be possible to report an it may not be possible to report an event observed at a receiver
event observed at a receiver immediately back to the sender. immediately back to the sender. However, the value of feedback
However, the value of feedback given to a sender typically given to a sender typically decreases over time -- in terms of the
decreases over time -- in terms of the media quality as perceived media quality as perceived by the user at the receiving end and/or
by the user at the receiving end and/or the cost required to the cost required to achieve media stream repair.
achieve media stream repair.
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 RTP packets)and to accommodate algorithms that
use FB messages and are sensitive to the feedback timing. use FB messages.
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: As long as no FB messages have to be conveyed, compound
compound RTCP packets are sent following the rules of RTP [1] -- RTCP packets are sent following the rules of RTP [1] -- except that
except that the five second minimum interval between RTCP reports the five second minimum interval between RTCP reports is not
is not enforced and the interval between RTCP reports is only enforced.Hence, the interval between RTCP reports is only derived
derived from the average RTCP packet size and the RTCP bandwidth from the average RTCP packet size and the RTCP bandwidth share
share available to the RTP/RTCP entity; in addition, a minimum available to the RTP/RTCP entity. Optionally, a minimum interval
interval between regular RTCP packets may be enforced. If a between Regular RTCP packets may be enforced.
receiver detects the need to send an FB message, the receiver waits
for a short, random dithering interval (in case of multicast) and If a receiver detects the need to send an FB message, it may do so
then checks whether it has already seen a corresponding FB message earlier than scheduled following the above (regular RTCP)
from any other receiver (which it can do with all FB messages that algorithm. Feedback suppression is used to avoid feedback
are transmitted via multicast; for unicast sessions, there is no implosion in multicast sessions: The receiver waits for a
such delay). If this is the case then the receiver refrains from (short)random dithering intervalto checkwhether it sees a
sending the FB message and continues to follow the regular RTCP corresponding FB message from any other receiver reporting the same
transmission schedule. If the receiver has not yet seen a similar event.. Note that for unicast sessions there is no such delay. If
FB message from any other receiver, it checks whether it has so this receiver refrains from sending the FB message and continues
recently sent another FB message (without waiting for its regularly to follow the Regular RTCP transmission schedule. In case the
scheduled RTCP transmission time). Only if this is not the case, receiver has not yet seen a corresponding FB message from any other
it sends the FB message as part of a (minimal) compound RTCP receiver, it checks whether it is allowed to send Early feedback. .
packet. If this is the case, it sends the FB message as part of a minimal
compound RTCP packet. The permission to send Early feedback is
derived from the time Early feedback was sent.
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 transmitted 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 of operation is an indication of
should send early feedback at all and, if so, whether, whether or not the receiver will, on average, be able to report all
statistically, all events observed at the receiver can be reported events to the sender in a timely fashion. The current mode of
back to the sender in a timely fashion. The current mode of operation is continuously derived independently at each receiver;
operation is continuously derived independently at each receiver
and the receivers do not have to agree on a common mode. and the receivers do not have to agree on a common mode.
a) Immediate feedback mode: the group size is below the FB a) Immediate Feedback mode: the group size is below the FB
threshold which gives each receiving party sufficient bandwidth threshold which gives each receiving party sufficient bandwidth
to transmit the RTCP feedback packets for the intended purpose. to transmit the RTCP feedback packets for the intended purpose.
This means that, for each receiver, there is enough bandwidth This means that, for each receiver, there is enough bandwidth
to report each event it is supposed/expected to by means of a to report each eventby means of a virtually "immediate" RTCP
virtually "immediate" RTCP feedback packet. feedback packet.
The group size threshold is a function of a number of The group size threshold is a function of a number of
parameters including (but not necessarily limited to) the type parameters including (but not necessarily limited to): the type
of feedback used (e.g. ACK vs. NACK), bandwidth, packet rate, of feedback used (e.g. ACK vs. NACK), bandwidth, packet rate,
packet loss probability and distribution, media type, codec, packet loss probability and distribution, media type, codec,
and -- again depending on the type of FB used -- the (worst and the (worst case or observed) frequency of events to report
case or observed) frequency of events to report (e.g. frame (e.g. frame received, packet lost).
received, packet lost).
A special case of this is the ACK mode (where positive A special case of this is the ACK mode (where positive
acknowledgements are used to confirm reception of data) which acknowledgements are used to confirm reception of data) which
is restricted to point-to-point communications. is restricted to point-to-point communications.
As a rough estimate, let N be the average number of events to As a rough estimate, let N be the average number of events to
be reported per interval T by a receiver, B the RTCP bandwidth be reported per interval T by a receiver, B the RTCP bandwidth
fraction for this particular receiver and R the average RTCP fraction for this particular receiver and R the average RTCP
packet size, then the receiver operates in Immediate Feedback packet size, then the receiver operates in Immediate Feedback
mode as long as N<=B*T/R. mode as long as N<=B*T/R.
b) Early RTCP mode: In this mode, the group size and other b) Early RTCP mode: In this mode, the group size and other
parameters no longer allow each receiver to react to each event parameters no longer allow each receiver to react to each event
that would be worth (or needed) to report. But feedback can that would be worth (or needed) to report. But feedback can
still be given sufficiently often so that it allows the sender still be given sufficiently often so that it allows the sender
to adapt the media stream transmission accordingly and thereby to adapt the media stream transmission accordingly and thereby
increase the overall reproduced media quality. increase the overall media playback quality.
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.
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 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 document scales
there is no need for an agreement among the participants on the smoothly, there is no need for an agreement among the participants
precise values of the respective "thresholds" within the group. on the precise values of the respective FB thresholds within the
Hence the borders between all these modes are allowed to be soft. group. Hence the borders between all these modes are soft.
ACK ACK
feedback feedback
V V
:<- - - - NACK feedback - - - ->// :<- - - - NACK feedback - - - ->//
: :
: Immediate || : Immediate ||
: Feedback mode ||Early RTCP mode Regular RTCP mode : Feedback mode ||Early RTCP mode Regular RTCP mode
:<=============>||<=============>//<=================> :<=============>||<=============>//<=================>
: || : ||
-+---------------||---------------//------------------> group size -+---------------||---------------//------------------> group size
2 || 2 ||
Application-specific FB Threshold Application-specific FB Threshold
= f(data rate, packet loss, codec, ...) = f(data rate, packet loss, codec, ...)
Figure 1: Modes of operation Figure 1: Modes of operation
As stated before, the respective thresholds depend on a number of As stated before, the respective FB thresholds depend on a number
technical parameters (of the codec, the transport, the type of 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 and Algorithm Overview
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 in g) are calculated independently at each receiver. Therefore,
local values may differ at any given point in time. their local values may differ at any given point in time.
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 (to allow [1]. Unlike in [1], the initial Tmin is set to 1 second to
for some group size sampling before sending the first RTCP allow for some group size sampling before sending the first RTCP
packet), then it is set to 0. packet. After the first RTCP packet is sent,Tmin 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. This value is
of [1]: T_rr = T (the "calculated interval") with tn = tp + T. obtained following the rules of [1] but with Tmin as defined in
Note that Tmin as defined in this specification is used to this document: T_rr = T (the "calculated interval" as defined in
compute the "calculated interval T". T_rr refers to the last [1]) with tn = tp + T. T_rr always refers to the last value of
value of T that has been computed (because of reconsideration or T that has been computed (because of reconsideration or to
to determine tn). determine tn). T_rr is also referred to as Regular RTCP interval
in this document.
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). For point-to-point sessions, T_dither_max is set implosions in multicast. For point-to-point sessions,
to 0 and hence no additional delay is introduced. T_dither_max is set to 0.
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. This value is application-specific; and no values are
defined in this document.
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 at time t0. of FB message in response to an event at time t0.
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 FB messages prior to its next
next regularly scheduled RTCP interval tn. This variable is regularly scheduled RTCP interval tn. This variable is used to
used to throttle the feedback sent by a single receiver. throttle the feedback sent by a single receiver. allow_early is
allow_early is adjusted (set to FALSE) after early feedback set to FALSE after Early feedback transmission and is set to
transmission and is reset to TRUE as soon as the next regular TRUE as soon as the next Regular RTCP transmission takes place.
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
as defined in [1]. as defined in [1].
m) Let T_rr_interval be an (optional) minimal interval to be used m) Let T_rr_interval be an OPTIONAL minimal interval to be used
between regular RTCP packets. If T_rr_interval != 0 then between Regular RTCP packets. If T_rr_interval!= 0 then Regular
regular RTCP packets will not be scheduled T_rr after the last RTCP packets will not be scheduled T_rr after the last Regular
regular RTCP transmission (at tp+T_rr) but only at least RTCP transmission (at tp+T_rr) but at least T_rr_interval after
T_rr_interval after the last regular RTCP transmission (later the last Regular RTCP transmission, i.e. later than or at
than or at tp+T_rr). T_rr_interval does not affect the tp+T_rr_interval. T_rr_interval does not affect the calculation
calculation of T_rr and tp but may lead to regular RTCP packets of T_rr and tp but may lead to Regular RTCP packets being
being suppressed. T_rr_interval does not affect transmission suppressed. In this case, Regular RTCP packets may be
scheduling for Early RTCP packets. suppressed if, for example, they do not contain any FB messages.
The T_rr_interval does not affect transmission scheduling of
n) Let t_rr_last be the point in time at which the last RTCP packet Early RTCP packets.
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 NOTE: Providing T_rr_interval as an independent variable is
meant to minimize regular feedback (and thus bandwidth meant to minimize Regular RTCP feedback (and thus bandwidth
consumption) as needed by the application but still allow for consumption) as needed by the application while additionally
more frequent use of Early RTCP packets to provide timely allowing the use of more frequent Early RTCP packets to provide
feedback. This goal could not be achieved by reducing the timely feedback. This goal could not be achieved by reducing
overall RTCP bandwidth as RTCP bandwidth reduction would also the overall RTCP bandwidth as RTCP bandwidth reduction would
impact the Early feedback. also impact the frequency of Early feedback.
o) Let T_retention be the time window for which past RTCP feedback n) Let t_rr_last be the point in time at which the last Regular
messages are stored by an AVPF entity. This is to ensure that RTCP packet has been scheduled and sent, i.e. has not been
feedback suppression also works for entities that have received suppressed due to T_rr_interval.
feedback messages from other entities prior to noticing the
feedback event itself. T_retention MUST be set to at least 2 Regular
seconds. o) Let T_retention be the time window for which past FB messages
are stored by an AVPF entity. This is to ensure that feedback
suppression also works for entities that have received FB
messages from other entities prior to noticing the feedback
event itself. T_retention MUST be set to at least 2 seconds.
p) Let Td be the timeout value for a receiver to be considered
inactive (as defined in [1]).
The feedback situation for an event to report at a receiver is The feedback situation for an event to report at a receiver is
depicted in figure 2 below. At time t0, such an event (e.g. a 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 FB message needs to be sent back to
back to the sender. the sender.
To avoid an implosion of immediate feedback packets in multicast To avoid an implosion of feedback packets in multicast sessions,
sessions, the receiver MUST delay the transmission of the RTCP the receiver MUST delay the transmission of the RTCP feedback
feedback packet by a random amount T_fd (with the random number packet by a random amount of time T_fd (with the random number
evenly distributed in the interval [0, T_dither_max]). evenly distributed in the interval [0, T_dither_max]).
Transmission of the compound RTCP packet MUST then be scheduled for Transmission of the compound RTCP packet MUST then be scheduled for
te = t0 + T_fd. 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, T_rr,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 FB 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
gain is considered insufficient. gain is considered insufficient.
If an RTCP feedback packet is scheduled, the time slot for the next If an Early RTCP packet is scheduled, the time slot for the next
scheduled (full) compound RTCP packet MUST be updated accordingly Regular RTCP packet MUST be updated accordingly to a new tn:
to a new tn (which will then be in the order of tn=tp+2*T_rr). tn=tp+2*T_rr. This is to ensure that the short-term average RTCP
This is to ensure that the short term average bandwidth used for bandwidth used with Early feedback does not exceed the bandwidth
RTCP with feedback does not exceed the bandwidth limit that would used without Early feedback.
be used without feedback.
event to event to
report report
detected detected
| |
| RTCP feedback range | RTCP feedback range
| (T_max_fb_delay) | (T_max_fb_delay)
vXXXXXXXXXXXXXXXXXXXXXXXXXXX ) ) vXXXXXXXXXXXXXXXXXXXXXXXXXXX ) )
|---+--------+-------------+-----+------------| |--------+---> |---+--------+-------------+-----+------------| |--------+--->
| | | | ( ( | | | | | ( ( |
| t0 te | | t0 te |
tp tn tp tn
\_______ ________/ \_______ ________/
\/ \/
T_dither_max T_dither_max
Figure 2: Event report and parameters for Early RTCP scheduling Figure 2: Event report and parameters for Early RTCP scheduling
3.5 Early RTCP Algorithm 3.5 Early RTCP Algorithm
Assume an active sender S0 (out of S senders) and a number N of Let S0 be an active sender (out of S senders) and let N be the
receivers with R being one of these receivers. number of receivers with R being one of these receivers.
Assume further that R has verified that using feedback mechanisms Assume that R has verified that using feedback mechanisms is
is reasonable at the current constellation (which is highly 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 document).
Assume that T_rr_interval is 0, if no minimal interval between Assume further that T_rr_interval is 0, if no minimal interval
regular RTCP packets is to be enforced, or T_rr_interval is set to between Regular RTCP packets is to be enforced, or T_rr_interval is
some meaningful value, as given by the application. This value set to some meaningful value, as given by the application. This
then denotes the minimal interval between regular RTCP packets. value then denotes the minimal interval between Regular RTCP
packets.
Then, receiver R MUST use the following rules for transmitting one With this, a receiver R MUST use the following rules for
or more Feedback messages as minimal or full compound RTCP packet: transmitting one or more FB 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. For a unicast applies except that the initial value for Tmin. For a unicast
session, the initial Tmin is set to 0. For a multicast session, session, the initial Tmin is set to 0. For a multicast session,
Tmin is initialized to 1.0 seconds. 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 as per [1]) for tn = tp + T_rr.
also that the last T_rr_interval-based transmission (if any) has Assume also that the last Regular RTCP packet transmission has
occurred at t_rr_last (if defined). occurred at t_rr_last.
1. At time t0, R detects the need to transmit one or more RTCP The Early Feedback algorithm then comprises the following steps:
feedback messages (e.g. because media "units" needs to be ACKed or
NACKed) and finds that sending the feedback information is useful 1. At time t0, R detects the need to transmit one or more FB
for the sender. messages, e.g. because media "units" need to be ACKed or NACKed,
and finds that sending the feedback information is potentially
useful for the sender.
2. R first checks whether there is already a compound RTCP packet 2. R first checks whether there is already a compound RTCP packet
containing an RTCP feedback message scheduled for transmission (as containing one or more FB messages scheduled for transmission
early or regular RTCP packet). (either as Early or as Regular RTCP packet).
2.a) If so, the new feedback message MUST be included in the 2.a) If so, the new FB message MUST be included in the
scheduled packet; the scheduling of the waiting RTCP feedback scheduled packet; the scheduling of the waiting compound RTCP
packet MUST remain unchanged. When doing so, the feedback packet MUST remain unchanged. When doing so, the available
information of several RTCP feedback packets SHOULD be merged feedback information SHOULD be merged to produce as few FB
to produce as few feedback messages as possible. This messages as possible. This completes the course of immediate
completes the course of immediate actions to be taken. actions to be taken.
2.b) If no RTCP feedback message is already scheduled for 2.b) If no compound RTCP packet is already scheduled for
transmission, a new (minimal or full) compound RTCP feedback transmission, a new (minimal or full) compound RTCP packet
packet MUST be created and the minimal interval for MUST be created and the minimal interval for T_dither_max MUST
T_dither_max MUST be chosen as follows: be chosen as follows:
i) If the session is a unicast session (group size = 2) then i) If the session is a unicast session then T_dither_max =
T_dither_max = 0. 0.
ii) If the session is a multicast session with potentially ii) If the session is a multicast session 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 Regular RTCP packet would be
packet would be within the time bounds for the RTCP FB (t0 + within the time bounds for the Early RTCP packet triggered at t0,
T_dither_max > tn). i.e. if t0 + 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 included in 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, i.e. allow_early == TRUE, or not.
4.a) If allow_early == FALSE then R MUST check the time for the 4.a) If allow_early == FALSE then R MUST check the time for the
next scheduled RR: next scheduled Regular RTCP packet:
1. If tn - t0 < T_max_fb_delay (i.e. if, despite late 1. If tn - t0 < T_max_fb_delay then the feedback could
reception, the feedback could still be useful for the still be useful for the sender, despite the late
sender) then R MAY create an RTCP FB message for reporting. Hence, R MAY create an RTCP FB message to
transmission along with the RTCP packet at tn. be included in the Regular RTCP packet for
transmission at tn.
2. Otherwise, R MUST discard the RTCP feedback message. 2. Otherwise, R MUST discard the RTCP FB 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. R MUST continuously monitor the received RTCP feedback packets 5. R MUST continuously monitor the received RTCP packets contained
contained in one or more (minimal) compound RTCP packets and keep in one or more (minimal) compound RTCP packets and keep each of
each of these packets for at least T_retention. When scheduling these RTCP packets for at least T_retention. When scheduling the
the transmission of an RTCP feedback message, R MUST check each of transmission of a FB message, R MUST check each of the FB messages
the RTCP feedback messages in the one or more compound RTCP packets in the one or more compound RTCP packets received during the
received in the interval [t0 - T_retention ; te] and act as interval [t0 - T_retention ; te] and act as follows:
follows:
5.a) If R understands the received feedback message's semantics 5.a) If R understands the received FB message's semantics and
and the message contents is a superset of the feedback R wanted the message contents is a superset of the feedback R wanted to
to send then R MUST discard its own feedback message and MUST send then R MUST discard its own FB message and MUST re-
re-schedule the next regular RTCP message transmission for tn schedule the next Regular RTCP packet transmission for tn (as
(as calculated before). calculated before).
5.b) If R understands the received feedback message's semantics 5.b) If R understands the received FB message's semantics and
and the message contents is not a superset of the feedback R the message contents is not a superset of the feedback R wanted
wanted to send then R SHOULD transmit its own feedback message to send then R SHOULD transmit its own FB message as scheduled.
as scheduled. If there is an overlap between the feedback If there is an overlap between the feedback information to send
information to send and the feedback information received, the and the feedback information received, the amount of feedback
amount of feedback transmitted is up to R: R MAY send its transmitted is up to R: R MAY keep its feedback information to
feedback information unchanged, R MAY as well eliminate any be sent unchanged, R MAY as well eliminate any redundancy
redundancy between its own feedback and the feedback received between its own feedback and the feedback received so far.
so far.
5.c) If R does not understand the received feedback message's 5.c) If R does not understand the received FB message's
semantics, R MAY send its own feedback message as Early RTCP semantics, R MAY keep its own FB message scheduled as an Early
packet, or R MAY re-schedule the next regular RTCP message RTCP packet, or R MAY re-schedule the next Regular RTCP packet
transmission for tn (as calculated before) and MAY append the transmission for tn (as calculated before) and MAY append the
feedback message to the now regularly scheduled RTCP message. FB message to the now regularly scheduled RTCP message.
Note: With rule #3, receiving unknown feedback packets may not Note: With 5.c, receiving unknown FB messages may not lead to
lead to feedback suppression at a particular receiver. As a feedback suppression at a particular receiver. As a
consequence, a given event may cause M different types of consequence, a given event may cause M different types of FB
feedback packets (which are all appropriate but not the same messages (which are all appropriate but not mutually
and mutually not understood) to be scheduled, and a "large" understood) to be scheduled, and a "large" receiver group may
receiver group may be partitioned into at most M groups. Among be partitioned into at most M groups. Among members of each of
members of each of these M groups, feedback suppression will these M groups, feedback suppression will occur following 5.a
occur following the rules #1 and #2 but no suppression will and 5.b but no suppression will happen across groups. As a
happen across groups. As a result, O(M) RTCP feedback messages result, O(M) RTCP FBmessages may be received by the sender.
may be received by the sender. Given that these M groups Hence, there is a chance for a limited feedback implosion.
consist of receivers for the same application using the same However, as sender(s) and all receivers make up the same
(set of) codecs in the same RTP session, M is assumed to be application using the same (set of) codecs in the same RTP
small in the general case. Given further that the O(M) session, only little divergence in semantics for FB messages
feedback packets are randomly distributed over a time interval can safely be assumed and, therefore, M is assumed to be small
of T_dither_max, the resulting limited number of extra feedback in the general case. Given further that the O(M) FB messages
packets (a) is assumed not to overwhelm the sender and (b) are randomly distributed over a time interval of T_dither_max
we find that the resulting limited number of extra compound
RTCP packets (a) is assumed not to overwhelm the sender and (b)
should be conveyed as all contain complementary pieces of should be 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 FB messages and for
for which feedback messages MUST be understood by a receiver. which FB messages MUST be understood by a receiver.
6. Otherwise, when te is reached, R MUST transmit the RTCP packet 6. Otherwise, when te is reached, R MUST transmit the (minimal)
containing the FB message. R then MUST set allow_early = FALSE, compound RTCP packet containing the FB message(s). R then MUST set
MUST recalculate tn = tp + 2*T_rr, and MUST set tp to the previous allow_early = FALSE, MUST recalculate tn = tp + 2*T_rr, and MUST
tn. As soon as the newly calculated tn is reached and R sends its set tp to the previous tn. As soon as the newly calculated tn is
next regularly scheduled RTCP RR or suppresses it because of reached , regardless whether R sends its next Regular RTCP packet
T_rr_interval, it MUST set allow_early = TRUE again. or suppresses it because of T_rr_interval, it MUST set allow_early
= TRUE again.
3.5.3 Regular RTCP Transmission 3.5.3 Regular RTCP Transmission
In regular intervals full compound RTCP packets MUST be sent. Full compound RTCP packets MUST be sent in regular intervals.
These packets MAY also contain one or more feedback messages. These packets MAY also contain one or more FB messages.
Transmission of regular RTCP packets is scheduled as follows: Transmission of Regular RTCP packets is scheduled as follows:
If T_rr_interval == 0 then the transmission MUST follow the rules If T_rr_interval == 0 then the transmission MUST follow the rules
as specified by [1] (except for the different Tmin) and MUST adhere as specified in section 3.2 and 3.4 of this document and MUST
to the adjustments of tn specified in section 3.5.2 (i.e. skip one adhere to the adjustments of tn specified in section 3.5.2, i.e.
regular transmission if an Early RTCP transmission has occurred). skip one regular transmission if an Early RTCP packet transmission
Timer reconsideration takes place when tn is reached as per [1] and has occurred. Timer reconsideration takes place when tn is reached
the regular RTCP packet is transmitted after timer reconsideration. as per [1]. The Regular RTCP packet is transmitted after timer
Whenever a regular RTCP message is sent, allow_early MUST be set to reconsideration. Whenever a Regular RTCP packet is sent or
TRUE and tp, tn MUST be updated as per [1]. If this was the first suppressed, allow_early MUST be set to TRUE and tp, tn MUST be
transmission of an RTCP packet, Tmin MUST be set to 0. updated as per [1]. After the first transmission of a Regular RTCP
packet, Tmin MUST be set to 0.
If T_rr_interval != 0 then the calculation for the transmission If T_rr_interval != 0 then the calculation for the transmission
times MUST follow the rules as specified in [1] (except for the times MUST follow the rules as specified in section 3.2 and 3.4 of
different Tmin) and MUST adhere to the adjustments of tn specified this document and MUST adhere to the adjustments of tn specified in
in section 3.5.2 (i.e. skip one regular transmission if an Early section 3.5.2 (i.e. skip one regular transmission if an Early RTCP
RTCP transmission has occurred). Timer reconsideration takes place transmission has occurred). Timer reconsideration takes place when
when tn is reached as per [1]. After timer reconsideration, the 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 1. If no Regular 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 Regular RTCP packet MUST be
scheduled. Stored RTCP feedback messages MAY be included in scheduled. Stored FB messages MAY be included in the
the full compound RTCP packet. t_rr_last MUST be set to tn. Regular RTCP packet. After the scheduled packet has been
Tmin MUST be set to 0. sent, t_rr_last MUST be set to tn. Tmin MUST be set to 0.
Otherwise, an temporary value T_rr_current_interval is 2. Otherwise, a temporary value T_rr_current_interval is
calculated as follows: calculated as follows:
T_rr_current_interval = RND*T_rr_interval T_rr_current_interval = RND*T_rr_interval
with RND being a pseudo random function evenly distributed with RND being a pseudo random function evenly distributed
between 0.5 and 1.5. This dithered value is used for the between 0.5 and 1.5. This dithered value is used to
following alternatives: determine one of the following alternatives:
If t_rr_last + T_rr_current_interval <= tn then a full 2a) If t_rr_last + T_rr_current_interval <= tn then a
compound RTCP packet MUST be scheduled. Stored RTCP feedback Regular RTCP packet MUST be scheduled. Stored RTCP FB
messages MAY be included in the full compound RTCP packet. messages MAY be included in the Regular RTCP packet.
t_rr_last MUST be set to tn. After the scheduled packet has been sent, t_rr_last
MUST be set to tn.
If t_rr_last + T_rr_current_interval > tn and RTCP feedback 2b) If t_rr_last + T_rr_current_interval > tn and RTCP FB
messages have been stored and are awaiting transmission, an messages have been stored and are awaiting
RTCP packet MUST be scheduled for transmission at tn. This transmission, an RTCP packet MUST be scheduled for
RTCP packet MAY be a minimal or a full compound RTCP packet transmission at tn. This RTCP packet MAY be a minimal
(at the discretion of the implementer) and the compound RTCP or a Regular RTCP packet (at the discretion of the
packet MUST include the stored RTCP feedback message. implementer) and the compound RTCP packet MUST include
t_rr_last MUST remain unchanged. the stored RTCP FB message. t_rr_last MUST remain
unchanged.
Otherwise (if t_rr_last + T_rr_current_interval > tn but no 2c) Otherwise (if t_rr_last + T_rr_current_interval > tn
stored RTCP feedback messages are awaiting transmission), no but no stored RTCP FB messages are awaiting
compound RTCP packet MUST be scheduled. transmission), no compound RTCP packet MUST be
scheduled. t_rr_last MUST remain unchanged.
In all the four cases above, allow early MUST be set to TRUE and tp In all the four cases above (1, 2a, 2b, and 2c), allow_early MUST
and tn MUST be updated following the rules of [1] except for the be set to TRUE after sending the Regular RTCP packet and tp and tn
five second minimum. MUST be updated following the rules of [1] except for the five
second minimum.
3.5.4 Other Considerations 3.5.4 Other Considerations
Furthermore, if T_rr_interval != 0 then the timeout calculation for If T_rr_interval != 0 then the timeout calculation for RTP/AVPF
RTP/AVPF entities (section 6.3.5 of [1]) MUST be modified to use 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 a compound RTCP packet is sent or received -- minimal or
compound, early or regularly scheduled -- the avg_rtcp_size full compound, Early or Regular -- the avg_rtcp_size variable MUST
variable MUST be updated accordingly (see [1]) and subsequent be updated accordingly (see [1]) and subsequent computations of tn
computations of tn MUST use the new avg_rtcp_size. 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
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 is 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 1,600 bit/s for RTCP. If we assume an kbit/s stream this yields 1,600 bit/s for RTCP. If we assume an
average of 96 bytes (=768 bits) per RTCP packet a receiver can average of 96 bytes (=768 bits) per RTCP packet a receiver can
report 2 events per second back to the sender. If acknowledgments report 2 events per second back to the sender. If acknowledgments
for 10 events are collected in each feedback message then 20 events for 10 events are collected in each FB message then 20 events can
can be acknowledged per second. At 256 kbit/s 8 events could be be acknowledged per second. At 256 kbit/s 8 events could be
reported per second; thus the ACKs may be sent in a finer reported per second; thus the ACKs may be sent in a finer
granularity (e.g. only combining three ACKs per RTCP feedback granularity (e.g. only combining three ACKs per FB 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 to work properly with these ACK strategies MUST be defined to work properly with 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 (this includes or other types of feedback
used for all groups larger than two. Of course, NACKs MAY be used exhibiting similar reporting characteristics) MUST be used for all
for point-to-point communications as well. sessions using multicast or multi-unicast (as indicated by the
addressing information, e.g. in their SDP m= and c= lines). Of
course, NACKs MAY be used for point-to-point communications as
well.
Whether or not the use of Immediate or Early RTCP packets should be Whether or not the use of Immediate or Early RTCP packets should be
considered depends upon a number of parameters including session considered depends upon a number of parameters including session
bandwidth, codec, special type of feedback, number of senders and bandwidth, codec, special type of feedback, number of senders and
receivers, among many others. receivers.
The crucial parameters -- to which virtually all of the above can The most important parameters when determining the mode of
be reduced -- is the allowed minimal interval between two RTCP operation are the allowed minimal interval between two compound
reports and the (average) number of events that presumably need RTCP packets (T_rr) and the average number of events that
reporting per time interval (plus their distribution over time, of presumably need reporting per time interval(plus their distribution
course). The minimum interval can be derived from the available over time, of course). The minimum interval can be derived from
RTCP bandwidth and the expected average size of an RTCP packet. the available RTCP bandwidth and the expected average size of an
The number of events to report e.g. per second may be derived from RTCP packet. The number of events to report e.g. per second may be
the packet loss rate and sender's rate of transmitting packets. derived from the packet loss rate and sender's rate of transmitting
From these two values, the allowable group size for the Immediate packets. From these two values, the allowable group size for the
feedback mode can be calculated. Immediate Feedback mode can be calculated.
Let N be the average number of events to be reported per Let N be the average number of events to be reported per
interval T by a receiver, B the RTCP bandwidth fraction for interval T by a receiver, B the RTCP bandwidth fraction for
this particular receiver and R the average RTCP packet size, this particular receiver and R the average RTCP packet size,
then the receiver operates in Immediate Feedback mode is used then the receiver operates in Immediate Feedback mode is used
as long as N<=B*T/R. as long as N<=B*T/R.
The upper bound for the Early RTCP mode then solely depends on the The upper bound for the Early RTCP mode then solely depends on the
acceptable quality degradation, i.e. how many events per time acceptable quality degradation, i.e. how many events per time
interval may go unreported. interval may go unreported.
skipping to change at page 4, line 691 skipping to change at page 20, line 21
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 1,500 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 into one 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.
Extending this example to determine the upper bound for Early RTCP Extending this example to determine the upper bound for Early RTCP
mode could lead to the following considerations: assume that the mode could lead to the following considerations: assume that the
underlying coding scheme and the application (as well as the underlying coding scheme and the application (as well as the
tolerant users) allow on the order of one loss without repair per tolerant users) allow on the order of one loss without repair per
two seconds. Thus the number of packets to be reported by each two seconds. Thus the number of packets to be reported by each
receiver decreases to two per two seconds second and increases the receiver decreases to two per two seconds second and increases the
group size to 10. Assuming further that some number of packet group size to 10. Assuming further that some number of packet
losses are correlated, feedback traffic is further reduced and losses are correlated, feedback traffic is further reduced and
group sizes of some 12 to 16 (maybe even 20) can be reasonably well group sizes of some 12 to 16 (maybe even 20) can be reasonably well
supported using Early RTCP mode. Note, of course, that all those supported using Early RTCP mode. Note that all these
considerations are based upon statistics and will fail to hold in considerations are based upon statistics and will fail to hold in
some cases. some cases.
3.7 Summary of decision steps 3.7 Summary of decision steps
3.7.1 General Hints 3.7.1 General Hints
Before even considering whether or not to send RTCP feedback Before even considering whether or not to send RTCP feedback
information an application has to determine whether this mechanism information an application has to determine whether this mechanism
is applicable: is applicable:
1) An application has to decide whether -- for the current ratio of 1) An application has to decide whether -- for the current ratio of
packet rate with the associated (application-specific) maximum packet rate with the associated (application-specific) maximum
feedback delay and the currently observed round-trip time (if feedback delay and the currently observed round-trip time (if
available) -- feedback mechanisms can be applied at all. available) -- feedback mechanisms can be applied at all.
skipping to change at page 4, line 731 skipping to change at page 21, line 15
Before even considering whether or not to send RTCP feedback Before even considering whether or not to send RTCP feedback
information an application has to determine whether this mechanism information an application has to determine whether this mechanism
is applicable: is applicable:
1) An application has to decide whether -- for the current ratio of 1) An application has to decide whether -- for the current ratio of
packet rate with the associated (application-specific) maximum packet rate with the associated (application-specific) maximum
feedback delay and the currently observed round-trip time (if feedback delay and the currently observed round-trip time (if
available) -- feedback mechanisms can be applied at all. available) -- feedback mechanisms can be applied at all.
This decision may obviously be based upon (and dynamically This decision may be based upon (and dynamically revised
revised following) regular RTCP reception statistics as well as following) RTCP reception statistics as well as out-of-band
out-of-band mechanisms. mechanisms.
2) The application has to decide -- for a certain observed error 2) The application has to decide -- for a certain observed error
rate, assigned bandwidth, frame/packet rate, and group size -- rate, assigned bandwidth, frame/packet rate, and group size --
whether (and which) feedback mechanisms can be applied. whether (and which) feedback mechanisms can be applied.
Regular RTCP provides valuable input to this step, too. Regular RTCP reception statistics provide valuable input to this
step, too.
3) If these tests pass, the application has to follow the rules for 3) If the application decides to send feedback, the application has
transmitting Early RTCP packets or regularly scheduled RTCP to follow the rules for transmitting Early RTCP packets or
packets with piggybacked feedback. Regular RTCP packets with containing FB messages.
3.7.2 Media Session Attributes 3.7.2 Media Session Attributes
Media sessions are typically described using out-of-band mechanisms Media sessions are typically described using out-of-band mechanisms
to convey transport addresses, codec information, etc. between to convey transport addresses, codec information, etc. between
sender(s) and receiver(s). Such a mechanisms consists of a format sender(s) and receiver(s). Such a mechanism is two-fold: a format
used to describe a media session and another mechanism for used to describe a media session and another mechanism for
transporting this description. transporting this description.
In the IETF, the Session Description Protocol (SDP) is currently In the IETF, the Session Description Protocol (SDP) is currently
used to describe media sessions while protocols such as SIP, SAP, used to describe media sessions while protocols such as SIP, SAP,
RTSP, and HTTP (among others) are used to convey the descriptions. RTSP, and HTTP (among others) are used to convey the descriptions.
A media session description format MAY include parameters to A media session description format MAY include parameters to
indicate that RTCP feedback mechanisms MAY be used (=are supported) indicate that RTCP feedback mechanisms are supported in this
in this session and which of the feedback mechanisms MAY be session and which of the feedback mechanisms MAY be applied.
applied.
To do so, the profile "AVPF" MUST be indicated instead of "AVP". To do so, the profile "AVPF" MUST be indicated instead of "AVP".
Further attributes may be defined to show which type(s) of feedback Further attributes may be defined to show which type(s) of feedback
are supported. are supported.
Section 4 contains the syntax specification to support RTCP Section 4 contains the syntax specification to support RTCP
feedback with SDP. Similar specifications for other media session feedback with SDP. Similar specifications for other media session
description formats are outside the scope of this document. description formats are outside the scope of this document.
4. SDP Definitions 4 SDP Definitions
This section defines a number of additional SDP parameters that are This section defines a number of additional SDP parameters that are
used to describe a session. All of these are defined as media used to describe a session. All of these are defined as media
level attributes. level attributes.
4.1 Profile identification 4.1 Profile identification
The AV profile defined in [4] is referred to as "AVP" in the The AV profile defined in [4] is referred to as "AVP" in the
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 description for this session indicates the use
the "AVPF" profile (exclusively or jointly with other AV profiles). of 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 is defined to indicate A new payload format-specific SDP attribute is defined to indicate
the capability of using RTCP feedback as specified in this the capability of using RTCP feedback as specified in this
document: "a=rtcp-fb". The "rtcp-fb" attribute MUST only be used document: "a=rtcp-fb". The "rtcp-fb" attribute MUST only be used
as an SDP media attribute and MUST NOT be provided at the session as an SDP media attribute and MUST NOT be provided at the session
level. The "rtcp-fb" attribute MUST only be used in media sessions level. The "rtcp-fb" attribute MUST 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 FB
feedback messages MAY be used in this media session for the messages MAY be used in this media session for the indicated
indicated payload type. A wildcard payload type ("*") MAY be used payload type. A wildcard payload type ("*") MAY be used to
to indicate that the RTCP feedback attribute applies to all payload indicate that the RTCP feedback attribute applies to all payload
types. If several types of feedback are supported and/or the same types. If several types of feedback are supported and/or the same
feedback shall be specified for a subset of the payload types, feedback shall be specified for a subset of the payload types,
several "a=rtcp-fb:" lines MUST be used. 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 FB 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=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 FB messages than those listed in one of the
the "rtcp-fb" attribute lines. "rtcp-fb" attribute lines.
When used in conjunction with the offer/answer model [18], the When used in conjunction with the offer/answer model [9], 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
well as those it does not support in general or does not wish to 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 use in this particular media session. The answerer MUST NOT add
feedback parameters to the media description and MUST NOT alter feedback parameters to the media description and MUST NOT alter
values of such parameters. The answer is binding for the media values of such parameters. The answer is binding for the media
session and both offerer and answerer MUST only use feedback session and both offerer and answerer MUST only use feedback
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 FB
messages and MUST silently discard all those RTCP feedback messages messages and MUST silently discard all those RTCP FB messages that
that they do not understand. 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=rtcp-fb:" rtcp-fb-pt 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 rtcp-fb-pt = "*" ; wildcard: applies to all formats
/ fmt ; as defined in SDP spec / fmt ; as defined in SDP spec
skipping to change at page 4, line 940 skipping to change at page 25, line 32
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": Regular RTCP minimum interval "trr-int":
The attribute "trr-int" is used to specify the minimum The attribute "trr-int" is used to specify the minimum
interval T_rr_interval between two regular (full compound) interval T_rr_interval between two Regular (full compound)
RTCP packets in milliseconds for this media session. If "trr- RTCP packets in milliseconds for this media session. If "trr-
int" is not specified, a default value of 0 is assumed. 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
information and up to the sender(s) to make use of feedback information and up to the sender(s) (how) to make use of feedback
provided. provided.
4.3 Unicasting vs. Multicasting 4.3 Unicasting vs. Multicasting
If a media session description indicates unicast addresses for a If a media session description indicates unicast addresses for a
particular media type (and does not operate in multi-unicast mode particular media type (and does not operate in multi-unicast mode
with all recipients listed explicitly but still addressed via with all recipients listed explicitly but still addressed via
unicast), the RTCP feedback MAY operate in ACK feedback mode. unicast), the RTCP feedback MAY operate in ACK feedback mode.
If a media session description indicates multicast addresses for a If a media session description indicates multicast addresses for a
skipping to change at page 4, line 986 skipping to change at page 26, line 29
determine the actual bandwidth to be used by senders and receivers. determine the actual bandwidth to be used by senders and receivers.
Applications operating knowingly over highly asymmetric links (such Applications operating knowingly over highly asymmetric links (such
as satellite links) SHOULD use this mechanism to reduce the as satellite links) SHOULD use this mechanism to reduce the
feedback rate for high bandwidth streams to prevent deterministic feedback rate for high bandwidth streams to prevent deterministic
congestion of the feedback path(s). congestion of the feedback path(s).
4.5 Examples 4.5 Examples
Example 1: The following session description indicates a session Example 1: The following session description indicates a session
made up from an audio and a DTMF for point-to-point communication made up from audio and DTMF [18] for point-to-point communication
in which the DTMF stream uses Generic ACKs. This session in which the DTMF stream uses Generic ACKs. This session
description could be contained in a SIP INVITE, 200 OK, or ACK description could be contained in a SIP INVITE, 200 OK, or ACK
message to indicate that its sender is capable of and willing to message to indicate that its sender is capable of and willing to
receive feedback for the DTMF stream it transmits. receive feedback for the DTMF stream it transmits.
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com o=alice 3203093520 3203093520 IN IP4 host.example.com
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
skipping to change at page 4, line 1048 skipping to change at page 27, line 44
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000 a=rtpmap:99 H261/90000
m=video 51372 RTP/AVPF 98 99 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=rtpmap:99 H261/90000 a=rtpmap:99 H261/90000
a=rtcp-fb:* nack a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi 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 mechanism to indicate that both are alternatives actually conveying
conveying the same contents. A sample mechanism by which this can the same contents. A sample mechanism by which this can be
be achieved is defined in [14]. achieved is defined in [7].
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
rules (including the upper bandwidth limit for RTCP and the rules (including the upper bandwidth limit for RTCP and the
bandwidth assignments to senders and receivers). Therefore, bandwidth assignments to senders and receivers). Therefore,
senders and receivers of using either of the two profiles can be senders and receivers of using either of the two profiles can be
mixed in a single session (see e.g. example 3 in section 4.5). mixed in a single session (see e.g. example 3 in section 4.5).
AVP and AVPF are defined in a way that, from a robustness point of AVP and AVPF are defined in a way that, from a robustness point of
view, the RTP entities do not need to be aware of entities of the view, the RTP entities do not need to be aware of entities of the
skipping to change at page 4, line 1084 skipping to change at page 28, line 30
closer spacing of RTCP messages (e.g. violating the five second closer spacing of RTCP messages (e.g. violating the five second
rule) by AVPF entities. As the overall bandwidth constraints rule) by AVPF entities. As the overall bandwidth constraints
are adhered to by both types of entities, they will still get are adhered to by both types of entities, they will still get
their share of the RTCP bandwidth. However, while AVP entities their share of the RTCP bandwidth. However, while AVP entities
are bound by the five second rule, depending on the group size are bound by the five second rule, depending on the group size
and session bandwidth, AVPF entities may provide more frequent and session bandwidth, AVPF entities may provide more frequent
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 larger than five seconds . 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
AVPF receivers SHOULD send immediate or early RTCP feedback AVPF receivers SHOULD send Immediate or Early RTCP feedback
packets only if all (sending) entities in the media session packets only if all sending entities in the media session
support AVPF. AVPF receivers MAY send feedback information as support AVPF. AVPF receivers MAY send feedback information as
part of regularly scheduled compound RTCP packets following the part of regularly scheduled compound RTCP packets following the
timing rules of [1] and [2] also in media sessions operating in timing rules of [1] and [2] also in media sessions operating in
mixed mode. However, the receiver providing feedback MUST NOT mixed mode. However, the receiver providing feedback MUST NOT
rely on the sender reacting to the feedback at all. rely on the sender reacting to the feedback at all.
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 FB messages
- Payload-specific feedback messages - Payload-specific FB messages
- Application layer feedback messages - Application layer FB messages
Transport layer feedback messages are intended to transmit general Transport layer FB 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 a 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 FB messages transport information that is specific
specific to a certain payload type and will be generated and acted to a certain payload type and will be generated and acted upon at
upon at the codec "layer". This document defines a common header the codec "layer". This document defines a common header to be
to be used in conjunction with all payload-specific feedback used in conjunction with all payload-specific FB messages. The
messages. The definition of specific messages is left to either definition of specific messages is left to either RTP payload
RTP payload format specifications or to additional feedback format format specifications or to additional feedback format documents.
documents.
Application layer feedback messages provide a means to Application layer FB messages provide a means to transparently
transparently convey feedback from the receiver's to the sender's convey feedback from the receiver's to the sender's application.
application. The information contained in such a message is not The information contained in such a message is not expected to be
expected to be acted upon at the transport/RTP or the codec layer. acted upon at the transport/RTP or the codec layer. The data to be
The data to be exchanged between two application instances is exchanged between two application instances is usually defined in
usually defined in the application protocol specification and thus the application protocol specification and thus can be identified
can be identified by the application so that there is no need for by the application so that there is no need for additional external
additional external information. Hence, this document defines only information. Hence, this document defines only a common header to
a common header to be used along with all application layer be used along with all application layer FB messages. From a
feedback messages. From a protocol point of view, an application protocol point of view, an application layer FB message is treated
layer feedback message is treated as a special case of a payload- as a special case of a payload-specific FB message.
specific feedback message.
NOTE: Proper processing of some feedback messages at the media NOTE: Proper processing of some FB messages at the media
sender side may require the sender to know which payload type sender side may require the sender to know which payload type
the feedback message refers to. Most of the time, this the FB message refers to. Most of the time, this knowledge
knowledge can likely be derived from a media stream using only can likely be derived from a media stream using only a single
a single payload type. However, if several codecs are used payload type. However, if several codecs are used
simultaneously (e.g. with audio and DTFM) or when codec simultaneously (e.g. with audio and DTFM) or when codec
changes occur, the payload type information may need to be changes occur, the payload type information may need to be
conveyed explicitly as part of the feedback message. This conveyed explicitly as part of the FB message. This applies
applies to all payload-specific as well as application layer to all payload-specific as well as application layer FB
feedback messages. It is up to the specification of a messages. It is up to the specification of a FB message to
feedback message to define how payload type information is define how payload type information is transmitted.
transmitted.
This document defines two transport layer feedback and three This document defines two transport layer and three (video)
(video) payload-specific feedback messages as well as a single payload-specific FB messages as well as a single container for
container for application layer feedback messages. Additional application layer FB messages. Additional transport layer and
transport layer and payload specific feedback messages MAY be payload specific FB messages MAY be defined in other documents and
defined in other documents and MUST be registered through IANA (see 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 FB message
message types are described in the following subsections. types are described in the following subsections.
6.1 Common Packet Format for Feedback Message 6.1 Common Packet Format for Feedback Messages
All feedback message MUST use a common packet format that is
depicted in figure 3: All FB messages MUST use a common packet format that is 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| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 4, line 1202 skipping to change at page 30, line 46
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): 5 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 FB message and is
interpreted relative to the RTCP message type (transport, interpreted relative to the type (transport, payload-
payload-specific, or application layer feedback). The values specific, or application layer feedback). The values for each
for each of the three feedback types are defined in the of the three feedback types are defined in the respective
respective sections below. sections below.
Payload type (PT): 8 bits Payload type (PT): 8 bits
This is the RTCP packet type which identifies the packet as This is the RTCP packet type which identifies the packet as
being an RTCP Feedback Message. Two values are defined (TBA. being an RTCP FB message. Two values are defined (TBA. by
by IANA): IANA):
Name | Value | Brief Description Name | Value | Brief Description
----------+-------+------------------------------------ ----------+-------+------------------------------------
RTPFB | 205 | Transport layer feedback message RTPFB | 205 | Transport layer FB message
PSFB | 206 | Payload-specific feedback message PSFB | 206 | Payload-specific FB message
Length: 16 bits Length: 16 bits
The length of this packet in 32-bit words minus one, including The length of this packet in 32-bit words minus one, including
the header and any padding. This is in line with the the header and any padding. This is in line with the
definition of the length field used in RTCP sender and receiver definition of the length field used in RTCP sender and receiver
reports [3]. reports [3].
SSRC of packet sender: 32 bits SSRC of packet sender: 32 bits
The synchronization source identifier for the originator of The synchronization source identifier for the originator of
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 FB message for each type of
type of feedback (further FCI contents MAY be specified in feedback: transport layer, payload-specific or application
further documents). layer feedback. Note that further FCI contents MAY be specified
in further documents.
Each RTCP feedback packet MUST contain at least one feedback Each RTCP feedback packet MUST contain at least one FB message in
message in the FCI field. Sections 6.2 and 6.3 define for each the FCI field. Sections 6.2 and 6.3 define for each FCI type,
FCI type, whether or not multiple feedback messages MAY be whether or not multiple FB messages MAY be compressed into a single
contained in a single FCI field. If multiple feedback messages FCI field. If this is the case, they MUST be of the same type,
are contained in one FCI field, they MUST be of the same type i.e. same FMT.. If multiple types of feedback messages, i.e.
as. If multiple types of feedback need to be conveyed, then several FMTs, need to be conveyed, then several RTCP FB messages
several RTCP feedback packets MUST be generated and SHOULD MUST be generated and SHOULD be concatenated in the same compound
concatenated in the same compound RTCP packet. 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 FB messages are identified by the value RTPFB as
as RTCP message type. RTCP message type.
Two general purpose transport layer feedback messages are defined Two general purpose transport layer FB messages are defined so far:
so far: General ACK and General NACK. They are identified by means General ACK and General NACK. They are identified by means of the
of the FMT parameter as follows: FMT parameter as follows:
0: unassigned 0: unassigned
1: Generic NACK 1: Generic NACK
2: Generic ACK 2: Generic ACK
3-30: unassigned 3-30: unassigned
31: reserved for future expansion of the sequence number space 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 formats of the FCI field
messages. for these types of FB 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 The FCI field MUST contain at least one and MAY contain more than
one Generic NACK. 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
skipping to change at page 4, line 1296 skipping to change at page 32, line 43
Packet ID (PID): 16 bits Packet ID (PID): 16 bits
The PID field is used to specify a lost packet. Typically, the The PID field is used to specify a lost packet. Typically, the
RTP sequence number is used for PID as the default format, but RTP sequence number is used for PID as the default format, but
RTP Payload Formats may decide to identify a packet 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 [6].
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 length of the FB message MUST be set to 2+n, with n being the
the number of Generic NACKs contained in the FCI field. number of Generic NACKs contained in the FCI field.
The Generic NACK message implicitly references the payload type The Generic NACK message implicitly references the payload type
through the sequence number(s). 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 The FCI field MUST contain at least one and MAY contain more than
one Generic ACK. 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:
skipping to change at page 4, line 1375 skipping to change at page 34, line 28
Example: If all packets between and including PIDx = 380 and Example: If all packets between and including PIDx = 380 and
PIDy = 422 have been received, the Generic ACK would contain PIDy = 422 have been received, the Generic ACK would contain
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 [6] except that, here,
here, BLP is only 15 bits wide. Denoting the BLP's least BLP is only 15 bits wide. Denoting the BLP's least significant
significant bit as bit 1, and its most significant bit as bit bit as bit 1, and its most significant bit as bit 15, then bit
15, then bit i of the bitmask is set to 1 if the receiver has i of the bitmask is set to 1 if the receiver has received RTP
received RTP packet number (PID+i) (modulo 2^16) and decides to packet number (PID+i) (modulo 2^16) and decides to ACK this
ACK this packet; bit i is set to 0 otherwise. If only the packet; bit i is set to 0 otherwise. If only the packet
packet indicated by PID is to be ACKed and R=0 then BLP MUST be indicated by PID is to be ACKed and R=0 then BLP MUST be set to
set to 0x0000. 0x0000.
The length of the feedback message MUST be set to 2+n, with n being The length of the FB message MUST be set to 2+n, with n being the
the number of Generic ACKs contained in the FCI field. number of Generic ACKs contained in the FCI field.
The Generic ACK message implicitly references the payload type The Generic ACK message implicitly references the payload type
through the sequence number(s). 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 FB messages are identified by the value PT=PSFB as
PT=PSFB as RTCP message type. RTCP message type.
Three payload-specific feedback messages are defined so far plus an Three payload-specific FB messages are defined so far plus an
application layer feedback message. They are identified by means application layer FB message. They are identified by means of the
of the FMT parameter as follows: FMT parameter as follows:
0: unassigned 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 FB message
16-30: unassigned 16-30: unassigned
31: reserved for future expansion of the sequence number space 31: reserved for future expansion of the sequence number space
The following subsections define the packet formats for the The following subsections define the FCI formats for the payload-
payload-specific messages, section 6.4 defines the application specific FB messages, section 6.4 defines FCI format for the
layer feedback message. application layer FB 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 FB message is identified by PT=PSFB and FMT=1.
There MUST be exactly one PLI contained in the FCI field. 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
similar to the FIR as defined in [10]); however, the sender MUST similar to the FIR as defined in [6]); however, the sender MUST
consider congestion control as outlined in section 7 which MAY consider congestion control as outlined in section 7 which MAY
restrict its ability to send an intra frame. restrict its ability to send an intra frame.
Other RTP payload specifications such as RFC 2032 [10] already Other RTP payload specifications such as RFC 2032 [6] already
define a feedback mechanism for some for certain codecs. An define a feedback mechanism for some for certain codecs. An
application supporting both schemes MUST use the feedback mechanism application supporting both schemes MUST use the feedback mechanism
defined in this specification when sending feedback. For backward defined in this specification when sending feedback. For backward
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 The semantics of this FB message is independent of the payload
payload type. 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.
Intra pictures are several times larger then predicted (inter) Intra pictures are several times larger then predicted (inter)
pictures. Their size is independent of the time they are pictures. Their size is independent of the time they are
generated. In most environments, especially when employing generated. In most environments, especially when employing
bandwidth-limited links, the use of an intra picture implies an bandwidth-limited links, the use of an intra picture implies an
allowed delay that is a significant multitude of the typical frame allowed delay that is a significant multitude of the typical frame
duration. An example: If the sending frame rate is 10 fps, and an duration. An example: If the sending frame rate is 10 fps, and an
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 FB message. Hence waiting for the next possible time
time slot allowed by RTCP timing rules as per [2] does not have a 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 FB message is identified by PT=PSFB and FMT=2.
The FCI field MUST contain at least one and MAY contain more than The FCI field MUST contain at least one and MAY contain more than
one SLI. 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 FB
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 FB
feedback message MUST be set to 2+n, with n being the number of message MUST be set to 2+n, with n being the number of SLIs
SLIs contained in the FCI field. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Payload Type| MBZ | First | | First | Number | PictureID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number | PictureId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Syntax of the Slice Lost Indication (SLI) Figure 6: Syntax of the Slice Lost Indication (SLI)
0: 1 bit First: 13 bits
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: 16 bits Number: 13 bits
The number of lost macroblocks, in scan order as discussed The number of lost macroblocks, in scan order as discussed
above. above.
PictureID: 16 bits PictureID: 6 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.
The applicability of this FB message is limited to a small set of
video codecs and therefore, no explicit payload type information is
provided.
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 4, line 1559 skipping to change at page 38, line 22
lead to the necessity of sending more than one SLI in order to lead to the necessity of sending more than one SLI in order to
precisely identify the region of lost/damaged MBs. precisely identify the region of lost/damaged MBs.
The first field of the FCI defines the first macroblock of a The first field of the FCI defines the first macroblock of a
picture as 1 and not, as one could suspect, as 0. This was done to picture as 1 and not, as one could suspect, as 0. This was done to
align this specification with the comparable mechanism available in align this specification with the comparable mechanism available in
H.245. The maximum number of macroblocks in a picture (2**13 or H.245. The maximum number of macroblocks in a picture (2**13 or
8192) corresponds to the maximum picture sizes of most of the ITU-T 8192) corresponds to the maximum picture sizes of most of the ITU-T
and ISO/IEC video codecs. If future video codecs offer larger and ISO/IEC video codecs. If future video codecs offer larger
picture sizes and/or smaller macroblock sizes, then an additional picture sizes and/or smaller macroblock sizes, then an additional
feedback message has to be defined. The six least significant bits FB message has to be defined. The six least significant bits of
of the Temporal Reference field are deemed to be sufficient to the Temporal Reference field are deemed to be sufficient to
indicate the picture in which the loss occurred. indicate the picture in which the loss occurred.
The reaction to a SLI is not part of this specification. One The reaction to a SLI is not part of this specification. One
typical way of reacting to a SLI is to use intra refresh for the typical way of reacting to a SLI is to use intra refresh for the
affected spatial region. affected spatial region.
Algorithms were reported that keep track of the regions affected by Algorithms were reported that keep track of the regions affected by
motion compensation, in order to allow for a transmission of Intra motion compensation, in order to allow for a transmission of Intra
macroblocks to all those areas, regardless of the timing of the FB macroblocks to all those areas, regardless of the timing of the FB
(see H.263 (2000) Appendix I [13] and [15]). While, when those (see H.263 (2000) Appendix I [17] 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 FB message is identified by PT=PSFB and FMT=3.
There MUST be exactly one RPSI contained in the FCI field. 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 [16]
or H.263 version 2 [13] allow to use older reference pictures than or H.263 version 2 [17] 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
coded picture will use more bits. coded picture will use more bits.
Both MPEG-4 and H.263 define a binary format for the "payload" of Both MPEG-4 and H.263 define a binary format for the "payload" of
an RPSI message that includes information such as the temporal ID an RPSI message that includes information such as the temporal ID
of the damaged picture and the size of the damaged region. This of the damaged picture and the size of the damaged region. This
skipping to change at page 4, line 1616 skipping to change at page 39, line 32
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 |0| Payload Type| Native RPSI bit string | | PB |0| Payload Type| Native RPSI bit string |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| as defined per codec ... | Padding (0)| | 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 0: 1 bit
skipping to change at page 4, line 1655 skipping to change at page 40, line 23
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
Application Layer Feedback Messages are a special case of payload- Application Layer FB 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 There MUST be exactly one Application Layer FB message contained in
contained in the FCI field. 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 FB 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 [16] or FB messages in H.263/Annex N, U
U. These messages do not need any additional information from the [17]. These messages do not need any additional information from
RTCP message. Thus the application message is simply placed into the RTCP message. Thus the application message is simply placed
the FCI field as follows and the length field is set accordingly. into 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 32-bit-aligned, variable. If the application data is not 32-bit-aligned,
padding bits and bytes must be added. Identification of padding bits and bytes must be added. Identification of
padding is up to the application layer and not defined in this padding is up to the application layer and not defined in this
specification. specification.
The application layer feedback message specification MUST define The application layer FB message specification MUST define whether
whether or not the message needs to be interpreted specifically in or not the message needs to be interpreted specifically in the
the context of a certain codec (identified by the RTP payload context of a certain codec (identified by the RTP payload type).
type). If a reference to the payload type is required for proper If a reference to the payload type is required for proper
processing, the application layer feedback message specification processing, the application layer FB message specification MUST
MUST define a way to communicate the payload type information as define a way to communicate the payload type information as part of
part of the application layer feedback message itself. the application layer FB 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 FB messages were defined as well as
well as the timing rules according to which to send these messages. the timing rules according to which to send these messages. The
The way to react to the feedback received depends on the way to react to the feedback received depends on the application
application using the feedback mechanisms and hence is beyond the using the feedback mechanisms and hence is beyond the scope of this
scope of this document. document.
However, across all applications, there is a common requirement for However, across all applications, there is a common requirement for
(TCP-friendly) congestion control on the media stream as defined in (TCP-friendly) congestion control on the media stream as defined in
[1] and [2] when operating in a best-effort network environment. [1] and [2] when operating in a best-effort network environment.
Low delay feedback supports the use of congestion control Low delay feedback supports the use of congestion control
algorithms in two ways: algorithms in two ways:
o The potentially more frequent RTCP messages allow the sender to o The potentially more frequent RTCP packets allow the sender to
monitor the network state more closely than with regular RTCP monitor the network state more closely than with Regular RTCP
and therefore enable reacting to upcoming congestion in a more packets and therefore enable reacting to upcoming congestion in
timely fashion. a more timely fashion.
o The feedback messages themselves may convey additional o The FB messages themselves may convey additional information as
information as input to congestion control algorithms and thus input to congestion control algorithms and thus improve reaction
improve reaction over conventional RTCP. (For example, ACK-based over conventional RTCP. (For example, ACK-based feedback may
feedback may even allow to construct closed loop algorithms and even allow to construct closed loop algorithms and NACK-based
NACK-based systems may provide further information on the packet systems may provide further information on the packet loss
loss distribution.) distribution.)
A congestion control algorithm that shares the available bandwidth A congestion control algorithm that shares the available bandwidth
fair with competing TCP connections, e.g. TFRC [16], SHOULD be used fair with competing TCP connections, e.g. TFRC [8], SHOULD be used
to determine the data rate for the media stream (if the low delay to determine the data rate for the media stream (if the low delay
RTP session is transmitted in a best effort environment). RTP session is transmitted in a best effort environment).
RTCP feedback messages or RTCP SR/RR packets that indicate recent RTCP FB messages or RTCP SR/RR packets that indicate recent packet
packet loss MUST NOT lead to a (mid-term) increase in the loss MUST NOT lead to a (mid-term) increase in the transmission
transmission data rate and SHOULD lead to a (short-term) decrease data rate and SHOULD lead to a (short-term) decrease of the
of the transmission data rate. Such messages SHOULD cause the transmission data rate. Such messages SHOULD cause the sender to
sender to adjust the transmission data rate to the order of the adjust the transmission data rate to the order of the throughput
throughput TCP would achieve under similar conditions (e.g. using TCP would achieve under similar conditions (e.g. using TFRC).
TFRC).
RTCP feedback messages or RTCP SR/RR packets that indicate no RTCP FB messages or RTCP SR/RR packets that indicate no recent
recent packet loss MAY cause the sender to increase the packet loss MAY cause the sender to increase the transmission data
transmission data rate to roughly the throughput TCP would achieve rate to roughly the throughput TCP would achieve under similar
under similar conditions (e.g. using TFRC). 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 five 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 FB
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
group member reducing early feedback by simply transmitting group member reducing Early feedback by simply transmitting
payload-specific RTCP feedback packets with random contents that payload-specific RTCP feedback packets with random contents that
are neither recognized by any receiver (so they will suppress are neither recognized by any receiver (so they will suppress
feedback) nor by the sender (so no repair actions will be taken). feedback) nor by the sender (so no repair actions will be taken).
A malicious group member can also report arbitrary high loss rates A malicious group member can also report arbitrary high loss rates
in the feedback information to make the sender throttle the data in the feedback information to make the sender throttle the data
transmission and increase the amount of redundancy information or transmission and increase the amount of redundancy information or
take other action to deal with the pretended packet loss (e.g. send take other action to deal with the pretended packet loss (e.g. send
fewer frames or decrease audio/video quality). This may result in fewer frames or decrease audio/video quality). This may result in
a degradation of the quality of the reproduced media stream. a degradation of the quality of the reproduced media stream.
Finally, a malicious group member can act as a large number of Finally, a malicious group member can act as a large number of
group members and thereby obtain an artificially large share of the group members and thereby obtain an artificially large share of the
early feedback bandwidth and reduce the reactivity of the other Early feedback bandwidth and reduce the reactivity of the other
group members -- possibly even causing them to no longer operate in group members -- possibly even causing them to no longer operate in
immediate or early feedback mode and thus undermining the whole Immediate or Early feedback mode and thus undermining the whole
purpose of this profile. purpose of this profile.
Senders as well as receivers SHOULD behave conservative when Senders as well as receivers SHOULD behave conservative when
observing strange reporting behavior. For excessive failure observing strange reporting behavior. For excessive failure
reporting from one or a few receivers, the sender MAY decide to no reporting from one or a few receivers, the sender MAY decide to no
longer consider this feedback when adapting its transmission longer consider this feedback when adapting its transmission
behavior for the media stream. In any case, senders and receivers behavior for the media stream. In any case, senders and receivers
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]; as a prerequisite, an appropriate profile as defined in [10]; as a prerequisite, an appropriate
combination of those two profiles (an "SAVPF") needs to be combination of those two profiles (an "SAVPF") needs to be
specified. specified.
9. IANA Considerations 9 IANA Considerations
The following contact information shall be used for all The following contact information shall be used for all
registrations included here: registrations included here:
Contact: Joerg Ott Contact: Joerg Ott
mailto:jo@acm.org mailto:jo@acm.org
tel:+49-421-201-7028 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 for visual conferences with minimal control needs to be registered for
skipping to change at page 4, line 1847 skipping to change at page 44, line 20
Reference: This document. Reference: This document.
Value name: trr-int Value name: trr-int
Long name: Minimal receiver report interval Long name: Minimal receiver report interval
Reference: This document. Reference: This document.
Value name: app Value name: app
Long name: Application-defined paramater Long name: Application-defined paramater
Reference: This document. Reference: This document.
Further entries may be registered on a first-come first serve Further entries may be registered on a first-come first-serve
basis. Each new registration needs to indicate the parameter name basis. Each new registration needs to indicate the parameter name
and the syntax of possible additional arguments. For each new and the syntax of possible additional arguments. For each new
registration, it is mandatory that a permanent, stable, and registration, it is mandatory that a permanent, stable, and
publicly accessible document exists that specifies the semantics of publicly accessible document exists that specifies the semantics of
the registered parameter, the syntax and semantics of its the registered parameter, the syntax and semantics of its
parameters as well as corresponding feedback packet formats (if parameters as well as corresponding feedback packet formats (if
needed). The general registration procedures of [3] apply. needed). The general registration procedures of [3] apply.
For use with both "ack" and "nack", a joint sub-registry needs to For use with both "ack" and "nack", a joint sub-registry needs to
be set up that initially registers the following values: be set up that initially registers the following values:
skipping to change at page 4, line 1882 skipping to change at page 45, line 7
Value name: rpsi Value name: rpsi
Long name: Reference Picture Selection Indication Long name: Reference Picture Selection Indication
Usable with: ack, nack Usable with: ack, nack
Reference: This document. Reference: This document.
Value name: app Value name: app
Long name: Application layer feedback Long name: Application layer feedback
Usable with: ack, nack Usable with: ack, nack
Reference: This document. Reference: This document.
Further entries may be registered on a first-come first serve Further entries may be registered on a first-come first-serve
basis. Each registrations needs to indicate the parameter name, basis. Each registrations needs to indicate the parameter name,
the syntax of possible additional arguments, and whether the the syntax of possible additional arguments, and whether the
parameter is applicable to "ack" or "nack" feedback or both or some parameter is applicable to "ack" or "nack" feedback or both or some
different "rtcp-fb" attribute parameter. For each new different "rtcp-fb" attribute parameter. For each new
registration, it is mandatory that a permanent, stable, and registration, it is mandatory that a permanent, stable, and
publicly accessible document exists that specifies the semantics of publicly accessible document exists that specifies the semantics of
the registered parameter, the syntax and semantics of its the registered parameter, the syntax and semantics of its
parameters as well as corresponding feedback packet formats (if parameters as well as corresponding feedback packet formats (if
needed). The general registration procedures of [3] apply. 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 FB
feedback messages ("RTPFB") and for the class of payload-specific messages ("RTPFB") and for the class of payload-specific FB
feedback messages ("PSFB"). Section 6 suggests RTPFB=205 and messages ("PSFB"). Section 6 suggests RTPFB=205 and PSFB=206 to be
PSFB=206 to be added to the RTCP registry. added to the RTCP registry.
RTP RTCP Control Packet types (PT): RTP RTCP Control Packet types (PT):
Name: RTPFB Name: RTPFB
Long name: Generic RTP Feedback Long name: Generic RTP Feedback
Value: 205 Value: 205
Reference: This document. Reference: This document.
Name: PSFB Name: PSFB
Long name: Payload-specific Long name: Payload-specific
Value: 206 Value: 206
Reference: This document. Reference: This document.
As AVPF defines additional RTCP payload types, the corresponding As AVPF defines additional RTCP payload types, the corresponding
"reserved" RTP payload type space (72--76, as defined in [2]), "reserved" RTP payload type space (72--76, as defined in [2]),
needs to be expanded accordingly (to cover the range 72--78). needs to be expanded accordingly.
A new sub-registry needs to be set up for the FMT values for both 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 the RTPFB payload type and the PSFB payload type, with the
following registrations created initially: following registrations created initially:
Within the RTPFB range, the following three format (FMT) values are Within the RTPFB range, the following three format (FMT) values are
initially registered: initially registered:
Name: Generic NACK Name: Generic NACK
Long name: Generic negative acknowledgement Long name: Generic negative acknowledgement
Value: 1 Value: 1
Reference: This document. Reference: This document.
Name: Generic ACK Name: Generic ACK
Long name: Generic positive acknowledgement Long name: Generic positive acknowledgement
skipping to change at page 4, line 1963 skipping to change at page 46, line 51
Name: AFB Name: AFB
Long name: Application Layer Feedback Long name: Application Layer Feedback
Value: 1 Value: 1
Reference: This document. Reference: This document.
Name: Extension Name: Extension
Long name: Reserved for future extensions. Long name: Reserved for future extensions.
Value: 31 Value: 31
Reference: This document. Reference: This document.
Further entries may be registered on a first-come first serve Further entries may be registered on a first-come first-serve
basis. Each registration needs to indicate the FMT value, if there basis. Each registration needs to indicate the FMT value, if there
is a specific feedback message to go into the FCI field, and is a specific FB message to go into the FCI field, and whether or
whether or not multiple feedback messages may be stacked in a not multiple FB messages may be stacked in a single FCI field. For
single FCI field. For each new registration, it is mandatory that each new registration, it is mandatory that a permanent, stable,
a permanent, stable, and publicly accessible document exists that and publicly accessible document exists that specifies the
specifies the semantics of the registered parameter as well as the semantics of the registered parameter as well as the syntax and
syntax and semantics of the associated feedback message (if any). semantics of the associated FB message (if any). The general
The general registration procedures of [3] apply. 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. The authors as for their responsiveness to numerous questions. The authors
would also like to thank Magnus Westerlund for his review and his would also like to particularly thank Magnus Westerlund for his
valuable suggestions; Shigeru Fukunaga, Koichi Yano, Akihiro review and his valuable suggestions, Shigeru Fukunaga for the
Miyazaki, and Rolf Hakenberg for the contributions on for feedback contributions on for FB message formats and semantics.
message formats and semantics; and Andreas Buesching for his
feedback based upon implementation and testing.
11. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on We would also like to thank Andreas Buesching and people at
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET Panasonic for their simulations and the first independent
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR implementations of the feedback profile.
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
12. Authors' Addresses 11 Authors' Addresses
Joerg Ott {sip,mailto}:jo@tzi.org Joerg Ott {sip,mailto}:jo@tzi.org
Uni Bremen TZI Uni Bremen TZI
MZH 5180 MZH 5180
Bibliothekstr. 1 Bibliothekstr. 1
D-28359 Bremen D-28359 Bremen
Germany Germany
Stephan Wenger stewe@cs.tu-berlin.de Stephan Wenger stewe@cs.tu-berlin.de
TU Berlin TU Berlin
skipping to change at page 4, line 2048 skipping to change at page 48, line 16
Monzastr. 4c, 63225 Langen, Germany Monzastr. 4c, 63225 Langen, Germany
Tel. +49-(0)6103-766-263 Tel. +49-(0)6103-766-263
Fax. +49-(0)6103-766-166 Fax. +49-(0)6103-766-166
Mail burmeister@panasonic.de Mail burmeister@panasonic.de
Jose Rey 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-134 Tel. +49-(0)6103-766-134
Fax. +49-(0)6103-766-166 Fax. +49-(0)6103-766-166
Mail hakenberg@panasonic.de Mail rey@panasonic.de
11. Bibliography 12 Bibliography
12.1 Normative references
[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, V. Jacobson, and Colin Perkins, "SDP: Session [3] M. Handley, V. Jacobson, and Colin Perkins, "SDP: Session
Description Protocol", Internet Draft draft-ietf-mmusic-sdp- Description Protocol", Internet Draft draft-ietf-mmusic-sdp-
new-10.txt, May 2002. new-11.txt, November 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] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Streaming Media," RFC 2354, June 1998. Levels," RFC 2119, March 1997.
[6] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for [6] T. Turletti and C. Huitema, "RTP Payload Format for H.261
Generic Forward Error Correction,", RFC 2733, December 1999. Video Streams, RFC 2032, October 1996.
[7] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, [7] G. Camarillo, J. Holler, G. Eriksson, H. Schulzrinne,
J.C. Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload "Grouping of media lines in SDP," RFC 3388, December 2002.
for Redundant Audio Data," RFC 2198, September 1997.
[8] S. Bradner, "Key words for use in RFCs to Indicate Requirement [8] M. Handley, J. Padhye, S. Floyd, J. Widmer, "TCP friendly Rate
Levels," RFC 2119, March 1997. Control (TFRC): Protocol Specification," RFC3448, January
2003.
[9] H. Schulzrinne and S. Petrack, "RTP Payload for DTMF Digits, [9] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
Telephony Tones and Telephony Signals," RFC 2833, May 2000. SDP," RFC 3264, June 2002.
[10] T. Turletti and C. Huitema, "RTP Payload Format for H.261 12.2 Informative References
Video Streams, RFC 2032, October 1996.
[11] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. [10] M. Baugher, R. Blom, E. Carrarra, D. McGrew, M. Naslund, K.
Norrman, D. Oran, "The Secure Real-Time Transport Protocol,"
Internet Draft, draft-ietf-avt-srtp-05.txt, Work in Progress,
June 2002.
[11] C. Perkins and O. Hodson, "Options for Repair of Streaming
Media," RFC 2354, June 1998.
[12] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction,", RFC 2733, December 1999.
[13] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley,
J.C. Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload
for Redundant Audio Data," RFC 2198, September 1997.
[14] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D.
Newell, J. Ott, G. Sullivan, S. Wenger, and C. Zhu, "RTP Newell, J. Ott, G. Sullivan, S. Wenger, and C. Zhu, "RTP
Payload Format for the 1998 Version of ITU-T Rec. H.263 Video Payload Format for the 1998 Version of ITU-T Rec. H.263 Video
(H.263+)," RFC 2429, October 1998. (H.263+)," RFC 2429, October 1998.
[12] ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology - [15] B. Girod, N. Faerber, "Feedback-based error control for mobile
Coding of audio-visual objects - Part2: Visual", July 2000. video transmission," Proceedings IEEE, Vol. 87, No. 10, pp.
1707 - 1723, October, 1999.
[13] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate [16] ISO/IEC 14496-2:2001/Amd.1:2002, "Information technology -
Coding of audio-visual objects - Part2: Visual", 2001.
[17] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate
Communication," November 2000. Communication," November 2000.
[14] G. Camarillo, J. Holler, G. Eriksson, H. Schulzrinne, [18] H. Schulzrinne and S. Petrack, "RTP Payload for DTMF Digits,
"Grouping of media lines in SDP," Internet Draft, draft-ietf- Telephony Tones and Telephony Signals," RFC 2833, May 2000.
mmusic-fid-05.txt, Work in Progress, September 2001.
[15] B. Girod, N. Faerber, "Feedback-based error control for mobile 13 IPR Notice
video transmission," Proceedings IEEE, Vol. 87, No. 10, pp.
1707 - 1723, October, 1999.
[16] M. Handley, J. Padhye, S. Floyd, J. Widmer, "TCP friendly Rate The IETF takes no position regarding the validity or scope of any
Control (TFRC): Protocol Specification," Internet Draft, intellectual property or other rights that might be claimed to
draft-ietf-tsvwg-tfrc-03.txt, Work in Progress, July 2001. pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
[17] M. Baugher, R. Blom, E. Carrarra, D. McGrew, M. Naslund, K. The IETF invites any interested party to bring to its attention any
Norrman, D. Oran, "The Secure Real-Time Transport Protocol," copyrights, patents or patent applications, or other proprietary
Internet Draft, draft-ietf-avt-srtp-05.txt, Work in Progress, rights which may cover technology that may be required to practice
June 2002. this standard. Please address the information to the IETF
Executive Director.
[18] J. Rosenberg and H. Schulzrinne, "An offer/answer model with 14 Full Copyright Statement
SDP," Internet Draft draft-ietf-mmusic-sdp-offer-answer-
02.txt, February 2002. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
 End of changes. 

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