Internet Draft                                                  J. Ott
draft-ietf-avt-rtcpssm-17            Helsinki University of Technology
AVT Working Group                                      J. Chesterfield
Intended Status: Proposed Standard             University of Cambridge
                                                           E. Schooler
                                                                 Intel
Expires: July 2008                                      7 January 2008


            RTCP Extensions for Single-Source Multicast Sessions
                            with Unicast Feedback


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as work in progress.

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   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.








Ott et al.       Internet Draft - Expires July 2008          [Page 1]


                      RTCP with Unicast Feedback


Table of Contents

   1. Conventions and Acronyms........................................2
   2. Introduction....................................................2
   3. Definitions.....................................................4
   4. Basic Operation.................................................6
   5. Packet types....................................................9
   6. Simple Feedback Model..........................................10
   7. Distribution Source Feedback Summary Model.....................12
   8. Mixer/Translator issues........................................32
   9. Transmission interval calculation..............................33
   10. SDP Extensions................................................35
   11. Security Considerations.......................................38
   12. Backwards Compatibility.......................................44
   13. IANA Considerations...........................................45
   14. Bibliography..................................................47
   15. Appendix A: Examples for Sender Side Configurations...........50
   16. Appendix B: Distribution Report processing at the receiver....54
   18. ACKNOWLEDGEMENTS..............................................58
   19. AUTHORS' ADDRESSES............................................58
   20. IPR Notice....................................................58
   21. FULL COPYRIGHT STATEMENT......................................59




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

   The following acronyms are used throughout this document:

   ASM  Any Source Multicast;

   SSM  Source-Specific Multicast.


2. 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


Ott et al.        Internet Draft - Expires July 2008           [Page 2]


                      RTCP with Unicast Feedback

   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 224.0.0.0 through
   239.255.255.255. To enable Internet-wide multicast communication,
   intra-domain routing protocols (those that operate only within a
   single administrative domain, e.g., DVMRP [16], PIM [17][18]) are
   used in combination with inter-domain routing protocols (those that
   operate across administrative domain borders, e.g., MBGP [19], MSDP
   [20]). Such routing protocols enable a host to join a single
   multicast group address and to send to or to 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, nor 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 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

Ott et al.        Internet Draft - Expires July 2008           [Page 3]


                      RTCP with Unicast Feedback

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


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
        applied.

        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

Ott et al.        Internet Draft - Expires July 2008           [Page 4]


                      RTCP with Unicast Feedback

        the receivers and the Distribution Source via the Feedback
        Target(s). Thus bi-directional 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 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 instances(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.

   SSRC:
        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).


Ott et al.        Internet Draft - Expires July 2008           [Page 5]


                      RTCP with Unicast Feedback


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) is/are co-located (or integrated) with
   the Distribution Source, re-distribution of original or summarized
   RTCP reports is trivial.  When the Feedback Target(s) is/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.

Ott et al.        Internet Draft - Expires July 2008           [Page 6]


                      RTCP with Unicast Feedback


        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 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 provided.

   Configuration information needs to be supplied so that (among
   others)

      . 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;
      . 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);
      . receivers know the addresses of their respectively responsible
        Feedback Target, and
      . the Feedback Target(s) 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 SDP descriptions MAY be used for this purpose)
   that 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.






















Ott et al.        Internet Draft - Expires July 2008           [Page 7]


                      RTCP with Unicast Feedback

                                             Source-specific
              +--------+       +-----+          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
              co=located.

                          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



Ott et al.        Internet Draft - Expires July 2008           [Page 8]


                      RTCP with Unicast Feedback

   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   208

   Within the Receiver Summary Information packet, there are various
   types of information that may be reported and encapsulated in
   optional sub-report blocks:










Ott et al.        Internet Draft - Expires July 2008           [Page 9]


                      RTCP with Unicast Feedback

   Sub-Report Block Type    Description            Identifier number
   ------------------------------------------------------------------
   IPv4 Address      IPv4 Unicast Feedback address        0
   IPv6 Address      IPv6 Unicast Feedback address        1
   DNS name          DNS name for Unicast Feedback        2
   -                 - reserved -                         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 -                         9
   Stats             General statistics                   10
   Receiver BW       RTCP Receiver Bandwidth              11
   Group Info        RTCP Group and Avg Packet Size       12
   -                 - reserved -                         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
   apply.


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
   feedback.

   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.


Ott et al.        Internet Draft - Expires July 2008          [Page 10]


                      RTCP with Unicast Feedback

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

   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.


Ott et al.        Internet Draft - Expires July 2008          [Page 11]


                      RTCP with Unicast Feedback

   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.


7. Distribution Source Feedback Summary Model

   In the Distribution Source Feedback Summary Model, the Distribution
   Source is required to summarize the information received from all
   the Receiver Reports generated by the receivers and place the
   information into summary reports.  The Distribution Source Feedback
   Summary Model introduces a new report block format, the Receiver
   Summary Information Report (RSI), and a number of optional sub-
   report block formats, which are enumerated in Section 7.1.  As
   described in section 7.3, individual instances of the Feedback
   Target may provide preliminary summarization to reduce the
   processing load at the Distribution Source.

   Sub-reports appended to the RSI report block provide more detailed
   information on the overall session characteristics reported by all
   receivers and can also convey important information such as the
   feedback address and reporting bandwidth.  Which sub-reports are
   mandatory and which ones are optional is defined below.

   From an RTP perspective, the Distribution Source is an RTP receiver,
   generating its own Receiver Reports and sending them to the receiver
   group and to the Media Senders.  In the Distribution Source Feedback
   Summary Model, an RSI report block MUST be appended to all RRs the
   Distribution Source generates.

   In addition, the Distribution Source MUST forward the RTCP SR
   reports and SDES packets of Media Senders without alteration.  If
   the Distribution Source is actually a Media Sender, even if it is

Ott et al.        Internet Draft - Expires July 2008          [Page 12]


                      RTCP with Unicast Feedback

   the only session sender, it MUST generate its own Sender Report (SR)
   packets for its role as a Media Sender and its Receiver Reports in
   its role as the Distribution Source.

   The Distribution Source MUST use its own SSRC value for transmitting
   summarization information and MUST perform proper SSRC collision
   detection and resolution.

   The Distribution Source MUST send at least one Receiver Summary
   Information packet for each reporting interval.  The Distribution
   Source MAY additionally stack sub-report blocks after the RSI
   packet.  If it does so, each sub-report block MUST correspond to the
   RSI packet and constitutes an enhancement to the basic summary
   information required by the receivers to calculate their reporting
   time interval.  For this reason, additional sub-report blocks are
   not required but recommended.  The compound RTCP packets containing
   the RSI packet and the optional corresponding sub-report blocks MUST
   be formed according to the rules defined in [1] for receiver-issued
   packets, e.g., they MUST begin with an RR packet, contain at least
   an SDES packet with a CNAME, and MAY contain further RTCP packets
   and SDES items.

   Every RSI packet MUST contain either a Group and Average Packet size
   sub-report or an RTCP Bandwidth sub-report for bandwidth indications
   to the receivers.


7.1 Packet Formats

7.1.1 RSI: Receiver Summary Information Packet

   The RSI report block has a fixed header size followed by a variable
   length report:

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |V=2|P|reserved |   PT=RSI=208  |             length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           SSRC                                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Summarized SSRC                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              NTP Timestamp (most significant word)            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              NTP Timestamp (least significant word)           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                       Sub-report blocks                       :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The RSI packet includes the following fields:

   length: 16 bits

Ott et al.        Internet Draft - Expires July 2008          [Page 13]


                      RTCP with Unicast Feedback

      As defined in [1], the length of the RTCP packet in 32-bit words
      minus one, including the header and any padding.

   SSRC: 32 bits
      The SSRC of the Distribution Source.

   Summarized SSRC: 32 bits
      The SSRC (of the Media Sender) of which this report contains a
      summary.

   Timestamp: 64 bits
      Indicates the wallclock time when this report was sent.
      Wallclock time (absolute date and time) is represented using the
      timestamp format of the Network Time Protocol (NTP), which is in
      seconds relative to 0h UTC on 1 January 1900 [4].    The
      wallclock time MAY (but need not) be NTP-synchronized but it MUST
      provide a consistent behavior in the advancement if time (similar
      to NTP).  The full resolution NTP timestamp is used which is a
      64-bit unsigned fixed-point number with the integer part in the
      first 32 bits and the fractional part in the last 32 bits.  This
      format is similar to RTCP sender reports (section 6.4.1 of [1]).
      The timestamp value is used to enable detection of duplicate
      packets, reordering and to provide a chronological profile of the
      feedback reports.


7.1.2 Sub-Report Block Types

   For RSI reports, this document also introduces a sub-report block
   format specific to the RSI packet.  The sub-report blocks are
   appended to the RSI packet using the following generic format.  All
   sub-report blocks MUST be 32-bit aligned.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SRBT      |    Length     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      SRBT-specific data       +
   |                                                               |
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   SRBT: 8 bits
      Sub-Report Block Type. The sub-report block type identifier.  The
      values for the sub-report block types are defined in section 5.

   Length: 8 bits
      The length of the sub-report in 32-bit words.

   SRBT-specific data: <Length*4 - 2> octets
      This field may contain type-specific information based upon the
      SRBT value.



Ott et al.        Internet Draft - Expires July 2008          [Page 14]


                      RTCP with Unicast Feedback

 7.1.3 Generic Sub-Report Block Fields

   For the sub-report blocks that convey distributions of values (Loss,
   Jitter, RTT, Cumulative Loss), a flexible 'data bucket' style report
   is used. This format divides the data set into variable size buckets
   that are interpreted according to the guide fields at the head of
   the report block.

    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
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |     SRBT      |    Length     |        NDB            |   MF  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Minimum Distribution Value                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Maximum Distribution Value                  |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                      Distribution Buckets                     |
   |                             ...                               |
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   The SRBT and Length fields are calculated as explained in section
   7.1.2.

   Number of distribution buckets (NDB): 12 bits
      The number of distribution buckets of data.  The size of each
      bucket can be calculated using the formula ((length * 4) -
      12)*8/NDB number of bits.  The calculation is based on the length
      of the whole sub-report block in octets (length field * 4) minus
      the header of 12 octets.  Providing 12 bits for the NDB field
      enables bucket sizes as small as 2 bits for a full length packet
      of MTU 1500 bytes.  The bucket size in bits must always be
      divisible by 2 to ensure proper byte alignment.  A bucket size of
      2 bits is fairly restrictive, however, and it is expected that
      larger bucket sizes will be more practical for most
      distributions.

   Multiplicative Factor (MF): 4 bits
      2^MF indicates the multiplicative factor to be applied to each
      distribution bucket value.  Possible values of MF are 0 - 15,
      creating a range of values from MF = 1, 2, 4 ... 32768.
      Appendix B gives an example of the use of the multiplicative
      factor; it is meant to provide more "bits" without having them
      -- the bucket values get scaled up by the MF.

   Length: 8 bits
      The length field tells the receiver the full length of the sub-
      report block in 32-bit words (i.e., length * 4 bytes), and
      enables the receiver to identify the bucket size. For example,
      given no MTU restrictions, the data portion of a distribution
      packet may be only as large as 1008 bytes (255 * 4 - 12),
      providing up to 4032 data buckets of length 2 bits, or 2016 data
      buckets of length 4 bits, etc.

