draft-ietf-avt-rtcp-feedback-05.txt   draft-ietf-avt-rtcp-feedback-06.txt 
INTERNET-DRAFT Joerg Ott/Uni Bremen TZI INTERNET-DRAFT Joerg Ott/Uni Bremen TZI
draft-ietf-avt-rtcp-feedback-05.txt Stephan Wenger/TU Berlin draft-ietf-avt-rtcp-feedback-06.txt Stephan Wenger/TU Berlin
Noriyuki Sato/Oki Noriyuki Sato/Oki
Carsten Burmeister/Matsushita Carsten Burmeister/Matsushita
Jose Rey/Matsushita Jose Rey/Matsushita
28 February 2003 2 May 2003
Expires August 2003 Expires November 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 This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
documents at any time. It is inappropriate to use Internet- Drafts documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." 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.
"Copyright (C) The Internet Society (date). All Rights Reserved.
Abstract Abstract
Real-time media streams that use RTP are not resilient against Real-time media streams that use RTP are, to some degree, resilient
packet losses. Receivers may use the base mechanisms of RTCP to against packet losses. Receivers may use the base mechanisms of
report packet reception statistics and thus allow a sender to adapt RTCP to report packet reception statistics and thus allow a sender
its transmission behavior in the mid-term as sole means for to adapt its transmission behavior in the mid-term as sole means
feedback and feedback-based error repair (besides a few codec- for 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.
Table of Contents Table of Contents
1 Introduction..................................................3 1 Introduction..................................................3
1.1 Definitions.............................................4 1.1 Definitions.............................................4
1.2 Terminology.............................................5 1.2 Terminology.............................................5
2 RTP and RTCP Packet Formats and Protocol Behavior.............6 2 RTP and RTCP Packet Formats and Protocol Behavior.............6
3 Rules for RTCP Feedback.......................................6 3 Rules for RTCP Feedback.......................................6
3.1 Compound RTCP Feedback Packets..........................6 3.1 Compound RTCP Feedback Packets..........................6
3.2 Algorithm Outline.......................................8 3.2 Algorithm Outline.......................................8
3.3 Modes of Operation......................................9 3.3 Modes of Operation......................................9
3.4 Definitions and Algorithm Overview.....................10 3.4 Definitions and Algorithm Overview.....................11
3.5 Early RTCP Algorithm...................................13 3.5 AVPF RTCP Scheduling Algorithm.........................14
3.5.1 Initialization........................................14 3.5.1 Initialization........................................14
3.5.2 Early Feedback Transmission...........................14 3.5.2 Early Feedback Transmission...........................14
3.5.3 Regular RTCP Transmission.............................17 3.5.3 Regular RTCP Transmission.............................17
3.5.4 Other Considerations..................................18 3.5.4 Other Considerations..................................18
3.6 Considerations on the Group Size.......................18 3.6 Considerations on the Group Size.......................19
3.6.1 ACK mode..............................................18 3.6.1 ACK mode..............................................19
3.6.2 NACK mode.............................................19 3.6.2 NACK mode.............................................19
3.7 Summary of decision steps..............................20 3.7 Summary of decision steps..............................21
3.7.1 General Hints.........................................21 3.7.1 General Hints.........................................21
3.7.2 Media Session Attributes..............................21 3.7.2 Media Session Attributes..............................21
4 SDP Definitions..............................................22 4 SDP Definitions..............................................22
4.1 Profile identification.................................22 4.1 Profile identification.................................22
4.2 RTCP Feedback Capability Attribute.....................22 4.2 RTCP Feedback Capability Attribute.....................22
4.3 Unicasting vs. Multicasting............................25 4.3 RTCP Bandwidth Modifiers...............................26
4.4 RTCP Bandwidth Modifiers...............................26 4.4 Examples...............................................26
4.5 Examples...............................................26 5 Interworking and Co-Existence of AVP and AVPF Entities.......28
5 Interworking and Co-Existence of AVP and AVPF Entities.......27
6 Format of RTCP Feedback Messages.............................29 6 Format of RTCP Feedback Messages.............................29
6.1 Common Packet Format for Feedback Messages.............30 6.1 Common Packet Format for Feedback Messages.............30
6.2 Transport Layer Feedback Messages......................31 6.2 Transport Layer Feedback Messages......................32
6.2.1 Generic NACK..........................................32 6.2.1 Generic NACK..........................................32
6.2.2 Generic ACK...........................................33 6.2.2 Generic ACK...........................................33
6.3 Payload Specific Feedback Messages.....................34 6.3 Payload Specific Feedback Messages.....................35
6.3.1 Picture Loss Indication (PLI).........................35 6.3.1 Picture Loss Indication (PLI).........................35
6.3.1.1 Semantics..........................................35 6.3.1.1 Semantics..........................................35
6.3.1.2 Message Format.....................................35 6.3.1.2 Message Format.....................................36
6.3.1.3 Timing Rules.......................................36 6.3.1.3 Timing Rules.......................................36
6.3.1.4 Remarks............................................36 6.3.1.4 Remarks............................................36
6.3.2 Slice Lost Indication (SLI)...........................36 6.3.2 Slice Lost Indication (SLI)...........................37
6.3.2.1 Semantics..........................................36 6.3.2.1 Semantics..........................................37
6.3.2.2 Format.............................................37 6.3.2.2 Format.............................................37
6.3.2.3 Timing Rules.......................................37 6.3.2.3 Timing Rules.......................................38
6.3.2.4 Remarks............................................38 6.3.2.4 Remarks............................................38
6.3.3 Reference Picture Selection Indication (RPSI).........38 6.3.3 Reference Picture Selection Indication (RPSI).........39
6.3.3.1 Semantics..........................................38 6.3.3.1 Semantics..........................................39
6.3.3.2 Format.............................................39 6.3.3.2 Format.............................................40
6.3.3.3 Timing Rules.......................................40 6.3.3.3 Timing Rules.......................................40
6.4 Application Layer Feedback Messages....................40 6.4 Application Layer Feedback Messages....................41
7 Early Feedback and Congestion Control........................41 7 Early Feedback and Congestion Control........................41
8 Security Considerations......................................42 8 Security Considerations......................................42
9 IANA Considerations..........................................43 9 IANA Considerations..........................................43
10 Acknowledgements.............................................47 10 Acknowledgements.............................................47
11 Authors' Addresses...........................................47 11 Authors' Addresses...........................................48
12 Bibliography.................................................48 12 Bibliography.................................................48
12.1 Normative references...................................48 12.1 Normative references...................................48
12.2 Informative References.................................49 12.2 Informative References.................................49
13 IPR Notice...................................................49 13 IPR Notice...................................................50
14 Full Copyright Statement.....................................50 14 Full Copyright Statement.....................................50
1 Introduction 1 Introduction
Real-time media streams that use RTP are not resilient against Real-time media streams that use RTP are, to some degree, resilient
packet losses. RTP [1] provides all the necessary mechanisms to against packet losses. RTP [1] provides all the necessary
restore ordering and timing present at the sender to properly mechanisms to restore ordering and timing present at the sender to
reproduce a media stream at a recipient. RTP also provides properly reproduce a media stream at a recipient. RTP also
continuous feedback about the overall reception quality from all provides continuous feedback about the overall reception quality
receivers -- thereby allowing the sender(s) in the mid-term (in the from all receivers -- thereby allowing the sender(s) in the mid-
order of several seconds to minutes) to adapt their coding scheme term (in the order of several seconds to minutes) to adapt their
and transmission behavior to the observed network QoS. However, coding scheme and transmission behavior to the observed network
except for a few payload specific mechanisms [6], RTP makes no QoS. However, except for a few payload specific mechanisms [6],
provision for timely feedback that would allow a sender to repair RTP makes no provision for timely feedback that would allow a
the media stream immediately: through retransmissions, retro-active sender to repair the media stream immediately: through
FEC control, or media-specific mechanisms for some video codecs, retransmissions, retro-active FEC control, or media-specific
such as reference picture selection. 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 [13], video redundancy coding [14], include audio redundancy coding [13], video redundancy coding [14],
RTP-level FEC [11], and general considerations on more robust media RTP-level FEC [11], and general considerations on more robust media
streams transmission [12]. 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 concept of Early RTCP messages as well as algorithms allowing for
well as algorithms allowing for low delay feedback in small low delay feedback in small multicast groups (and preventing
multicast groups (and preventing feedback implosion in large ones) feedback implosion in large ones) are introduced. Special
are introduced. Special consideration is given to point-to-point consideration is given to point-to-point scenarios. A small number
scenarios. A small number of general-purpose feedback messages as of general-purpose feedback messages as well as a format for codec
well as a format for codec and application-specific feedback and application-specific feedback information are defined for
information are defined for transmission in the RTCP payloads. 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 RTP/RTCP [1] and the RTP Profile for Audio and
definitions are used in this document: Video Conferences with Minimal Control [2] apply. In addition, the
following 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 often (but not always) capable of reporting events of is often (but not always) capable of reporting events of
interest back to the sender close to their occurrence. In interest back to the sender close to their occurrence. In
Early RTCP mode, RTCP packets are transmitted according to Early RTCP mode, RTCP packets are transmitted according to
the timing rules defined in this document. the timing rules 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
skipping to change at page 5, line 7 skipping to change at page 5, line 9
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. For the sake of clarity, feedback message is stream. For the sake of clarity, feedback message is
referred to as FB message throughout this document. 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 multiparty 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
skipping to change at page 6, line 13 skipping to change at page 6, line 13
[5]. [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 are registered and the Two additional RTCP packet types are registered and the
corresponding FB messages to convey feedback information corresponding FB messages to convey feedback information
are defined in section 6. are defined in section 6 of this memo.
RTCP report intervals: RTCP report intervals:
This document 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 of
Regular RTCP mode, all rules from [1] apply. In both this memo). In Regular RTCP mode, all rules from [1] apply
Immediate Feedback and Early RTCP modes the minimal except for the minimal interval of five seconds between two
interval of five seconds between two RTCP reports is RTCP reports from the same RTP entity. In both Immediate
dropped and the rules specified in section 3 apply if RTCP Feedback and Early RTCP modes, the minimal interval of five
packets containing FB messages (defined in section 4) are seconds between two RTCP reports is dropped and,
to be transmitted. additionally, the rules specified in section 3 of this memo
apply if RTCP packets containing FB messages (defined in
section 4 of this memo) are to be transmitted.
The rules set forth in [1] may be overridden by session The rules set forth in [1] may be overridden by session
descriptions specifying different parameters (e.g. for the descriptions specifying different parameters (e.g. for the
bandwidth share assigned to RTCP for senders and receivers, bandwidth share assigned to RTCP for senders and receivers,
respectively). For sessions defined using the Session respectively). For sessions defined using the Session
Description Protocol (SDP) [3], the rules of [4] apply. Description Protocol (SDP) [3], the rules of [4] apply.
Congestion control: Congestion control:
The same basic rules as detailed in [2] apply. Beyond The same basic rules as detailed in [2] apply. Beyond
this, in section 5, further consideration is given to the this, in section 5, further consideration is given to the
skipping to change at page 8, line 24 skipping to change at page 8, line 28
to the RTCP bandwidth constraints. This means, in particular, that to the RTCP bandwidth constraints. This means, in particular, that
it may not be possible to report an event observed at a receiver it may not be possible to report an event observed at a receiver
immediately back to the sender. However, the value of feedback immediately back to the sender. However, the value of feedback
given to a sender typically decreases over time -- in terms of the given to a sender typically decreases over time -- in terms of the
media quality as perceived by the user at the receiving end and/or media quality as perceived by the user at the receiving end and/or
the cost required to achieve media stream repair. the cost required to 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 RTP packets)and to accommodate algorithms that loss or reception of RTP packets) and to accommodate algorithms
use FB messages. that use FB messages.
The modified RTCP transmission algorithm can be outlined as The modified RTCP transmission algorithm can be outlined as
follows: As long as no FB messages have to be conveyed, compound follows: As long as no FB messages have to be conveyed, compound
RTCP packets are sent following the rules of RTP [1] -- except that RTCP packets are sent following the rules of RTP [1] -- except that
the five second minimum interval between RTCP reports is not the five second minimum interval between RTCP reports is not
enforced.Hence, the interval between RTCP reports is only derived enforced.Hence, the interval between RTCP reports is only derived
from the average RTCP packet size and the RTCP bandwidth share from the average RTCP packet size and the RTCP bandwidth share
available to the RTP/RTCP entity. Optionally, a minimum interval available to the RTP/RTCP entity. Optionally, a minimum interval
between Regular RTCP packets may be enforced. between Regular RTCP packets may be enforced.
If a receiver detects the need to send an FB message, it may do so If a receiver detects the need to send an FB message, it may do so
earlier than scheduled following the above (regular RTCP) earlier than the next regular RTCP reporting interval (for which it
algorithm. Feedback suppression is used to avoid feedback would be scheduled following the above regular RTCP algorithm).
implosion in multicast sessions: The receiver waits for a Feedback suppression is used to avoid feedback implosion in
(short)random dithering intervalto checkwhether it sees a multiparty sessions: The receiver waits for a (short) random
corresponding FB message from any other receiver reporting the same dithering interval to check whether it sees a corresponding FB
event.. Note that for unicast sessions there is no such delay. If message from any other receiver reporting the same event. Note
so this receiver refrains from sending the FB message and continues that for point-to-point sessions there is no such delay. If a
to follow the Regular RTCP transmission schedule. In case the corresponding FB message from another member is received, this
receiver refrains from sending the FB message and continues to
follow the Regular RTCP transmission schedule. In case the
receiver has not yet seen a corresponding FB message from any other receiver has not yet seen a corresponding FB message from any other
receiver, it checks whether it is allowed to send Early feedback. . member, it checks whether it is allowed to send Early feedback. If
If this is the case, it sends the FB message as part of a minimal sending Early feedback is permissible , the receiver sends the FB
compound RTCP packet. The permission to send Early feedback is message as part of a minimal compound RTCP packet. The permission
derived from the time Early feedback was sent. to send Early feedback depends on the type of the previous RTCP
packet sent by this receiver and the time the previous Early
feedback message 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 transmitted 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 of operation is an indication of described below. The mode of operation is just an indication of
whether or not the receiver will, on average, be able to report all whether or not the receiver will, on average, be able to report all
events to the sender in a timely fashion. The current mode of events to the sender in a timely fashion; the mode does not
operation is continuously derived independently at each receiver; influence the algorithm used for scheduling the transmission of FB
and the receivers do not have to agree on a common mode. messages. And, depending on the reception quality and the locally
monitored state of the RTP session, individual receivers may not
(and not have to) agree on a common perception on the current mode
of operation.
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 eventby means of a virtually "immediate" RTCP to report each eventby means of a 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 the (worst case or observed) frequency of events to report and the (worst case or observed) frequency of events to report
(e.g. frame received, packet lost). (e.g. frame received, packet lost).
A special case of this is the ACK mode (where positive
acknowledgements are used to confirm reception of data) which
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
skipping to change at page 10, line 7 skipping to change at page 10, line 13
increase the overall media playback 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) Regular RTCP Mode: From some group size upwards, it is no
feedback from individual receivers at all -- because of the longer useful to provide feedback for individual events from
time scale in which the feedback could be provided and/or receivers at all -- because of the time scale in which the
because in large groups the sender(s) have no chance to react feedback could be provided and/or because in large groups the
to individual feedback anymore. sender(s) have no chance to react to individual feedback
anymore.
No group size threshold can be specified at which this mode No precise group size threshold can be specified at which this
starts. mode starts but, obviously, this boundary matches the upper
bound of the Early RTCP mode as specified in item b).
As the feedback algorithm described in this document scales As the feedback algorithm described in this document scales
smoothly, there is no need for an agreement among the participants smoothly, there is no need for an agreement among the participants
on the precise values of the respective FB thresholds within the on the precise values of the respective FB thresholds within the
group. Hence the borders between all these modes are soft. group. Hence the borders between all these modes are soft.
ACK ACK
feedback feedback
V V
:<- - - - NACK feedback - - - ->// :<- - - - NACK feedback - - - ->//
skipping to change at page 10, line 47 skipping to change at page 11, line 9
As stated before, the respective FB thresholds depend on a number As stated before, the respective FB thresholds depend on a number
of 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 and Algorithm Overview 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
in g) are calculated independently at each receiver. Therefore, in item g) below) are calculated independently at each receiver.
their local values may differ at any given point in time. Therefore, 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.
skipping to change at page 11, line 34 skipping to change at page 11, line 42
[1]) with tn = tp + T. T_rr always refers to the last value of [1]) with tn = tp + T. T_rr always refers to the last value of
T that has been computed (because of reconsideration or to T that has been computed (because of reconsideration or to
determine tn). T_rr is also referred to as Regular RTCP interval determine tn). T_rr is also referred to as Regular RTCP interval
in this document. 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 in multicast. For point-to-point sessions, implosions in multiparty sessions; the value for T_dither_max is
dynamically calculated based upon T_rr. For point-to-point
sessions (i.e. sessions with exactly two members with no change
in the group size expected, e.g. unicast streaming sessions),
T_dither_max is set to 0. 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. This value is application-specific; and no values are all. This value is application-specific; and no values are
defined in this document. 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
skipping to change at page 12, line 9 skipping to change at page 12, line 19
receiver currently may transmit FB messages prior to its next receiver currently may transmit FB messages prior to its next
regularly scheduled RTCP interval tn. This variable is used to regularly scheduled RTCP interval tn. This variable is used to
throttle the feedback sent by a single receiver. allow_early is throttle the feedback sent by a single receiver. allow_early is
set to FALSE after Early feedback transmission and is set to set to FALSE after Early feedback transmission and is set to
TRUE as soon as the next Regular RTCP transmission takes place. TRUE as soon as the next Regular RTCP transmission takes place.
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 Regular between Regular RTCP packets. If T_rr_interval == 0, then this
RTCP packets will not be scheduled T_rr after the last Regular variable does not have any impact on the overall operation of
RTCP transmission (at tp+T_rr) but at least T_rr_interval after the RTCP feedback algorithm. If T_rr_interval != 0 then the
the last Regular RTCP transmission, i.e. later than or at next Regular RTCP packet will not be scheduled T_rr after the
tp+T_rr_interval. T_rr_interval does not affect the calculation last Regular RTCP transmission (i.e. at tp+T_rr). Instead, the
of T_rr and tp but may lead to Regular RTCP packets being next Regular RTCP packet will be delayed until at least
suppressed. In this case, Regular RTCP packets may be T_rr_interval after the last Regular RTCP transmission, i.e. it
suppressed if, for example, they do not contain any FB messages. will be scheduled at or later than tp+T_rr_interval. Note that
The T_rr_interval does not affect transmission scheduling of T_rr_interval does not affect the calculation of T_rr and tp;
Early RTCP packets. instead, Regular RTCP packets scheduled for transmission before
tp+T_rr_interval will be suppressed if, for example, they do not
contain any FB messages. The T_rr_interval does not affect
transmission scheduling of Early RTCP packets.
NOTE: Providing T_rr_interval as an independent variable is NOTE: Providing T_rr_interval as an independent variable is
meant to minimize Regular RTCP feedback (and thus bandwidth meant to minimize Regular RTCP feedback (and thus bandwidth
consumption) as needed by the application while additionally consumption) as needed by the application while additionally
allowing the use of more frequent Early RTCP packets to provide allowing the use of more frequent Early RTCP packets to provide
timely feedback. This goal could not be achieved by reducing timely feedback. This goal could not be achieved by reducing
the overall RTCP bandwidth as RTCP bandwidth reduction would the overall RTCP bandwidth as RTCP bandwidth reduction would
also impact the frequency of Early feedback. also impact the frequency of Early feedback.
n) Let t_rr_last be the point in time at which the last Regular n) Let t_rr_last be the point in time at which the last Regular
RTCP packet has been scheduled and sent, i.e. has not been RTCP packet has been scheduled and sent, i.e. has not been
suppressed due to T_rr_interval. suppressed due to T_rr_interval.
Regular
o) Let T_retention be the time window for which past FB messages 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 are stored by an AVPF entity. This is to ensure that feedback
suppression also works for entities that have received FB suppression also works for entities that have received FB
messages from other entities prior to noticing the feedback messages from other entities prior to noticing the feedback
event itself. T_retention MUST be set to at least 2 seconds. 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 p) Let M*Td be the timeout value for a receiver to be considered
inactive (as defined in [1]). 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 FB message needs to be sent back to specific parameters -- that a FB message needs to be sent back to
the sender. the sender.
To avoid an implosion of feedback packets in multicast sessions, To avoid an implosion of feedback packets in multiparty sessions,
the receiver MUST delay the transmission of the RTCP feedback the receiver MUST delay the transmission of the RTCP feedback
packet by a random amount of time 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, T_rr,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 FB 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
skipping to change at page 13, line 21 skipping to change at page 13, line 32
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 FB 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 Early RTCP packet is scheduled, the time slot for the next If an Early RTCP packet is scheduled, the time slot for the next
Regular RTCP packet MUST be updated accordingly to a new tn: Regular RTCP packet MUST be updated accordingly to a new tn:
tn=tp+2*T_rr. This is to ensure that the short-term average RTCP tn=tp+2*T_rr and so MUST tp: tp=tp+T_rr afterwards. This is to
bandwidth used with Early feedback does not exceed the bandwidth ensure that the short-term average RTCP bandwidth used with Early
used without Early feedback. feedback does not exceed the bandwidth used without Early
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 AVPF RTCP Scheduling Algorithm
3.5 Early RTCP Algorithm
Let S0 be an active sender (out of S senders) and let N be the Let S0 be an active sender (out of S senders) and let N be the
number of receivers with R being one of these receivers. number of receivers with R being one of these receivers.
Assume that R has verified that using feedback mechanisms is Assume that R has verified that using feedback mechanisms 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 document). application specific and hence not specified in this document).
Assume further that T_rr_interval is 0, if no minimal interval Assume further that T_rr_interval is 0, if no minimal interval
between Regular RTCP packets is to be enforced, or T_rr_interval is between Regular RTCP packets is to be enforced, or T_rr_interval is
set to some meaningful value, as given by the application. This set to some meaningful value, as given by the application. This
value then denotes the minimal interval between Regular RTCP value then denotes the minimal interval between Regular RTCP
packets. packets.
With this, a receiver R MUST use the following rules for With this, a receiver R MUST use the following rules for
transmitting one or more FB messages as minimal or full compound transmitting one or more FB messages as minimal or full compound
RTCP packet: 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 (Not-
a-Number, i.e. some invalid value that can be distinguished from a
valid time).
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 point-to-
session, the initial Tmin is set to 0. For a multicast session, point session, the initial Tmin is set to 0. For a multiparty
Tmin is initialized to 1.0 seconds. session, Tmin is initialized to 1.0 seconds.
3.5.2 Early Feedback Transmission 3.5.2 Early Feedback Transmission
Assume that R has scheduled the last RTCP RR packet for Assume that R had scheduled the last Regular RTCP RR packet for
transmission at tp and has scheduled the next transmission transmission at tp (and sent or suppressed this packet at tp) and
(including possible reconsideration as per [1]) for tn = tp + T_rr. has scheduled the next transmission (including possible
Assume also that the last Regular RTCP packet transmission has reconsideration as per [1]) for tn = tp + T_rr. Assume also that
occurred at t_rr_last. the last Regular RTCP packet transmission has occurred at
t_rr_last.
The Early Feedback algorithm then comprises the following steps: The Early Feedback algorithm then comprises the following steps:
1. At time t0, R detects the need to transmit one or more FB 1. At time t0, R detects the need to transmit one or more FB
messages, e.g. because media "units" need to be ACKed or NACKed, messages, e.g. because media "units" need to be ACKed or NACKed,
and finds that sending the feedback information is potentially and finds that providing the feedback information is potentially
useful for the sender. 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 one or more FB messages scheduled for transmission containing one or more FB messages scheduled for transmission
(either as Early or as Regular RTCP packet). (either as Early or as Regular RTCP packet).
2.a) If so, the new FB 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 compound RTCP scheduled packet; the scheduling of the waiting compound RTCP
packet MUST remain unchanged. When doing so, the available packet MUST remain unchanged. When doing so, the available
feedback information SHOULD be merged to produce as few FB feedback information SHOULD be merged to produce as few FB
messages as possible. This completes the course of immediate messages as possible. This completes the course of immediate
actions to be taken. actions to be taken.
2.b) If no compound RTCP packet is already scheduled for 2.b) If no compound RTCP packet is already scheduled for
transmission, a new (minimal or full) compound RTCP packet transmission, a new (minimal or full) compound RTCP packet
MUST be created and the minimal interval for T_dither_max MUST MUST be created and the minimal interval for T_dither_max MUST
be chosen as follows: be chosen as follows:
i) If the session is a unicast session then T_dither_max = i) If the session is a point-to-point session then
0. T_dither_max = 0.
ii) If the session is a multicast session then ii) If the session is a multiparty session 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.
skipping to change at page 15, line 50 skipping to change at page 16, line 15
transmission at tn. transmission at tn.
2. Otherwise, R MUST discard the RTCP FB 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 packets contained 5. R MUST detect overlaps in FB messages received from other
in one or more (minimal) compound RTCP packets and keep each of members of the RTP session and the FB messages R wants to send.
these RTCP packets for at least T_retention. When scheduling the Therefore, while member of the RTP session, R MUST continuously
transmission of a FB message, R MUST check each of the FB messages monitor the arrival of (minimal) compound RTCP packets and store
in the one or more compound RTCP packets received during the each FB message contained in these RTCP packets for at least
interval [t0 - T_retention ; te] and act as follows: T_retention. When scheduling the transmission of its own FB
message following steps 1. through 4. above, R MUST check each of
the stored and newly received FB messages from the RTCP packets
received during the interval [t0 - T_retention ; te] and act as
follows:
5.a) If R understands the received FB message's semantics and 5.a) If R understands the received FB message's semantics and
the message contents is a superset of the feedback R wanted to the message contents is a superset of the feedback R wanted to
send then R MUST discard its own FB message and MUST re- send then R MUST discard its own FB message and MUST re-
schedule the next Regular RTCP packet transmission for tn (as schedule the next Regular RTCP packet transmission for tn (as
calculated before). calculated before).
5.b) If R understands the received FB message's semantics and 5.b) If R understands the received FB message's semantics and
the message contents is not a superset of the feedback R wanted the message contents is not a superset of the feedback R wanted
to send then R SHOULD transmit its own FB message as scheduled. to send then R SHOULD transmit its own FB message as scheduled.
If there is an overlap between the feedback information to send If there is an overlap between the feedback information to send
and the feedback information received, the amount of feedback and the feedback information received, the amount of feedback
transmitted is up to R: R MAY keep its feedback information to transmitted is up to R: R MAY leave its feedback information to
be sent unchanged, R MAY as well eliminate any redundancy be sent unchanged, R MAY as well eliminate any redundancy
between its own feedback and the feedback received so far. between its own feedback and the feedback received so far from
other session members.
5.c) If R does not understand the received FB message's 5.c) If R does not understand the received FB message's
semantics, R MAY keep its own FB message scheduled as an Early semantics, R MAY keep its own FB message scheduled as an Early
RTCP packet, or R MAY re-schedule the next Regular RTCP packet 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
FB message to the now regularly scheduled RTCP message. FB message to the now regularly scheduled RTCP message.
Note: With 5.c, receiving unknown FB messages may not lead to Note: With 5.c), receiving unknown FB messages may not 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 FB consequence, a given event may cause M different types of FB
messages (which are all appropriate but not mutually messages (which are all appropriate but not mutually
understood) to be scheduled, and a "large" receiver group may understood) to be scheduled, so that a "large" receiver group
be partitioned into at most M groups. Among members of each of may effectively be partitioned into at most M groups. Among
these M groups, feedback suppression will occur following 5.a members of each of these M groups, feedback suppression will
and 5.b but no suppression will happen across groups. As a occur following 5.a and 5.b but no suppression will happen
result, O(M) RTCP FBmessages may be received by the sender. across groups. As a result, O(M) RTCP FB messages may be
Hence, there is a chance for a limited feedback implosion. received by the sender. Hence, there is a chance for a very
However, as sender(s) and all receivers make up the same limited feedback implosion. However, as sender(s) and all
application using the same (set of) codecs in the same RTP receivers make up the same application using the same (set of)
session, only little divergence in semantics for FB messages codecs in the same RTP session, only little divergence in
can safely be assumed and, therefore, M is assumed to be small semantics for FB messages can safely be assumed and, therefore,
in the general case. Given further that the O(M) FB messages M is assumed to be small in the general case. Given further
are randomly distributed over a time interval of T_dither_max that the O(M) FB messages are randomly distributed over a time
we find that the resulting limited number of extra compound interval of T_dither_max we find that the resulting limited
RTCP packets (a) is assumed not to overwhelm the sender and (b) number of extra compound RTCP packets (a) is assumed not to
should be conveyed as all contain complementary pieces of overwhelm the sender and (b) should be conveyed as all contain
information. complementary pieces of information.
Refer to section 4 on the comparison of FB messages and for
which FB messages MUST be understood by a receiver.
6. Otherwise, when te is reached, R MUST transmit the (minimal) 6. If R's FB message(s) was not suppressed by other receiver FB
compound RTCP packet containing the FB message(s). R then MUST set messages as per 5., when te is reached, R MUST transmit the
allow_early = FALSE, MUST recalculate tn = tp + 2*T_rr, and MUST (minimal) compound RTCP packet containing its FB message(s). R
set tp to the previous tn. As soon as the newly calculated tn is then MUST set allow_early = FALSE, MUST recalculate tn = tp +
reached , regardless whether R sends its next Regular RTCP packet 2*T_rr, and MUST set tp to the previous tn. As soon as the newly
or suppresses it because of T_rr_interval, it MUST set allow_early calculated tn is reached, regardless whether R sends its next
= TRUE again. Regular RTCP packet 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
Full compound RTCP packets MUST be sent in regular intervals. Full compound RTCP packets MUST be sent in regular intervals.
These packets MAY also contain one or more FB 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 in section 3.2 and 3.4 of this document and MUST as specified in section 3.2 and 3.4 of this document and MUST
adhere to the adjustments of tn specified in section 3.5.2, i.e. adhere to the adjustments of tn specified in section 3.5.2, i.e.
skipping to change at page 18, line 17 skipping to change at page 18, line 32
messages MAY be included in the Regular RTCP packet. messages MAY be included in the Regular RTCP packet.
After the scheduled packet has been sent, t_rr_last After the scheduled packet has been sent, t_rr_last
MUST be set to tn. MUST be set to tn.
2b) If t_rr_last + T_rr_current_interval > tn and RTCP FB 2b) If t_rr_last + T_rr_current_interval > tn and RTCP FB
messages have been stored and are awaiting messages have been stored and are awaiting
transmission, an RTCP packet MUST be scheduled for transmission, an RTCP packet MUST be scheduled for
transmission at tn. This RTCP packet MAY be a minimal transmission at tn. This RTCP packet MAY be a minimal
or a Regular RTCP packet (at the discretion of the or a Regular RTCP packet (at the discretion of the
implementer) and the compound RTCP packet MUST include implementer) and the compound RTCP packet MUST include
the stored RTCP FB message. t_rr_last MUST remain the stored RTCP FB message(s). t_rr_last MUST remain
unchanged. unchanged.
2c) Otherwise (if t_rr_last + T_rr_current_interval > tn 2c) Otherwise (if t_rr_last + T_rr_current_interval > tn
but no stored RTCP FB messages are awaiting but no stored RTCP FB messages are awaiting
transmission), no compound RTCP packet MUST be transmission), the compound RTCP packet MUST NOT be
scheduled. t_rr_last MUST remain unchanged. scheduled. t_rr_last MUST remain unchanged.
In all the four cases above (1, 2a, 2b, and 2c), allow_early MUST In all the four cases above (1, 2a, 2b, and 2c), allow_early MUST
be set to TRUE after sending the Regular RTCP packet and tp and tn be set to TRUE (possibly after sending the Regular RTCP packet) and
MUST be updated following the rules of [1] except for the five tp and tn MUST be updated following the rules of [1] except for the
second minimum. five second minimum.
3.5.4 Other Considerations 3.5.4 Other Considerations
If T_rr_interval != 0 then the timeout calculation for RTP/AVPF If T_rr_interval != 0 then the timeout calculation for 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 and thus M*Td.
Whenever a compound RTCP packet is sent or received -- minimal or Whenever a compound RTCP packet is sent or received -- minimal or
full compound, Early or Regular -- the avg_rtcp_size variable MUST full compound, Early or Regular -- the avg_rtcp_size variable MUST
be updated accordingly (see [1]) and subsequent computations of tn be updated accordingly (see [1]) and subsequent 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 RTP session MUST have exactly two members and this group size
point communications. Unicast addresses MUST be used in the MUST NOT grow, i.e. it MUST be point-to-point communications.
session description. Unicast addresses SHOULD be used in the 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 is 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 FB message then 20 events can for 10 events are collected in each FB message then 20 events 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
skipping to change at page 19, line 27 skipping to change at page 19, line 40
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 (this includes or other types of feedback Negative acknowledgements (and other types of feedback exhibiting
exhibiting similar reporting characteristics) MUST be used for all similar reporting characteristics) MUST be used for all sessions
sessions using multicast or multi-unicast (as indicated by the with a group size that may grow larger than two. Of course, NACKs
addressing information, e.g. in their SDP m= and c= lines). Of MAY be used for point-to-point communications as well.
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 Early RTCP packets should be considered
considered depends upon a number of parameters including session depends upon a number of parameters including session bandwidth,
bandwidth, codec, special type of feedback, number of senders and codec, special type of feedback, number of senders and receivers.
receivers.
The most important parameters when determining the mode of The most important parameters when determining the mode of
operation are the allowed minimal interval between two compound operation are the allowed minimal interval between two compound
RTCP packets (T_rr) and the average number of events that RTCP packets (T_rr) and the average number of events that
presumably need reporting per time interval(plus their distribution presumably need reporting per time interval (plus their
over time, of course). The minimum interval can be derived from distribution over time, of course). The minimum interval can be
the available RTCP bandwidth and the expected average size of an derived from the available RTCP bandwidth and the expected average
RTCP packet. The number of events to report e.g. per second may be size of an RTCP packet. The number of events to report e.g. per
derived from the packet loss rate and sender's rate of transmitting second may be derived from the packet loss rate and sender's rate
packets. From these two values, the allowable group size for the of transmitting packets. From these two values, the allowable
Immediate Feedback mode can be calculated. group size for the 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 as long
as long as N<=B*T/R. 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.
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 into one 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, on average, have to report 3 packets lost each
Assuming a single sender and more than three receivers, this yields two seconds. Assuming a single sender and more than three
3.75% of the RTCP bandwidth allocated to the receivers and thus receivers, this yields 3.75% of the RTCP bandwidth allocated to the
9.6kbit/s. Assuming further a size of 120 bytes for the average receivers and thus 9.6kbit/s. Assuming further a size of 120 bytes
compound RTCP packet allows 10 RTCP packets to be sent per second for the average compound RTCP packet allows 10 RTCP packets to be
or 20 in two seconds. If every receiver needs to report three sent per second or 20 in two seconds. If every receiver needs to
packets, this yields a maximum group size of 6-7 receivers if all report three lost packets per two seconds, this yields a maximum
loss events shall be reported. The rules for transmission of group size of 6-7 receivers if all loss events shall be reported.
Immediate RTCP packets should provide sufficient flexibility for The rules for transmission of Early RTCP packets should provide
most of this reporting to occur in a timely fashion. sufficient flexibility for 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
skipping to change at page 21, line 28 skipping to change at page 21, line 39
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 reception statistics provide valuable input to this Regular RTCP reception statistics provide valuable input to this
step, too. step, too.
3) If the application decides to send feedback, the application has 3) If the application decides to send feedback, the application has
to follow the rules for transmitting Early RTCP packets or to follow the rules for transmitting Early RTCP packets or
Regular RTCP packets with containing FB messages. Regular RTCP packets 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 mechanism is two-fold: 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
skipping to change at page 23, line 23 skipping to change at page 23, line 37
"rtcp-fb" attribute lines. "rtcp-fb" attribute lines.
When used in conjunction with the offer/answer model [9], 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. Both offerer and answerer MAY
independently decide to send RTCP FB messages of only a subset of
the negotiated feedback mechanisms; but they SHOULD react properly
to all types of the negotiated FB messages when received.
RTP senders MUST be prepared to receive any kind of RTCP FB RTP senders MUST be prepared to receive any kind of RTCP FB
messages and MUST silently discard all those RTCP FB messages that messages and MUST silently discard all those RTCP FB messages 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, fmt, 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
rtcp-fb-val = "ack" rtcp-fb-ack-param rtcp-fb-val = "ack" rtcp-fb-ack-param
/ "nack" rtcp-fb-nack-param / "nack" rtcp-fb-nack-param
/ "trr-int" SP 1*DIGIT / "trr-int" SP 1*DIGIT
/ rtcp-fb-id rtcp-fb-param / rtcp-fb-id rtcp-fb-param
rtcp-fb-id = 1*(alpha-numeric | "-" | "_") rtcp-fb-id = 1*(alpha-numeric | "-" | "_")
skipping to change at page 25, line 49 skipping to change at page 26, line 18
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) (how) 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 RTCP Bandwidth Modifiers
If a media session description indicates unicast addresses for a
particular media type (and does not operate in multi-unicast mode
with all recipients listed explicitly but still addressed via
unicast), the RTCP feedback MAY operate in ACK feedback mode.
If a media session description indicates multicast addresses for a
particular media type or a multi-unicast session, ACK feedback mode
MUST NOT be used.
4.4 RTCP Bandwidth Modifiers
The standard RTCP bandwidth assignments as defined in [1] and [2] The standard RTCP bandwidth assignments as defined in [1] and [2]
may be overridden by bandwidth modifiers that explicitly define the may be overridden by bandwidth modifiers that explicitly define the
maximum RTCP bandwidth. For use with SDP, such modifiers are maximum RTCP bandwidth. For use with SDP, such modifiers are
specified in [4]: "b=RS:<bw>" and "b=RR:<bw>" MAY be used to assign specified in [4]: "b=RS:<bw>" and "b=RR:<bw>" MAY be used to assign
a different bandwidth (measured in bits per second) to RTP senders a different bandwidth (measured in bits per second) to RTP senders
and receivers, respectively. The precedence rules of [4] apply to and receivers, respectively. The precedence rules of [4] apply to
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.4 Examples
Example 1: The following session description indicates a session Example 1: The following session description indicates a session
made up from audio and DTMF [18] 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
skipping to change at page 28, line 33 skipping to change at page 28, line 40
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 entities (senders and receivers)
If the dynamically calculated T_rr is sufficiently small (e.g.
less than one second), AVPF entities may accidentally time out
AVP group members and hence under-estimate the group size.
Therefore, if AVP entities may be involved in a media session,
T_rr_interval SHOULD be used and SHOULD be set to five seconds.
In conclusion, if AVP entities may be involved in a media
session and T_rr_interval is to be used, T_rr_interval SHOULD be
set to 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 Early RTCP feedback packets only if
packets only if all sending entities in the media session all sending entities in the media session support AVPF. AVPF
support AVPF. AVPF receivers MAY send feedback information as receivers MAY send feedback information as part of regularly
part of regularly scheduled compound RTCP packets following the scheduled compound RTCP packets following the timing rules of
timing rules of [1] and [2] also in media sessions operating in [1] and [2] also in media sessions operating in mixed mode.
mixed mode. However, the receiver providing feedback MUST NOT However, the receiver providing feedback MUST NOT rely on the
rely on the sender reacting to the feedback at all. 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 are classified into three categories as
follows: follows:
- Transport layer FB messages - Transport layer FB messages
- Payload-specific FB messages - Payload-specific FB messages
- Application layer FB messages - Application layer FB messages
Transport layer FB 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.
skipping to change at page 29, line 46 skipping to change at page 30, line 17
information. Hence, this document defines only a common header to information. Hence, this document defines only a common header to
be used along with all application layer FB messages. From a be used along with all application layer FB messages. From a
protocol point of view, an application layer FB message is treated protocol point of view, an application layer FB message is treated
as a special case of a payload-specific FB message. as a special case of a payload-specific FB message.
NOTE: Proper processing of some FB 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 FB message refers to. Most of the time, this knowledge the FB message refers to. Most of the time, this knowledge
can likely be derived from a media stream using only a single can likely be derived from a media stream using only 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 DTMF) 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 FB message. This applies conveyed explicitly as part of the FB message. This applies
to all payload-specific as well as application layer FB to all payload-specific as well as application layer FB
messages. It is up to the specification of a FB message to messages. It is up to the specification of a FB message to
define how payload type information is transmitted. define how payload type information is transmitted.
This document defines two transport layer and three (video) This document defines two transport layer and three (video)
payload-specific FB messages as well as a single container for payload-specific FB messages as well as a single container for
application layer FB messages. Additional transport layer and application layer FB messages. Additional transport layer and
payload specific FB messages MAY be defined in other documents and payload specific FB messages MAY be defined in other documents and
skipping to change at page 31, line 40 skipping to change at page 32, line 9
The following three sections define which additional The following three sections define which additional
information MAY be included in the FB message for each type of information MAY be included in the FB message for each type of
feedback: transport layer, payload-specific or application feedback: transport layer, payload-specific or application
layer feedback. Note that further FCI contents MAY be specified layer feedback. Note that further FCI contents MAY be specified
in further documents. in further documents.
Each RTCP feedback packet MUST contain at least one FB message in Each RTCP feedback packet MUST contain at least one FB message in
the FCI field. Sections 6.2 and 6.3 define for each FCI type, the FCI field. Sections 6.2 and 6.3 define for each FCI type,
whether or not multiple FB messages MAY be compressed into a single whether or not multiple FB messages MAY be compressed into a single
FCI field. If this is the case, they MUST be of the same type, FCI field. If this is the case, they MUST be of the same type,
i.e. same FMT.. If multiple types of feedback messages, i.e. i.e. same FMT. If multiple types of feedback messages, i.e.
several FMTs, need to be conveyed, then several RTCP FB messages several FMTs, need to be conveyed, then several RTCP FB messages
MUST be generated and SHOULD be concatenated in the same compound MUST be generated and SHOULD be concatenated in the same compound
RTCP packet. RTCP packet.
6.2 Transport Layer Feedback Messages 6.2 Transport Layer Feedback Messages
Transport Layer FB messages are identified by the value RTPFB as Transport Layer FB messages are identified by the value RTPFB as
RTCP message type. RTCP message type.
Two general purpose transport layer FB messages are defined so far: Two general purpose transport layer FB messages are defined so far:
General ACK and General NACK. They are identified by means of the General ACK and General NACK. They are identified by means 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 identifier number
space
The following two subsections define the formats of the FCI field The following two subsections define the formats of the FCI field
for these types of FB 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.
skipping to change at page 32, line 35 skipping to change at page 33, line 14
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP | | PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Syntax for the Generic NACK message Figure 4: Syntax for the Generic NACK message
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. The PID field
RTP sequence number is used for PID as the default format, but refers to the RTP sequence number of the lost packet.
RTP Payload Formats may decide to identify a packet
differently.
bitmask of following lost packets (BLP): 16 bits bitmask of following lost packets (BLP): 16 bits
The BLP allows for reporting losses of any of the 16 RTP 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 [6]. 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
skipping to change at page 33, line 41 skipping to change at page 34, line 18
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |R| BLP/#packets | | PID |R| BLP/#packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Syntax for the Generic ACK message Figure 5: Syntax for the Generic ACK message
Packet ID (1st PID): 16 bits Packet ID (1st PID): 16 bits
This PID field is used to specify a correctly received packet. This PID field is used to specify a correctly received packet.
Typically, the RTP sequence number is used for PID as the The PID field refers to the RTP sequence number of the lost
default format, but RTP Payload Formats may decide to identify packet.
a packet differently.
Range of ACKs (R): 1 bit Range of ACKs (R): 1 bit
The R-bit indicates that a range of consecutive packets are The R-bit indicates that a range of consecutive packets are
received correctly. If R=1 then the PID field specifies the received correctly. If R=1 then the PID field specifies the
first packet of that range and the next field (BLP/#packets) first packet of that range and the next field (BLP/#packets)
will carry the number of packets being acknowledged. If R=0 will carry the number of packets being acknowledged. If R=0
then PID specifies the first packet to be acknowledged and then PID specifies the first packet to be acknowledged and
BLP/#packets provides a bit mask to selectively indicate BLP/#packets provides a bit mask to selectively indicate
individual packets that are acknowledged. individual packets that are acknowledged.
skipping to change at page 35, line 7 skipping to change at page 35, line 29
RTCP message type. RTCP message type.
Three payload-specific FB messages are defined so far plus an Three payload-specific FB messages are defined so far plus an
application layer FB message. They are identified by means of the application layer FB message. They are identified by means 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: unassigned
15: Application layer FB 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 FCI formats for the payload- The following subsections define the FCI formats for the payload-
specific FB messages, section 6.4 defines FCI format for the specific FB messages, section 6.4 defines FCI format for the
application layer FB message. application layer FB message.
6.3.1 Picture Loss Indication (PLI) 6.3.1 Picture Loss Indication (PLI)
skipping to change at page 39, line 18 skipping to change at page 39, line 41
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
bit string is typically small -- a couple of dozen bits --, of bit string is typically small -- a couple of dozen bits --, of
variable length, and self-contained, i.e. contains all information variable length, and self-contained, i.e. contains all information
that is necessary to perform reference picture selection. that is necessary to perform reference picture selection.
Note that both MPEG-4 and H.263 allow the use of RPSI with positive Note that both MPEG-4 and H.263 allow the use of RPSI with positive
feedback information as well. That is, pictures (or Slices) are feedback information as well. That is, pictures (or Slices) are
reported that were decoded without error. Note that any form of reported that were decoded without error. Note that any form of
positive feedback MUST NOT be used when in a multicast environment positive feedback MUST NOT be used when in a multiparty session
(reporting positive feedback about individual reference pictures at (reporting positive feedback about individual reference pictures at
RTCP intervals is not expected to be of much use anyway). RTCP intervals is not expected to be of much use anyway).
6.3.3.2 Format 6.3.3.2 Format
The FCI for the RPSI message follows the format depicted in figure The FCI for the RPSI message follows the format depicted in figure
7: 7:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 41, line 38 skipping to change at page 42, line 21
a more timely fashion. a more timely fashion.
o The FB messages themselves may convey additional information as o The FB messages themselves may convey additional information as
input to congestion control algorithms and thus improve reaction input to congestion control algorithms and thus improve reaction
over conventional RTCP. (For example, ACK-based feedback may over conventional RTCP. (For example, ACK-based feedback may
even allow to construct closed loop algorithms and NACK-based even allow to construct closed loop algorithms and NACK-based
systems may provide further information on the packet loss systems may provide further information on the packet 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 [8], SHOULD be used fairly with competing TCP connections, e.g. TFRC [8], SHOULD be
to determine the data rate for the media stream (if the low delay used to determine the data rate for the media stream (if the low
RTP session is transmitted in a best effort environment). delay RTP session is transmitted in a best effort environment).
RTCP FB messages or RTCP SR/RR packets that indicate recent packet RTCP FB messages or RTCP SR/RR packets that indicate recent packet
loss MUST NOT lead to a (mid-term) increase in the transmission loss MUST NOT lead to a (mid-term) increase in the transmission
data rate and SHOULD lead to a (short-term) decrease of the data rate and SHOULD lead to a (short-term) decrease of the
transmission data rate. Such messages SHOULD cause the sender to transmission data rate. Such messages SHOULD cause the sender to
adjust the transmission data rate to the order of the throughput adjust the transmission data rate to the order of the throughput
TCP would achieve under similar conditions (e.g. using TFRC). TCP would achieve under similar conditions (e.g. using TFRC).
RTCP FB messages or RTCP SR/RR packets that indicate no recent RTCP FB messages or RTCP SR/RR packets that indicate no recent
packet loss MAY cause the sender to increase the transmission data packet loss MAY cause the sender to increase the transmission data
skipping to change at page 42, line 20 skipping to change at page 42, line 52
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 FB 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.) Similarly, malicious members may
send very large RTCP messages, thereby increasing the avg_rtcp_size
variable and reducing the effectively available RTCP bandwidth.
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
skipping to change at page 43, line 34 skipping to change at page 44, line 18
visual conferences with minimal control needs to be registered for visual conferences with minimal control needs to be registered for
the Session Description Protocol (specifically the type "proto"): the Session Description Protocol (specifically the type "proto"):
"RTP/AVPF". "RTP/AVPF".
SDP Protocol ("proto"): SDP Protocol ("proto"):
Name: RTP/AVPF Name: RTP/AVPF
Long form: Extended RTP Profile with RTCP-based Feedback Long form: Extended RTP Profile with RTCP-based Feedback
Type of name: proto Type of name: proto
Type of attribute: Media level only Type of attribute: Media level only
Purpose: See this document Purpose: RFC XXXX
Reference: This document Reference: RFC XXXX
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: rtcp-fb Attribute name: rtcp-fb
Long form: RTCP Feedback parameter Long form: RTCP Feedback parameter
Type of name: att-field Type of name: att-field
Type of attribute: Media level only Type of attribute: Media level only
Subject to charset: No Subject to charset: No
Purpose: See this document Purpose: RFC XXXX
Reference: This document Reference: RFC XXXX
Values: See this document and registrations below Values: See this document and registrations below
A new registry needs to be set up for the "rtcp-fb" attribute, with A new registry needs to be set up for the "rtcp-fb" attribute, with
the following registrations created initially: "ack", "nack", "trr- the following registrations created initially: "ack", "nack", "trr-
int", and "app" as defined in this document. int", and "app" as defined in this document.
Initial value registration for the attribute "rtcp-fb" Initial value registration for the attribute "rtcp-fb"
Value name: ack Value name: ack
Long name: Positive acknowledgement Long name: Positive acknowledgement
Reference: This document. Reference: RFC XXXX.
Value name: nack Value name: nack
Long name: Negative Acknowledgement Long name: Negative Acknowledgement
Reference: This document. Reference: RFC XXXX.
Value name: trr-int Value name: trr-int
Long name: Minimal receiver report interval Long name: Minimal receiver report interval
Reference: This document. Reference: RFC XXXX.
Value name: app Value name: app
Long name: Application-defined paramater Long name: Application-defined paramater
Reference: This document. Reference: RFC XXXX.
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:
Initial value registration for the attribute values "ack" and Initial value registration for the attribute values "ack" and
"nack": "nack":
Value name: sli Value name: sli
Long name: Slice Loss Indication Long name: Slice Loss Indication
Usable with: nack Usable with: nack
Reference: This document. Reference: RFC XXXX.
Value name: pli Value name: pli
Long name: Picture Loss Indication Long name: Picture Loss Indication
Usable with: nack Usable with: nack
Reference: This document. Reference: RFC XXXX.
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: RFC XXXX.
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: RFC XXXX.
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
skipping to change at page 45, line 28 skipping to change at page 46, line 12
Two RTCP Control Packet Types: for the class of transport layer FB Two RTCP Control Packet Types: for the class of transport layer FB
messages ("RTPFB") and for the class of payload-specific FB messages ("RTPFB") and for the class of payload-specific FB
messages ("PSFB"). Section 6 suggests RTPFB=205 and PSFB=206 to be messages ("PSFB"). Section 6 suggests RTPFB=205 and 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: RFC XXXX.
Name: PSFB Name: PSFB
Long name: Payload-specific Long name: Payload-specific
Value: 206 Value: 206
Reference: This document. Reference: RFC XXXX.
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. 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: RFC XXXX.
Name: Generic ACK Name: Generic ACK
Long name: Generic positive acknowledgement Long name: Generic positive acknowledgement
Value: 2 Value: 2
Reference: This document. Reference: RFC XXXX.
Name: Extension Name: Extension
Long name: Reserved for future extensions Long name: Reserved for future extensions
Value: 31 Value: 31
Reference: This document. Reference: RFC XXXX.
Within the PSFB range, the following five format (FMT) values are Within the PSFB range, the following five format (FMT) values are
initially registered: initially registered:
Name: PLI Name: PLI
Long name: Picture Loss Indication Long name: Picture Loss Indication
Value: 1 Value: 1
Reference: This document. Reference: RFC XXXX.
Name: SLI Name: SLI
Long name: Slice Loss Indication Long name: Slice Loss Indication
Value: 2 Value: 2
Reference: This document. Reference: RFC XXXX.
Name: RPSI Name: RPSI
Long name: Reference Picture Selection Indication Long name: Reference Picture Selection Indication
Value: 3 Value: 3
Reference: This document. Reference: RFC XXXX.
Name: AFB Name: AFB
Long name: Application Layer Feedback Long name: Application Layer Feedback
Value: 1 Value: 15
Reference: This document. Reference: RFC XXXX.
Name: Extension Name: Extension
Long name: Reserved for future extensions. Long name: Reserved for future extensions.
Value: 31 Value: 31
Reference: This document. Reference: RFC XXXX.
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 FB message to go into the FCI field, and whether or is a specific FB message to go into the FCI field, and whether or
not multiple FB messages may be stacked in a single FCI field. For not multiple FB messages may be stacked in a single FCI field. For
each new registration, it is mandatory that a permanent, stable, each new registration, it is mandatory that a permanent, stable,
and publicly accessible document exists that specifies the and publicly accessible document exists that specifies the
semantics of the registered parameter as well as the syntax and semantics of the registered parameter as well as the syntax and
semantics of the associated FB message (if any). The general semantics of the associated FB message (if any). The general
registration procedures of [3] apply. registration procedures of [3] apply.
NOTE TO THE RFC EDITOR: Please replace all occurrences of RFC XXXX by
the RFC number assigned to this document.
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 particularly thank Magnus Westerlund for his would also like to particularly thank Magnus Westerlund for his
review and his valuable suggestions, Shigeru Fukunaga for the review and his valuable suggestions, Shigeru Fukunaga for the
contributions on for FB message formats and semantics. contributions on for FB message formats and semantics.
skipping to change at page 48, line 24 skipping to change at page 49, line 4
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 rey@panasonic.de Mail rey@panasonic.de
12 Bibliography 12 Bibliography
12.1 Normative references 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-12.txt, Work in Progress, March
November 2001. 2003.
[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-13.txt, March 2003.
[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-11.txt, November 2002. new-12.txt, March 2003.
[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] S. Bradner, "Key words for use in RFCs to Indicate Requirement [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels," RFC 2119, March 1997. Levels," RFC 2119, March 1997.
[6] T. Turletti and C. Huitema, "RTP Payload Format for H.261 [6] T. Turletti and C. Huitema, "RTP Payload Format for H.261
Video Streams, RFC 2032, October 1996. Video Streams, RFC 2032, October 1996.
skipping to change at page 50, line 18 skipping to change at page 50, line 44
can be obtained from the IETF Secretariat. can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF this standard. Please address the information to the IETF
Executive Director. Executive Director.
14 Full Copyright Statement 14 Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works. paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the Society or other Internet organizations, except as needed for the
 End of changes. 

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