Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 1889

RTP: A Transport Protocol for Real-Time Applications

Pages: 75
Obsoleted by:  3550
Part 2 of 3 – Pages 15 to 44
First   Prev   Next

ToP   noToC   RFC1889 - Page 15   prevText
6.  RTP Control Protocol -- RTCP

   The RTP control protocol (RTCP) is based on the periodic transmission
   of control packets to all participants in the session, using the same
   distribution mechanism as the data packets. The underlying protocol
   must provide multiplexing of the data and control packets, for
   example using separate port numbers with UDP. RTCP performs four

        1.   The primary function is to provide feedback on the quality
             of the data distribution. This is an integral part of the
             RTP's role as a transport protocol and is related to the
             flow and congestion control functions of other transport
             protocols. The feedback may be directly useful for control
             of adaptive encodings [8,9], but experiments with IP
ToP   noToC   RFC1889 - Page 16
             multicasting have shown that it is also critical to get
             feedback from the receivers to diagnose faults in the
             distribution. Sending reception feedback reports to all
             participants allows one who is observing problems to
             evaluate whether those problems are local or global. With a
             distribution mechanism like IP multicast, it is also
             possible for an entity such as a network service provider
             who is not otherwise involved in the session to receive the
             feedback information and act as a third-party monitor to
             diagnose network problems. This feedback function is
             performed by the RTCP sender and receiver reports,
             described below in Section 6.3.

        2.   RTCP carries a persistent transport-level identifier for an
             RTP source called the canonical name or CNAME, Section
             6.4.1. Since the SSRC identifier may change if a conflict
             is discovered or a program is restarted, receivers require
             the CNAME to keep track of each participant. Receivers also
             require the CNAME to associate multiple data streams from a
             given participant in a set of related RTP sessions, for
             example to synchronize audio and video.

        3.   The first two functions require that all participants send
             RTCP packets, therefore the rate must be controlled in
             order for RTP to scale up to a large number of
             participants. By having each participant send its control
             packets to all the others, each can independently observe
             the number of participants. This number is used to
             calculate the rate at which the packets are sent, as
             explained in Section 6.2.

        4.   A fourth, optional function is to convey minimal session
             control information, for example participant identification
             to be displayed in the user interface. This is most likely
             to be useful in "loosely controlled" sessions where
             participants enter and leave without membership control or
             parameter negotiation. RTCP serves as a convenient channel
             to reach all the participants, but it is not necessarily
             expected to support all the control communication
             requirements of an application. A higher-level session
             control protocol, which is beyond the scope of this
             document, may be needed.

   Functions 1-3 are mandatory when RTP is used in the IP multicast
   environment, and are recommended for all environments. RTP
   application designers are advised to avoid mechanisms that can only
   work in unicast mode and will not scale to larger numbers.
ToP   noToC   RFC1889 - Page 17
6.1 RTCP Packet Format

   This specification defines several RTCP packet types to carry a
   variety of control information:

   SR: Sender report, for transmission and reception statistics from
        participants that are active senders

   RR: Receiver report, for reception statistics from participants that
        are not active senders

   SDES: Source description items, including CNAME

   BYE: Indicates end of participation

   APP: Application specific functions

   Each RTCP packet begins with a fixed part similar to that of RTP data
   packets, followed by structured elements that may be of variable
   length according to the packet type but always end on a 32-bit
   boundary. The alignment requirement and a length field in the fixed
   part are included to make RTCP packets "stackable". Multiple RTCP
   packets may be concatenated without any intervening separators to
   form a compound RTCP packet that is sent in a single packet of the
   lower layer protocol, for example UDP. There is no explicit count of
   individual RTCP packets in the compound packet since the lower layer
   protocols are expected to provide an overall length to determine the
   end of the compound packet.

   Each individual RTCP packet in the compound packet may be processed
   independently with no requirements upon the order or combination of
   packets. However, in order to perform the functions of the protocol,
   the following constraints are imposed:

        o Reception statistics (in SR or RR) should be sent as often as
         bandwidth constraints will allow to maximize the resolution of
         the statistics, therefore each periodically transmitted
         compound RTCP packet should include a report packet.

        o New receivers need to receive the CNAME for a source as soon
         as possible to identify the source and to begin associating
         media for purposes such as lip-sync, so each compound RTCP
         packet should also include the SDES CNAME.

        o The number of packet types that may appear first in the
         compound packet should be limited to increase the number of
         constant bits in the first word and the probability of
         successfully validating RTCP packets against misaddressed RTP
ToP   noToC   RFC1889 - Page 18
         data packets or other unrelated packets.

   Thus, all RTCP packets must be sent in a compound packet of at least
   two individual packets, with the following format recommended:

   Encryption prefix:  If and only if the compound packet is to be
        encrypted, it is prefixed by a random 32-bit quantity redrawn
        for every compound packet transmitted.

   SR or RR:  The first RTCP packet in the compound packet must always
        be a report packet to facilitate header validation as described
        in Appendix A.2. This is true even if no data has been sent nor
        received, in which case an empty RR is sent, and even if the
        only other RTCP packet in the compound packet is a BYE.

   Additional RRs:  If the number of sources for which reception
        statistics are being reported exceeds 31, the number that will
        fit into one SR or RR packet, then additional RR packets should
        follow the initial report packet.

   SDES:  An SDES packet containing a CNAME item must be included in
        each compound RTCP packet. Other source description items may
        optionally be included if required by a particular application,
        subject to bandwidth constraints (see Section 6.2.2).

   BYE or APP:  Other RTCP packet types, including those yet to be
        defined, may follow in any order, except that BYE should be the
        last packet sent with a given SSRC/CSRC. Packet types may appear
        more than once.

   It is advisable for translators and mixers to combine individual RTCP
   packets from the multiple sources they are forwarding into one
   compound packet whenever feasible in order to amortize the packet
   overhead (see Section 7). An example RTCP compound packet as might be
   produced by a mixer is shown in Fig. 1.  If the overall length of a
   compound packet would exceed the maximum transmission unit (MTU) of
   the network path, it may be segmented into multiple shorter compound
   packets to be transmitted in separate packets of the underlying
   protocol. Note that each of the compound packets must begin with an
   SR or RR packet.

   An implementation may ignore incoming RTCP packets with types unknown
   to it. Additional RTCP packet types may be registered with the
   Internet Assigned Numbers Authority (IANA).