Ott et al.        Internet Draft - Expires July 2008          [Page 15]


                      RTCP with Unicast Feedback

   Minimum distribution value (min): 32 bits
      The minimum distribution value, in combination with the maximum
      distribution value, indicates the range covered by the data
      bucket values.

   Maximum distribution value (max): 32 bits
      The maximum distribution value, in combination with the minimum
      distribution value, indicates the range covered by the data
      bucket values.  The significance and range of the distribution
      values is defined in the individual subsections for each
      distribution type (DT).

   Distribution buckets: each bucket is ((length * 4) - 12)*8/NDB bits
      The size and number of buckets is calculated as outlined above
      based upon the value of NDB and the length of the packet.  The
      values for distribution buckets are equally distributed;
      according to the following formula, distribution bucket x
      (with 0 <= x < NDB) covering the value range:

      x=0; [min, min+(max-min)/NDB]
      x>0; [min+(x)*(max-min)/NDB, min+(x+1)*(max-min)/NDB]

   Interpretation of the minimum, maximum, and distribution values in
   the sub-report block is sub-report-specific and is addressed
   individually in the sections below.  The size of the sub-report
   block is variable, as indicated by the packet length field.

   Note that, for any bucket-based reporting, if the Distribution
   Source and the Feedback Target(s) are disjoint entities, out-of-band
   agreement on the bucket reporting granularity is recommended to
   allow the Distribution Source to forward accurate information in
   these kinds of reports to the receivers.


 7.1.4 Loss sub-report block

   The loss sub-report block allows a receiver to determine how its own
   reception quality relates to the other recipients.  A receiver may
   use this information, e.g., to drop out of a session (instead of
   sending lots of error repair feedback) if it finds itself isolated
   at the lower end of the reception quality scale.

   The loss sub-report block indicates the distribution of losses as
   reported by the receivers to the Distribution Source.  Values are
   expressed as a fixed-point number with the binary point at the left
   edge of the field similar to the "fraction lost" field in SR and RR
   packets as defined in [1].  The Loss sub-report block type (SRBT) is
   4.

   Valid results for the minimum distribution value field are 0 - 254.
   Similarly, valid results for the maximum distribution value field
   are 1 - 255.  The minimum distribution value MUST always be less
   than the maximum.


Ott et al.        Internet Draft - Expires July 2008          [Page 16]


                      RTCP with Unicast Feedback

   For examples on processing summarized loss report sub-blocks, see
   Appendix B.


  7.1.5 Jitter sub-report block

   A jitter sub-report block indicates the distribution of the
   estimated statistical variation of the RTP data packet inter-arrival
   time reported by the receivers to the Distribution Source.  This
   allows receivers both to place their own observed jitter values in
   context with the rest of the group, and to approximate dynamic
   parameters for playout buffers. See [1] for details on the
   calculation of the values and the relevance of the jitter results.
   Jitter values are measured in timestamp units with the rate used by
   the Media Sender and expressed as unsigned integers.  The minimum
   distribution value MUST always be less than the maximum.  The Jitter
   sub-report block type (SRBT) is 5.

   Since timestamp units are payload-type specific, the relevance of a
   jitter value is impacted by any change in the payload type during a
   session.  Therefore, a Distribution Source MUST NOT report jitter
   distribution values for at least 2 reporting intervals after a
   payload type change occurs.


  7.1.6 Round Trip Time sub-report block

   A round trip time sub-report indicates the distribution of round
   trip times from the Distribution Source to the receivers, providing
   receivers with a global view of the range of values in the group.
   The Distribution Source is capable of calculating the round trip
   time to any other members since it forwards all the SR packets from
   the Media Sender(s) to the group.  If the Distribution Source is not
   itself a Media Sender, it can calculate the round trip time from
   itself to any of the receivers by maintaining a record of the SR
   sender timestamp, and the current time as measured from its own
   system clock.  The Distribution Source consequently calculates the
   round trip time from the receiver report by identifying the
   corresponding SR timestamp and subtracting the RR advertised holding
   time as reported by the receiver from its own time difference
   measurement, as calculated by the time the RR packet is received and
   the recorded time the SR was sent.

   The Distribution Source has the option of distributing these round
   trip time estimations to the whole group, uses of which are
   described in Section 7.4.  The round trip time is expressed in units
   of 1/65536 seconds and indicates an absolute value.  This is
   calculated by the Distribution Source based on the Receiver Report
   responses declaring the time difference since an original Sender
   Report, and the holding time at the receiver.  The minimum
   distribution value MUST always be less than the maximum. The Round
   Trip Time sub-report block type (SRBT) is 6.



Ott et al.        Internet Draft - Expires July 2008          [Page 17]


                      RTCP with Unicast Feedback

       Note that if the Distribution Source and the Feedback Target
       functions are disjoint, it is only possible for the Distribution
       Source to determine RTT if all the Feedback Targets forward all
       RTCP reports from the receivers immediately (i.e., do not perform
       any preliminary summarization) and include at least the RR
       packet.


  7.1.7 Cumulative Loss sub-report block

   The cumulative loss field in a Receiver Report [1], in contrast to
   the fraction lost field, is intended to provide some historical
   perspective on the session performance, i.e., the total number of
   lost packets since the receiver joined the session.  The cumulative
   loss value provides a longer-term average by summing over a larger
   sample set (typically the whole session).  The Distribution Source
   MAY record the values as reported by the receiver group and report a
   distribution of values.  Values are expressed as a fixed-point
   number with the binary point at the left edge of the field, in the
   same manner as the Loss sub-report block.  Since the individual
   Receiver Reports give the cumulative number of packets lost but not
   the cumulative number sent, which is required as a denominator to
   calculate the long-term fraction lost, the Distribution Source MUST
   maintain a record of the cumulative number lost and extended highest
   sequence number received as reported by each receiver at some point
   in the past.  Ideally the recorded values are from the first report
   received.  Subsequent calculations are then based on (<the new
   cumulative loss value> - <the recorded value>) / (<new extended
   highest sequence number> - <recorded sequence number>).

   Valid results for the minimum distribution value field are 0 - 254.
   Similarly, valid results for the maximum distribution value field
   are 1 - 255.  The minimum distribution value MUST always be less
   than the maximum.  The Cumulative loss sub-report block type (SRBT)
   is 7.


  7.1.8 Feedback Target Address sub-report block

   The Feedback Target Address block provides a dynamic mechanism for
   the Distribution Source to signal an alternative unicast RTCP
   feedback address to the receivers.  If a block of this type is
   included, receivers MUST override any static SDP address information
   for the session with the Feedback Target address provided in this
   sub-report block.

   If a Feedback Target Address sub-report block is used, it MUST be
   included in every RTCP packet originated by the Distribution Source
   to ensure that all receivers understand the information.  In this
   manner, receiver behavior should remain consistent even in the face
   of packet loss or when there are late session arrivals.




Ott et al.        Internet Draft - Expires July 2008          [Page 18]


                      RTCP with Unicast Feedback


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SRBT={0,1,2}  |     Length    |             Port              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                            Address                            :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   SRBT: 8 bits
      The type of sub-report block that corresponds to the type of
      address is as follows:

         0: IPv4 address
         1: IPv6 address
         2: DNS name


   Length: 8 bits
      The length of the sub-report block in 32-bit words. For an IPv4
      address this should be 2 (i.e., Total length = 4 + 4 = 2*4
      octets). For an IPv6 address this should be 5.  For a DNS name,
      the length field indicates the number of 32-bit words making up
      the string plus 1 byte and any additional padding required to
      reach the next word boundary.

   Port: 2 octets
      The port number to which receivers send feedback reports.  A port
      number of 0 is invalid and MUST NOT be used.

   Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name)
      The address to which receivers send feedback reports.  For IPv4
      and IPv6 fixed-length address fields are used.  A DNS name is an
      arbitrary length string that is padded with null bytes to the
      next 32 bit boundary.  The string MUST be UTF-8 encoded [11].

   A feedback target address block for a certain address type (i.e.,
   with a certain SRBT of 0, 1, or 2) MUST NOT occur more than once
   within a packet. Numerical feedback target address blocks for IPv4
   and IPv6 MAY both be present.  If so, the resulting transport
   addresses MUST point to the same logical entity.

   If a feedback target address block with an SRBT indicating a DNS
   name is present, there SHOULD NOT be any other numerical Feedback
   Target Address blocks present.

   The Feedback Target Address presents a significant security risk if
   accepted from unauthenticated RTCP packets.  See section 11.3.a and
   11.4.a.




Ott et al.        Internet Draft - Expires July 2008          [Page 19]


                      RTCP with Unicast Feedback

 7.1.9 Collisions sub-report block

   The collision SSRC sub-report provides the Distribution Source with
   a mechanism to report SSRC collisions amongst the group.  In the
   event that a non-unique SSRC is discovered based on the tuple
   [SSRC,CNAME], the collision is reported in this block and the
   affected nodes must reselect their respective SSRC identifiers.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SRBT=8    |    Length     |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                         Collision SSRC                        :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Collision SSRC: n x 32 bits
      This field contains a list of SSRCs that are duplicated within
      the group.  Usually this is handled by the hosts upon detection
      of the same SSRC; however, since receivers in an SSM session
      using the Distribution Source Feedback Summary Model no longer
      have a global view of the session, the collision algorithm is
      handled by the Distribution Source.  SSRCs that collide are
      listed in the packet.  Each Collision SSRC is reported only once
      for each collision detection.  If more Collision SSRCs need to be
      reported than fit into an MTU, the reporting is done in a round
      robin fashion so that all Collision SSRCs have been reported once
      before the second round of reporting starts.  On receipt of the
      packet, receiver(s) MUST detect the collision and select another
      SSRC, if the collision pertains to them.

   The Collisions sub-report block type (SRBT) is 8.

   Collision detection is only possible at the Distribution Source.  If
   the Distribution Source and Feedback Target Functions are disjoint
   and collision reporting across RTP receiver SSRCs shall be provided,
   the Feedback Targets(s) MUST forward the RTCP reports from the RTP
   receivers including at least the RR and the SDES packets to the
   Distribution Source.

   In system settings in which, by explicit configuration or
   implementation, RTP receivers are not going to act as Media Senders
   in a session (e.g. for various types of television broadcasting),
   SSRC collision detection MAY be omitted for RTP receivers.  In
   system settings in which an RTP receiver MAY become a Media Sender
   (e.g., any conversational application), SSRC collision detection
   MUST be provided for RTP receivers.

        Note: The purpose of SSRC collision reporting is to ensure
        unique identification of RTCP entities.  This is of particular
        relevance for Media Senders so that an RTP receiver can

Ott et al.        Internet Draft - Expires July 2008          [Page 20]


                      RTCP with Unicast Feedback

        associate each of multiple incoming media streams (via the
        Distribution Source) properly with the correct sender.
        Collision resolution for Media Senders is not affected by the
        Distribution Source's collision reporting because all SR
        reports are always forwarded among the senders and to all
        receivers.  Collision resolution for RTP receivers is of
        particular relevance for those receivers capable of becoming a
        Media Sender.  RTP receivers that will, by configuration or
        implementation choice, not act as a sender in a particular RTP
        session, do not necessarily need to be aware of collisions as
        long as the those entities receiving and processing RTCP
        feedback messages from the receivers are capable of
        disambiguating the various RTCP receivers (e.g., by CNAME).

        Note also that RTP receivers should be able to deal with
        changing SSRCs of a Media Sender (like any RTP receiver has to
        do.) and, if possible, be prepared to render a media stream
        continuously nevertheless.


 7.1.10 General Statistics sub-report block

   The general statistics sub-report block is used if specifying
   buckets is deemed too complex.  With the general statistics sub-
   report block only aggregated values are reported back.  The rules
   for the generation of these values are provided in section 7.2.1.b.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    SRBT=10    |    Length     |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      MFL      |                    HCNL                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Median interarrival jitter                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Median fraction lost (MFL): 8 bits
      The median fraction lost indicated by Receiver Reports forwarded
      to this Distribution Source, expressed as a fixed point number
      with the binary point at the left edge of the field.  A value of
      all '1's indicates that the MFL value is not provided.

   Highest cumulative number of packets lost (HCNL): 24 bits
      Highest 'cumulative number of packets lost' value out of the most
      recent RTCP RR packets from any of the receivers.  A value of all
      '1's indicates that the HCNL value is not provided.

   Median inter-arrival jitter: 32 bits
      Median 'inter-arrival jitter' value out of the most recent RTCP
      RR packets from the receiver set.  A value of all '1's indicates
      that this value is not provided.


Ott et al.        Internet Draft - Expires July 2008          [Page 21]


                      RTCP with Unicast Feedback

   The General Statistics sub-report block type (SRBT) is 10.

   Note that, in case the Distribution Source and the Feedback Target
   functions are disjoint, it is only possible for the Distribution
   Source to determine the median of the inter-arrival jitter if all
   the Feedback Targets forward all RTCP reports from the receivers
   immediately and include at least the RR packet.


