rfc3550.txt

完整的RTP RTSP代码库

Schulzrinne, et al.         Standards Track                    [Page 19]

RFC 3550                          RTP                          July 2003


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

   2. RTCP carries a persistent transport-level identifier for an RTP
      source called the canonical name or CNAME, Section 6.5.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 may 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.  Inter-media synchronization also requires the NTP and RTP
      timestamps included in RTCP packets by data senders.

   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 SHOULD be used in all environments, but particularly in
   the IP multicast environment.  RTP application designers SHOULD avoid
   mechanisms that can only work in unicast mode and will not scale to
   larger numbers.  Transmission of RTCP MAY be controlled separately
   for senders and receivers, as described in Section 6.2, for cases
   such as unidirectional links where feedback from receivers is not
   possible.




Schulzrinne, et al.         Standards Track                    [Page 20]

RFC 3550                          RTP                          July 2003


   Non-normative note:  In the multicast routing approach
      called Source-Specific Multicast (SSM), there is only one sender
      per "channel" (a source address, group address pair), and
      receivers (except for the channel source) cannot use multicast to
      communicate directly with other channel members.  The
      recommendations here accommodate SSM only through Section 6.2's
      option of turning off receivers' RTCP entirely.  Future work will
      specify adaptation of RTCP for SSM so that feedback from receivers
      can be maintained.

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 and in combination with SR for
         active senders reporting on more than 31 sources

   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 MUST end on a 32-bit
   boundary.  The alignment requirement and a length field in the fixed
   part of each packet are included to make RTCP packets "stackable".
   Multiple RTCP packets can 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:







Schulzrinne, et al.         Standards Track                    [Page 21]

RFC 3550                          RTP                          July 2003


   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 MUST 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 MUST also
      include the SDES CNAME except when the compound RTCP packet is
      split for partial encryption as described in Section 9.1.

   o  The number of packet types that may appear first in the compound
      packet needs to be limited to increase the number of constant bits
      in the first word and the probability of successfully validating
      RTCP packets against misaddressed RTP 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:

   Encryption prefix:  If and only if the compound packet is to be
      encrypted according to the method in Section 9.1, it MUST be
      prefixed by a random 32-bit quantity redrawn for every compound
      packet transmitted.  If padding is required for the encryption, it
      MUST be added to the last packet of the compound packet.

   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 or received, in which case an empty RR MUST be 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, except as noted in Section 9.1.
      Other source description items MAY optionally be included if
      required by a particular application, subject to bandwidth
      constraints (see Section 6.3.9).

   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.




Schulzrinne, et al.         Standards Track                    [Page 22]

RFC 3550                          RTP                          July 2003


   An individual RTP participant SHOULD send only one compound RTCP
   packet per report interval in order for the RTCP bandwidth per
   participant to be estimated correctly (see Section 6.2), except when
   the compound RTCP packet is split for partial encryption as described
   in Section 9.1.  If there are too many sources to fit all the
   necessary RR packets into one compound RTCP packet without exceeding
   the maximum transmission unit (MTU) of the network path, then only
   the subset that will fit into one MTU SHOULD be included in each
   interval.  The subsets SHOULD be selected round-robin across multiple
   intervals so that all sources are reported.

   It is RECOMMENDED that translators and mixers 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 MTU of the network path, it SHOULD
   be segmented into multiple shorter compound packets to be transmitted
   in separate packets of the underlying protocol.  This does not impair
   the RTCP bandwidth estimation because each compound packet represents
   at least one distinct participant.  Note that each of the compound
   packets MUST begin with an SR or RR packet.

   An implementation SHOULD ignore incoming RTCP packets with types
   unknown to it.  Additional RTCP packet types may be registered with
   the Internet Assigned Numbers Authority (IANA) as described in
   Section 15.

   if encrypted: random 32-bit integer
   |
   |[--------- packet --------][---------- packet ----------][-packet-]
   |
   |                receiver            chunk        chunk
   V                reports           item  item   item  item
   --------------------------------------------------------------------
   R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
   --------------------------------------------------------------------
   |                                                                  |
   |<-----------------------  compound packet ----------------------->|
   |<--------------------------  UDP packet ------------------------->|

   #: SSRC/CSRC identifier

              Figure 1: Example of an RTCP compound packet







Schulzrinne, et al.         Standards Track                    [Page 23]

RFC 3550                          RTP                          July 2003


6.2 RTCP Transmission Interval

   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 by dynamically calculating
   the interval between RTCP packet transmissions.

   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.  If there is no reservation, there may be
   other constraints, depending on the environment, that establish the
   "reasonable" maximum for the session to use, and that would be the
   session bandwidth.  The session bandwidth may be chosen based on 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.  Often, the
   session bandwidth is the sum of the nominal bandwidths of the senders
   expected to be concurrently active.  For teleconference audio, this
   number would typically be one sender's bandwidth.  For layered
   encodings, each layer is a separate RTP session with its own session
   bandwidth parameter.

   The session bandwidth parameter is expected to be supplied by a
   session management application when it invokes a media application,
   b