rfc1889.txt

网络MPEG4IP流媒体开发源代码

Network Working Group                Audio-Video Transport Working Group
Request for Comments: 1889                                H. Schulzrinne
Category: Standards Track                                      GMD Fokus
                                                               S. Casner
                                                  Precept Software, Inc.
                                                            R. Frederick
                                         Xerox Palo Alto Research Center
                                                             V. Jacobson
                                   Lawrence Berkeley National Laboratory
                                                            January 1996


          RTP: A Transport Protocol for Real-Time Applications

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This memorandum describes RTP, the real-time transport protocol. RTP
   provides end-to-end network transport functions suitable for
   applications transmitting real-time data, such as audio, video or
   simulation data, over multicast or unicast network services. RTP does
   not address resource reservation and does not guarantee quality-of-
   service for real-time services. The data transport is augmented by a
   control protocol (RTCP) to allow monitoring of the data delivery in a
   manner scalable to large multicast networks, and to provide minimal
   control and identification functionality. RTP and RTCP are designed
   to be independent of the underlying transport and network layers. The
   protocol supports the use of RTP-level translators and mixers.

Table of Contents

   1.         Introduction ........................................    3
   2.         RTP Use Scenarios ...................................    5
   2.1        Simple Multicast Audio Conference ...................    5
   2.2        Audio and Video Conference ..........................    6
   2.3        Mixers and Translators ..............................    6
   3.         Definitions .........................................    7
   4.         Byte Order, Alignment, and Time Format ..............    9
   5.         RTP Data Transfer Protocol ..........................   10
   5.1        RTP Fixed Header Fields .............................   10
   5.2        Multiplexing RTP Sessions ...........................   13



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


   5.3        Profile-Specific Modifications to the RTP Header.....   14
   5.3.1      RTP Header Extension ................................   14
   6.         RTP Control Protocol -- RTCP ........................   15
   6.1        RTCP Packet Format ..................................   17
   6.2        RTCP Transmission Interval ..........................   19
   6.2.1      Maintaining the number of session members ...........   21
   6.2.2      Allocation of source description bandwidth ..........   21
   6.3        Sender and Receiver Reports .........................   22
   6.3.1      SR: Sender report RTCP packet .......................   23
   6.3.2      RR: Receiver report RTCP packet .....................   28
   6.3.3      Extending the sender and receiver reports ...........   29
   6.3.4      Analyzing sender and receiver reports ...............   29
   6.4        SDES: Source description RTCP packet ................   31
   6.4.1      CNAME: Canonical end-point identifier SDES item .....   32
   6.4.2      NAME: User name SDES item ...........................   34
   6.4.3      EMAIL: Electronic mail address SDES item ............   34
   6.4.4      PHONE: Phone number SDES item .......................   34
   6.4.5      LOC: Geographic user location SDES item .............   35
   6.4.6      TOOL: Application or tool name SDES item ............   35
   6.4.7      NOTE: Notice/status SDES item .......................   35
   6.4.8      PRIV: Private extensions SDES item ..................   36
   6.5        BYE: Goodbye RTCP packet ............................   37
   6.6        APP: Application-defined RTCP packet ................   38
   7.         RTP Translators and Mixers ..........................   39
   7.1        General Description .................................   39
   7.2        RTCP Processing in Translators ......................   41
   7.3        RTCP Processing in Mixers ...........................   43
   7.4        Cascaded Mixers .....................................   44
   8.         SSRC Identifier Allocation and Use ..................   44
   8.1        Probability of Collision ............................   44
   8.2        Collision Resolution and Loop Detection .............   45
   9.         Security ............................................   49
   9.1        Confidentiality .....................................   49
   9.2        Authentication and Message Integrity ................   50
   10.        RTP over Network and Transport Protocols ............   51
   11.        Summary of Protocol Constants .......................   51
   11.1       RTCP packet types ...................................   52
   11.2       SDES types ..........................................   52
   12.        RTP Profiles and Payload Format Specifications ......   53
   A.         Algorithms ..........................................   56
   A.1        RTP Data Header Validity Checks .....................   59
   A.2        RTCP Header Validity Checks .........................   63
   A.3        Determining the Number of RTP Packets Expected and
              Lost ................................................   63
   A.4        Generating SDES RTCP Packets ........................   64
   A.5        Parsing RTCP SDES Packets ...........................   65
   A.6        Generating a Random 32-bit Identifier ...............   66
   A.7        Computing the RTCP Transmission Interval ............   68



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


   A.8        Estimating the Interarrival Jitter ..................   71
   B.         Security Considerations .............................   72
   C.         Addresses of Authors ................................   72
   D.         Bibliography ........................................   73