7.1.11 RTCP Bandwidth Indication sub-report block

   This sub-report block is used to inform the Media Senders and
   receivers about the maximum RTCP bandwidth that is supposed to be
   used by each Media Sender or about the maximum bandwidth allowance
   to be used by each receiver.  The value is applied universally to
   all Media Senders or all receivers.  Each receiver MUST base its
   RTCP transmission interval calculation on the average size of the
   RTCP packets sent by itself. Conversely, each Media Sender MUST base
   its RTCP transmission interval calculation on the average size of
   the RTCP packets sent by itself.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    SRBT=11    |     Length    |S|R|         Reserved          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        RTCP Bandwidth                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Sender (S): 1 bit
      The contained bandwidth value applies to each Media Sender.

   Receivers (R): 1 bit
      The contained bandwidth value applies to each RTP receiver.

   Reserved: 14 bits
      MUST be set to zero upon transmission and ignored upon reception.

   RTCP Bandwidth: 32 bits
      If the S bit is set to 1, this field indicates the maximum
      bandwidth allocated to each individual Media Sender.  This also
      informs the receivers about the RTCP report frequency to expect
      from the senders.  This is a fixed point value with the binary
      point in between the second and third bytes. The value represents
      the bandwidth allocation per-receiver in kilobits per second with
      values in the range 0 <= BW < 65536.

      If the R bit is set to 1, this field indicates the maximum
      bandwidth allocated per receiver for sending RTCP data relating
      to the session.  This is a fixed point value with the binary
      point in between the second and third bytes.  The value
      represents the bandwidth allocation per-receiver in kilobits per


Ott et al.        Internet Draft - Expires July 2008          [Page 22]


                      RTCP with Unicast Feedback

      second with values in the range 0 <= BW < 65536.  Each receiver
      MUST use this value for its bandwidth allowance.

   This report block SHOULD only be used when the Group and Average
   Packet Size sub-report block is NOT included. The RTCP Bandwidth
   Indication sub-report block type (SRBT) is 11.


7.1.12 RTCP Group and Average Packet Size Sub-report Block

   This sub-report block is used to inform the Media Senders and
   receivers about the size of the group (used for calculating feedback
   bandwidth allocation) and the average packet size of the group.
   This sub-report MUST always be present, appended to every RSI
   packet, unless an RTCP Bandwidth indication sub-report block is
   included (in which case it MAY but need not be present).

      Note: The RTCP Bandwidth Indication sub-report block allows the
      Distribution Source to hide the actual group size from the
      receivers while still avoiding feedback implosion.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    SRBT=12    |    Length     |     Average Packet Size       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Receiver Group Size                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Group size: 32 bits
      This field provides the Distribution Source's view of the number
      of receivers in a session. Note that the number of Media Senders
      is not explicitly reported since it can be derived by observing
      the RTCP SR packets forwarded by the Distribution Source. The
      group size is calculated according to the rules outlined in [1].
      When this sub-report block is included, this field MUST always be
      present.

   Average RTCP packet size: 16 bits
      This field provides the Distribution Source's view of the average
      RTCP packet size as locally calculated following the rules
      defined in [1].  The value is an unsigned integer counting
      octets.  When this sub-report block is included, this field MUST
      always be present.

   The Group and Average Packet Size sub-report block type (SRBT) is
   12.


7.2 Distribution Source behavior



Ott et al.        Internet Draft - Expires July 2008          [Page 23]


                      RTCP with Unicast Feedback

   In the Distribution Source Feedback Summary Model, the Distribution
   Source (the unicast Feedback Target) MUST listen for unicast RTCP
   packets sent to the RTCP port.  All RTCP packets received on this
   port MUST be processed by the Distribution Source as described
   below.  The processing MUST take place per Media Sender SSRC about
   which receiver reports are received.

   The Distribution Source acts like a regular RTCP receiver.  In
   particular, it receives an RTP stream from each RTP Media Sender(s)
   and MUST calculate the proper reception statistics for these RTP
   streams.  It MUST transmit the resulting information as report
   blocks contained in each RTCP packet it sends (in an RR packet).

        Note: This information may help to determine the transmission
        characteristics of the feed path from the RTP sender to the
        Distribution Source (if these are separate entities).

   The Distribution Source is responsible for accepting RTCP packets
   from the receivers, and interpreting and storing per-receiver
   information as defined in [1].  The importance of providing these
   functions is apparent when creating the RSI and sub-report block
   reports, since incorrect information can have serious implications.
   Section 11 addresses the security risks in detail.

   As defined in [1], all RTCP reports from the Distribution Source
   MUST start with an RR report followed by any relevant SDES fields.
   Then, the Distribution Source MUST append an RSI header and sub-
   reports containing any summarization specific data.  In addition,
   either the Group and Average Packet size sub-report or the Receiver
   RTCP Bandwidth sub-report block MUST be appended to the RSI header.

   A Distribution Source has the option of masking the Group size by
   including only an RTCP bandwidth sub-report.  If both sub-reports
   are included, the receiver is expected to give precedence to the
   information contained in the Receiver RTCP Bandwidth sub-report.

   The Receiver RTCP Bandwidth sub-report block provides the
   Distribution Source with the capability to control the amount of
   feedback from the receivers and the bandwidth value MAY be increased
   or decreased based upon the requirements of the Distribution Source.
   Regardless of the value selected by the Distribution Source for the
   Receiver RTCP Bandwidth sub-report block, the Distribution Source
   MUST continue to forward Sender Reports and RSI packets at the rate
   allowed by the total RTCP bandwidth allocation. See Section 9 for
   further details about the frequency of reports.

   A Distribution Source MAY start out reporting Group size and switch
   to Receiver RTCP Bandwidth reporting later on and vice versa.  If
   the Distribution Source does so, it SHOULD ensure that the
   correspondingly indicated values for the Receiver RTCP Bandwidth
   roughly match, i.e., are at least the same order of magnitude.

   In order to identify SSRC collisions, the Distribution Source is
   responsible for maintaining a record of each SSRC and the

Ott et al.        Internet Draft - Expires July 2008          [Page 24]


                      RTCP with Unicast Feedback

   corresponding CNAME within at least one reporting interval by the
   group in order to differentiate between clients.  It is RECOMMENDED
   that an updated list of more than one interval be maintained to
   increase accuracy.  This mechanism should prevent the possibility of
   collisions since the combination of SSRC and CNAME should be unique,
   if the CNAME is generated correctly.  If collisions are not
   detected, the Distribution Source will have an inaccurate impression
   of the group size.  Since the statistical probability is very low
   that collisions will both occur and be undetectable, this should not
   be a significant concern.  In particular, the clients would have to
   randomly select the same SSRC and have the same username + IP
   address (e.g., using private address space behind a NAT router).


7.2.1 Receiver Report Aggregation

   The Distribution Source is responsible for aggregating reception
   quality information received in RR packets.  In doing so, the
   Distribution Source MUST consider the report blocks received in
   every RR packet and MUST NOT consider the report blocks of an SR
   packet.

        Note: the receivers will get the information contained in the SR
        packets anyway by packet forwarding so that duplication of this
        information should be avoided.

   For the optional sub-report blocks, the Distribution Source MAY
   decide which are the most significant feedback values to convey and
   MAY choose not to include any.  The packet format provides
   flexibility in the amount of detail conveyed by the data points.
   There is a tradeoff between the granularity of the data and the
   accuracy of the data based on the multiplicative factor (MF), the
   number of buckets, and the min and max values.  In order to focus on
   a particular region of a distribution, the Distribution Source can
   adjust the minimum and maximum values, and either increase the
   number of buckets and possibly the factorization, or decrease the
   number of buckets and provide more accurate values.  See Appendix B
   for detailed examples on how to convey a summary of RTCP Receiver
   Reports as RSI sub-report block information.

   For each value the Distribution Source decides to include in an RSI
   packet, it MUST adhere to the following measurement rules.

   a)  If the Distribution Source intends to use a sub-report to convey
        a distribution of values (sections 7.1.3 to 7.1.7), it MUST keep
        per receiver state, i.e., remember the last value V reported by
        the respective receiver.  If a new value is reported by a
        receiver, the existing value MUST be replaced by the new one.
        The value MUST be deleted (along with the entire entry) if the
        receiver is timed out (as per section 6.3.5 of [1]) or has sent
        a BYE packet (as per section 6.3.7 of [1]).

        All the values collected in this way MUST be included in the
        creation of the subsequent distribution sub-report block.

Ott et al.        Internet Draft - Expires July 2008          [Page 25]


                      RTCP with Unicast Feedback


        The results should correspond as closely as possible to the
        values received during the interval since the last report.  The
        Distribution Source may stack as many sub-report blocks as
        required in order to convey different distributions.  If the
        distribution size exceeds the largest packet length (1008 bytes
        data portion), more packets MAY be stacked with additional
        information (but in total SHOULD NOT exceed the path MTU).

        All stacked sub-reports MUST be internally consistent, i.e.,
        generated from the same session data. Overlapping of
        distributions is therefore allowed, and variation in values
        should only occur as a result of data set granularity, with the
        more accurate bucket sizes taking precedence in the event that
        values differ. Non-divisible values MUST be rounded up or down
        to the closest bucket value, and the number of data buckets must
        always be an even number, padding where necessary with an
        additional zero bucket value to maintain consistency.

        Note: This intentionally provides persistent full coverage of
        the entire session membership to avoid oscillations due to
        changing membership samples.

   b)  If the Distribution Source intends to report a short summary
        using the General Statistics sub-report block format defined in
        section 7.1.10, for EACH of the values included in the report
        (AFL, HCNL, average interarrival jitter), it MUST keep a timer
        T_summary as well as a sufficient set of variables to calculate
        the summaries for the last three reporting intervals.

        The summary values are included here to reflect the current
        group situation. By recording the last three reporting intervals
        the Distribution Source incorporates reports from all members
        while allowing for individual RTCP receiver report packet
        losses.  The process of collecting these values also aims to
        avoid resetting any of the values and then having to send out an
        RSI report based upon just a few values collected.  If data is
        available for less than three reporting intervals (as will be
        the case for the first two reports sent), only those values
        available are considered.

        The timer T_summary MUST be initialized as T_summary = 1.5*Td,
        where Td is the deterministic reporting interval, and MUST be
        updated following timer reconsideration whenever the group size
        or the average RTCP size ("avg_rtcp_size") changes.  This choice
        should allow each receiver to report once per interval.









Ott et al.        Internet Draft - Expires July 2008          [Page 26]


                      RTCP with Unicast Feedback

              Td
             __^__
          t0/     \   t1        t2        t3        t4        t5
         ---+---------+---------+---------+---------+---------+------->
            \____ ____/         :         :         :         :
            :    V    :         :         :         :         :
            :T_summary:         :         :         :         :
            : =1.5*Td :         :         :         :         :
            \______________ ______________/         :         :
                      :    V    :                   :         :
                      : 3*T_summary                 :         :
                      :         :                   :         :
                      \______________ ______________/         :
                                :    V                        :
                                : 3*T_summary                 :
                                :                             :
                                \______________ ______________/
                                               V
                                            3*T_summary

        Figure 2: Overview of summarization reporting

        Figure 2 depicts how the summarization reporting shall be
        performed.  At time t3, the RTCP reports collected from t0
        through t3 are included in the RSI reporting, at time t4, those
        from t1 through t4, and so on.  The RSI summary report sent MUST
        NOT include any RTCP report from more than three reporting
        intervals ago; e.g., the one sent at time t5, must not include
        reports received at the Distribution Source prior to t2.


7.2.2 Handling Other RTCP Packets from RTP receivers

   When following the Feedback Summary Model the Distribution Source
   MAY reflect any other RTCP packets of potential relevance to the
   receivers (such as APP, RTPFB, PSFB) to the receiver group and MAY
   decide not to forward other RTCP packets not needed as such by the
   receivers (such as BYE, RR, SDES because the Distribution Source
   performs collision resolution, group size estimation, and RR
   aggregation).  The Distribution Source MUST NOT forward RR packets
   to the receiver group.

   If the Distribution Source is able to interpret and aggregate
   information contained in any RTCP packets other than RR, it MAY
   include the aggregated information along with the RSI packet in its
   own compound RTCP packet.

   Aggregation MAY be a null operation, i.e., the Distribution Source
   MAY simply append one or more RTCP packets from receivers to the
   compound RTCP packet (containing at least RR, SDES and RSI from the
   Distribution Source).




