Network Working Group                                     H. SchulzrinneRequest for Comments: 3551                           Columbia UniversityObsoletes: 1890                                                S. CasnerCategory: Standards Track                                  Packet Design                                                               July 2003              RTP Profile for Audio and Video Conferences                          with Minimal ControlStatus 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 2003Table 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 ....................... 41Schulzrinne & 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 ..................................... 441. 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 20032. 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