tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5760

Proposed STD
Pages: 66
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: AVT

RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback

Part 1 of 3, p. 1 to 13
None       Next RFC Part

Updated by:    6128

Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                            J. Ott
Request for Comments: 5760                              Aalto University
Category: Standards Track                                J. Chesterfield
ISSN: 2070-1721                                  University of Cambridge
                                                             E. Schooler
                                                           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
   reporting mechanism.

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 Notice

   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
   ( 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

Page 2 
   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
   than English.

Table of Contents

   1. Introduction ....................................................3
   2. Conventions and Acronyms ........................................4
   3. Definitions .....................................................5
   4. Basic Operation .................................................6
   5. Packet Types ...................................................10
   6. Simple Feedback Model ..........................................11
   7. Distribution Source Feedback Summary Model .....................13
   8. Mixer/Translator Issues ........................................36
   9. Transmission Interval Calculation ..............................37
   10. SDP Extensions ................................................39
   11. Security Considerations .......................................41
   12. Backwards Compatibility .......................................51
   13. IANA Considerations ...........................................51
   14. References ....................................................53
   Appendix A. Examples for Sender-Side Configurations ...............57
   Appendix B. Distribution Report Processing at the Receiver ........60

Top      ToC       Page 3 
1.  Introduction

   The Real-time Transport Protocol (RTP) [1] 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 through  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) [16] and Protocol Independent Multicast
   (PIM) [17][18]) are used in combination with inter-domain routing
   protocols (those that operate across administrative domain borders,
   e.g., Multicast BGP (MBGP) [19] and the Multicast Source Discovery
   Protocol (MSDP) [20]).  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) [8][9] 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

Top      ToC       Page 4 
   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 [1].

2.  Conventions and Acronyms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [13].

   The following acronyms are used throughout this document:

      ASM  Any Source Multicast
      SSM  Source-Specific Multicast

Top      ToC       Page 5 
3.  Definitions

   Distribution Source:
      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).

   Media Sender:
      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 [1].  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)
      may vary.

   (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

Top      ToC       Page 6 
      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 [1].  This 32-bit value
      uniquely identifies each member in a session.

   Report blocks:
      Report block is the standard terminology for an RTCP reception
      report.  RTCP [1] 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

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
   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
      Distribution Source.

   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.

Top      ToC       Page 9 
         +--------+       +-----+          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.

Top      ToC       Page 10 
   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 [1], [26], and [15] 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:

Top      ToC       Page 11 
   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 [1].  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 [1].
   The rules for generating BYE and APP packets as outlined in [1] 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

Top      ToC       Page 12 
   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 [1]) or may be set
   explicitly by means of an SDP attribute [10].  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.

Top      ToC       Page 13 
   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 [1].
   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 [1] apply for resolving SSRC collisions
   between receivers.

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 [1].

   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 [1], 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.

(page 13 continued on part 2)

Next RFC Part