Internet Engineering Task Force (IETF) J. Ott
Request for Comments: 5760 Aalto University
Category: Standards Track J. Chesterfield
ISSN: 2070-1721 University of Cambridge
February 2010 RTP Control Protocol (RTCP) Extensions for
Single-Source Multicast Sessions with Unicast Feedback
This document specifies an extension to the Real-time Transport
Control Protocol (RTCP) to use unicast feedback to a multicast
sender. The proposed extension is useful for single-source multicast
sessions such as Source-Specific Multicast (SSM) communication where
the traditional model of many-to-many group communication is either
not available or not desired. In addition, it can be applied to any
group that might benefit from a sender-controlled summarized
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
Table of Contents
1. Introduction ....................................................32. Conventions and Acronyms ........................................43. Definitions .....................................................54. Basic Operation .................................................65. Packet Types ...................................................106. Simple Feedback Model ..........................................117. Distribution Source Feedback Summary Model .....................138. Mixer/Translator Issues ........................................369. Transmission Interval Calculation ..............................3710. SDP Extensions ................................................3911. Security Considerations .......................................4112. Backwards Compatibility .......................................5113. IANA Considerations ...........................................5114. References ....................................................53
Appendix A. Examples for Sender-Side Configurations ...............57
Appendix B. Distribution Report Processing at the Receiver ........60
The Real-time Transport Protocol (RTP)  provides a real-time
transport mechanism suitable for unicast or multicast communication
between multimedia applications. Typical uses of RTP are for real-
time or near real-time group communication of audio and video data
streams. An important component of the RTP protocol is the control
channel, defined as the RTP Control Protocol (RTCP). RTCP involves
the periodic transmission of control packets between group members,
enabling group size estimation and the distribution and calculation
of session-specific information such as packet loss and round-trip
time to other hosts. An additional advantage of providing a control
channel for a session is that a third-party session monitor can
listen to the traffic to establish network conditions and to diagnose
faults based on receiver locations.
RTP was designed to operate in either a unicast or multicast mode.
In multicast mode, it assumes an Any Source Multicast (ASM) group
model, where both one-to-many and many-to-many communication are
supported via a common group address in the range 220.127.116.11 through
18.104.22.168. To enable Internet-wide multicast communication,
intra-domain routing protocols (those that operate only within a
single administrative domain, e.g., the Distance Vector Multicast
Routing Protocol (DVMRP)  and Protocol Independent Multicast
(PIM) ) are used in combination with inter-domain routing
protocols (those that operate across administrative domain borders,
e.g., Multicast BGP (MBGP)  and the Multicast Source Discovery
Protocol (MSDP) ). Such routing protocols enable a host to join
a single multicast group address and send data to or receive data
from all members in the group with no prior knowledge of the
membership. However, there is a great deal of complexity involved at
the routing level to support such a multicast service in the network.
Many-to-many communication is not always available or desired by all
group applications. For example, with Source-Specific Multicast
(SSM)  and satellite communication, the multicast distribution
channel only supports source-to-receiver traffic. In other cases,
such as large ASM groups with a single active data source and many
passive receivers, it is sub-optimal to create a full routing-level
mesh of multicast sources just for the distribution of RTCP control
packets. Thus, an alternative solution is preferable.
Although a one-to-many multicast topology may simplify routing and
may be a closer approximation to the requirements of certain RTP
applications, unidirectional communication makes it impossible for
receivers in the group to share RTCP feedback information with other
group members. In this document, we specify a solution to that
problem. We introduce unicast feedback as a new method to distribute
RTCP control information amongst all session members. This method is
designed to operate under any group communication model, ASM or SSM.
The RTP data stream protocol itself is unaltered.
Scenarios under which the unicast feedback method can provide benefit
include but are not limited to:
a) SSM groups with a single sender.
The proposed extensions allow SSM groups that do not have many-to-
many communication capability to receive RTP data streams and to
continue to participate in the RTP control protocol (RTCP) by
using multicast in the source-to-receiver direction and unicast to
send receiver feedback to the source on the standard RTCP port.
b) One-to-many broadcast networks.
Unicast feedback may also be beneficial to one-to-many broadcast
networks, such as a satellite network with a terrestrial low-
bandwidth return channel or a broadband cable link. Unlike the
SSM network, these networks may have the ability for a receiver to
multicast return data to the group. However, a unicast feedback
mechanism may be preferable for routing simplicity.
c) ASM with a single sender.
A unicast feedback approach can be used by an ASM application with
a single sender to reduce the load on the multicast routing
infrastructure that does not scale as efficiently as unicast
routing does. Because this is no more efficient than a standard
multicast group RTP communication scenario, it is not expected to
replace the traditional mechanism.
The modifications proposed in this document are intended to
supplement the existing RTCP feedback mechanisms described in Section
6 of .
2. Conventions and Acronyms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 .
The following acronyms are used throughout this document:
ASM Any Source Multicast
SSM Source-Specific Multicast
In an SSM context, only one entity distributes RTP data and
redistributes RTCP information to all receivers. This entity is
called the Distribution Source. It is also responsible for
forwarding RTCP feedback to the Media Senders and thus creates a
virtual multicast environment in which RTP and RTCP can be
Note that heterogeneous networks consisting of ASM multiple-sender
groups, unicast-only clients, and/or SSM single-sender receiver
groups MAY be connected via translators or mixers to create a
single-source group (see Section 8 for details).
A Media Sender is an entity that originates RTP packets for a
particular media session. In RFC 3550, a Media Sender is simply
called a source. However, as the RTCP SSM system architecture
includes a Distribution Source, to avoid confusion, in this
document a media source is commonly referred to as a Media Sender.
There may often be a single Media Sender that is co-located with
the Distribution Source. But although there MUST be only one
Distribution Source, there MAY be multiple Media Senders on whose
behalf the Distribution Source forwards RTP and RTCP packets.
RTP and RTCP Channels:
The data distributed from the source to the receivers is referred
to as the RTP channel and the control information as the RTCP
channel. With standard RTP/RTCP, these channels typically share
the same multicast address but are differentiated via port numbers
as specified in . In an SSM context, the RTP channel is
multicast from the Distribution Source to the receivers. In
contrast, the RTCP or feedback channel is actually the collection
of unicast channels between the receivers and the Distribution
Source via the Feedback Target(s). Thus, bidirectional
communication is accomplished by using SSM in the direction from
Distribution Source to the receivers and using the unicast
feedback channel in the direction from receivers to Distribution
Source. As discussed in the next section, the nature of the
channels between the Distribution Source and the Media Sender(s)
(Unicast RTCP) Feedback Target:
The Feedback Target is a logical function to which RTCP unicast
feedback traffic is addressed. The functions of the Feedback
Target and the Distribution Source MAY be co-located or integrated
in the same entity. In this case, for a session defined as having
a Distribution Source A, on ports n for the RTP channel and k for
the RTCP channel, the unicast RTCP Feedback Target is identified
by an IP address of Distribution Source A on port k, unless
otherwise stated in the session description. See Section 10 for
details on how the address is specified. The Feedback Target MAY
also be implemented in one or more entities different from the
Distribution Source, and different RTP receivers MAY use different
Feedback Target instances, e.g., for aggregation purposes. In
this case, the Feedback Target instance(s) MUST convey the
feedback received from the RTP receivers to the Distribution
Source using the RTCP mechanisms specified in this document. If
disjoint, the Feedback Target instances MAY be organized in
arbitrary topological structures: in parallel, hierarchical, or
chained. But the Feedback Target instance(s) and Distribution
Source MUST share, e.g., through configuration, enough information
to be able to provide coherent RTCP information to the RTP
receivers based upon the RTCP feedback collected by the Feedback
Target instance(s) -- as would be done if both functions were part
of the same entity.
In order for unicast feedback to work, each receiver MUST direct
its RTCP reports to a single specific Feedback Target instance.
Synchronization source as defined in . This 32-bit value
uniquely identifies each member in a session.
Report block is the standard terminology for an RTCP reception
report. RTCP  encourages the stacking of multiple report
blocks in Sender Report (SR) and Receiver Report (RR) packets. As
a result, a variable-size feedback packet may be created by one
source that reports on multiple other sources in the group. The
summarized reporting scheme builds upon this model through the
inclusion of multiple summary report blocks in one packet.
However, stacking of reports from multiple receivers is not
permitted in the Simple Feedback Model (see Section 6).
4. Basic Operation
As indicated by the definitions of the preceding section, one or more
Media Senders send RTP packets to the Distribution Source. The
Distribution Source relays the RTP packets to the receivers using a
source-specific multicast arrangement. In the reverse direction, the
receivers transmit RTCP packets via unicast to one or more instances
of the Feedback Target. The Feedback Target sends either the
original RTCP reports (the Simple Feedback Model) or summaries of
these reports (the Summary Feedback Model) to the Distribution
Source. The Distribution Source in turn relays the RTCP reports
and/or summaries to the Media Senders. The Distribution Source also
transmits the RTCP Sender Reports and Receiver Reports or summaries
back to the receivers, using source-specific multicast.
When the Feedback Target(s) are co-located (or integrated) with the
Distribution Source, redistribution of original or summarized RTCP
reports is trivial. When the Feedback Target(s) are physically
and/or topologically distinct from the Distribution Source, each
Feedback Target either relays the RTCP packets to the Distribution
Source or summarizes the reports and forwards an RTCP summary report
to the Distribution Source. Coordination between multiple Feedback
Targets is beyond the scope of this specification.
The Distribution Source MUST be able to communicate with all group
members in order for either mechanism to work. The general
architecture is displayed below in Figure 1. There may be a single
Media Sender or multiple Media Senders (Media Sender i, 1<=i<=M) on
whose behalf the Distribution Source disseminates RTP and RTCP
packets. The base case, which is expected to be the most common
case, is that the Distribution Source is co-located with a particular
Media Sender. A basic assumption is that communication is multicast
(either SSM or ASM) in the direction of the Distribution Source to
the receivers (R(j), 1<=j<=N) and unicast in the direction of the
receivers to the Distribution Source.
Communication between Media Sender(s) and the Distribution Source may
be performed in numerous ways:
i. Unicast only: The Media Sender(s) MAY send RTP and RTCP via
unicast to the Distribution Source and receive RTCP via unicast.
ii. Any Source Multicast (ASM): The Media Sender(s) and the
Distribution Source MAY be in the same ASM group, and RTP and
RTCP packets are exchanged via multicast.
iii. Source-Specific Multicast (SSM): The Media Sender(s) and the
Distribution Source MAY be in an SSM group with the source being
the Distribution Source. RTP and RTCP packets from the Media
Senders are sent via unicast to the Distribution Source, while
RTCP packets from the Distribution Source are sent via multicast
to the Media Senders.
Note that this SSM group MAY be identical to the SSM group used
for RTP/RTCP delivery from the Distribution Source to the
receivers or it MAY be a different one.
Note that Figure 1 below shows a logical diagram and, therefore, no
details about the above options for the communication between Media
Sender(s), Distribution Source, Feedback Target(s), and receivers are
Configuration information needs to be supplied so that (among other
o Media Sender(s) know the transport address of the Distribution
Source or the transport address of the (ASM or SSM) multicast
group used for the contribution link;
o the Distribution Source knows either the unicast transport
address(es) or the (ASM or SSM) multicast transport address(es) to
reach the Media Sender(s);
o receivers know the addresses of their respectively responsible
Feedback Targets; and
o the Feedback Targets know the transport address of the
The precise setup and configuration of the Media Senders and their
interaction with the Distribution Source is beyond the scope of this
document (appropriate Session Description Protocol (SDP) descriptions
MAY be used for this purpose), which only specifies how the various
components interact within an RTP session. Informative examples for
different configurations of the Media Sources and the Distribution
Source are given in Appendix A.
Future specifications may be defined to address these aspects.
+--------+ +-----+ Multicast
|Media | | | +----------------> R(1)
|Sender 1|<----->| D S | | |
+--------+ | I O | +--+ |
| S U | | | |
+--------+ | T R | | +-----------> R(2) |
|Media |<----->| R C |->+ +---- : | |
|Sender 2| | I E | | +------> R(n-1) | |
+--------+ | B | | | | | |
: | U | +--+--> R(n) | | |
: | T +-| | | | |
| I | |<---------+ | | |
+--------+ | O |F|<---------------+ | |
|Media | | N |T|<--------------------+ |
|Sender M|<----->| | |<-------------------------+
+--------+ +-----+ Unicast
FT = Feedback Target
Transport from the Feedback Target to the Distribution
Source is via unicast or multicast RTCP if they are not
Figure 1: System Architecture
The first method proposed to support unicast RTCP feedback, the
'Simple Feedback Model', is a basic reflection mechanism whereby all
Receiver RTCP packets are unicast to the Feedback Target, which
relays them unmodified to the Distribution Source. Subsequently,
these packets are forwarded by the Distribution Source to all
receivers on the multicast RTCP channel. The advantage of using this
method is that an existing receiver implementation requires little
modification in order to use it. Instead of sending reports to a
multicast address, a receiver uses a unicast address yet still
receives forwarded RTCP traffic on the multicast control channel.
This method also has the advantage of being backwards compatible with
standard RTP/RTCP implementations. The Simple Feedback Model is
specified in Section 6.
The second method, the 'Distribution Source Feedback Summary Model',
is a summarized reporting scheme that provides savings in bandwidth
by consolidating Receiver Reports at the Distribution Source,
optionally with help from the Feedback Target(s), into summary
packets that are then distributed to all the receivers. The
Distribution Source Feedback Summary Model is specified in Section 7.
The advantage of the latter scheme is apparent for large group
sessions where the basic reflection mechanism outlined above
generates a large amount of packet forwarding when it replicates all
the information to all the receivers. Clearly, this technique
requires that all session members understand the new summarized
packet format outlined in Section 7.1. Additionally, the summarized
scheme provides an optional mechanism to send distribution
information or histograms about the feedback data reported by the
whole group. Potential uses for the compilation of distribution
information are addressed in Section 7.4.
To differentiate between the two reporting methods, a new SDP
identifier is created and discussed in Section 10. The reporting
method MUST be decided prior to the start of the session. A
Distribution Source MUST NOT change the method during a session.
In a session using SSM, the network SHOULD prevent any multicast data
from the receiver being distributed further than the first hop
router. Additionally, any data heard from a non-unicast-capable
receiver by other hosts on the same subnet SHOULD be filtered out by
the host IP stack so that it does not cause problems with respect to
the calculation of the receiver RTCP bandwidth share.
5. Packet Types
The RTCP packet types defined in , , and  are:
Type Description Payload number
SR Sender Report 200
RR Receiver Report 201
SDES Source Description 202
BYE Goodbye 203
APP Application-Defined 204
RTPFB Generic RTP feedback 205
PSFB Payload-specific feedback 206
XR RTCP Extension 207
This document defines one further RTCP packet format:
Type Description Payload number
RSI Receiver Summary Information 209
Within the Receiver Summary Information packet, there are various
types of information that may be reported and encapsulated in
optional sub-report blocks:
Name Long Name Value
IPv4 Address IPv4 Feedback Target Address 0
IPv6 Address IPv6 Feedback Target Address 1
DNS Name DNS name indicating Feedback Target Address 2
Reserved Reserved for Assignment by Standards Action 3
Loss Loss distribution 4
Jitter Jitter distribution 5
RTT Round-trip time distribution 6
Cumulative loss Cumulative loss distribution 7
Collisions SSRC collision list 8
Reserved Reserved for Assignment by Standards Action 9
Stats General statistics 10
RTCP BW RTCP bandwidth indication 11
Group Info RTCP group and average packet size 12
- Unassigned 13 - 255
As with standard RTP/RTCP, the various reports MAY be combined into a
single RTCP packet, which SHOULD NOT exceed the path MTU. Packets
continue to be sent at a rate that is inversely proportional to the
group size in order to scale the amount of traffic generated.
6. Simple Feedback Model
6.1. Packet Formats
The Simple Feedback Model uses the same packet types as traditional
RTCP feedback described in . Receivers still generate Receiver
Reports with information on the quality of the stream received from
the Distribution Source. The Distribution Source still MUST create
Sender Reports that include timestamp information for stream
synchronization and round-trip time calculation. Both Media Senders
and receivers are required to send SDES packets as outlined in .
The rules for generating BYE and APP packets as outlined in  also
6.2. Distribution Source Behavior
For the Simple Feedback Model, the Distribution Source MUST provide a
basic packet-reflection mechanism. It is the default behavior for
any Distribution Source and is the minimum requirement for acting as
a Distribution Source to a group of receivers using unicast RTCP
The Distribution Source (unicast Feedback Target) MUST listen for
unicast RTCP data sent to the RTCP port. All valid unicast RTCP
packets received on this port MUST be forwarded by the Distribution
Source to the group on the multicast RTCP channel. The Distribution
Source MUST NOT stack report blocks received from different receivers
into one packet for retransmission to the group. Every RTCP packet
from each receiver MUST be reflected individually.
If the Media Sender(s) are not part of the SSM group for RTCP packet
reflection, the Distribution Source MUST also forward the RTCP
packets received from the receivers to the Media Sender(s). If there
is more than one Media Sender and these Media Senders do not
communicate via ASM with the Distribution Source and each other, the
Distribution Source MUST forward each RTCP packet originated by one
Media Sender to all other Media Senders.
The Distribution Source MUST forward RTCP packets originating from
the Media Sender(s) to the receivers.
The reflected or forwarded RTCP traffic SHOULD NOT be counted as its
own traffic in the transmission interval calculation by the
Distribution Source. In other words, the Distribution Source SHOULD
NOT consider reflected packets as part of its own control data
bandwidth allowance. However, reflected packets MUST be processed by
the Distribution Source and the average RTCP packet size, RTCP
transmission rate, and RTCP statistics MUST be calculated. The
algorithm for computing the allowance is explained in Section 9.
6.3. Disjoint Distribution Source and Feedback Target(s)
If the Feedback Target function is disjoint from the Distribution
Source, the Feedback Target(s) MUST forward all RTCP packets from the
receivers or another Feedback Target -- directly or indirectly -- to
the Distribution Source.
6.4. Receiver Behavior
Receivers MUST listen on the RTP channel for data and on the RTCP
channel for control. Each receiver MUST calculate its share of the
control bandwidth R/n, in accordance with the profile in use, so that
a fraction of the RTCP bandwidth, R, allocated to receivers is
divided equally between the number of unique receiver SSRCs in the
session, n. R may be rtcp_bw * 0.75 or rtcp_bw * 0.5 (depending on
the ratio of senders to receivers as per ) or may be set
explicitly by means of an SDP attribute . See Section 9 for
further information on the calculation of the bandwidth allowance.
When a receiver is eligible to transmit, it MUST send a unicast
Receiver Report packet to the Feedback Target following the rules
defined in Section 9.
When a receiver observes either RTP packets or RTCP Sender Reports
from a Media Sender with an SSRC that collides with its own chosen
SSRC, it MUST change its own SSRC following the procedures of .
The receiver MUST do so immediately after noticing and before sending
any (further) RTCP feedback messages.
If a receiver has out-of-band information available about the Media
Sender SSRC(s) used in the media session, it MUST NOT use the same
SSRC for itself. Even if such out-of-band information is available,
a receiver MUST obey the above collision-resolution mechanisms.
Further mechanisms defined in  apply for resolving SSRC collisions
6.5. Media Sender Behavior
Media Senders listen on a unicast or multicast transport address for
RTCP reports sent by the receivers (and forwarded by the Distribution
Source) or other Media Senders (forwarded by the Distribution Source
if needed). Processing and general operation follows .
A Media Sender that observes an SSRC collision with another entity
that is not also a Media Sender MAY delay its own collision-
resolution actions as per , by 5 * 1.5 * Td, with Td being the
deterministic calculated reporting interval, for receivers to see
whether the conflict still exists. SSRC collisions with other Media
Senders MUST be acted upon immediately.
Note: This gives precedence to Media Senders and places the burden
of collision resolution on the RTP receivers.
Sender SSRC information MAY be communicated out-of-band, e.g., by
means of SDP media descriptions. Therefore, senders SHOULD NOT
change their own SSRC aggressively or unnecessarily.