Ott et al.        Internet Draft - Expires July 2008          [Page 27]


                      RTCP with Unicast Feedback

        Note: This is likely to be useful only for a few cases, e.g.,
        to forward aggregated information from RTPFB Generic NACK
        packets and thereby maintain the damping property of [15].

        Note: This entire processing rule implies that the flow of
        information contained in non-RR RTCP packets may terminate at
        the Distribution Source depending on its capabilities and
        configuration.

   The configuration of the RTCP SSM media session (expressed in SDP)
   MUST specify explicitly which processing the Distribution Source
   will apply to which RTCP packets.  See section 10.1 for details.


7.2.3 Receiver Report Forwarding

   If the Media Sender(s) are not part of the SSM group for RTCP packet
   reflection, the Distribution Source MUST explicitly inform the Media
   Senders of the receiver group.  To achieve this, the Distribution
   Source has two options: Either it forwards the RTCP RR and SDES
   packets received from the receivers to the Media Sender(s).  Or, if
   the Media Senders also support the RTCP RSI packet, the Distribution
   Source sends the RSI packets not just to the receivers but also to
   the Media Senders.

   If the Distribution Source decides to forward RR and SDES packets
   unchanged, it MAY also forward any other RTCP packets to the
   senders.

   If the Distribution Source decides to forward RSI packets to the
   senders, the considerations of 7.2.2 apply.


7.2.4 Handling Sender Reports

   The Distribution Source also receives RTCP (including SR) packets
   from the RTP Media Senders.

   The Distribution Source MUST forward all RTCP packets from the Media
   Senders to the RTP receivers.

   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 from any one
   Media Sender to all other Media Senders.


7.2.5 RTCP Data Rate Calculation

   As noted above, the Distribution Source is a receiver from an RTP
   perspective.  The Distribution Sources MUST calculate its
   deterministic transmission interval Td as every other receiver,
   however, it MAY adjust its available data rate depending on the
   destination transport address and its local operation:

Ott et al.        Internet Draft - Expires July 2008          [Page 28]


                      RTCP with Unicast Feedback


   1. For sending its own RTCP reports to the SSM group towards the
      receivers, the Distribution Source MAY use up to the joint share
      of all receivers as it is forwarding summaries on behalf of all
      of them.  Thus, the Distribution Source MAY send its reports up
      to every Td/R time units, with R being the number of receivers.

   2. For sending its own RTCP reports to the Media Senders only (i.e.,
      if the Media Senders are not part of the SSM group), the
      allocated rate depends on the operation of the Distribution
      Source:

        a) If the Distribution Source only sends RSI packets along with
           its own RTCP RR packets, the same rate calculation applies
           as for 1 above.

        b) If the Distribution Source forwards RTCP packets from all
           other receivers to the Media Senders, then it MUST adhere to
           the same bandwidth share for its own transmissions as all
           other receivers and use the calculation as per [1].


7.2.6 Collision Resolution

   A Distribution Source observing RTP packets from a Media Sender with
   an SSRC that collides with its own chosen SSRC MUST change its own
   SSRC following the procedures of [1] and MUST do so immediately
   after noticing.

   A Distribution Source MAY use out-of-band information about the
   Media Sender SSRC(s) used in the media session when available to
   avoid SSRC collisions with Media Senders.  Nevertheless, the
   Distribution Source MUST monitor Sender Report (SR) packets to
   detect any changes, observe collisions, and then follow the above
   collision resolution procedure.

   For collision resolution between the Distribution Source and
   receivers or the Feedback Target(s) (if a separate entity as
   described in the next subsection), the Distribution Source and the
   Feedback Target (if separate) operate similar to ordinary receivers.


7.3 Disjoint Distribution Source and Feedback Target

   If the Distribution Source and the Feedback Target are disjoint, the
   processing of the Distribution Source is limited by the amount of
   RTCP feedback information made available by the Feedback Target.

   The Feedback Target(s) MAY simply forward all RTCP packets incoming
   from the RTP receivers to the Distribution Source in which case the
   Distribution Source will have all the information available
   necessary to perform all the functions described above.



Ott et al.        Internet Draft - Expires July 2008          [Page 29]


                      RTCP with Unicast Feedback

   The Feedback Target(s) MAY also perform aggregation of incoming RTCP
   packets and send only aggregated information to the Distribution
   Source.  In this case, the Feedback Target(s) MUST use correctly
   formed RTCP packets to communicate with the Distribution Source and
   they MUST operate in concert with the Distribution Source so that
   the Distribution Source and the Feedback Target(s) appear operating
   as a single entity.  The Feedback Target(s) MUST report their
   observed receiver group size to the Distribution Source, either
   explicitly by means of RSI packets or implicitly by forwarding all
   RR packets.

        Note: For example, for detailed statistics reporting, the
        Distribution Source and the Feedback Target(s) may need to
        agree on a common reporting granularity so that the
        Distribution Source can aggregate the buckets incoming from
        various Feedback Targets into a coherent report sent to the
        receivers.

   The joint behavior or Distribution Source and Feedback Target(s)
   MUST be reflected in the (SDP-based) media session description as
   per 7.2.2.

   If the Feedback Target performs summarization functions, it MUST
   also act as a receiver and choose a unique SSRC for its own
   reporting towards the Distribution Source.  The collision resolution
   considerations for receivers apply.


7.4 Receiver behavior

   An RTP receiver MUST process RSI packets and adapt session
   parameters such as the RTCP bandwidth based on the information
   received.  The receiver no longer has a global view of the session,
   and will therefore be unable to receive information from individual
   receivers aside from itself.  However, the information conveyed by
   the Distribution Source can be extremely detailed, providing the
   receiver with an accurate view of the session quality overall,
   without the processing overhead associated with listening to and
   analyzing all Receiver Reports.

   The RTP receiver MUST process the report blocks contained in any RTP
   SR and RR packets to complete its view of the RTP session.

   The SSRC collision list MUST be checked against the SSRC selected by
   the receiver to ensure there are no collisions as MUST be incoming
   RTP packets from the Media Senders.  A receiver observing RTP
   packets from a Media Sender with an SSRC that collides with its own
   chosen SSRC 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.

   A Group and Average Packet size sub-report block is most likely to
   be appended to the RSI header (either a Group size sub-report or an
   RTCP Bandwidth sub-report MUST be included).  The Group size n

