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 report 2 events
per second back to the sender. If acknowledgements 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 reported per second; thus,
the ACKs may be sent in a finer granularity (e.g., only combining
three ACKs per FB message).
From 1 Mbit/s upwards, a receiver would be able to acknowledge each
individual frame (not packet!) in a 30-fps video stream.
ACK strategies MUST be defined to work properly with these bandwidth
limitations. An indication whether or not ACKs are allowed for a
session and, if so, which ACK strategy should be used, MAY be
conveyed by out-of-band mechanisms, e.g., media-specific attributes
in a session description using SDP.
3.6.2. NACK Mode
Negative acknowledgements (and the other types of feedback exhibiting
similar reporting characteristics) MUST be used for all sessions with
a group size that may grow larger than two. Of course, NACKs MAY be
used for point-to-point communications as well.
Whether or not the use of Early RTCP packets should be considered
depends upon a number of parameters including session bandwidth,
codec, special type of feedback, and number of senders and receivers.
The most important parameters when determining the mode of operation
are the allowed minimal interval between two compound RTCP packets
(T_rr) and the average number of events that presumably need
reporting per time interval (plus their distribution over time, of
course). The minimum interval can be derived from the available RTCP
bandwidth and the expected average size of an RTCP packet. The
number of events to report (e.g., per second) may be derived from the
packet loss rate and sender’s rate of transmitting packets. From
these two values, the allowable group size for the Immediate Feedback
mode can be calculated.
As stated in Section 3.3:
Let N be the average number of events to be reported per interval
T by a receiver, B the RTCP bandwidth fraction for this particular
receiver, and R the average RTCP packet size, then the receiver
operates in Immediate Feedback mode as long as N<=B*T/R.
The upper bound for the Early RTCP mode then solely depends on the
acceptable quality degradation, i.e., how many events per time
interval may go unreported.
As stated in Section 3.3:
Using the above notation, Early RTCP mode can be roughly
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 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 to determine
whether or not early transmission of RTCP packets is useful.
Example: If a 256-kbit/s video with 30 fps is transmitted through a
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
30 packets per second. If 5% packet loss occurs in the network
(equally distributed, no inter-dependence between receivers), then
each receiver will, on average, have to report 3 packets lost each
two seconds. Assuming a single sender and more than three receivers,
this yields 3.75% of the RTCP bandwidth allocated to the receivers
and thus 9.6 kbit/s. Assuming further a size of 120 bytes for the
average compound RTCP packet allows 10 RTCP packets to be sent per
second or 20 in two seconds. If every receiver needs to report three
lost packets per two seconds, this yields a maximum group size of 6-7
receivers if all loss events are reported. The rules for
transmission of Early RTCP packets should provide sufficient
flexibility for most of this reporting to occur in a timely fashion.
Extending this example to determine the upper bound for Early RTCP
mode could lead to the following considerations: assume that the
underlying coding scheme and the application (as well as the tolerant
users) allow on the order of one loss without repair per two seconds.
Thus, the number of packets to be reported by each receiver decreases
to two per two seconds and increases the group size to 10. Assuming
further that some number of packet losses are correlated, feedback
traffic is further reduced and group sizes of some 12 to 16 (maybe
even 20) can be reasonably well supported using Early RTCP mode.
Note that all these considerations are based upon statistics and will
fail to hold in some cases.
3.7. Summary of Decision Steps
3.7.1. General Hints
Before even considering whether or not to send RTCP feedback
information, an application has to determine whether this mechanism
is applicable:
1) An application has to decide whether -- for the current ratio of
packet rate with the associated (application-specific) maximum
feedback delay and the currently observed round-trip time (if
available) -- feedback mechanisms can be applied at all.
This decision may be based upon (and dynamically revised
following) RTCP reception statistics as well as out-of-band
mechanisms.
2) The application has to decide -- for a certain observed error
rate, assigned bandwidth, frame/packet rate, and group size --
whether (and which) feedback mechanisms can be applied.
Regular RTCP reception statistics provide valuable input to this
step, too.
3) If the application decides to send feedback, the application has
to follow the rules for transmitting Early RTCP packets or Regular
RTCP packets containing FB messages.
4) The type of RTCP feedback sent should not duplicate information
available to the sender from a lower layer transport protocol.
That is, if the transport protocol provides negative or positive
acknowledgements about packet reception (such as DCCP), the
receiver should avoid repeating the same information at the RTCP
layer (i.e., abstain from sending Generic NACKs).
3.7.2. Media Session Attributes
Media sessions are typically described using out-of-band mechanisms
to convey transport addresses, codec information, etc., between
sender(s) and receiver(s). Such a mechanism is two-fold: a format
used to describe a media session and another mechanism for
transporting this description.
In the IETF, the Session Description Protocol (SDP) is currently used
to describe media sessions while protocols such as SIP, Session
Announcement Protocol (SAP), Real Time Streaming Protocol (RTSP), and
HTTP (among others) are used to convey the descriptions.
A media session description format MAY include parameters to indicate
that RTCP feedback mechanisms are supported in this session and which
of the feedback mechanisms MAY be applied.
To do so, the profile "AVPF" MUST be indicated instead of "AVP".
Further attributes may be defined to show which type(s) of feedback
are supported.
Section 4 contains the syntax specification to support RTCP feedback
with SDP. Similar specifications for other media session description
formats are outside the scope of this document.
4. SDP Definitions
This section defines a number of additional SDP parameters that are
used to describe a session. All of these are defined as media-level
attributes.
4.1. Profile Identification
The AV profile defined in [4] is referred to as "AVP" in the context
of, e.g., the Session Description Protocol (SDP) [3]. The profile
specified in this document is referred to as "AVPF".
Feedback information following the modified timing rules as specified
in this document MUST NOT be sent for a particular media session
unless the description for this session indicates the use of the
"AVPF" profile (exclusively or jointly with other AV profiles).
4.2. RTCP Feedback Capability Attribute
A new payload format-specific SDP attribute is defined to indicate
the capability of using RTCP feedback as specified in this document:
"a=rtcp-fb". The "rtcp-fb" attribute MUST only be used as an SDP
media attribute and MUST NOT be provided at the session level. The
"rtcp-fb" attribute MUST only be used in media sessions for which the
"AVPF" is specified.
The "rtcp-fb" attribute SHOULD be used to indicate which RTCP FB
messages MAY be used in this media session for the indicated payload
type. A wildcard payload type ("*") MAY be used to indicate that the
RTCP feedback attribute applies to all payload types. If several
types of feedback are supported and/or the same feedback shall be
specified for a subset of the payload types, several "a=rtcp-fb"
lines MUST be used.
If no "rtcp-fb" attribute is specified, the RTP receivers MAY send
feedback using other suitable RTCP feedback packets as defined for
the respective media type. The RTP receivers MUST NOT rely on the
RTP senders reacting to any of the FB messages. The RTP sender MAY
choose to ignore some feedback messages.
If one or more "rtcp-fb" attributes are present in a media session
description, the RTCP receivers for the media session(s) containing
the "rtcp-fb"
o MUST ignore all "rtcp-fb" attributes of which they do not fully
understand the semantics (i.e., where they do not understand the
meaning of all values in the "a=rtcp-fb" line);
o SHOULD provide feedback information as specified in this document
using any of the RTCP feedback packets as specified in one of the
"rtcp-fb" attributes for this media session; and
o MUST NOT use other FB messages than those listed in one of the
"rtcp-fb" attribute lines.
When used in conjunction with the offer/answer model [8], the offerer
MAY present a set of these AVPF attributes to its peer. The answerer
MUST remove all attributes it does not understand as well as those it
does not support in general or does not wish to use in this
particular media session. The answerer MUST NOT add feedback
parameters to the media description and MUST NOT alter values of such
parameters. The answer is binding for the media session, and both
offerer and answerer MUST only use feedback mechanisms negotiated in
this way. 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 messages
and MUST silently discard all those RTCP FB messages that they do not
understand.
The syntax of the "rtcp-fb" attribute is as follows (the feedback
types and optional parameters are all case sensitive):
(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-pt = "*" ; wildcard: applies to all formats
/ fmt ; as defined in SDP spec
rtcp-fb-val = "ack" rtcp-fb-ack-param
/ "nack" rtcp-fb-nack-param
/ "trr-int" SP 1*DIGIT
/ rtcp-fb-id rtcp-fb-param
rtcp-fb-id = 1*(alpha-numeric / "-" / "_")
rtcp-fb-param = SP "app" [SP byte-string]
/ SP token [SP byte-string]
/ ; empty
rtcp-fb-ack-param = SP "rpsi"
/ SP "app" [SP byte-string]
/ SP token [SP byte-string]
/ ; empty
rtcp-fb-nack-param = SP "pli"
/ SP "sli"
/ SP "rpsi"
/ SP "app" [SP byte-string]
/ SP token [SP byte-string]
/ ; empty
The literals of the above grammar have the following semantics:
Feedback type "ack":
This feedback type indicates that positive acknowledgements for
feedback are supported.
The feedback type "ack" MUST only be used if the media session is
allowed to operate in ACK mode as defined in Section 3.6.1.
Parameters MUST be provided to further distinguish different types
of positive acknowledgement feedback.
The parameter "rpsi" indicates the use of Reference Picture
Selection Indication feedback as defined in Section 6.3.3.
If the parameter "app" is specified, this indicates the use of
application layer feedback. In this case, additional parameters
following "app" MAY be used to further differentiate various types
of application layer feedback. This document does not define any
parameters specific to "app".
Further parameters for "ack" MAY be defined in other documents.
Feedback type "nack":
This feedback type indicates that negative acknowledgements for
feedback are supported.
The feedback type "nack", without parameters, indicates use of the
Generic NACK feedback format as defined in Section 6.2.1.
The following three parameters are defined in this document for
use with "nack" in conjunction with the media type "video":
o "pli" indicates the use of Picture Loss Indication feedback as
defined in Section 6.3.1.
o "sli" indicates the use of Slice Loss Indication feedback as
defined in Section 6.3.2.
o "rpsi" indicates the use of Reference Picture Selection
Indication feedback as defined in Section 6.3.3.
"app" indicates the use of application layer feedback. Additional
parameters after "app" MAY be provided to differentiate different
types of application layer feedback. No parameters specific to
"app" are defined in this document.
Further parameters for "nack" MAY be defined in other documents.
Other feedback types <rtcp-fb-id>:
Other documents MAY define additional types of feedback; to keep
the grammar extensible for those cases, the rtcp-fb-id is
introduced as a placeholder. A new feedback scheme name MUST to
be unique (and thus MUST be registered with IANA). Along with a
new name, its semantics, packet formats (if necessary), and rules
for its operation MUST be specified.
Regular RTCP minimum interval "trr-int":
The attribute "trr-int" is used to specify the minimum interval
T_rr_interval between two Regular (full compound) RTCP packets in
milliseconds for this media session. If "trr-int" is not
specified, a default value of 0 is assumed.
Note that it is assumed that more specific information about
application layer feedback (as defined in Section 6.4) will be
conveyed as feedback types and parameters defined elsewhere. Hence,
no further provision for any types and parameters is made in this
document.
Further types of feedback as well as further parameters may be
defined in other documents.
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
provided.
4.3. RTCP Bandwidth Modifiers
The standard RTCP bandwidth assignments as defined in [1] and [2] MAY
be overridden by bandwidth modifiers that explicitly define the
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 a
different bandwidth (measured in bits per second) to RTP senders and
receivers, respectively. The precedence rules of [4] apply to
determine the actual bandwidth to be used by senders and receivers.
Applications operating knowingly over highly asymmetric links (such
as satellite links) SHOULD use this mechanism to reduce the feedback
rate for high bandwidth streams to prevent deterministic congestion
of the feedback path(s).
4.4. Examples
Example 1: The following session description indicates a session made
up from audio and DTMF [18] for point-to-point communication in which
the DTMF stream uses Generic NACKs. This session description could
be contained in a SIP INVITE, 200 OK, or ACK message to indicate that
its sender is capable of and willing to receive feedback for the DTMF
stream it transmits.
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/AVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
This allows sender and receiver to provide reliable transmission of
DTMF events in an audio session. Assuming a 64-kbit/s audio stream
with one receiver, the receiver has 2.5% RTCP bandwidth available for
the negative acknowledgement stream, i.e., 250 bytes per second or
some 2 RTCP feedback messages every second. Hence, the receiver can
individually communicate up to two missing DTMF audio packets per
second.
Example 2: The following session description indicates a multicast
video-only session (using either H.261 or H.263+) with the video
source accepting Generic NACKs for both codecs and Reference Picture
Selection for H.263. Such a description may have been conveyed using
the Session Announcement Protocol (SAP).
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
m=audio 49170 RTP/AVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi
The sender may use an incoming Generic NACK as a hint to send a new
intra-frame as soon as possible (congestion control permitting).
Receipt of a Reference Picture Selection Indication (RPSI) message
allows the sender to avoid sending a large intra-frame; instead it
may continue to send inter-frames, however, choosing the indicated
frame as new encoding reference.
Example 3: The following session description defines the same media
session as example 2 but allows for mixed-mode operation of AVP and
AVPF RTP entities (see also next section). Note that both media
descriptions use the same addresses; however, two m= lines are needed
to convey information about both applicable RTP profiles.
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
m=audio 49170 RTP/AVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
m=video 51372 RTP/AVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi
Note that these two m= lines SHOULD be grouped by some appropriate
mechanism to indicate that both are alternatives actually conveying
the same contents. A sample framework by which this can be
achieved is defined in [10].
In this example, the RTCP feedback-enabled receivers will gain an
occasional advantage to report events earlier back to the sender
(which may benefit the entire group). On average, however, all RTP
receivers will provide the same amount of feedback. The
interworking between AVP and AVPF entities is discussed in depth in
the next section.
5. Interworking and Coexistence of AVP and AVPF Entities
The AVPF profile defined in this document is an extension of the
AVP profile as defined in [2]. Both profiles follow the same basic
rules (including the upper bandwidth limit for RTCP and the
bandwidth assignments to senders and receivers). Therefore,
senders and receivers using either of the two profiles can be
mixed in a single session (see Example 3 in Section 4.5).
AVP and AVPF are defined in a way that, from a robustness point of
view, the RTP entities do not need to be aware of entities of the
respective other profile: they will not disturb each other’s
functioning. However, the quality of the media presented may
suffer.
The following considerations apply to senders and receivers when
used in a combined session.
o AVP entities (senders and receivers)
AVP senders will receive RTCP feedback packets from AVPF
receivers and ignore these packets. They will see occasional
closer spacing of RTCP messages (e.g., violating the five-second
rule) by AVPF entities. As the overall bandwidth constraints
are adhered to by both types of entities, they will still get
their share of the RTCP bandwidth. However, while AVP entities
are bound by the five-second rule, depending on the group size
and session bandwidth, AVPF entities may provide more frequent
RTCP reports than AVP ones will. Also, the overall reporting
may decrease slightly as AVPF entities may send bigger compound
RTCP packets (due to the extra RTCP packets).
If T_rr_interval is used as lower bound between Regular RTCP
packets, T_rr_interval is sufficiently large (e.g., T_rr_interval
> M*Td as per Section 6.3.5 of [1]), and no Early RTCP packets
are sent by AVPF entities, AVP entities may accidentally time
out those AVPF group members and hence underestimate the group
size. Therefore, if AVP entities may be involved in a media
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 underestimate 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
AVPF senders will receive feedback information only from AVPF
receivers. If they rely on feedback to provide the target media
quality, the quality achieved for AVP receivers may be suboptimal.
o AVPF receivers
AVPF receivers SHOULD send Early RTCP feedback packets only if
all sending entities in the media session support AVPF. AVPF
receivers MAY send feedback information as part of regularly
scheduled compound RTCP packets following the timing rules of
[1] and [2] also in media sessions operating in mixed mode.
However, the receiver providing feedback MUST NOT rely on the
sender reacting to the feedback at all.
6. Format of RTCP Feedback Messages
This section defines the format of the low-delay RTCP feedback
messages. These messages are classified into three categories as
follows:
- Transport layer FB messages
- Payload-specific FB messages
- Application layer FB messages
Transport layer FB messages are intended to transmit general purpose