rfc1889.txt

RFC关于RTP实时传输协议的详细规范。 原理并不复杂

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

   #: SSRC/CSRC

              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.






Schulzrinne, et al          Standards Track                    [Page 19]

RFC 1889                          RTP                       January 1996


   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.




Schulzrinne, et al          Standards Track                    [Page 20]

RFC 1889                          RTP                       January 1996


        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



Schulzrinne, et al          Standards Track                    [Page 21]

RFC 1889                          RTP                       January 1996


   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.




Schulzrinne, et al          Standards Track                    [Page 22]

RFC 1889                          RTP                       January 1996


   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