Network Working Group                                     H. SchulzrinneRequest for Comments: 3550                           Columbia UniversityObsoletes: 1889                                               S.  CasnerCategory: Standards Track                                  Packet Design                                                            R. Frederick                                                  Blue Coat Systems Inc.                                                             V. Jacobson                                                           Packet Design                                                               July 2003          RTP: A Transport Protocol for Real-Time ApplicationsStatus 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 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.   Most of the text in this memorandum is identical to RFC 1889 which it   obsoletes.  There are no changes in the packet formats on the wire,   only changes to the rules and algorithms governing how the protocol   is used.  The biggest change is an enhancement to the scalable timer   algorithm for calculating when to send RTCP packets in order to   minimize transmission in excess of the intended rate when many   participants join a session simultaneously.Schulzrinne, et al.         Standards Track                     [Page 1]RFC 3550                          RTP                          July 2003Table of Contents   1.  Introduction ................................................   4       1.1  Terminology ............................................   5   2.  RTP Use Scenarios ...........................................   5       2.1  Simple Multicast Audio Conference ......................   6       2.2  Audio and Video Conference .............................   7       2.3  Mixers and Translators .................................   7       2.4  Layered Encodings ......................................   8   3.  Definitions .................................................   8   4.  Byte Order, Alignment, and Time Format ......................  12   5.  RTP Data Transfer Protocol ..................................  13       5.1  RTP Fixed Header Fields ................................  13       5.2  Multiplexing RTP Sessions ..............................  16       5.3  Profile-Specific Modifications to the RTP Header .......  18            5.3.1  RTP Header Extension ............................  18   6.  RTP Control Protocol -- RTCP ................................  19       6.1  RTCP Packet Format .....................................  21       6.2  RTCP Transmission Interval .............................  24            6.2.1  Maintaining the Number of Session Members .......  28       6.3  RTCP Packet Send and Receive Rules .....................  28            6.3.1  Computing the RTCP Transmission Interval ........  29            6.3.2  Initialization ..................................  30            6.3.3  Receiving an RTP or Non-BYE RTCP Packet .........  31            6.3.4  Receiving an RTCP BYE Packet ....................  31            6.3.5  Timing Out an SSRC ..............................  32            6.3.6  Expiration of Transmission Timer ................  32            6.3.7  Transmitting a BYE Packet .......................  33            6.3.8  Updating we_sent ................................  34            6.3.9  Allocation of Source Description Bandwidth ......  34       6.4  Sender and Receiver Reports ............................  35            6.4.1  SR: Sender Report RTCP Packet ...................  36            6.4.2  RR: Receiver Report RTCP Packet .................  42            6.4.3  Extending the Sender and Receiver Reports .......  42            6.4.4  Analyzing Sender and Receiver Reports ...........  43       6.5  SDES: Source Description RTCP Packet ...................  45            6.5.1  CNAME: Canonical End-Point Identifier SDES Item .  46            6.5.2  NAME: User Name SDES Item .......................  48            6.5.3  EMAIL: Electronic Mail Address SDES Item ........  48            6.5.4  PHONE: Phone Number SDES Item ...................  49            6.5.5  LOC: Geographic User Location SDES Item .........  49            6.5.6  TOOL: Application or Tool Name SDES Item ........  49            6.5.7  NOTE: Notice/Status SDES Item ...................  50            6.5.8  PRIV: Private Extensions SDES Item ..............  50       6.6  BYE: Goodbye RTCP Packet ...............................  51       6.7  APP: Application-Defined RTCP Packet ...................  52   7.  RTP Translators and Mixers ..................................  53       7.1  General Description ....................................  53Schulzrinne, et al.         Standards Track                     [Page 2]RFC 3550                          RTP                          July 2003       7.2  RTCP Processing in Translators .........................  55       7.3  RTCP Processing in Mixers ..............................  57       7.4  Cascaded Mixers ........................................  58   8.  SSRC Identifier Allocation and Use ..........................  59       8.1  Probability of Collision ...............................  59       8.2  Collision Resolution and Loop Detection ................  60       8.3  Use with Layered Encodings .............................  64   9.  Security ....................................................  65       9.1  Confidentiality ........................................  65       9.2  Authentication and Message Integrity ...................  67   10. Congestion Control ..........................................  67   11. RTP over Network and Transport Protocols ....................  68   12. Summary of Protocol Constants ...............................  69       12.1 RTCP Packet Types ......................................  70       12.2 SDES Types .............................................  70   13. RTP Profiles and Payload Format Specifications ..............  71   14. Security Considerations .....................................  73   15. IANA Considerations .........................................  73   16. Intellectual Property Rights Statement ......................  74   17. Acknowledgments .............................................  74   Appendix A.   Algorithms ........................................  75   Appendix A.1  RTP Data Header Validity Checks ...................  78   Appendix A.2  RTCP Header Validity Checks .......................  82   Appendix A.3  Determining Number of Packets Expected and Lost ...  83   Appendix A.4  Generating RTCP SDES Packets ......................  84   Appendix A.5  Parsing RTCP SDES Packets .........................  85   Appendix A.6  Generating a Random 32-bit Identifier .............  85   Appendix A.7  Computing the RTCP Transmission Interval ..........  87   Appendix A.8  Estimating the Interarrival Jitter ................  94   Appendix B.   Changes from RFC 1889 .............................  95   References ...................................................... 100   Normative References ............................................ 100   Informative References .......................................... 100   Authors' Addresses .............................................. 103   Full Copyright Statement ........................................ 104Schulzrinne, et al.         Standards Track                     [Page 3]RFC 3550                          RTP                          July 20031. 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 11).  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, 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 [10].  That is, RTP is intended to be malleableSchulzrinne, et al.         Standards Track                     [Page 4]RFC 3550                          RTP                          July 2003   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.4.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 13):   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      3551 [1].   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 [11].1.1 Terminology   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this