ToP   noToC   RFC1889 - Page 19
6.2 RTCP Transmission Interval

   if encrypted: random 32-bit integer
    |[------- packet -------][----------- packet -----------][-packet-]
    |             receiver reports          chunk        chunk
    V                                    item  item     item  item
   |R[SR|# sender #site#site][SDES|# CNAME PHONE |#CNAME LOC][BYE##why]
   |R[  |# report #  1 #  2 ][    |#             |#         ][   ##   ]
   |R[  |#        #    #    ][    |#             |#         ][   ##   ]
   |R[  |#        #    #    ][    |#             |#         ][   ##   ]
   |<------------------  UDP packet (compound packet) --------------->|


              Figure 1: Example of an RTCP compound packet

   RTP is designed to allow an application to scale automatically over
   session sizes ranging from a few participants to thousands. For
   example, in an audio conference the data traffic is inherently self-
   limiting because only one or two people will speak at a time, so with
   multicast distribution the data rate on any given link remains
   relatively constant independent of the number of participants.
   However, the control traffic is not self-limiting. If the reception
   reports from each participant were sent at a constant rate, the
   control traffic would grow linearly with the number of participants.
   Therefore, the rate must be scaled down.

   For each session, it is assumed that the data traffic is subject to
   an aggregate limit called the "session bandwidth" to be divided among
   the participants. This bandwidth might be reserved and the limit
   enforced by the network, or it might just be a reasonable share. The
   session bandwidth may be chosen based or some cost or a priori
   knowledge of the available network bandwidth for the session. It is
   somewhat independent of the media encoding, but the encoding choice
   may be limited by the session bandwidth. The session bandwidth
   parameter is expected to be supplied by a session management
   application when it invokes a media application, but media
   applications may also set a default based on the single-sender data
   bandwidth for the encoding selected for the session. The application
   may also enforce bandwidth limits based on multicast scope rules or
   other criteria.
ToP   noToC   RFC1889 - Page 20
   Bandwidth calculations for control and data traffic include lower-
   layer transport and network protocols (e.g., UDP and IP) since that
   is what the resource reservation system would need to know. The
   application can also be expected to know which of these protocols are
   in use. Link level headers are not included in the calculation since
   the packet will be encapsulated with different link level headers as
   it travels.

   The control traffic should be limited to a small and known fraction
   of the session bandwidth: small so that the primary function of the
   transport protocol to carry data is not impaired; known so that the
   control traffic can be included in the bandwidth specification given
   to a resource reservation protocol, and so that each participant can
   independently calculate its share. It is suggested that the fraction
   of the session bandwidth allocated to RTCP be fixed at 5%. While the
   value of this and other constants in the interval calculation is not
   critical, all participants in the session must use the same values so
   the same interval will be calculated. Therefore, these constants
   should be fixed for a particular profile.

   The algorithm described in Appendix A.7 was designed to meet the
   goals outlined above. It calculates the interval between sending
   compound RTCP packets to divide the allowed control traffic bandwidth
   among the participants. This allows an application to provide fast
   response for small sessions where, for example, identification of all
   participants is important, yet automatically adapt to large sessions.
   The algorithm incorporates the following characteristics:

        o Senders are collectively allocated at least 1/4 of the control
         traffic bandwidth so that in sessions with a large number of
         receivers but a small number of senders, newly joining
         participants will more quickly receive the CNAME for the
         sending sites.

        o The calculated interval between RTCP packets is required to be
         greater than a minimum of 5 seconds to avoid having bursts of
         RTCP packets exceed the allowed bandwidth when the number of
         participants is small and the traffic isn't smoothed according
         to the law of large numbers.

        o The interval between RTCP packets is varied randomly over the
         range [0.5,1.5] times the calculated interval to avoid
         unintended synchronization of all participants [10].  The first
         RTCP packet sent after joining a session is also delayed by a
         random variation of half the minimum RTCP interval in case the
         application is started at multiple sites simultaneously, for
         example as initiated by a session announcement.
ToP   noToC   RFC1889 - Page 21
        o A dynamic estimate of the average compound RTCP packet size is
         calculated, including all those received and sent, to
         automatically adapt to changes in the amount of control
         information carried.

   This algorithm may be used for sessions in which all participants are
   allowed to send. In that case, the session bandwidth parameter is the
   product of the individual sender's bandwidth times the number of
   participants, and the RTCP bandwidth is 5% of that.

6.2.1 Maintaining the number of session members

   Calculation of the RTCP packet interval depends upon an estimate of
   the number of sites participating in the session. New sites are added
   to the count when they are heard, and an entry for each is created in
   a table indexed by the SSRC or CSRC identifier (see Section 8.2) to
   keep track of them. New entries may not be considered valid until
   multiple packets carrying the new SSRC have been received (see
   Appendix A.1). Entries may be deleted from the table when an RTCP BYE
   packet with the corresponding SSRC identifier is received.

   A participant may mark another site inactive, or delete it if not yet
   valid, if no RTP or RTCP packet has been received for a small number
   of RTCP report intervals (5 is suggested). This provides some
   robustness against packet loss. All sites must calculate roughly the
   same value for the RTCP report interval in order for this timeout to
   work properly.

   Once a site has been validated, then if it is later marked inactive
   the state for that site should still be retained and the site should
   continue to be counted in the total number of sites sharing RTCP
   bandwidth for a period long enough to span typical network
   partitions.  This is to avoid excessive traffic, when the partition
   heals, due to an RTCP report interval that is too small. A timeout of
   30 minutes is suggested. Note that this is still larger than 5 times
   the largest value to which the RTCP report interval is expected to
   usefully scale, about 2 to 5 minutes.

6.2.2 Allocation of source description bandwidth

   This specification defines several source description (SDES) items in
   addition to the mandatory CNAME item, such as NAME (personal name)
   and EMAIL (email address). It also provides a means to define new
   application-specific RTCP packet types. Applications should exercise
   caution in allocating control bandwidth to this additional
   information because it will slow down the rate at which reception
   reports and CNAME are sent, thus impairing the performance of the
   protocol. It is recommended that no more than 20% of the RTCP
ToP   noToC   RFC1889 - Page 22
   bandwidth allocated to a single participant be used to carry the
   additional information.  Furthermore, it is not intended that all
   SDES items should be included in every application. Those that are
   included should be assigned a fraction of the bandwidth according to
   their utility.  Rather than estimate these fractions dynamically, it
   is recommended that the percentages be translated statically into
   report interval counts based on the typical length of an item.

   For example, an application may be designed to send only CNAME, NAME
   and EMAIL and not any others. NAME might be given much higher
   priority than EMAIL because the NAME would be displayed continuously
   in the application's user interface, whereas EMAIL would be displayed
   only when requested. At every RTCP interval, an RR packet and an SDES
   packet with the CNAME item would be sent. For a small session
   operating at the minimum interval, that would be every 5 seconds on
   the average. Every third interval (15 seconds), one extra item would
   be included in the SDES packet. Seven out of eight times this would
   be the NAME item, and every eighth time (2 minutes) it would be the
   EMAIL item.

   When multiple applications operate in concert using cross-application
   binding through a common CNAME for each participant, for example in a
   multimedia conference composed of an RTP session for each medium, the
   additional SDES information might be sent in only one RTP session.
   The other sessions would carry only the CNAME item.

6.3 Sender and Receiver Reports

   RTP receivers provide reception quality feedback using RTCP report
   packets which may take one of two forms depending upon whether or not
   the receiver is also a sender. The only difference between the sender
   report (SR) and receiver report (RR) forms, besides the packet type
   code, is that the sender report includes a 20-byte sender information
   section for use by active senders. The SR is issued if a site has
   sent any data packets during the interval since issuing the last
   report or the previous one, otherwise the RR is issued.

   Both the SR and RR forms include zero or more reception report
   blocks, one for each of the synchronization sources from which this
   receiver has received RTP data packets since the last report. Reports
   are not issued for contributing sources listed in the CSRC list. Each
   reception report block provides statistics about the data received
   from the particular source indicated in that block. Since a maximum
   of 31 reception report blocks will fit in an SR or RR packet,
   additional RR packets may be stacked after the initial SR or RR
   packet as needed to contain the reception reports for all sources
   heard during the interval since the last report.
ToP   noToC   RFC1889 - Page 23
   The next sections define the formats of the two reports, how they may
   be extended in a profile-specific manner if an application requires
   additional feedback information, and how the reports may be used.
   Details of reception reporting by translators and mixers is given in
   Section 7.

6.3.1 SR: Sender report RTCP packet

 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|    RC   |   PT=SR=200   |             length            | header
|                         SSRC of sender                        |
|              NTP timestamp, most significant word             | sender
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info
|             NTP timestamp, least significant word             |
|                         RTP timestamp                         |
|                     sender's packet count                     |
|                      sender's octet count                     |
|                 SSRC_1 (SSRC of first source)                 | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| fraction lost |       cumulative number of packets lost       |   1
|           extended highest sequence number received           |
|                      interarrival jitter                      |
|                         last SR (LSR)                         |
|                   delay since last SR (DLSR)                  |
|                 SSRC_2 (SSRC of second source)                | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
:                               ...                             :   2
|                  profile-specific extensions                  |

   The sender report packet consists of three sections, possibly
   followed by a fourth profile-specific extension section if defined.
   The first section, the header, is 8 octets long. The fields have the
   following meaning:
ToP   noToC   RFC1889 - Page 24
   version (V): 2 bits
        Identifies the version of RTP, which is the same in RTCP packets
        as in RTP data packets. The version defined by this
        specification is two (2).

   padding (P): 1 bit
        If the padding bit is set, this RTCP packet contains some
        additional padding octets at the end which are not part of the
        control information. The last octet of the padding is a count of
        how many padding octets should be ignored. Padding may be needed
        by some encryption algorithms with fixed block sizes. In a
        compound RTCP packet, padding should only be required on the
        last individual packet because the compound packet is encrypted
        as a whole.

   reception report count (RC): 5 bits
        The number of reception report blocks contained in this packet.
        A value of zero is valid.

   packet type (PT): 8 bits
        Contains the constant 200 to identify this as an RTCP SR packet.

   length: 16 bits
        The length of this RTCP packet in 32-bit words minus one,
        including the header and any padding. (The offset of one makes
        zero a valid length and avoids a possible infinite loop in
        scanning a compound RTCP packet, while counting 32-bit words
        avoids a validity check for a multiple of 4.)

   SSRC: 32 bits
        The synchronization source identifier for the originator of this
        SR packet.

   The second section, the sender information, is 20 octets long and is
   present in every sender report packet. It summarizes the data
   transmissions from this sender. The fields have the following

   NTP timestamp: 64 bits
        Indicates the wallclock time when this report was sent so that
        it may be used in combination with timestamps returned in
        reception reports from other receivers to measure round-trip
        propagation to those receivers. Receivers should expect that the
        measurement accuracy of the timestamp may be limited to far less
        than the resolution of the NTP timestamp. The measurement
        uncertainty of the timestamp is not indicated as it may not be
        known. A sender that can keep track of elapsed time but has no
        notion of wallclock time may use the elapsed time since joining
ToP   noToC   RFC1889 - Page 25
        the session instead. This is assumed to be less than 68 years,
        so the high bit will be zero. It is permissible to use the
        sampling clock to estimate elapsed wallclock time. A sender that
        has no notion of wallclock or elapsed time may set the NTP
        timestamp to zero.

   RTP timestamp: 32 bits
        Corresponds to the same time as the NTP timestamp (above), but
        in the same units and with the same random offset as the RTP
        timestamps in data packets. This correspondence may be used for
        intra- and inter-media synchronization for sources whose NTP
        timestamps are synchronized, and may be used by media-
        independent receivers to estimate the nominal RTP clock
        frequency. Note that in most cases this timestamp will not be
        equal to the RTP timestamp in any adjacent data packet. Rather,
        it is calculated from the corresponding NTP timestamp using the
        relationship between the RTP timestamp counter and real time as
        maintained by periodically checking the wallclock time at a
        sampling instant.

   sender's packet count: 32 bits
        The total number of RTP data packets transmitted by the sender
        since starting transmission up until the time this SR packet was
        generated.  The count is reset if the sender changes its SSRC

   sender's octet count: 32 bits
        The total number of payload octets (i.e., not including header
        or padding) transmitted in RTP data packets by the sender since
        starting transmission up until the time this SR packet was
        generated. The count is reset if the sender changes its SSRC
        identifier. This field can be used to estimate the average
        payload data rate.

   The third section contains zero or more reception report blocks
   depending on the number of other sources heard by this sender since
   the last report. Each reception report block conveys statistics on
   the reception of RTP packets from a single synchronization source.
   Receivers do not carry over statistics when a source changes its SSRC
   identifier due to a collision. These statistics are:

   SSRC_n (source identifier): 32 bits
        The SSRC identifier of the source to which the information in
        this reception report block pertains.

   fraction lost: 8 bits
        The fraction of RTP data packets from source SSRC_n lost since
        the previous SR or RR packet was sent, expressed as a fixed
ToP   noToC   RFC1889 - Page 26
        point number with the binary point at the left edge of the
        field. (That is equivalent to taking the integer part after
        multiplying the loss fraction by 256.) This fraction is defined
        to be the number of packets lost divided by the number of
        packets expected,  as defined in the next paragraph.  An
        implementation is shown in Appendix A.3. If the loss is negative
        due to duplicates, the fraction lost is set to zero. Note that a
        receiver cannot tell whether any packets were lost after the
        last one received, and that there will be no reception report
        block issued for a source if all packets from that source sent
        during the last reporting interval have been lost.

   cumulative number of packets lost: 24 bits
        The total number of RTP data packets from source SSRC_n that
        have been lost since the beginning of reception. This number is
        defined to be the number of packets expected less the number of
        packets actually received, where the number of packets received
        includes any which are late or duplicates. Thus packets that
        arrive late are not counted as lost, and the loss may be
        negative if there are duplicates.  The number of packets
        expected is defined to be the extended last sequence number
        received, as defined next, less the initial sequence number
        received. This may be calculated as shown in Appendix A.3.

   extended highest sequence number received: 32 bits
        The low 16 bits contain the highest sequence number received in
        an RTP data packet from source SSRC_n, and the most significant
        16 bits extend that sequence number with the corresponding count
        of sequence number cycles, which may be maintained according to
        the algorithm in Appendix A.1. Note that different receivers
        within the same session will generate different extensions to
        the sequence number if their start times differ significantly.

   interarrival jitter: 32 bits
        An estimate of the statistical variance of the RTP data packet
        interarrival time, measured in timestamp units and expressed as
        an unsigned integer. The interarrival jitter J is defined to be
        the mean deviation (smoothed absolute value) of the difference D
        in packet spacing at the receiver compared to the sender for a
        pair of packets. As shown in the equation below, this is
        equivalent to the difference in the "relative transit time" for
        the two packets; the relative transit time is the difference
        between a packet's RTP timestamp and the receiver's clock at the
        time of arrival, measured in the same units.
ToP   noToC   RFC1889 - Page 27
   If Si is the RTP timestamp from packet i, and Ri is the time of
   arrival in RTP timestamp units for packet i, then for two packets i
   and j, D may be expressed as


   The interarrival jitter is calculated continuously as each data
   packet i is received from source SSRC_n, using this difference D for
   that packet and the previous packet i-1 in order of arrival (not
   necessarily in sequence), according to the formula


   Whenever a reception report is issued, the current value of J is

   The jitter calculation is prescribed here to allow profile-
   independent monitors to make valid interpretations of reports coming
   from different implementations. This algorithm is the optimal first-
   order estimator and the gain parameter 1/16 gives a good noise
   reduction ratio while maintaining a reasonable rate of convergence
   [11].  A sample implementation is shown in Appendix A.8.

   last SR timestamp (LSR): 32 bits
        The middle 32 bits out of 64 in the NTP timestamp (as explained
        in Section 4) received as part of the most recent RTCP sender
        report (SR) packet from source SSRC_n.  If no SR has been
        received yet, the field is set to zero.

   delay since last SR (DLSR): 32 bits
        The delay, expressed in units of 1/65536 seconds, between
        receiving the last SR packet from source SSRC_n and sending this
        reception report block.  If no SR packet has been received yet
        from SSRC_n, the DLSR field is set to zero.

   Let SSRC_r denote the receiver issuing this receiver report. Source
   SSRC_n can compute the round propagation delay to SSRC_r by recording
   the time A when this reception report block is received.  It
   calculates the total round-trip time A-LSR using the last SR
   timestamp (LSR) field, and then subtracting this field to leave the
   round-trip propagation delay as (A- LSR - DLSR).  This is illustrated
   in Fig. 2.

   This may be used as an approximate measure of distance to cluster
   receivers, although some links have very asymmetric delays.
ToP   noToC   RFC1889 - Page 28
6.3.2 RR: Receiver report RTCP packet

   [10 Nov 1995 11:33:25.125]           [10 Nov 1995 11:33:36.5]
   n                 SR(n)              A=b710:8000 (46864.500 s)
                      v                 ^
   ntp_sec =0xb44db705 v               ^ dlsr=0x0005.4000 (    5.250s)
   ntp_frac=0x20000000  v             ^  lsr =0xb705:2000 (46853.125s)
     (3024992016.125 s)  v           ^
   r                      v         ^ RR(n)
                           (5.250 s)

   A     0xb710:8000 (46864.500 s)
   DLSR -0x0005:4000 (    5.250 s)
   LSR  -0xb705:2000 (46853.125 s)
   delay 0x   6:2000 (    6.125 s)

           Figure 2: Example for round-trip time computation

 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|    RC   |   PT=RR=201   |             length            | header
|                     SSRC of packet sender                     |
|                 SSRC_1 (SSRC of first source)                 | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| fraction lost |       cumulative number of packets lost       |   1
|           extended highest sequence number received           |
|                      interarrival jitter                      |
|                         last SR (LSR)                         |
|                   delay since last SR (DLSR)                  |
|                 SSRC_2 (SSRC of second source)                | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
:                               ...                             :   2
|                  profile-specific extensions                  |
ToP   noToC   RFC1889 - Page 29
   The format of the receiver report (RR) packet is the same as that of
   the SR packet except that the packet type field contains the constant
   201 and the five words of sender information are omitted (these are
   the NTP and RTP timestamps and sender's packet and octet counts). The
   remaining fields have the same meaning as for the SR packet.

   An empty RR packet (RC = 0) is put at the head of a compound RTCP
   packet when there is no data transmission or reception to report.

6.3.3 Extending the sender and receiver reports

   A profile should define profile- or application-specific extensions
   to the sender report and receiver if there is additional information
   that should be reported regularly about the sender or receivers. This
   method should be used in preference to defining another RTCP packet
   type because it requires less overhead:

        o fewer octets in the packet (no RTCP header or SSRC field);

        o simpler and faster parsing because applications running under
         that profile would be programmed to always expect the extension
         fields in the directly accessible location after the reception

   If additional sender information is required, it should be included
   first in the extension for sender reports, but would not be present
   in receiver reports. If information about receivers is to be
   included, that data may be structured as an array of blocks parallel
   to the existing array of reception report blocks; that is, the number
   of blocks would be indicated by the RC field.

6.3.4 Analyzing sender and receiver reports

   It is expected that reception quality feedback will be useful not
   only for the sender but also for other receivers and third-party
   monitors.  The sender may modify its transmissions based on the
   feedback; receivers can determine whether problems are local,
   regional or global; network managers may use profile-independent
   monitors that receive only the RTCP packets and not the corresponding
   RTP data packets to evaluate the performance of their networks for
   multicast distribution.

   Cumulative counts are used in both the sender information and
   receiver report blocks so that differences may be calculated between
   any two reports to make measurements over both short and long time
   periods, and to provide resilience against the loss of a report. The
   difference between the last two reports received can be used to
   estimate the recent quality of the distribution. The NTP timestamp is
ToP   noToC   RFC1889 - Page 30
   included so that rates may be calculated from these differences over
   the interval between two reports. Since that timestamp is independent
   of the clock rate for the data encoding, it is possible to implement
   encoding- and profile-independent quality monitors.

   An example calculation is the packet loss rate over the interval
   between two reception reports. The difference in the cumulative
   number of packets lost gives the number lost during that interval.
   The difference in the extended last sequence numbers received gives
   the number of packets expected during the interval. The ratio of
   these two is the packet loss fraction over the interval. This ratio
   should equal the fraction lost field if the two reports are
   consecutive, but otherwise not. The loss rate per second can be
   obtained by dividing the loss fraction by the difference in NTP
   timestamps, expressed in seconds. The number of packets received is
   the number of packets expected minus the number lost. The number of
   packets expected may also be used to judge the statistical validity
   of any loss estimates.  For example, 1 out of 5 packets lost has a
   lower significance than 200 out of 1000.

   From the sender information, a third-party monitor can calculate the
   average payload data rate and the average packet rate over an
   interval without receiving the data. Taking the ratio of the two
   gives the average payload size. If it can be assumed that packet loss
   is independent of packet size, then the number of packets received by
   a particular receiver times the average payload size (or the
   corresponding packet size) gives the apparent throughput available to
   that receiver.

   In addition to the cumulative counts which allow long-term packet
   loss measurements using differences between reports, the fraction
   lost field provides a short-term measurement from a single report.
   This becomes more important as the size of a session scales up enough
   that reception state information might not be kept for all receivers
   or the interval between reports becomes long enough that only one
   report might have been received from a particular receiver.

   The interarrival jitter field provides a second short-term measure of
   network congestion. Packet loss tracks persistent congestion while
   the jitter measure tracks transient congestion. The jitter measure
   may indicate congestion before it leads to packet loss. Since the
   interarrival jitter field is only a snapshot of the jitter at the
   time of a report, it may be necessary to analyze a number of reports
   from one receiver over time or from multiple receivers, e.g., within
   a single network.
ToP   noToC   RFC1889 - Page 31
6.4 SDES: Source description RTCP packet

 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|    SC   |  PT=SDES=202  |             length            | header
|                          SSRC/CSRC_1                          | chunk
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   1
|                           SDES items                          |
|                              ...                              |
|                          SSRC/CSRC_2                          | chunk
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   2
|                           SDES items                          |
|                              ...                              |

   The SDES packet is a three-level structure composed of a header and
   zero or more chunks, each of of which is composed of items describing
   the source identified in that chunk. The items are described
   individually in subsequent sections.

   version (V), padding (P), length:
        As described for the SR packet (see Section 6.3.1).

   packet type (PT): 8 bits
        Contains the constant 202 to identify this as an RTCP SDES

   source count (SC): 5 bits
        The number of SSRC/CSRC chunks contained in this SDES packet. A
        value of zero is valid but useless.

   Each chunk consists of an SSRC/CSRC identifier followed by a list of
   zero or more items, which carry information about the SSRC/CSRC. Each
   chunk starts on a 32-bit boundary. Each item consists of an 8-bit
   type field, an 8-bit octet count describing the length of the text
   (thus, not including this two-octet header), and the text itself.
   Note that the text can be no longer than 255 octets, but this is
   consistent with the need to limit RTCP bandwidth consumption.

   The text is encoded according to the UTF-2 encoding specified in
   Annex F of ISO standard 10646 [12,13]. This encoding is also known as
   UTF-8 or UTF-FSS. It is described in "File System Safe UCS
   Transformation Format (FSS_UTF)", X/Open Preliminary Specification,
   Document Number P316 and Unicode Technical Report #4. US-ASCII is a
   subset of this encoding and requires no additional encoding. The
ToP   noToC   RFC1889 - Page 32
   presence of multi-octet encodings is indicated by setting the most
   significant bit of a character to a value of one.

   Items are contiguous, i.e., items are not individually padded to a
   32-bit boundary. Text is not null terminated because some multi-octet
   encodings include null octets. The list of items in each chunk is
   terminated by one or more null octets, the first of which is
   interpreted as an item type of zero to denote the end of the list,
   and the remainder as needed to pad until the next 32-bit boundary. A
   chunk with zero items (four null octets) is valid but useless.

   End systems send one SDES packet containing their own source
   identifier (the same as the SSRC in the fixed RTP header). A mixer
   sends one SDES packet containing a chunk for each contributing source
   from which it is receiving SDES information, or multiple complete
   SDES packets in the format above if there are more than 31 such
   sources (see Section 7).

   The SDES items currently defined are described in the next sections.
   Only the CNAME item is mandatory. Some items shown here may be useful
   only for particular profiles, but the item types are all assigned
   from one common space to promote shared use and to simplify profile-
   independent applications. Additional items may be defined in a
   profile by registering the type numbers with IANA.

6.4.1 CNAME: Canonical end-point identifier SDES item

    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
   |    CNAME=1    |     length    | user and domain name         ...

   The CNAME identifier has the following properties:

        o Because the randomly allocated SSRC identifier may change if a
         conflict is discovered or if a program is restarted, the CNAME
         item is required to provide the binding from the SSRC
         identifier to an identifier for the source that remains

        o Like the SSRC identifier, the CNAME identifier should also be
         unique among all participants within one RTP session.

        o To provide a binding across multiple media tools used by one
         participant in a set of related RTP sessions, the CNAME should
         be fixed for that participant.
ToP   noToC   RFC1889 - Page 33
        o To facilitate third-party monitoring, the CNAME should be
         suitable for either a program or a person to locate the source.

   Therefore, the CNAME should be derived algorithmically and not
   entered manually, when possible. To meet these requirements, the
   following format should be used unless a profile specifies an
   alternate syntax or semantics. The CNAME item should have the format
   "user@host", or "host" if a user name is not available as on single-
   user systems.  For both formats, "host" is either the fully qualified
   domain name of the host from which the real-time data originates,
   formatted according to the rules specified in RFC 1034 [14], RFC 1035
   [15] and Section 2.1 of RFC 1123 [16]; or the standard ASCII
   representation of the host's numeric address on the interface used
   for the RTP communication. For example, the standard ASCII
   representation of an IP Version 4 address is "dotted decimal", also
   known as dotted quad. Other address types are expected to have ASCII
   representations that are mutually unique.  The fully qualified domain
   name is more convenient for a human observer and may avoid the need
   to send a NAME item in addition, but it may be difficult or
   impossible to obtain reliably in some operating environments.
   Applications that may be run in such environments should use the
   ASCII representation of the address instead.

   Examples are "" or "doe@" for a
   multi-user system. On a system with no user name, examples would be
   "" or "".

   The user name should be in a form that a program such as "finger" or
   "talk" could use, i.e., it typically is the login name rather than
   the personal name. The host name is not necessarily identical to the
   one in the participant's electronic mail address.

   This syntax will not provide unique identifiers for each source if an
   application permits a user to generate multiple sources from one
   host.  Such an application would have to rely on the SSRC to further
   identify the source, or the profile for that application would have
   to specify additional syntax for the CNAME identifier.

   If each application creates its CNAME independently, the resulting
   CNAMEs may not be identical as would be required to provide a binding
   across multiple media tools belonging to one participant in a set of
   related RTP sessions. If cross-media binding is required, it may be
   necessary for the CNAME of each tool to be externally configured with
   the same value by a coordination tool.

   Application writers should be aware that private network address
   assignments such as the Net-10 assignment proposed in RFC 1597 [17]
   may create network addresses that are not globally unique. This would
ToP   noToC   RFC1889 - Page 34
   lead to non-unique CNAMEs if hosts with private addresses and no
   direct IP connectivity to the public Internet have their RTP packets
   forwarded to the public Internet through an RTP-level translator.
   (See also RFC 1627 [18].) To handle this case, applications may
   provide a means to configure a unique CNAME, but the burden is on the
   translator to translate CNAMEs from private addresses to public
   addresses if necessary to keep private addresses from being exposed.

6.4.2 NAME: User name SDES item

    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
   |     NAME=2    |     length    | common name of source        ...

   This is the real name used to describe the source, e.g., "John Doe,
   Bit Recycler, Megacorp". It may be in any form desired by the user.
   For applications such as conferencing, this form of name may be the
   most desirable for display in participant lists, and therefore might
   be sent most frequently of those items other than CNAME. Profiles may
   establish such priorities.  The NAME value is expected to remain
   constant at least for the duration of a session. It should not be
   relied upon to be unique among all participants in the session.

6.4.3 EMAIL: Electronic mail address SDES item

    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
   |    EMAIL=3    |     length    | email address of source      ...

   The email address is formatted according to RFC 822 [19], for
   example, "". The EMAIL value is expected to
   remain constant for the duration of a session.

6.4.4 PHONE: Phone number SDES item

    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
   |    PHONE=4    |     length    | phone number of source       ...

   The phone number should be formatted with the plus sign replacing the
   international access code.  For example, "+1 908 555 1212" for a
   number in the United States.
ToP   noToC   RFC1889 - Page 35
6.4.5 LOC: Geographic user location SDES item

    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
   |     LOC=5     |     length    | geographic location of site  ...

   Depending on the application, different degrees of detail are
   appropriate for this item. For conference applications, a string like
   "Murray Hill, New Jersey" may be sufficient, while, for an active
   badge system, strings like "Room 2A244, AT&T BL MH" might be
   appropriate. The degree of detail is left to the implementation
   and/or user, but format and content may be prescribed by a profile.
   The LOC value is expected to remain constant for the duration of a
   session, except for mobile hosts.

6.4.6 TOOL: Application or tool name SDES item

    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
   |     TOOL=6    |     length    | name/version of source appl. ...

   A string giving the name and possibly version of the application
   generating the stream, e.g., "videotool 1.2". This information may be
   useful for debugging purposes and is similar to the Mailer or Mail-
   System-Version SMTP headers. The TOOL value is expected to remain
   constant for the duration of the session.

6.4.7 NOTE: Notice/status SDES item

    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
   |     NOTE=7    |     length    | note about the source        ...

   The following semantics are suggested for this item, but these or
   other semantics may be explicitly defined by a profile. The NOTE item
   is intended for transient messages describing the current state of
   the source, e.g., "on the phone, can't talk". Or, during a seminar,
   this item might be used to convey the title of the talk. It should be
   used only to carry exceptional information and should not be included
   routinely by all participants because this would slow down the rate
   at which reception reports and CNAME are sent, thus impairing the
   performance of the protocol. In particular, it should not be included
ToP   noToC   RFC1889 - Page 36
   as an item in a user's configuration file nor automatically generated
   as in a quote-of-the-day.

   Since the NOTE item may be important to display while it is active,
   the rate at which other non-CNAME items such as NAME are transmitted
   might be reduced so that the NOTE item can take that part of the RTCP
   bandwidth. When the transient message becomes inactive, the NOTE item
   should continue to be transmitted a few times at the same repetition
   rate but with a string of length zero to signal the receivers.
   However, receivers should also consider the NOTE item inactive if it
   is not received for a small multiple of the repetition rate, or
   perhaps 20-30 RTCP intervals.

6.4.8 PRIV: Private extensions SDES item

      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
     |     PRIV=8    |     length    | prefix length | prefix string...
    ...              |                  value string                ...

   This item is used to define experimental or application-specific SDES
   extensions. The item contains a prefix consisting of a length-string
   pair, followed by the value string filling the remainder of the item
   and carrying the desired information. The prefix length field is 8
   bits long. The prefix string is a name chosen by the person defining
   the PRIV item to be unique with respect to other PRIV items this
   application might receive. The application creator might choose to
   use the application name plus an additional subtype identification if
   needed.  Alternatively, it is recommended that others choose a name
   based on the entity they represent, then coordinate the use of the
   name within that entity.

   Note that the prefix consumes some space within the item's total
   length of 255 octets, so the prefix should be kept as short as
   possible. This facility and the constrained RTCP bandwidth should not
   be overloaded; it is not intended to satisfy all the control
   communication requirements of all applications.

   SDES PRIV prefixes will not be registered by IANA. If some form of
   the PRIV item proves to be of general utility, it should instead be
   assigned a regular SDES item type registered with IANA so that no
   prefix is required. This simplifies use and increases transmission
ToP   noToC   RFC1889 - Page 37
6.5 BYE: Goodbye RTCP packet

    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|    SC   |   PT=BYE=203  |             length            |
   |                           SSRC/CSRC                           |
   :                              ...                              :
   |     length    |               reason for leaving             ... (opt)

   The BYE packet indicates that one or more sources are no longer

   version (V), padding (P), length:
        As described for the SR packet (see Section 6.3.1).

   packet type (PT): 8 bits
        Contains the constant 203 to identify this as an RTCP BYE

   source count (SC): 5 bits
        The number of SSRC/CSRC identifiers included in this BYE packet.
        A count value of zero is valid, but useless.

   If a BYE packet is received by a mixer, the mixer forwards the BYE
   packet with the SSRC/CSRC identifier(s) unchanged. If a mixer shuts
   down, it should send a BYE packet listing all contributing sources it
   handles, as well as its own SSRC identifier. Optionally, the BYE
   packet may include an 8-bit octet count followed by that many octets
   of text indicating the reason for leaving, e.g., "camera malfunction"
   or "RTP loop detected". The string has the same encoding as that
   described for SDES. If the string fills the packet to the next 32-bit
   boundary, the string is not null terminated. If not, the BYE packet
   is padded with null octets.
ToP   noToC   RFC1889 - Page 38
6.6 APP: Application-defined RTCP packet

    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| subtype |   PT=APP=204  |             length            |
   |                           SSRC/CSRC                           |
   |                          name (ASCII)                         |
   |                   application-dependent data                 ...

   The APP packet is intended for experimental use as new applications
   and new features are developed, without requiring packet type value
   registration. APP packets with unrecognized names should be ignored.
   After testing and if wider use is justified, it is recommended that
   each APP packet be redefined without the subtype and name fields and
   registered with the Internet Assigned Numbers Authority using an RTCP
   packet type.

   version (V), padding (P), length:
        As described for the SR packet (see Section 6.3.1).

   subtype: 5 bits
        May be used as a subtype to allow a set of APP packets to be
        defined under one unique name, or for any application-dependent

   packet type (PT): 8 bits
        Contains the constant 204 to identify this as an RTCP APP

   name: 4 octets
        A name chosen by the person defining the set of APP packets to
        be unique with respect to other APP packets this application
        might receive. The application creator might choose to use the
        application name, and then coordinate the allocation of subtype
        values to others who want to define new packet types for the
        application.  Alternatively, it is recommended that others
        choose a name based on the entity they represent, then
        coordinate the use of the name within that entity. The name is
        interpreted as a sequence of four ASCII characters, with
        uppercase and lowercase characters treated as distinct.
ToP   noToC   RFC1889 - Page 39
   application-dependent data: variable length
        Application-dependent data may or may not appear in an APP
        packet. It is interpreted by the application and not RTP itself.
        It must be a multiple of 32 bits long.

7.  RTP Translators and Mixers

   In addition to end systems, RTP supports the notion of "translators"
   and "mixers", which could be considered as "intermediate systems" at
   the RTP level. Although this support adds some complexity to the
   protocol, the need for these functions has been clearly established
   by experiments with multicast audio and video applications in the
   Internet. Example uses of translators and mixers given in Section 2.3
   stem from the presence of firewalls and low bandwidth connections,
   both of which are likely to remain.

7.1 General Description

   An RTP translator/mixer connects two or more transport-level
   "clouds".  Typically, each cloud is defined by a common network and
   transport protocol (e.g., IP/UDP), multicast address or pair of
   unicast addresses, and transport level destination port.  (Network-
   level protocol translators, such as IP version 4 to IP version 6, may
   be present within a cloud invisibly to RTP.) One system may serve as
   a translator or mixer for a number of RTP sessions, but each is
   considered a logically separate entity.

   In order to avoid creating a loop when a translator or mixer is
   installed, the following rules must be observed:

        o Each of the clouds connected by translators and mixers
         participating in one RTP session either must be distinct from
         all the others in at least one of these parameters (protocol,
         address, port), or must be isolated at the network level from
         the others.

        o A derivative of the first rule is that there must not be
         multiple translators or mixers connected in parallel unless by
         some arrangement they partition the set of sources to be

   Similarly, all RTP end systems that can communicate through one or
   more RTP translators or mixers share the same SSRC space, that is,
   the SSRC identifiers must be unique among all these end systems.
   Section 8.2 describes the collision resolution algorithm by which
   SSRC identifiers are kept unique and loops are detected.
ToP   noToC   RFC1889 - Page 40
   There may be many varieties of translators and mixers designed for
   different purposes and applications. Some examples are to add or
   remove encryption, change the encoding of the data or the underlying
   protocols, or replicate between a multicast address and one or more
   unicast addresses. The distinction between translators and mixers is
   that a translator passes through the data streams from different
   sources separately, whereas a mixer combines them to form one new

   Translator: Forwards RTP packets with their SSRC identifier intact;
        this makes it possible for receivers to identify individual
        sources even though packets from all the sources pass through
        the same translator and carry the translator's network source
        address. Some kinds of translators will pass through the data
        untouched, but others may change the encoding of the data and
        thus the RTP data payload type and timestamp. If multiple data
        packets are re-encoded into one, or vice versa, a translator
        must assign new sequence numbers to the outgoing packets. Losses
        in the incoming packet stream may induce corresponding gaps in
        the outgoing sequence numbers. Receivers cannot detect the
        presence of a translator unless they know by some other means
        what payload type or transport address was used by the original

   Mixer: Receives streams of RTP data packets from one or more sources,
        possibly changes the data format, combines the streams in some
        manner and then forwards the combined stream. Since the timing
        among multiple input sources will not generally be synchronized,
        the mixer will make timing adjustments among the streams and
        generate its own timing for the combined stream, so it is the
        synchronization source. Thus, all data packets forwarded by a
        mixer will be marked with the mixer's own SSRC identifier. In
        order to preserve the identity of the original sources
        contributing to the mixed packet, the mixer should insert their
        SSRC identifiers into the CSRC identifier list following the
        fixed RTP header of the packet. A mixer that is also itself a
        contributing source for some packet should explicitly include
        its own SSRC identifier in the CSRC list for that packet.

   For some applications, it may be acceptable for a mixer not to
   identify sources in the CSRC list. However, this introduces the
   danger that loops involving those sources could not be detected.

   The advantage of a mixer over a translator for applications like
   audio is that the output bandwidth is limited to that of one source
   even when multiple sources are active on the input side. This may be
   important for low-bandwidth links. The disadvantage is that receivers
   on the output side don't have any control over which sources are
ToP   noToC   RFC1889 - Page 41
   passed through or muted, unless some mechanism is implemented for
   remote control of the mixer. The regeneration of synchronization
   information by mixers also means that receivers can't do inter-media
   synchronization of the original streams. A multi-media mixer could do

         [E1]                                    [E6]
          |                                       |
    E1:17 |                                 E6:15 |
          |                                       |   E6:15
          V  M1:48 (1,17)         M1:48 (1,17)    V   M1:48 (1,17)
          ^                 ^     E4:47           ^   E4:47
     E2:1 |           E4:47 |                     |   M3:89 (64,45)
          |                 |                     |
         [E2]              [E4]     M3:89 (64,45) |
                                                  |        legend:
   [E3] --------->(M2)----------->(M3)------------|        [End system]
          E3:64        M2:12 (64)  ^                       (Mixer)
                                   | E5:45                 <Translator>
                                  [E5]          source: SSRC (CSRCs)

 Figure 3: Sample RTP network with end systems, mixers and translators

   A collection of mixers and translators is shown in Figure 3 to
   illustrate their effect on SSRC and CSRC identifiers. In the figure,
   end systems are shown as rectangles (named E), translators as
   triangles (named T) and mixers as ovals (named M). The notation "M1:
   48(1,17)" designates a packet originating a mixer M1, identified with
   M1's (random) SSRC value of 48 and two CSRC identifiers, 1 and 17,
   copied from the SSRC identifiers of packets from E1 and E2.

7.2 RTCP Processing in Translators

   In addition to forwarding data packets, perhaps modified, translators
   and mixers must also process RTCP packets. In many cases, they will
   take apart the compound RTCP packets received from end systems to
   aggregate SDES information and to modify the SR or RR packets.
   Retransmission of this information may be triggered by the packet
   arrival or by the RTCP interval timer of the translator or mixer

   A translator that does not modify the data packets, for example one
   that just replicates between a multicast address and a unicast
   address, may simply forward RTCP packets unmodified as well. A
ToP   noToC   RFC1889 - Page 42
   translator that transforms the payload in some way must make
   corresponding transformations in the SR and RR information so that it
   still reflects the characteristics of the data and the reception
   quality. These translators must not simply forward RTCP packets. In
   general, a translator should not aggregate SR and RR packets from
   different sources into one packet since that would reduce the
   accuracy of the propagation delay measurements based on the LSR and
   DLSR fields.

   SR sender information:  A translator does not generate its own sender
        information, but forwards the SR packets received from one cloud
        to the others. The SSRC is left intact but the sender
        information must be modified if required by the translation. If
        a translator changes the data encoding, it must change the
        "sender's byte count" field. If it also combines several data
        packets into one output packet, it must change the "sender's
        packet count" field. If it changes the timestamp frequency, it
        must change the "RTP timestamp" field in the SR packet.

   SR/RR reception report blocks:  A translator forwards reception
        reports received from one cloud to the others. Note that these
        flow in the direction opposite to the data.  The SSRC is left
        intact. If a translator combines several data packets into one
        output packet, and therefore changes the sequence numbers, it
        must make the inverse manipulation for the packet loss fields
        and the "extended last sequence number" field. This may be
        complex. In the extreme case, there may be no meaningful way to
        translate the reception reports, so the translator may pass on
        no reception report at all or a synthetic report based on its
        own reception. The general rule is to do what makes sense for a
        particular translation.

   A translator does not require an SSRC identifier of its own, but may
   choose to allocate one for the purpose of sending reports about what
   it has received. These would be sent to all the connected clouds,
   each corresponding to the translation of the data stream as sent to
   that cloud, since reception reports are normally multicast to all

   SDES:  Translators typically forward without change the SDES
        information they receive from one cloud to the others, but may,
        for example, decide to filter non-CNAME SDES information if
        bandwidth is limited. The CNAMEs must be forwarded to allow SSRC
        identifier collision detection to work. A translator that
        generates its own RR packets must send SDES CNAME information
        about itself to the same clouds that it sends those RR packets.
ToP   noToC   RFC1889 - Page 43
   BYE:  Translators forward BYE packets unchanged. Translators with
        their own SSRC should generate BYE packets with that SSRC
        identifier if they are about to cease forwarding packets.

   APP:  Translators forward APP packets unchanged.

7.3 RTCP Processing in Mixers

   Since a mixer generates a new data stream of its own, it does not
   pass through SR or RR packets at all and instead generates new
   information for both sides.

   SR sender information:  A mixer does not pass through sender
        information from the sources it mixes because the
        characteristics of the source streams are lost in the mix. As a
        synchronization source, the mixer generates its own SR packets
        with sender information about the mixed data stream and sends
        them in the same direction as the mixed stream.

   SR/RR reception report blocks:  A mixer generates its own reception
        reports for sources in each cloud and sends them out only to the
        same cloud. It does not send these reception reports to the
        other clouds and does not forward reception reports from one
        cloud to the others because the sources would not be SSRCs there
        (only CSRCs).

   SDES:  Mixers typically forward without change the SDES information
        they receive from one cloud to the others, but may, for example,
        decide to filter non-CNAME SDES information if bandwidth is
        limited. The CNAMEs must be forwarded to allow SSRC identifier
        collision detection to work. (An identifier in a CSRC list
        generated by a mixer might collide with an SSRC identifier
        generated by an end system.) A mixer must send SDES CNAME
        information about itself to the same clouds that it sends SR or
        RR packets.

   Since mixers do not forward SR or RR packets, they will typically be
   extracting SDES packets from a compound RTCP packet. To minimize
   overhead, chunks from the SDES packets may be aggregated into a
   single SDES packet which is then stacked on an SR or RR packet
   originating from the mixer. The RTCP packet rate may be different on
   each side of the mixer.

   A mixer that does not insert CSRC identifiers may also refrain from
   forwarding SDES CNAMEs. In this case, the SSRC identifier spaces in
   the two clouds are independent. As mentioned earlier, this mode of
   operation creates a danger that loops can't be detected.
ToP   noToC   RFC1889 - Page 44
   BYE:  Mixers need to forward BYE packets. They should generate BYE
        packets with their own SSRC identifiers if they are about to
        cease forwarding packets.

   APP:  The treatment of APP packets by mixers is application-specific.

7.4 Cascaded Mixers

   An RTP session may involve a collection of mixers and translators as
   shown in Figure 3. If two mixers are cascaded, such as M2 and M3 in
   the figure, packets received by a mixer may already have been mixed
   and may include a CSRC list with multiple identifiers. The second
   mixer should build the CSRC list for the outgoing packet using the
   CSRC identifiers from already-mixed input packets and the SSRC
   identifiers from unmixed input packets. This is shown in the output
   arc from mixer M3 labeled M3:89(64,45) in the figure. As in the case
   of mixers that are not cascaded, if the resulting CSRC list has more
   than 15 identifiers, the remainder cannot be included.

(page 44 continued on part 3)

Next Section