rfc1889.txt

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

        o If a particular class of applications needs additional
         functionality independent of payload format, the profile under
         which those applications operate should define additional fixed
         fields to follow immediately after the SSRC field of the
         existing fixed header.  Those applications will be able to
         quickly and directly access the additional fields while
         profile-independent monitors or recorders can still process the
         RTP packets by interpreting only the first twelve octets.

   If it turns out that additional functionality is needed in common
   across all profiles, then a new version of RTP should be defined to
   make a permanent change to the fixed header.

5.3.1 RTP Header Extension

   An extension mechanism is provided to allow individual
   implementations to experiment with new payload-format-independent
   functions that require additional information to be carried in the
   RTP data packet header. This mechanism is designed so that the header
   extension may be ignored by other interoperating implementations that
   have not been extended.




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


   Note that this header extension is intended only for limited use.
   Most potential uses of this mechanism would be better done another
   way, using the methods described in the previous section. For
   example, a profile-specific extension to the fixed header is less
   expensive to process because it is not conditional nor in a variable
   location. Additional information required for a particular payload
   format should not use this header extension, but should be carried in
   the payload section of the 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      defined by profile       |           length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        header extension                       |
   |                             ....                              |


   If the X bit in the RTP header is one, a variable-length header
   extension is appended to the RTP header, following the CSRC list if
   present. The header extension contains a 16-bit length field that
   counts the number of 32-bit words in the extension, excluding the
   four-octet extension header (therefore zero is a valid length). Only
   a single extension may be appended to the RTP data header. To allow
   multiple interoperating implementations to each experiment
   independently with different header extensions, or to allow a
   particular implementation to experiment with more than one type of
   header extension, the first 16 bits of the header extension are left
   open for distinguishing identifiers or parameters. The format of
   these 16 bits is to be defined by the profile specification under
   which the implementations are operating. This RTP specification does
   not define any header extensions itself.

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
   functions:

        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



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


             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.




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


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



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


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







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