Ott et al.        Internet Draft - Expires July 2008          [Page 30]


                      RTCP with Unicast Feedback

   allows a receiver to calculate its share of the RTCP bandwidth, r.
   Given R, the total available RTCP bandwidth share for receivers (in
   the SSM RTP session) r = R/(n).  For the group size calculation, the
   RTP receiver MUST NOT include the Distribution Source, i.e. the only
   RTP receiver sending RSI packets.

   The Receiver RTCP Bandwidth field MAY override this value.  If the
   Receiver RTCP Bandwidth field is present, the receiver MUST use this
   value as its own RTCP reporting bandwidth r.

   If the RTCP Bandwidth field was used by the Distribution Source in
   an RTCP session but this field was not included in the last five
   RTCP RSI reports, the receiver MUST revert to calculating its
   bandwidth share based upon the Group size information.

   If the receiver has not received any RTCP RSI packets from the
   Distribution Source for a period of five times the sender reporting
   interval, it MUST cease transmitting RTCP receiver reports until the
   next RTCP RSI packet is received.

   The receiver can use the summarized data as desired.  This data is
   most useful in providing the receiver with a more global view of the
   conditions experienced by other receivers, and enables the client to
   place itself within the distribution and establish the extent to
   which its reported conditions correspond to the group reports as a
   whole.  The appendix B (section 16) provides further information and
   examples of data processing at the receiver.

   The receiver SHOULD assume that any sub-report blocks in the same
   packet correspond to the same data set received by the Distribution
   Source during the last reporting time interval.  This applies to
   packets with multiple blocks, where each block conveys a different
   range of values.

   A receiver MUST NOT rely on all of the RTCP packets it sends
   reaching the Media Senders or any other receiver.  While RR
   statistics will be aggregated, BYE packets processed, and SSRC
   collisions usually be announced, processing and/or forwarding of
   further RTCP packets is up to the discretion of the Distribution
   Source and will be performed as specified in the session
   description.

   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.  The receiver MUST be aware that such out-of-band
   information may be outdated (i.e., that the sender SSRC(s) have
   changed, and MUST follow the above collision resolution procedure if
   necessary.

   A receiver MAY use such Media Sender SSRC information when available
   but MUST beware of potential changes to the SSRC (which can only be
   learned from Sender Report (SR) packets).



Ott et al.        Internet Draft - Expires July 2008          [Page 31]


                      RTCP with Unicast Feedback

7.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 (optionally forwarded by
   the Distribution Source).

   Unlike in the case of the simple forwarding model, Media Senders
   MUST be able to process RSI packets from the Distribution Source to
   determine the group size and their own RTCP bandwidth share.  Media
   Senders MUST also be capable of determining the group size (and
   their corresponding RTCP bandwidth share) from listening to
   (forwarded) RTCP RR and SR packets (as mandated in [1]).

   As long as they send RTP packets they MUST also send RTCP SRs as
   defined in [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 RTP receivers.

   Sender SSRC information MAY be communicated out-of-band, e.g., by
   means of SDP media descriptions.  Therefore, senders SHOULD NOT
   eagerly change their own SSRC eagerly or unnecessarily.


8. Mixer/Translator issues

   The original RTP specification allows a session to use mixers and
   translators to help connect heterogeneous networks into one session.
   There are a number of issues, however, which are raised by the
   unicast feedback model proposed in this document. The term 'mixer'
   refers to devices that provide data stream multiplexing where
   multiple sources are combined into one stream. Conversely, a
   translator does not multiplex streams, but simply acts as a bridge
   between two distribution mechanisms, e.g., a unicast-to-multicast
   network translator. Since the issues raised by this document apply
   equally to either a mixer or translator, the latter are referred to
   from this point onwards as mixer-translator devices.

   A mixer-translator between distribution networks in a session must
   ensure that all members in the session receive all the relevant
   traffic to enable the usual operation by the clients. A typical use
   may be to connect an older implementation of an RTP client with an
   SSM distribution network, where the client is not capable of
   unicasting feedback to the source. In this instance the mixer-
   translator must join the session on behalf of the client and send


Ott et al.        Internet Draft - Expires July 2008          [Page 32]


                      RTCP with Unicast Feedback

   and receive traffic from the session to the client. Certain hybrid
   scenarios may have different requirements.


8.1 Use of a mixer-translator

   The mixer-translator MUST adhere to the SDP description [5] for the
   single source session (Section 11) and use the feedback mechanism
   indicated. Implementers of receivers SHOULD be aware, when a mixer-
   translator is present in the session, more than one Media Sender may
   be active since the mixer-translator may be forwarding traffic to
   the SSM receivers from either multiple unicast sources or from an
   ASM session. Receivers SHOULD still forward unicast RTCP reports in
   the usual manner to their assigned Feedback Target/Distribution
   Source, which -- by assumption -- in this case would be the mixer-
   translator itself. It is RECOMMENDED that the simple packet
   reflection mechanism be used under these circumstances since
   attempting to coordinate RSI + summarization reporting between more
   than one source may be complicated unless the mixer-translator is
   capable of summarization.


8.2 Encryption and Authentication issues

   Encryption and security issues are discussed in detail in Section
   11. A mixer-translator MUST be able to follow the same security
   policy as the client in order to unicast RTCP feedback to the
   source, and it therefore MUST be able to apply the same
   authentication and/or encryption policy required for the session.
   Transparent bridging and subsequent unicast feedback to the source,
   where the mixer-translator is not acting as the Distribution Source,
   is only allowed if the mixer-translator can conduct the same source
   authentication as required by the receivers. A translator MAY
   forward unicast packets on behalf of a client, but SHOULD NOT
   translate between multicast-to-unicast flows towards the source
   without authenticating the source of the feedback address
   information.


9. Transmission interval calculation

   The Control Traffic Bandwidth referred to in [1] is an arbitrary
   amount that is intended to be supplied by a session management
   application (e.g., sdr [21]) or decided based upon the bandwidth of
   a single sender in a session.

   The RTCP transmission interval calculation remains the same as in
   the original RTP specification [1] or uses the algorithm in [10]
   when bandwidth modifiers have been specified for the session.


9.1 Receiver RTCP Transmission



Ott et al.        Internet Draft - Expires July 2008          [Page 33]


                      RTCP with Unicast Feedback

   If the Distribution Source is operating in Simple Feedback mode
   (which may be indicated in the corresponding session description for
   the media session but which the receiver also notices from the
   absence of RTCP RSI packets), a receiver MUST calculate the number
   of other members in a session based upon its own SSRC count derived
   from the forwarded Sender and Receiver Reports it receives. The
   receiver MUST calculate the average RTCP packet size from all the
   RTCP packets it receives.

   If the Distribution Source is operating in Distribution Source
   Feedback Summary mode, the receiver MUST use either the Group size
   field and the average RTCP packet size field, or the Receiver
   Bandwidth Field from the respective sub-report blocks appended to
   the RSI packet.

   A receiver uses these values as input to the calculation of the
   deterministic calculated interval as per [1] and [10].


9.2 Distribution Source RTCP Transmission

   If operating in Simple Feedback mode, the Distribution Source MUST
   calculate the transmission interval for its Receiver Reports and
   associated RTCP packets based upon the above control traffic
   bandwidth and MUST count itself as RTP receiver.  Receiver Reports
   will be forwarded as they arrive without further consideration.  The
   Distribution Source MAY choose to validate that all or selected
   receivers roughly adhere to the calculated bandwidth constraints and
   MAY choose to drop excess packets for receivers that do not.  In all
   cases, the average RTCP packet size is determined from the Media
   Senders' and receivers' RTCP packets forwarded and those originated
   by the Distribution Source.

   If operating in Distribution Source Feedback Summary mode, the
   Distribution Source does not share the forward RTCP bandwidth with
   any of the receivers.  Therefore, the Distribution Source SHOULD use
   the full RTCP bandwidth for its receiver reports and associated RTCP
   packets, as well as RTCP RSI packets.  In this case, the average
   RTCP packet size is only determined from the RTCP packets originated
   by the Distribution Source.

   The Distribution Source uses these values as input to the
   calculation of the deterministic calculated interval as per [1] and
   [10].


9.3 Media Senders RTCP Transmission

   In Simple Feedback Mode, the Media Senders obtain all RTCP SRs and
   RRs as they would in an ASM session, except that the packets are
   forwarded by the Distribution Source.  They MUST perform their RTCP
   group size estimate and calculation of the deterministic
   transmission interval as per [1] and [10].


Ott et al.        Internet Draft - Expires July 2008          [Page 34]


                      RTCP with Unicast Feedback

   In Distribution Source Feedback Summary Mode, the Media Senders
   obtain all RTCP SRs as they would in an ASM session.  They receive
   either RTCP RR reports as in ASM (in case these packets are
   forwarded by the Distribution Source) or RSI packets containing
   summaries.  In the former case, they MUST perform their RTCP group
   size estimate and calculation of the deterministic transmission
   interval as per [1] and [10].  In the latter case, they MUST combine
   the information obtained from the Sender Reports and the RSI packets
   to create a complete view of the group size and the average RTCP
   packet size and perform the calculation of the deterministic
   transmission interval as per [1] and [10] based upon these input
   values.


9.4 Operation in conjunction with AVPF and SAVPF

   If the RTP session is an AVPF session [15] or an SAVPF session [28]
   (as opposed to a regular AVP [6] session) the receivers MAY modify
   their RTCP report scheduling as defined in [15].  Use of AVPF or
   SAVPF does not affect the Distribution Source's RTCP transmission or
   forwarding behavior.

   It is RECOMMENDED that a Distribution Source and possible separate
   Feedback Target(s) be configured to forward AVPF/SAVPF-specific RTCP
   packets in order not to counteract the damping mechanism built into
   AVPF; optionally, they MAY aggregate the feedback information from
   the receivers as per section 7.2.2.  If only generic feedback
   packets are in use that are understood by the Distribution Source
   and that can easily be aggregated, the Distribution MAY combine
   several incoming RTCP feedback packets and forward the aggregate
   along with its next RTCP RR/RSI packet.  In any case, the
   Distribution Source and Feedback Target(s) SHOULD minimize the extra
   delay when forwarding feedback information but the Distribution
   Source MUST stay within its RTCP bandwidth constraints.

   In the event that specific APP packets without a format and
   summarization mechanism understood by the Feedback Target(s) and/or
   the Distribution Source are to be used, it is RECOMMENDED that such
   packets are forwarded with minimal delay.  Otherwise, the capability
   of receiver to send timely feedback messages is likely to be
   affected.


10. SDP Extensions

   The Session Description Protocol (SDP) [5] is used as a means to
   describe media sessions in terms of their transport addresses,
   codecs, and other attributes. Signaling that RTCP feedback will be
   provided via unicast as specified in this document requires another
   session parameter in the session description. Similarly, other SSM
   RTCP feedback parameters need to be provided, such as the
   summarization mode at the sender and the target unicast address to
   which to send feedback information.  This section defines the SDP


Ott et al.        Internet Draft - Expires July 2008          [Page 35]


                      RTCP with Unicast Feedback

   parameters that are needed by the proposed mechanisms in this
   document (and that also need to be registered with IANA).


10.1 SSM RTCP Session Identification

   A new session level attribute MUST be used to indicate the use of
   unicast instead of multicast feedback: "rtcp-unicast".

   This attribute uses one parameter to specify the mode of operation.
   An optional set of parameters specifies the behavior for RTCP packet
   types (and subtypes).

   rtcp-unicast:reflection

        This attribute MUST be used to indicate the "Simple Feedback"
        mode of operation where packet reflection is used by the
        Distribution Source (without further processing).

   rtcp-unicast:rsi *(SP <processing>:<rtcp-type>])

        This attribute MUST be used to indicate the "Distribution
        Source Feedback Summary" mode of operation.  In this mode, a
        list or parameters may be used to explicitly specify how RTCP
        packets originated by receivers are handled.  Options for
        processing a given RTCP packet type are:

        aggr:    The Distribution Source has means for aggregating the
                  contents of the RTCP packets and will do so.

        forward: The Distribution Source will forward the RTCP packet
                  unchanged.

        term:    The Distribution Source will terminate the RTCP
                  packet.

        The default rules applying if no parameters are specified are as
        follows:

        RR and SDES packets MUST be aggregated and MUST lead to RSI
        packets being generated.  All other RTP packets MUST be
        terminated at the Distribution Source (or Feedback Target(s)).

        The SDP description needs only specify deviations from the
        default rules.  Aggregation of RR packets and forwarding of SR
        packet MUST NOT be changed.

   The token for the new SDP attribute is "rtcp-unicast" and the formal
   SDP ABNF syntax for the new attribute value is as follows:

   att-value  = "reflection"
              / "rsi" *(SP rsi-rule)

   rsi-rule   = processing ":" rtcp-type

Ott et al.        Internet Draft - Expires July 2008          [Page 36]


                      RTCP with Unicast Feedback


   processing = "aggr" / "forward" / "term" / token ;keep it extensible

   rtcp-type  = 3*3DIGIT    ;the RTCP type (192, 193, 202--208)


10.2 SSM Source Specification

   In a Source-Specific Multicast RTCP session, the address of the
   Distribution Source needs to be indicated both for source-specific
   joins to the multicast group, and for addressing unicast RTCP
   packets on the backchannel from receivers to the Distribution
   Source.

   This is achieved by following the proposal for SDP source filters
   documented in [4]. According to the specification, for SSM RTCP only
   the inclusion mode ("a=source-filter:incl") MUST be used.

   There SHOULD be exactly one "a=source-filter:incl" attribute listing
   the address of the sender.  The RTCP port MUST be derived from the
   m= line of the media description.

   An alternative Feedback Target address and port MAY be supplied
   using the SDP RTCP attribute [7], e.g., a=rtcp:<port> IN IP4
   192.0.2.1.  This attribute only defines the transport address of
   the Feedback Target and does not affect the SSM group specification
   for media stream reception.

   Two "source-filter" attributes MAY be present to indicate an IPv4
   and an IPv6 representation of the Distribution Source address.


10.3 RTP Source Identification

   The SSRC information for the Media Sender(s) MAY be communicated out
   of band.  One option for doing so is the Session Description
   Protocol (SDP) [5].  If such an indication is desired, the "ssrc"
   attribute [12] MUST be used for this purpose.  As per [12], the
   "cname" Source Attribute MUST be present.  Further Source Attributes
   MAY be specified as needed.

   If used in an SDP session description of an RTCP-SSM session, the
   ssrc MUST contain the SSRC intended to be used by the respective
   Media Sender and the cname MUST equal the CNAME for the Media
   Sender.  If present, the role SHOULD indicate the function of the
   RTP entity identified by this line for which presently only the
   "media-sender" is defined.

   Example:

       a=ssrc:314159 cname:iptv-sender@example.com

   In the above example, the Media Sender is identified to use the SSRC
   identifier 314159 and the CNAME iptv-sender@example.com.

Ott et al.        Internet Draft - Expires July 2008          [Page 37]


                      RTCP with Unicast Feedback



11. Security Considerations

   The level of security provided by the current RTP/RTCP model MUST
   NOT be diminished by the introduction of unicast feedback to the
   source. This section identifies the security weaknesses introduced
   by the feedback mechanism, potential threats, and level of
   protection that MUST be adopted. Any suggestions on increasing the
   level of security provided to RTP sessions above the current
   standard are RECOMMENDED but OPTIONAL. The final section outlines
   some security frameworks that are suitable to conform to this
   specification.


11.1 Assumptions

   RTP/RTCP is a protocol that carries real-time multimedia traffic,
   and therefore a main requirement is for any security framework to
   maintain as low overhead as possible. This includes the overhead of
   different applications and types of cryptographic operations, as
   well as the overhead to deploy or to create security infrastructure
   for large groups.

   Although the distribution of session parameters, typically encoded
   as SDP objects, through SAP [22], e-mail, or the web, is beyond the
   scope of this document, it is RECOMMENDED that the distribution
   method employs adequate security measures to ensure the integrity
   and authenticity of the information. Suitable solutions that meet
   the security requirements outlined here are included at the end of
   this section.

   In practice, the multicast and group distribution mechanism, e.g.,
   the SSM routing tree, is not immune to source IP address spoofing or
   traffic snooping, however such concerns are not discussed here. In
   all the following discussions, security weaknesses are addressed
   from the transport level or above.


11.2 Security threats

   Attacks on media distribution and the feedback architecture proposed
   in this document may take a variety of forms. An outline of the
   types of attacks in detail:

   a) Denial of Service (DoS)

      DoS is a major area of concern. Due to the nature of the
      communication architecture a DoS can be generated in a number of
      ways by using the unicast feedback channel to the attacker's
      advantage.




Ott et al.        Internet Draft - Expires July 2008          [Page 38]


                      RTCP with Unicast Feedback

   b) Packet Forgery

      Another potential area for attack is packet forgery. In
      particular, it is essential to protect the integrity of certain
      influential packets since compromise could directly affect the
      transmission characteristics of the whole group.

   c) Session Replay

      The potential for session recording and subsequent replay is an
      additional concern.  An attacker may not actually need to
      understand packet content, but simply have the ability to record
      the data stream and, at a later time, replay it to any receivers
      that are listening.

   d) Eavesdropping on a session

      The consequences of an attacker eavesdropping on a session
      already constitutes a security weakness; in addition,
      eavesdropping might facilitate other types of attacks, and is
      therefore considered a potential threat. For example, an attacker
      might be able to use the eavesdropped information to perform an
      intelligent DoS attack.


