rfc3551.txt

完整的RTP RTSP代码库

Network Working Group                                     H. Schulzrinne
Request for Comments: 3551                           Columbia University
Obsoletes: 1890                                                S. Casner
Category: Standards Track                                  Packet Design
                                                               July 2003


              RTP Profile for Audio and Video Conferences
                          with Minimal Control

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.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document describes a profile called "RTP/AVP" for the use of the
   real-time transport protocol (RTP), version 2, and the associated
   control protocol, RTCP, within audio and video multiparticipant
   conferences with minimal control.  It provides interpretations of
   generic fields within the RTP specification suitable for audio and
   video conferences.  In particular, this document defines a set of
   default mappings from payload type numbers to encodings.

   This document also describes how audio and video data may be carried
   within RTP.  It defines a set of standard encodings and their names
   when used within RTP.  The descriptions provide pointers to reference
   implementations and the detailed standards.  This document is meant
   as an aid for implementors of audio, video and other real-time
   multimedia applications.

   This memorandum obsoletes RFC 1890.  It is mostly backwards-
   compatible except for functions removed because two interoperable
   implementations were not found.  The additions to RFC 1890 codify
   existing practice in the use of payload formats under this profile
   and include new payload formats defined since RFC 1890 was published.







Schulzrinne & Casner        Standards Track                     [Page 1]

RFC 3551                    RTP A/V Profile                    July 2003


Table of Contents

   1.  Introduction .................................................  3
       1.1  Terminology .............................................  3
   2.  RTP and RTCP Packet Forms and Protocol Behavior ..............  4
   3.  Registering Additional Encodings .............................  6
   4.  Audio ........................................................  8
       4.1  Encoding-Independent Rules ..............................  8
       4.2  Operating Recommendations ...............................  9
       4.3  Guidelines for Sample-Based Audio Encodings ............. 10
       4.4  Guidelines for Frame-Based Audio Encodings .............. 11
       4.5  Audio Encodings ......................................... 12
            4.5.1   DVI4 ............................................ 13
            4.5.2   G722 ............................................ 14
            4.5.3   G723 ............................................ 14
            4.5.4   G726-40, G726-32, G726-24, and G726-16 .......... 18
            4.5.5   G728 ............................................ 19
            4.5.6   G729 ............................................ 20
            4.5.7   G729D and G729E ................................. 22
            4.5.8   GSM ............................................. 24
            4.5.9   GSM-EFR ......................................... 27
            4.5.10  L8 .............................................. 27
            4.5.11  L16 ............................................. 27
            4.5.12  LPC ............................................. 27
            4.5.13  MPA ............................................. 28
            4.5.14  PCMA and PCMU ................................... 28
            4.5.15  QCELP ........................................... 28
            4.5.16  RED ............................................. 29
            4.5.17  VDVI ............................................ 29
   5.  Video ........................................................ 30
       5.1  CelB .................................................... 30
       5.2  JPEG .................................................... 30
       5.3  H261 .................................................... 30
       5.4  H263 .................................................... 31
       5.5  H263-1998 ............................................... 31
       5.6  MPV ..................................................... 31
       5.7  MP2T .................................................... 31
       5.8  nv ...................................................... 32
   6.  Payload Type Definitions ..................................... 32
   7.  RTP over TCP and Similar Byte Stream Protocols ............... 34
   8.  Port Assignment .............................................. 34
   9.  Changes from RFC 1890 ........................................ 35
   10. Security Considerations ...................................... 38
   11. IANA Considerations .......................................... 39
   12. References ................................................... 39
       12.1 Normative References .................................... 39
       12.2 Informative References .................................. 39
   13. Current Locations of Related Resources ....................... 41



Schulzrinne & Casner        Standards Track                     [Page 2]

RFC 3551                    RTP A/V Profile                    July 2003


   14. Acknowledgments .............................................. 42
   15. Intellectual Property Rights Statement ....................... 43
   16. Authors' Addresses ........................................... 43
   17. Full Copyright Statement ..................................... 44

1. Introduction

   This profile defines aspects of RTP left unspecified in the RTP
   Version 2 protocol definition (RFC 3550) [1].  This profile is
   intended for the use within audio and video conferences with minimal
   session control.  In particular, no support for the negotiation of
   parameters or membership control is provided.  The profile is
   expected to be useful in sessions where no negotiation or membership
   control are used (e.g., using the static payload types and the
   membership indications provided by RTCP), but this profile may also
   be useful in conjunction with a higher-level control protocol.

   Use of this profile may be implicit in the use of the appropriate
   applications; there may be no explicit indication by port number,
   protocol identifier or the like.  Applications such as session
   directories may use the name for this profile specified in Section
   11.

   Other profiles may make different choices for the items specified
   here.

   This document also defines a set of encodings and payload formats for
   audio and video.  These payload format descriptions are included here
   only as a matter of convenience since they are too small to warrant
   separate documents.  Use of these payload formats is NOT REQUIRED to
   use this profile.  Only the binding of some of the payload formats to
   static payload type numbers in Tables 4 and 5 is normative.