1.  Introduction

   This memorandum specifies the real-time transport protocol (RTP),
   which provides end-to-end delivery services for data with real-time
   characteristics, such as interactive audio and video. Those services
   include payload type identification, sequence numbering, timestamping
   and delivery monitoring. Applications typically run RTP on top of UDP
   to make use of its multiplexing and checksum services; both protocols
   contribute parts of the transport protocol functionality. However,
   RTP may be used with other suitable underlying network or transport
   protocols (see Section 10). RTP supports data transfer to multiple
   destinations using multicast distribution if provided by the
   underlying network.

   Note that RTP itself does not provide any mechanism to ensure timely
   delivery or provide other quality-of-service guarantees, but relies
   on lower-layer services to do so. It does not guarantee delivery or
   prevent out-of-order delivery, nor does it assume that the underlying
   network is reliable and delivers packets in sequence. The sequence
   numbers included in RTP allow the receiver to reconstruct the
   sender's packet sequence, but sequence numbers might also be used to
   determine the proper location of a packet, for example in video
   decoding, without necessarily decoding packets in sequence.

   While RTP is primarily designed to satisfy the needs of multi-
   participant multimedia conferences, it is not limited to that
   particular application. Storage of continuous data, interactive
   distributed simulation, active badge, and control and measurement
   applications may also find RTP applicable.

   This document defines RTP, consisting of two closely-linked parts:

        o the real-time transport protocol (RTP), to carry data that has
         real-time properties.

        o the RTP control protocol (RTCP), to monitor the quality of
         service and to convey information about the participants in an
         on-going session. The latter aspect of RTCP may be sufficient
         for "loosely controlled" sessions, i.e., where there is no
         explicit membership control and set-up, but it is not
         necessarily intended to support all of an application's control
         communication requirements.  This functionality may be fully or
         partially subsumed by a separate session control protocol,



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


         which is beyond the scope of this document.

   RTP represents a new style of protocol following the principles of
   application level framing and integrated layer processing proposed by
   Clark and Tennenhouse [1]. That is, RTP is intended to be malleable
   to provide the information required by a particular application and
   will often be integrated into the application processing rather than
   being implemented as a separate layer. RTP is a protocol framework
   that is deliberately not complete.  This document specifies those
   functions expected to be common across all the applications for which
   RTP would be appropriate. Unlike conventional protocols in which
   additional functions might be accommodated by making the protocol
   more general or by adding an option mechanism that would require
   parsing, RTP is intended to be tailored through modifications and/or
   additions to the headers as needed. Examples are given in Sections
   5.3 and 6.3.3.

   Therefore, in addition to this document, a complete specification of
   RTP for a particular application will require one or more companion
   documents (see Section 12):

        o a profile specification document, which defines a set of
         payload type codes and their mapping to payload formats (e.g.,
         media encodings). A profile may also define extensions or
         modifications to RTP that are specific to a particular class of
         applications.  Typically an application will operate under only
         one profile. A profile for audio and video data may be found in
         the companion RFC TBD.

        o payload format specification documents, which define how a
         particular payload, such as an audio or video encoding, is to
         be carried in RTP.

   A discussion of real-time services and algorithms for their
   implementation as well as background discussion on some of the RTP
   design decisions can be found in [2].

   Several RTP applications, both experimental and commercial, have
   already been implemented from draft specifications. These
   applications include audio and video tools along with diagnostic
   tools such as traffic monitors. Users of these tools number in the
   thousands.  However, the current Internet cannot yet support the full
   potential demand for real-time services. High-bandwidth services
   using RTP, such as video, can potentially seriously degrade the
   quality of service of other network services. Thus, implementors
   should take appropriate precautions to limit accidental bandwidth
   usage. Application documentation should clearly outline the
   limitations and possible operational impact of high-bandwidth real-



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


   time services on the Internet and other network services.

2.  RTP Use Scenarios

   The following sections describe some aspects of the use of RTP. The
   examples were chosen to illustrate the basic operation of
   applications using RTP, not to limit what RTP may be used for. In
   these examples, RTP is carried on top of IP and UDP, and follows the
   conventions established by the profile for audio and video specified
   in the companion Internet-Draft draft-ietf-avt-profile

2.1 Simple Multicast Audio Conference

   A working group of the IETF meets to discuss the latest protocol
   draft, using the IP multicast services of the Internet for voice
   communications. Through some allocation mechanism the working group
   chair obtains a multicast group address and pair of ports. One port
   is used for audio data, and the other is used for control (RTCP)
   packets.  This address and port information is distributed to the
   intended participants. If privacy is desired, the data and control
   packets may be encrypted as specified in Section 9.1, in which case
   an encryption key must also be generated and distributed.  The exact
   details of these allocation and distribution mechanisms are beyond
   the scope of RTP.

   The audio conferencing application used by each conference
   participant sends audio data in small chunks of, say, 20 ms duration.