11.3 Architectural Contexts

   To better understand the requirements of the solution, the threats
   outlined above are addressed for each of the two communication
   contexts:

   a) Source-to-Receiver communication

      The downstream communication channel, from the source to the
      receivers, is critical to protect as it controls the behavior of
      the group; it conveys the bandwidth allocation for each receiver
      and hence the rate at which the RTCP traffic is unicast directly
      back to the source. All traffic that is distributed over the
      downstream channel is generated by a single source. Both the RTP
      data stream and the RTCP control data from the source are
      included in this context, with the RTCP data generated by the
      source being indirectly influenced by the group feedback.

      The downstream channel is vulnerable to four types of attacks. A
      denial of service attack is possible, but less of a concern. The
      worst case effect would be the transmission of large volumes of
      traffic over the distribution channel with the potential to reach
      every receiver, but only on a one-to-one basis. Consequently,
      this threat is no more pronounced than the current multicast ASM
      model. The real danger of denial of service attacks in this
      context comes indirectly via compromise of the source RTCP
      traffic. If receivers are provided with an incorrect group size
      estimate or bandwidth allowance, the return traffic to the source
      may create a distributed DoS effect on the source. Similarly, an

Ott et al.        Internet Draft - Expires July 2008          [Page 39]


                      RTCP with Unicast Feedback

      incorrect feedback address whether as a result of a malicious
      attack or by mistake, e.g., an IP address configuration (e.g.,
      typing) error, could directly create a denial of service attack
      on another host.

      An additional concern relating to Denial of Service attacks would
      come indirectly through the generation of fake BYE packets
      causing the source to adjust the advertised group size. A
      Distribution Source MUST follow the correct rules for timing out
      members in a session prior to reporting a change in the group
      size, which allows the authentic SSRC sufficient time to continue
      to report and consequently cancel the fake BYE report.

      The danger of Packet Forgery in the worst case may be to
      maliciously instigate a denial of service attack, e.g., if an
      attacker were capable of spoofing the source address and
      injecting incorrect packets into the data stream or intercepting
      the source RTCP traffic and modifying the fields.

      The Replay of a Session would have the effect of recreating the
      receiver feedback to the source address at a time when the source
      is not expecting additional traffic from a potentially large
      group. The consequence of this type of attack may be less
      effective on its own, but in combination with other attacks might
      be serious.

      Eavesdropping on the session would provide an attacker with
      information on the characteristics of the source-to-receiver
      traffic such as the frequency of RTCP traffic. If RTCP traffic is
      unencrypted, this might also provide valuable information on
      characteristics such as group size, Media Source SSRC(s) and
      transmission characteristics of the receivers back to the source.

   b) Receiver-to-Distribution-Source communication

      The second context is the return traffic from the group to the
      Distribution Source. This traffic should only consist of RTCP
      packets, and should include receiver reports, SDES information,
      BYE reports, extended reports (XR), feedback messages (RTPFB,
      PSFB) and possibly Application specific packets. The effects of
      compromise on a single or subset of receivers are not likely to
      have as great an impact as in context (a), however much of the
      responsibility for detecting compromise of the source data stream
      relies on the receivers.

      The effects of compromise of critical Distribution Source control
      information can be seriously amplified in the present context. A
      large group of receivers may unwittingly generate a distributed
      DoS attack on the Distribution Source in the event that the
      integrity of the source RTCP channel has been compromised and the
      compromise is not detected by the individual receivers.

      An attacker capable of instigating a Packet Forgery attack could
      introduce false RTCP traffic and create fake SSRC identifiers.

Ott et al.        Internet Draft - Expires July 2008          [Page 40]


                      RTCP with Unicast Feedback

      Such attacks might slow down the overall control channel data
      rate, since an incorrect perception of the group size may be
      created. Similarly, the creation of fake BYE reports by an
      attacker would cause some group size instability, but should not
      be effective as long as the correct timeout rules are applied by
      the source in removing SSRC entries from its database.

      A replay attack on receiver return data to the source would have
      the same implications as the generation of false SSRC identifiers
      and RTCP traffic to the source. Therefore, ensuring authenticity
      and freshness of the data source is important.

      Eavesdropping in this context potentially provides an attacker
      with a great deal of potentially personal information about a
      large group of receivers available from SDES packets. It would
      also provide an attacker with information on group traffic
      generation characteristics and parameters for calculating
      individual receiver bandwidth allowances.


11.4 Requirements in each context

   To address these threats, this section presents the security
   requirements for each context.

   a) The main threat in the source-to-receiver context concerns denial
      of service attacks through possible packet forgery. The forgery
      may take the form of interception and modification of packets
      from the source, or simply injecting false packets into the
      distribution channel. To combat these attacks, data integrity and
      source authenticity MUST be applied to source traffic. Since the
      consequences of eavesdropping do not affect the operation of the
      protocol, confidentiality is not a requirement in this context.
      However without confidentiality, access to personal and group
      characteristics information would be unrestricted to an external
      listener. Therefore confidentiality is RECOMMENDED.

   b) The threats in the receiver-to-source context also concern the
      same kinds of attacks but are considered less important than the
      downstream traffic compromise. All the security weaknesses are
      also applicable to the current RTP/RTCP security model and
      therefore only recommendations are made towards protection from
      compromise. Data integrity is RECOMMENDED to ensure that
      interception and modification of an individual receiver's RTCP
      traffic can be detected. This would protect against the false
      influence of group control information and the potentially more
      serious compromise of future services provided by the
      distribution functionality. In order to ensure security, data
      integrity and authenticity of receiver traffic is therefore also
      RECOMMENDED. The same situation applies as in the first context
      with respect to data confidentiality, and it is RECOMMENDED that
      precautions should be taken to protect the privacy of the data.



Ott et al.        Internet Draft - Expires July 2008          [Page 41]


                      RTCP with Unicast Feedback

   An additional security consideration that is not a component of this
   specification but has a direct influence upon the general security
   is the origin of the session initiation data. This involves the SDP
   parameters that are communicated to the members prior to the start
   of the session via channels such as an HTTP server, email, SAP, or
   other means. It is beyond the scope of this document to place any
   strict requirements on the external communication of such
   information, however suitably secure SDP communication approaches
   are outlined in section 11.7.


11.5 Discussion of trust models

   As identified in the previous sections, source authenticity is a
   fundamental requirement of the protocol. However, it is important to
   also clarify the model of trust that would be acceptable to achieve
   this requirement. There are two fundamental models that apply in
   this instance:

   a) The shared- key model where all authorized group members share
      the same key and can equally encrypt/decrypt the data. This
      method assumes that an out-of-band method is applied to the
      distribution of the shared group key ensuring that every key-
      holder is individually authorized to receive the key, and in the
      event of member departures from the group, a re-keying exercise
      can occur. The advantage of this model is that the costly
      processing associated with one-way key authentication techniques
      is avoided, as well as the need to execute additional cipher
      operations with alternative key sets on the same data set, e.g.,
      in the event that data confidentiality is also applied. The
      disadvantage is that, for very large groups where the receiver
      set becomes effectively untrusted, a shared key does not offer
      much protection.

   b) The public-key authentication model, using cryptosystems such as
      RSA-based or PGP authentication, provides a more secure method of
      source authentication at the expense of generating higher
      processing overhead. This is typically not recommended for Real-
      time data streams, but in the case of RTCP reports which are
      distributed with a minimum interval of 5 seconds, this may be a
      viable option (the processing overhead might still be too great
      for small, low-powered devices and should therefore be considered
      with caution). Wherever possible, however, the use of public key
      source authentication is preferable to the shared key model
      identified above.

   As concerns requirements for protocol acceptability, either model is
   acceptable, although it is RECOMMENDED that the more secure public-
   key based options should be applied wherever possible.






Ott et al.        Internet Draft - Expires July 2008          [Page 42]


                      RTCP with Unicast Feedback

11.6 Recommended security solutions

   This section presents some existing security mechanisms that are
   RECOMMENDED to suitably address the requirements outlined in section
   11.5. This is only intended as a guideline and it is acknowledged
   that there are other solutions that would also be suitable to be
   compliant with the specification.


  11.6.1 Secure Distribution of SDP Parameters

   a) SAP, HTTPS, Email -- Initial distribution of the SDP parameters
      for the session SHOULD use a secure mechanism such as the SAP
      authentication framework which allows an authentication
      certificate to be attached to the session announcements. Other
      methods might involve HTTPS or signed email content from a
      trusted source. However, some more commonly used techniques for
      distributing session information and starting media streams are
      RTSP [25] and SIP [14].

   b) RTSP -- RTSP provides a client or server initiated stream control
      mechanism for real-time multimedia streams. The session
      parameters are conveyed using SDP syntax and may adopt standard
      HTTP authentication mechanisms in combination with suitable
      network (e.g. IPsec) or transport (e.g. TLS) level security.

   c) SIP -- A typical use of SIP involving a unicast feedback
      identifier might be a client wishing to dynamically join a multi-
      party call on a multicast address using unicast RTCP feedback.
      The client would be required to authenticate the SDP session
      descriptor information returned by the SIP server. The
      recommended method for this, as outlined in the SIP specification
      [14], is to use an S/MIME message body containing the session
      parameters signed with an acceptable certificate.

   For the purposes of this profile, it is acceptable to use any
   suitably secure authentication mechanism which establishes the
   identity and integrity of the information provided to the client.


  11.6.2 Suitable Security Solutions for RTP Sessions with Unicast
  Feedback

   a) SRTP -- SRTP [3] is the recommended AVT security framework for
   RTP sessions. It specifies the general packet formats and cipher
   operations that are used, and provides the flexibility to select
   different stream ciphers based on preference/requirements. It can
   provide confidentiality of the RTP and RTCP packets as well as
   protection against integrity compromise and replay attacks. It
   provides authentication of the data stream using the shared- key
   trust model. Any suitable key-distribution mechanism can be used in
   parallel to the SRTP streams.



Ott et al.        Internet Draft - Expires July 2008          [Page 43]


                      RTCP with Unicast Feedback

   b) IPSEC -- A more general group security profile which might be
   used is the Group Domain of Interpretation [23], which defines the
   process of applying IPSec mechanisms to multicast groups. This
   requires the use of ESP in tunnel mode as the framework and it
   provides the capability to authenticate either using a shared key or
   individually through public-key mechanisms. It should be noted that
   using IPSec would break the 'transport independent' condition of RTP
   and would therefore not be useable for anything other than IP based
   communication.

   c) TESLA - TESLA [24] is a scheme that provides a more flexible
   approach to data authentication using time-based key disclosure. The
   authentication uses one-way pseudo-random key functions based on key
   chain hashes that have a short period of authenticity based on the
   key disclosure intervals from the source. As long as the receiver
   can ensure that the encrypted packet is received prior to the key
   disclosure by the source, this requires loose time synchronization
   between source and receivers, it can prove the authenticity of the
   packet. The scheme does introduce a delay into the packet
   distribution/decryption phase due to the key disclosure delay
   however the processing overhead is much lower than other standard
   public-key mechanisms and therefore may be more suited to small or
   energy-restricted devices.


  11.6.3 Secure Key Distribution Mechanisms

   a) MIKEY -- MIKEY [29] is the preferred solution for SRTP sessions
      providing a shared group key distribution mechanism and intra-
      session rekeying facilities.  If a partly protected communication
      channel exists, keys may also be conveyed using SDP as per [27].

   b) GSAKMP -- GSAKMP is the general solution favored for Multicast
      Secure group key distribution. It is the recommended key
      distribution solution for GDOI sessions.


12. Backwards Compatibility

   The use of unicast feedback to the source should not present any
   serious backwards compatibility issues. The RTP data streams should
   remain unaffected, as are the RTCP packets from the Media Sender(s)
   that continue to enable inter-stream synchronization in the case of
   multiple streams. The unicast transmission of RTCP data to a source
   that does not have the ability to redistribute the traffic either by
   simple reflection or through summaries could have serious security
   implications as outlined in Section 11, but would not actually break
   the operation of RTP. For RTP-compliant receivers that do not
   understand the unicast mechanisms, the RTCP traffic may still reach
   the group, in the event that an ASM distribution network is used, in
   which case there may be some duplication of traffic due to the
   reflection channel, but this should be ignored. It is anticipated,
   however, that typically the distribution network will not enable the
   receiver to multicast RTCP traffic, in which case the data will be

Ott et al.        Internet Draft - Expires July 2008          [Page 44]


                      RTCP with Unicast Feedback

   lost, and the RTCP calculations will not include those receivers. It
   is RECOMMENDED that any session that may involve non-unicast capable
   clients should always use the simple packet reflection mechanism to
   ensure that the packets received can be understood by all clients.