1.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2] and
   indicate requirement levels for implementations compliant with this
   RTP profile.

   This document defines the term media type as dividing encodings of
   audio and video content into three classes: audio, video and
   audio/video (interleaved).







Schulzrinne & Casner        Standards Track                     [Page 3]

RFC 3551                    RTP A/V Profile                    July 2003


2. RTP and RTCP Packet Forms and Protocol Behavior

   The section "RTP Profiles and Payload Format Specifications" of RFC
   3550 enumerates a number of items that can be specified or modified
   in a profile.  This section addresses these items.  Generally, this
   profile follows the default and/or recommended aspects of the RTP
   specification.

   RTP data header: The standard format of the fixed RTP data
      header is used (one marker bit).

   Payload types: Static payload types are defined in Section 6.

   RTP data header additions: No additional fixed fields are
      appended to the RTP data header.

   RTP data header extensions: No RTP header extensions are
      defined, but applications operating under this profile MAY use
      such extensions.  Thus, applications SHOULD NOT assume that the
      RTP header X bit is always zero and SHOULD be prepared to ignore
      the header extension.  If a header extension is defined in the
      future, that definition MUST specify the contents of the first 16
      bits in such a way that multiple different extensions can be
      identified.

   RTCP packet types: No additional RTCP packet types are defined
      by this profile specification.

   RTCP report interval: The suggested constants are to be used for
      the RTCP report interval calculation.  Sessions operating under
      this profile MAY specify a separate parameter for the RTCP traffic
      bandwidth rather than using the default fraction of the session
      bandwidth.  The RTCP traffic bandwidth MAY be divided into two
      separate session parameters for those participants which are
      active data senders and those which are not.  Following the
      recommendation in the RTP specification [1] that 1/4 of the RTCP
      bandwidth be dedicated to data senders, the RECOMMENDED default
      values for these two parameters would be 1.25% and 3.75%,
      respectively.  For a particular session, the RTCP bandwidth for
      non-data-senders MAY be set to zero when operating on
      unidirectional links or for sessions that don't require feedback
      on the quality of reception.  The RTCP bandwidth for data senders
      SHOULD be kept non-zero so that sender reports can still be sent
      for inter-media synchronization and to identify the source by
      CNAME.  The means by which the one or two session parameters for
      RTCP bandwidth are specified is beyond the scope of this memo.





Schulzrinne & Casner        Standards Track                     [Page 4]

RFC 3551                    RTP A/V Profile                    July 2003


   SR/RR extension: No extension section is defined for the RTCP SR
      or RR packet.

   SDES use: Applications MAY use any of the SDES items described
      in the RTP specification.  While CNAME information MUST be sent
      every reporting interval, other items SHOULD only be sent every
      third reporting interval, with NAME sent seven out of eight times
      within that slot and the remaining SDES items cyclically taking up
      the eighth slot, as defined in Section 6.2.2 of the RTP
      specification.  In other words, NAME is sent in RTCP packets 1, 4,
      7, 10, 13, 16, 19, while, say, EMAIL is used in RTCP packet 22.

   Security: The RTP default security services are also the default
      under this profile.

   String-to-key mapping: No mapping is specified by this profile.

   Congestion: RTP and this profile may be used in the context of
      enhanced network service, for example, through Integrated Services
      (RFC 1633) [4] or Differentiated Services (RFC 2475) [5], or they
      may be used with best effort service.

      If enhanced service is being used, RTP receivers SHOULD monitor
      packet loss to ensure that the service that was requested is
      actually being delivered.  If it is not, then they SHOULD assume
      that they are receiving best-effort service and behave
      accordingly.

      If best-effort service is being used, RTP receivers SHOULD monitor
      packet loss to ensure that the packet loss rate is within
      acceptable parameters.  Packet loss is considered acceptable if a
      TCP flow across the same network path and experiencing the same
      network conditions would achieve an average throughput, measured
      on a reasonable timescale, that is not less than the RTP flow is
      achieving.  This condition can be satisfied by implementing
      congestion control mechanisms to adapt the transmission rate (or
      the number of layers subscribed for a layered multicast session),
      or by arranging for a receiver to leave the session if the loss
      rate is unacceptably high.

      The comparison to TCP cannot be specified exactly, but is intended
      as an "order-of-magnitude" comparison in timescale and throughput.
      The timescale on which TCP throughput is measured is the round-
      trip time of the connection.  In essence, this requirement states
      that it is not acceptable to deploy an application (using RTP or
      any other transport protocol) on the best-effort Internet which
      consumes bandwidth arbitrarily and does not compete fairly with
      TCP within an order of magnitude.



Schulzrinne & Casner        Standards Track                     [Page 5]

RFC 3551                    RTP A/V Profile                    July 2003


   Underlying protocol: The profile specifies the use of RTP over