13. IANA Considerations

   The following contact information shall be used for all
   registrations included here:

     Contact:      Joerg Ott
                   mailto:jo@acm.org
                   tel:+358-9-451-2460

   Based on the guidelines suggested in [2], this document proposes 1
   new RTCP packet format to be registered with the RTCP Control Packet
   type (PT) Registry:

     Name:           RSI
     Long name:      Receiver Summary Information
     Value:          208
     Reference:      This document.

   This document defines a substructure for RTCP RSI packets.  A new
   sub-registry needs to be set up for the sub-report block type (SRBT)
   values for the RSI packet, with the following registrations created
   initially:

     Name:           IPv4 Address
     Long name:      IPv4 Feedback Target Address
     Value:          0
     Reference:      This document.

     Name:           IPv6 Address
     Long name:      IPv6 Feedback Target Address
     Value:          1
     Reference:      This document.

     Name:           DNS Name
     Long name:      DNS Name indicating Feedback Target Address
     Value:          2
     Reference:      This document.

     Name:           Loss
     Long name:      Loss distribution
     Value:          4
     Reference:      This document.

     Name:           Jitter
     Long name:      Jitter Distribution
     Value:          5
     Reference:      This document.


Ott et al.        Internet Draft - Expires July 2008          [Page 45]


                      RTCP with Unicast Feedback

     Name:           RTT
     Long name:      Round-trip time distribution
     Value:          6
     Reference:      This document.

     Name:           Cumulative loss
     Long name:      Cumulative loss distribution
     Value:          7
     Reference:      This document.

     Name:           Collisions
     Long name:      SSRC Collision list
     Value:          8
     Reference:      This document.

     Name:           Stats
     Long name:      General statistics
     Value:          10
     Reference:      This document.

     Name:           RTCP BW
     Long name:      RTCP Bandwidth indication
     Value:          11
     Reference:      This document.

     Name:           Group Info
     Long name:      RTCP Group and Average Packet size
     Value:          12
     Reference:      This document.

      The value 3 shall be reserved for a further way of specifying a
      feedback target address.  The value 3 MUST only be allocated for a
      use defined in an IETF Standards Track document.

      Further values may be registered on a first-come first-serve
      basis.  For each new registration, it is mandatory that a
      permanent, stable, and publicly accessible document exists that
      specifies the semantics of the registered parameter as well as the
      syntax and semantics of the associated sub-report block.  The
      general registration procedures of [5] apply.

   In the registry for SDP parameters, the attribute names "unicast-
   rtcp" need to be registered as follows:

   SDP Attribute ("att-field"):

     Attribute Name:     unicast-rtcp
     Long form:          RTCP Unicast feedback address
     Type of name:       att-field
     Type of attribute:  Media level only
     Subject to charset: No
     Purpose:            RFC XXXX
     Reference:          RFC XXXX
      Values:             See this document.

Ott et al.        Internet Draft - Expires July 2008          [Page 46]


                      RTCP with Unicast Feedback



14. Bibliography

   14.1 Normative References

   [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP -
        A Transport Protocol for Real-time Applications," RFC 3550 (STD
        64), July 2003.

   [2] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [3] M. Baugher, D. McGrew, D. Oran, R. Blom, E. Carrara, M. Naslund,
        and K. Norrman, "The Secure Real Time Transport Protocol", RFC
        3711, March 2004.

   [4] B. Quinn, R. Finlayson, "SDP Source-Filters", RFC 4570, July
        2006.

   [5] M. Handley, V. Jacobson, and C. Perkins, "SDP: Session
        Description Protocol", RFC 4566, July 2006.

   [6] H. Schulzrinne, S. Casner, "RTP Profile for Audio and Video
        Conferences with Minimal Control", RFC 3551 (STD 65), July 2003.

   [7] C. Huitema, "RTCP Attribute in SDP", RFC 3605, October 2003.

   [8] D. Meyer, R. Rockell, G. Shepherd, "Source-Specific Protocol
        Independent Multicast in 232/8", RFC 4608, August 2006.

   [9] H. Holbrook, B. Cain, B. Haberman, "Using Internet Group
        Management Protocol Version 3 (IGMPv3) and Multicast Listener
        Discovery Protocol Version 2 (MLDv2) for Source-Specific
        Multicast", RFC 4604, August 2006.

   [10] S. Casner, "Session Description Protocol (SDP) Bandwidth
        Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
        July 2003.

   [11] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC
        3629, November 2003.

   [12] J. Lennox, J. Ott, and T, Schierld, "Source-specific Media
        Attributes in the Session Description Protocol (SDP)," Internet
        Draft draft-ietf-mmusic-sdp-source-attributes-00.txt, November
        2007.

   [13] Bradner, S, "Key words for use in RFCs to Indicate Requirement
        Levels," RFC 2119, March 1997.





Ott et al.        Internet Draft - Expires July 2008          [Page 47]


                      RTCP with Unicast Feedback

   14.2 Informative References

   [14] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
        Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session
        Initiation Protocol", RFC 3261, June 2002.

   [15] J. Ott, S. Wenger, N. Sato, C. Burmeister, and J. Rey, "
        Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", RFC
        4585, July 2006.

   [16] Pusateri, T, "Distance Vector Multicast Routing Protocol",
        Internet Draft draft-ietf-idmr-dvmrp-v3-11.txt, Work in
        Progress, October 2003.

   [17] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
        Independent Multicast - Sparse Mode (PIM-SM): Protocol
        Specification (Revised)", RFC 4601, August 2006.

   [18] Adams, A, Nicholas, J, Siadak, W, "Protocol Independent
        Multicast- Dense Mode (PIM-DM)", RFC 3973, January 2005.

   [19] Bates, T, Chandra, R, Katz, D, Rekhter, Y, "Multiprotocol
        Extension of BGP-4", RFC 4760, January 2007.

   [20] D. Meyer, B. Fenner, "Multicast Source Discovery Protocol
        (MSDP)", Experimental RFC 3618, October 2003.

   [21] Session Directory Rendez-vous (SDR), developed at University
        College London by Mark Handley and the Multimedia Research
        Group, http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/.

   [22] M. Handley, C. Perkins, E. Whelan, "Session Announcement
        Protocol (SAP)", RFC 2974, October 2000.

   [23] M. Baugher, T. Hardjono, H. Harney, and B. Weis, "The Group
        Domain of Interpretation", RFC 3547, July 2003.

   [24] A. Perrig, D. Song, R. Canetti, D. Tygar, B. Briscoe, "TESLA:
        Multicast Source Authentication Transform Introduction", RFC
        4082, June 2005.

   [25] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming
        Protocol (RTSP)", RFC 2326, April 1998.

   [26] T. Friedman, R. Caceres, and A. Clark (eds), "RTCP Reporting
        Extensions", RFC 3611, November 2003.

   [27] F. Andreasen, M. Baugher, and D. Wing, "Session Description
        Protocol Security Descriptions for Media Streams", RFC 4568,
        July 2006.

   [28] J. Ott and E. Cararra, "Extended Secure RTP Profile for RTCP-
        based Feedback (RTP/SAVPF)", Internet Draft draft-ietf-avt-
        profile-savpf-12.txt, Work in Progress, November 2007.

Ott et al.        Internet Draft - Expires July 2008          [Page 48]


                      RTCP with Unicast Feedback


   [29] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman,
        "MIKEY: Multimedia Internet Keying", RFC 3830, August 2004.




















































Ott et al.        Internet Draft - Expires July 2008          [Page 49]


                      RTCP with Unicast Feedback

15. Appendix A: Examples for Sender Side Configurations

   This appendix describes a few common setups focusing on the
   contribution side, i.e., the communications between the Media
   Sender(s) and the Distribution Source.  In all cases, the same
   session description may be used for the distribution side as defined
   in the main part of this document.  This is because this
   specification defines only the media stream setup between the
   Distribution Source and the receivers.

   15.1 One Media Sender identical to the Distribution Source

      In the simplest case, the Distribution Source is identical to the
      Media Sender as depicted in figure 2.  Obviously, no further
      configuration for the interaction between the Media Sender and the
      Distribution Source is necessary.

                              Source-specific
             +--------+          Multicast
             |        |     +----------------> R(1)
             |M   D S |     |                    |
             |E   I O |  +--+                    |
             |D   S U |  |  |                    |
             |I   T R |  |  +-----------> R(2)   |
             |A   R C |->+-----  :          |    |
             |  = I E |  |  +------> R(n-1) |    |
             |S   B   |  |  |          |    |    |
             |E   U   |  +--+--> R(n)  |    |    |
             |N   T   |          |     |    |    |
             |D   I   |<---------+     |    |    |
             |E   O   |<---------------+    |    |
             |R   N   |<--------------------+    |
             |        |<-------------------------+
             +--------+            Unicast


      Figure 2: Media Source == Distribution Source

   15.2 One Media Sender

      In a slightly more complex scenario, the Media Sender and the
      Distribution Source are separate entities running on the same or
      different machines.  Hence, the Media Sender needs to deliver the
      media stream(s) to the Distribution Source.  This can be done
      either via unicasting the RTP stream, via ASM multicast, or via
      SSM.  In this case, the Distribution Source is responsible for
      forwarding the RTP packets comprising the media stream and the
      RTCP sender reports towards the receivers and conveying feedback
      from the receivers, as well as from itself, to the Media Sender.

      This scenario is depicted in figure 3.  The communication setup
      between the Media Sender and the Distribution Source may be
      statically configured or SDP may be used in conjunction with some
      signaling protocol to convey the session parameters.  Note that it

Ott et al.        Internet Draft - Expires July 2008          [Page 50]


                      RTCP with Unicast Feedback

      is a local configuration matter of the Distribution Source how to
      associate a session between the Media Sender and itself (the
      Contribution session) with the corresponding session between
      itself and the receivers (the Distribution session).

                                       Source-specific
                         +-----+          Multicast
                         |     |     +----------------> R(1)
                         | D S |     |                    |
                         | I O |  +--+                    |
                         | S U |  |  |                    |
         +--------+      | T R |  |  +-----------> R(2)   |
         | Media  |<---->| R C |->+-----  :          |    |
         | Sender |      | I E |  |  +------> R(n-1) |    |
         +--------+      | B   |  |  |          |    |    |
                         | U   |  +--+--> R(n)  |    |    |
                         | T   |          |     |    |    |
                         | I   |<---------+     |    |    |
                         | O   |<---------------+    |    |
                         | N   |<--------------------+    |
                         |     |<-------------------------+
                         +-----+            Unicast

            Contribution               Distribution
              Session                    Session
          (unicast or ASM)                 (SSM)

       Figure 3: One Media Sender Separate from Distribution Source


   15.3 Three Media Senders, Unicast Contribution

   Similar considerations apply if three Media Senders transmit to an
   SSM multicast group via the Distribution Source and individually
   send their media stream RTP packets via unicast to the Distribution
   Source.

   In this case, the responsibilities of the Distribution Source are a
   superset to the previous case: the Distribution Source also needs to
   relay media traffic from each Media Sender to the receivers and to
   forward (aggregated) feedback from the receivers to the Media
   Senders.  In addition, the Distribution Source relays RTCP packets
   (SRs) from each Media Sender to the other two.

   The configuration of the Media Senders is identical to the previous
   case.  It is just the Distribution Source that must be aware that
   there are multiple senders and then perform the necessary relaying.
   The transport address for the RTP session at the Distribution Source
   may be identical for all Media Senders (which may make correlation
   easier) or different addresses may be used.

   This setup is depicted in figure 4.



Ott et al.        Internet Draft - Expires July 2008          [Page 51]


                      RTCP with Unicast Feedback

                                    Source-specific
                      +-----+          Multicast
      +--------+      |     |     +----------------> R(1)
      | Media  |<---->| D S |     |                    |
      |Sender 1|      | I O |  +--+                    |
      +--------+      | S U |  |  |                    |
                      | T R |  |  +-----------> R(2)   |
      +--------+      | R C |->+-----  :          |    |
      | Media  |<---->| I E |  |  +------> R(n-1) |    |
      |Sender 2|      | B   |  |  |          |    |    |
      +--------+      | U   |  +--+--> R(n)  |    |    |
                      | T   |          |     |    |    |
      +--------+      | I   |<---------+     |    |    |
      | Media  |<---->| O   |<---------------+    |    |
      |Sender 3|      | N   |<--------------------+    |
      +--------+      |     |<-------------------------+
                      +-----+            Unicast

            Contribution               Distribution
              Session                    Session
             (unicast)                    (SSM)

      Figure 4: Three Media Senders, unicast contribution


   15.4 Three Media Senders, ASM Contribution Group

      In this final example, the individual unicast contribution
      sessions between the Media Senders and the Distribution Source are
      replaced by a single ASM contribution group (i.e., a single common
      RTP session).  Consequently, all Media Senders receive each
      other's traffic by means of IP-layer multicast and the
      Distribution Source no longer needs to perform explicit forwarding
      between the Media Senders.  Of course, the Distribution Source
      still forwards feedback information received from the receivers
      (optionally as summaries) to the ASM contribution group.

      The ASM contribution group may be statically configured or the
      necessary information can be communicated using a standard SDP
      session description for a multicast session.  Again, it is up to
      the implementation of the Distribution Source to properly
      associate the ASM contribution session and the SSM distribution
      sessions.

      Figure 5 shows this scenario.










Ott et al.        Internet Draft - Expires July 2008          [Page 52]


                      RTCP with Unicast Feedback


                     _                   Source-specific
                    / \    +-----+          Multicast
      +--------+   |   |   |     |     +----------------> R(1)
      | Media  |<->| A |   | D S |     |                    |
      |Sender 1|   | S |   | I O |  +--+                    |
      +--------+   | M |   | S U |  |  |                    |
                   |   |   | T R |  |  +-----------> R(2)   |
      +--------+   | G |   | R C |->+-----  :          |    |
      | Media  |<->| r |<->| I E |  |  +------> R(n-1) |    |
      |Sender 2|   | o |   | B   |  |  |          |    |    |
      +--------+   | u |   | U   |  +--+--> R(n)  |    |    |
                   | p |   | T   |          |     |    |    |
      +--------+   |   |   | I   |<---------+     |    |    |
      | Media  |<->|   |   | O   |<---------------+    |    |
      |Sender 3|    \_/    | N   |<--------------------+    |
      +--------+           |     |<-------------------------+
                           +-----+            Unicast

               Contribution            Distribution
                 Session                  Session
                  (ASM)                   (SSM)


         Figure 5: Three Media Sender in ASM Group






























Ott et al.        Internet Draft - Expires July 2008          [Page 53]


                      RTCP with Unicast Feedback

16. Appendix B: Distribution Report processing at the receiver

   16.1 Algorithm

   Example processing of Loss Distribution Values
   X values represent the loss percentage.
   Y values represent the number of receivers.

   Number of x values is the NDB value
   xrange = Max Distribution Value(MaDV) - Min Distribution Value(MnDV)
   First data point = MnDV,first ydata
   then
   For each ydata => xdata += (MnDV + (xrange / NDB))

   16.2 Pseudo-code

   Packet Variables -> factor,NDB,MnDVL,MaDV
   Code variables -> xrange, ydata[NDB],x,y

   xrange = MaDV - MnDV
   x = MnDV;

   for(i=0;i<NDB;i++) {
        y = (ydata[i] * factor);
        /*OUTPUT x and y values*/
        x += (xrange / NDB);
   }


   16.3 Application Uses and Scenarios

   Providing a distribution function in a feedback message has a number
   of uses for different types of applications. Although this section
   enumerates potential uses for the distribution scheme, it is
   anticipated that future applications might benefit from it in ways
   not addressed in this document. Due to the flexible nature of the
   summarization format, future extensions may easily be added. Some of
   the scenarios addressed in this section envisage potential uses
   beyond a simple SSM architecture. For example, single-source group
   topologies where every receiver may in fact also be capable of
   becoming the source. Another example may be multiple SSM topologies,
   which when combined, make up a larger distribution tree.

   A distribution of values is useful as input into any algorithm,
   multicast or otherwise, that could be optimized or tuned as a result
   of having access to the feedback values for all group members.
   Following is a list of example areas that might benefit from
   distribution information:

   - The parameterization of a multicast Forward Error Correction (FEC)
   algorithm. Given an accurate estimate of the distribution of
   reported losses, a source or other distribution agent, which does
   not have a global view, would be able to tune the degree of
   redundancy built in to the FEC stream. The distribution might help

Ott et al.        Internet Draft - Expires July 2008          [Page 54]


                      RTCP with Unicast Feedback

   to identify whether the majority of the group is experiencing high
   levels of loss, or whether in fact the high loss reports are only
   from a small subset of the group. Similarly, this data might enable
   a receiver to make a more informed decision about whether it should
   leave a group that includes a very high percentage of the worst-case
   reporters.

   - The organization of a multicast data stream into useful layers for
   layered coding schemes. The distribution of packet losses and delay
   would help to identify what percentage of members experience various
   loss and delay levels, and thus how the data stream bandwidth might
   be partitioned to suit the group conditions. This would require the
   same algorithm to be used by both senders and receivers in order to
   derive the same results.

   - The establishment of a suitable feedback threshold. An application
   might be interested to generate feedback values when above (or
   below) a particular threshold.  However, determining an appropriate
   threshold may be difficult when the range and distribution of
   feedback values is not known a priori.  In a very large group,
   knowing the distribution of feedback values would allow a reasonable
   threshold value to be established, and in turn would have the
   potential to prevent message implosion if many group members share
   the same feedback value. A typical application might include a
   sensor network that gauges temperature or some other natural
   phenomenon.  Another example is a network of mobile devices
   interested in tracking signal power to assist with hand-off to a
   different distribution device when power becomes too low.

   - The tuning of Suppression algorithms. Having access to the
   distribution of round trip times, bandwidth, and network loss would
   allow optimization of wake-up timers and proper adjustment of the
   Suppression interval bounds.  In addition, biased wake-up functions
   could be created not only to favor the early response from more
   capable group members, but also to smooth out responses from
   subsequent respondents and to avoid bursty response traffic.

   - Leader election among a group of processes based on the maximum or
   minimum of some attribute value. Knowledge of the distribution of
   values would allow a group of processes to select a leader process
   or processes to act on behalf of the group. Leader election can
   promote scalability when group sizes become extremely large.


   16.4 Distribution Sub-report creation at the source

   The following example demonstrates two different ways to convey loss
   data using the generic format of a Loss sub-report block (section
   7.1.4). The same techniques could also be applied to representing
   other distribution types.

   1) The first method attempts to represent the data in as few bytes
   as possible.


Ott et al.        Internet Draft - Expires July 2008          [Page 55]


                      RTCP with Unicast Feedback

   2) The second method conveys all values without providing any
   savings in bandwidth.


   Data Set
   X values indicate loss percentage reported, Y values indicate the
   number of receivers reporting that loss percentage

        X -  0  |  1  | 2 |  3   |   4  |  5   |  6   |  7   |  8  |  9
        Y - 1000| 800 | 6 | 1800 | 2600 | 3120 | 2300 | 1100 | 200 | 103

        X - 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19
        Y - 74 | 21 | 30 | 65 | 60 | 80 |  6 |  7 |  4 |  5

        X - 20 | 21 | 22  |  23  |  24  | 25  | 26  | 27  | 28  | 29
        Y - 2  | 10 | 870 | 2300 | 1162 | 270 | 234 | 211 | 196 | 205


        X - 30  | 31  | 32  | 33 | 34 | 35 | 36 | 37 | 38 | 39
        Y - 163 | 174 | 103 | 94 | 76 | 52 | 68 | 79 | 42 | 4


   Constant value
   Due to the size of the multiplicative factor field being 4 bits, the
   Maximum multiplicative value is 15.

   The Distribution Type field of this packet would be value 1 since it
   it represents loss data.


   Example: 1st Method

   Description
   The minimal method of conveying data, i.e., small amount of
   bytes used to convey the values.

                                                              [Algorithm
   Attempt to fit the data set into a small sub-report size, selected
   length 8 Octets

   Can we split the range (0 - 39) into 16 4-bit values?
   The largest bucket value would in this case the bucket for X values 5
   - 7.5, the sum of which is 5970. An MF value of 9 will generate a
   multiplicative factor of 2^9, or 512 which multiplied by the max
   bucket value produces a maximum real value of 7680.


   The packet fields will contain the values:
   Header distribution Block
   Distribution Type:                       1
   Number of Data Buckets:                  16
   Multiplicative Factor:                   9
   Packet Length field:                     5 (5 * 4 => 20 Bytes)
   Minimum Data Value:                      0

Ott et al.        Internet Draft - Expires July 2008          [Page 56]


                      RTCP with Unicast Feedback

   Maximum Data Value:                      39
   Data Bucket values:                      (each value is 16-bits)

   Results, 4-bit buckets:


        X - 0 - 2.5 | 2.5 - 5 | 5 - 7.5 | 7.5 - 10
       (Y -   1803  |   4403  |   5970  |   853 )  ACTUAL
        Y -    4    |    9    |    12   |    2

        X - 10 - 12.5 | 12.5 - 15 | 15 - 17.5 | 17.5 - 20
       (Y -     110   |    140    |    89.5   |    12.5)  ACTUAL
        Y -      0    |     0     |     0     |      0

        X - 20 - 22.5 | 22.5 - 25 | 25 - 27.5 | 27.5 - 30
       (Y -    447    |    3897   |    609.5  |   506.5)  ACTUAL
        Y -     1     |     8     |      1    |     1

        X - 30 - 32.5 | 32.5 - 35 | 35 - 37.5 | 37.5 - 40
       (Y -   388.5   |    221.5  |   159.5   |    85.5)  ACTUAL
        Y -    1      |      0    |     0     |     0





   Example: 2nd Method

   Description
   This demonstrates the most accurate method for representing the data
   set. This method doesn't attempt to optimise any values.

   Algorithm
   Identify the highest value and select buckets large enough to convey
   the exact values, i.e. no multiplicative factor.

   The highest value is 3120. This requires 12 bits (closest 2 bit
   boundary) to represent, therefore it will use 60 bytes to represent
   the entire distribution. This is within the max packet size,
   therefore all data will fit within one sub-report block. The
   multiplicative value will be 1.

   The packet fields will contain the values:

   Header Distribution Block
   Distribution Type:                        1
   Number of Data Buckets:                   40
   Multiplicative Factor:                    0
   Packet Length field:                      18 (18 * 4 => 72 Bytes)
   Minimum Loss Value:                       0
   Maximum Loss Value:                       39


   Bucket values are the same as initial data set.

Ott et al.        Internet Draft - Expires July 2008          [Page 57]


                      RTCP with Unicast Feedback


   Result
   The selection of which of the three methods outlined above might be
   determined by a congestion parameter, or a user preference. The
   overhead associated with processing the packets is likely to differ
   very little between the techniques. The savings in bandwidth are
   apparent however, using 20, 52 and 72 octets respectively. These
   values would vary more widely for a larger data set with less
   correlation between results.


18. ACKNOWLEDGEMENTS

   The authors would like to thank Magnus Westerlund, Dave Oran, Tom
   Taylor and Colin Perkins for detailed reviews and valuable comments.


19. AUTHORS' ADDRESSES

   Joerg Ott
   Helsinki University of Technology
   Networking Laboratory
   PO Box 3000
   FIN-02015 TKK
   jo@acm.org

   Julian Chesterfield
   University of Cambridge
   Computer Laboratory,
   15 JJ Thompson Avenue
   Cambridge
   CB3 0FD
   UK
   Julian.chesterfield@cl.cam.ac.uk

   Eve Schooler
   Intel Research / CTL
   MS RNB6-61
   2200 Mission College Blvd.
   Santa Clara, CA, USA 95054-1537
   eve_(underscore) schooler (at) acm.org


20. IPR Notice

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.


Ott et al.        Internet Draft - Expires July 2008          [Page 58]


                      RTCP with Unicast Feedback

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


21. FULL COPYRIGHT STATEMENT

   Copyright (C) The IETF Trust (2008).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.



























Ott et al.        Internet Draft - Expires July 2008          [Page 59]