tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8088

Informational
Pages: 65
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: PAYLOAD

How to Write an RTP Payload Format

Part 1 of 5, p. 1 to 13
None       Next Section

Updates:    2736


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                     M. Westerlund
Request for Comments: 8088                                      Ericsson
Updates: 2736                                                   May 2017
Category: Informational
ISSN: 2070-1721


                   How to Write an RTP Payload Format

Abstract

   This document contains information on how best to write an RTP
   payload format specification.  It provides reading tips, design
   practices, and practical tips on how to produce an RTP payload format
   specification quickly and with good results.  A template is also
   included with instructions.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc8088.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................4
      1.1. Structure ..................................................4
   2. Terminology .....................................................5
      2.1. Definitions ................................................5
      2.2. Abbreviations ..............................................5
      2.3. Use of Normative Requirements Language .....................6
   3. Preparations ....................................................6
      3.1. Read and Understand the Media Coding Specification .........6
      3.2. Recommended Reading ........................................7
           3.2.1. IETF Process and Publication ........................7
           3.2.2. RTP .................................................9
      3.3. Important RTP Details .....................................13
           3.3.1. The RTP Session ....................................13
           3.3.2. RTP Header .........................................14
           3.3.3. RTP Multiplexing ...................................16
           3.3.4. RTP Synchronization ................................16
      3.4. Signaling Aspects .........................................18
           3.4.1. Media Types ........................................19
           3.4.2. Mapping to SDP .....................................20
      3.5. Transport Characteristics .................................23
           3.5.1. Path MTU ...........................................23
           3.5.2. Different Queuing Algorithms .......................23
           3.5.3. Quality of Service .................................24
   4. Standardization Process for an RTP Payload Format ..............24
      4.1. IETF ......................................................25
           4.1.1. Steps from Idea to Publication .....................25
           4.1.2. WG Meetings ........................................27
           4.1.3. Draft Naming .......................................27
           4.1.4. Writing Style ......................................28
           4.1.5. How to Speed Up the Process ........................29
      4.2. Other Standards Bodies ....................................29
      4.3. Proprietary and Vendor Specific ...........................30
      4.4. Joint Development of Media Coding Specification
           and RTP Payload Format ....................................31
   5. Designing Payload Formats ......................................31
      5.1. Features of RTP Payload Formats ...........................32
           5.1.1. Aggregation ........................................32
           5.1.2. Fragmentation ......................................33
           5.1.3. Interleaving and Transmission Rescheduling .........33
           5.1.4. Media Back Channels ................................34
           5.1.5. Media Scalability ..................................34
           5.1.6. High Packet Rates ..................................37
      5.2. Selecting Timestamp Definition ............................37

Top      ToC       Page 3 
   6. Noteworthy Aspects in Payload Format Design ....................39
      6.1. Audio Payloads ............................................39
      6.2. Video .....................................................40
      6.3. Text ......................................................41
      6.4. Application ...............................................41
   7. Important Specification Sections ...............................42
      7.1. Media Format Description ..................................42
      7.2. Security Considerations ...................................43
      7.3. Congestion Control ........................................44
      7.4. IANA Considerations .......................................45
   8. Authoring Tools ................................................45
      8.1. Editing Tools .............................................46
      8.2. Verification Tools ........................................46
   9. Security Considerations ........................................47
   10. Informative References ........................................47
   Appendix A. RTP Payload Format Template ...........................58
     A.1.  Title .....................................................58
     A.2.  Front-Page Boilerplate ....................................58
     A.3.  Abstract ..................................................58
     A.4.  Table of Contents .........................................58
     A.5.  Introduction ..............................................59
     A.6.  Conventions, Definitions, and Abbreviations ...............59
     A.7.  Media Format Description ..................................59
     A.8.  Payload Format ............................................59
       A.8.1.  RTP Header Usage ......................................59
       A.8.2.  Payload Header ........................................59
       A.8.3.  Payload Data ..........................................60
     A.9.  Payload Examples ..........................................60
     A.10. Congestion Control Considerations .........................60
     A.11. Payload Format Parameters .................................60
       A.11.1.  Media Type Definition ................................60
       A.11.2.  Mapping to SDP .......................................62
     A.12. IANA Considerations .......................................63
     A.13. Security Considerations ...................................63
     A.14. RFC Editor Considerations .................................64
     A.15. References ................................................64
       A.15.1.  Normative References .................................64
       A.15.2.  Informative References ...............................64
     A.16. Authors' Addresses ........................................64
   Acknowledgements ..................................................64
   Contributors ......................................................65
   Author's Address ..................................................65

Top      ToC       Page 4 
1.  Introduction

   RTP [RFC3550] payload formats define how a specific real-time data
   format is structured in the payload of an RTP packet.  A real-time
   data format without a payload format specification cannot be
   transported using RTP.  This creates an interest in many individuals/
   organizations with media encoders or other types of real-time data to
   define RTP payload formats.  However, the specification of a well-
   designed RTP payload format is nontrivial and requires knowledge of
   both RTP and the real-time data format.

   This document is intended to help any author of an RTP payload format
   specification make important design decisions, consider important
   features of RTP and RTP security, etc.  The document is also intended
   to be a good starting point for any person with little experience in
   the IETF and/or RTP to learn the necessary steps.

   This document extends and updates the information that is available
   in "Guidelines for Writers of RTP Payload Format Specifications"
   [RFC2736].  Since that RFC was written, further experience has been
   gained on the design and specification of RTP payload formats.
   Several new RTP profiles and robustness tools have been defined, and
   these need to be considered.

   This document also discusses the possible venues for defining an RTP
   payload format: the IETF, other standards bodies, and proprietary
   ones.

   Note, this document does discuss IETF, IANA, and RFC Editor processes
   and rules as they were when this document was published.  This to
   make clear how the work to specify an RTP payload formats depends,
   uses, and interacts with these rules and processes.  However, these
   rules and processes are subject to change and the formal rule and
   process specifications always takes precedence over what is written
   here.

1.1.  Structure

   This document has several different parts discussing different
   aspects of the creation of an RTP payload format specification.
   Section 3 discusses the preparations the author(s) should make before
   starting to write a specification.  Section 4 discusses the different
   processes used when specifying and completing a payload format, with
   focus on working inside the IETF.  Section 5 discusses the design of
   payload formats themselves in detail.  Section 6 discusses current
   design trends and provides good examples of practices that should be
   followed when applicable.  Following that, Section 7 provides a
   discussion on important sections in the RTP payload format

Top      ToC       Page 5 
   specification itself such as Security Considerations and IANA
   Considerations.  This document ends with an appendix containing a
   template that can be used when writing RTP payload formats
   specifications.

2.  Terminology

2.1.  Definitions

   RTP Stream:  A sequence of RTP packets that together carry part or
      all of the content of a specific media (audio, video, text, or
      data whose form and meaning are defined by a specific real-time
      application) from a specific sender source within a given RTP
      session.

   RTP Session:  An association among a set of participants
      communicating with RTP.  The distinguishing feature of an RTP
      session is that each session maintains a full, separate space of
      synchronization source (SSRC) identifiers.  See also
      Section 3.3.1.

   RTP Payload Format:  The RTP payload format specifies how units of a
      specific encoded media are put into the RTP packet payloads and
      how the fields of the RTP packet header are used, thus enabling
      the format to be used in RTP applications.

   A Taxonomy of Semantics and Mechanisms for Real-Time Transport
   Protocol (RTP) Sources [RFC7656] defines many useful terms.

2.2.  Abbreviations

   ABNF:  Augmented Backus-Naur Form [RFC5234]

   ADU:  Application Data Unit

   ALF:  Application Level Framing

   ASM:  Any-Source Multicast

   BCP:  Best Current Practice

   I-D:  Internet-Draft

   IESG:  Internet Engineering Steering Group

   MTU:  Maximum Transmission Unit

   WG:  Working Group

Top      ToC       Page 6 
   QoS:  Quality of Service

   RFC:  Request For Comments

   RTP:  Real-time Transport Protocol

   RTCP:  RTP Control Protocol

   RTT:  Round-Trip Time

   SSM:  Source-Specific Multicast

2.3.  Use of Normative Requirements Language

   As this document is both Informational and instructional rather than
   a specification, this document does not use any RFC 2119 language and
   the use of "may", "should", "recommended", and "must" carries no
   special connotation.

3.  Preparations

   RTP is a complex real-time media delivery framework, and it has a lot
   of details that need to be considered when writing an RTP payload
   format.  It is also important to have a good understanding of the
   media codec / format so that all of its important features and
   properties are considered.  Only when one has sufficient
   understanding of both parts can one produce an RTP payload format of
   high quality.  On top of this, one needs to understand the process
   within the IETF and especially the Working Group responsible for
   standardizing payload formats (currently the PAYLOAD WG) to go
   quickly from the initial idea stage to a finished RFC.  This and the
   next sections help an author prepare himself in those regards.

3.1.  Read and Understand the Media Coding Specification

   It may be obvious, but it is necessary for an author of an RTP
   payload specification to have a solid understanding of the media to
   be transported.  Important are not only the specifically spelled out
   transport aspects (if any) in the media coding specification, but
   also core concepts of the underlying technology.  For example, an RTP
   payload format for video coded with inter-picture prediction will
   perform poorly if the payload designer does not take the use of
   inter-picture prediction into account.  On the other hand, some
   (mostly older) media codecs offer error-resilience tools against bit
   errors, which, when misapplied over RTP, in almost all cases would
   only introduce overhead with no measurable return.

Top      ToC       Page 7 
3.2.  Recommended Reading

   The following subsections list a number of documents.  Not all need
   to be read in full detail.  However, an author basically needs to be
   aware of everything listed below.

3.2.1.  IETF Process and Publication

   Newcomers to the IETF are strongly recommended to read the "Tao of
   the IETF" [TAO] that goes through most things that one needs to know
   about the IETF: the history, organizational structure, how the WGs
   and meetings work, etc.

   It is very important to note and understand the IETF Intellectual
   Property Rights (IPR) policy that requires early disclosures based on
   personal knowledge from anyone contributing in IETF.  The IETF
   policies associated with IPR are documented in BCP 78 [BCP78]
   (related to copyright, including software copyright, for example,
   code) and BCP 79 [BCP79] (related to patent rights).  These rules may
   be different from other standardization organizations.  For example,
   a person that has a patent or a patent application that he or she
   reasonably and personally believes to cover a mechanism that gets
   added to the Internet-Draft they are contributing to (e.g., by
   submitting the draft, posting comments or suggestions on a mailing
   list, or speaking at a meeting) will need to make a timely IPR
   disclosure.  Read the above documents for the authoritative rules.
   Failure to follow the IPR rules can have dire implications for the
   specification and the author(s) as discussed in [RFC6701].

      Note: These IPR rules apply on what is specified in the RTP
      payload format Internet-Draft (and later RFC); an IPR that relates
      to a codec specification from an external body does not require
      IETF IPR disclosure.  Informative text explaining the nature of
      the codec would not normally require an IETF IPR declaration.
      Appropriate IPR declarations for the codec itself would normally
      be found in files of the external body defining the codec, in
      accordance with that external body's own IPR rules.

   The main part of the IETF process is formally defined in BCP 9
   [BCP9].  BCP 25 [BCP25] describes the WG process, the relation
   between the IESG and the WG, and the responsibilities of WG Chairs
   and participants.

   It is important to note that the RFC Series contains documents of
   several different publication streams as defined by The RFC Series
   and RFC Editor [RFC4844].  The most important stream for RTP payload
   formats authors is the IETF Stream.  In this stream, the work of the
   IETF is published.  The stream contains documents of several

Top      ToC       Page 8 
   different categories: Standards Track, Informational, Experimental,
   Best Current Practice, and Historic.  "Standards Track" contains two
   maturity levels: Proposed Standard and Internet Standard [RFC6410].
   A Standards Track document must start as a Proposed Standard; after
   successful deployment and operational experience with at least two
   implementations, it can be moved to an Internet Standard.  The
   Independent Submission Stream could appear to be of interest as it
   provides a way of publishing documents of certain categories such as
   Experimental and Informational with a different review process.
   However, as long as IETF has a WG that is chartered to work on RTP
   payload formats, this stream should not be used.

   As the content of a given RFC is not allowed to change once
   published, the only way to modify an RFC is to write and publish a
   new one that either updates or replaces the old one.  Therefore,
   whether reading or referencing an RFC, it is important to consider
   both the Category field in the document header and to check if the
   RFC is the latest on the subject and still valid.  One way of
   checking the current status of an RFC is to use the RFC Editor's RFC
   search page (https://www.rfc-editor.org/search), which displays the
   current status and which if any RFC has updated or obsoleted it.  The
   RFC Editor search engine will also indicate if there exist any errata
   reports for the RFC.  Any verified errata report contains issues of
   significant importance with the RFC; thus, they should be known prior
   to an update and replacement publication.

   Before starting to write a draft, one should also read the Internet-
   Draft writing guidelines (http://www.ietf.org/ietf/1id-
   guidelines.txt), the I-D checklist (http://www.ietf.org/ID-
   Checklist.html), and the RFC Style Guide [RFC7322].  Another document
   that can be useful is "Guide for Internet Standards Writers"
   [RFC2360].

   There are also a number of documents to consider in the process of
   writing drafts intended to become RFCs.  These are important when
   writing certain types of text.

   RFC 2606:  When writing examples using DNS names in Internet-Drafts,
      those names shall be chosen from the example.com, example.net, and
      example.org domains.

   RFC 3849:  Defines the range of IPv6 unicast addresses
      (2001:DB8::/32) that should be used in any examples.

   RFC 5737:  Defines the ranges of IPv4 unicast addresses reserved for
      documentation and examples: 192.0.2.0/24, 198.51.100.0/24, and
      203.0.113.0/24.

Top      ToC       Page 9 
   RFC 5234:  Augmented Backus-Naur Form (ABNF) is often used when
      writing text field specifications.  Not commonly used in RTP
      payload formats, but may be useful when defining media type
      parameters of some complexity.

3.2.2.  RTP

   The recommended reading for RTP consists of several different parts:
   design guidelines, the RTP protocol, profiles, robustness tools, and
   media-specific recommendations.

   Any author of RTP payload formats should start by reading "Guidelines
   for Writers of RTP Payload Format Specifications" [RFC2736], which
   contains an introduction to the Application Level Framing (ALF)
   principle, the channel characteristics of IP channels, and design
   guidelines for RTP payload formats.  The goal of ALF is to be able to
   transmit Application Data Units (ADUs) that are independently usable
   by the receiver in individual RTP packets, thus minimizing
   dependencies between RTP packets and the effects of packet loss.

   Then, it is advisable to learn more about the RTP protocol, by
   studying the RTP specification "RTP: A Transport Protocol for Real-
   Time Applications" [RFC3550] and the existing profiles.  As a
   complement to the Standards Track documents, there exists a book
   totally dedicated to RTP [CSP-RTP].  There exist several profiles for
   RTP today, but all are based on "RTP Profile for Audio and Video
   Conferences with Minimal Control" [RFC3551] (abbreviated as RTP/AVP).
   The other profiles that one should know about are "The Secure Real-
   time Transport Protocol (SRTP)" (RTP/SAVP) [RFC3711], "Extended RTP
   Profile for RTCP-based Feedback (RTP/AVPF)" [RFC4585], and "Extended
   Secure Real-time Transport Control Protocol (RTCP)-Based Feedback
   (RTP/SAVPF)" [RFC5124].  It is important to understand RTP and the
   RTP/AVP profile in detail.  For the other profiles, it is sufficient
   to have an understanding of what functionality they provide and the
   limitations they create.

   A number of robustness tools have been developed for RTP.  The tools
   are for different use cases and real-time requirements.

   RFC 2198:  "RTP Payload for Redundant Audio Data" [RFC2198] provides
      functionalities to transmit redundant copies of audio or text
      payloads.  These redundant copies are sent together with a primary
      format in the same RTP payload.  This format relies on the RTP
      timestamp to determine where data belongs in a sequence;
      therefore, it is usually most suitable to be used with audio.
      However, the RTP Payload format for T.140 [RFC4103] text format
      also uses this format.  The format's major property is that it
      only preserves the timestamp of the redundant payloads, not the

Top      ToC       Page 10 
      original sequence number.  This makes it unusable for most video
      formats.  This format is also only suitable for media formats that
      produce relatively small RTP payloads.

   RFC 6354:  The "Forward-Shifted RTP Redundancy Payload Support"
      [RFC6354] is a variant of RFC 2198 that allows the redundant data
      to be transmitted prior to the original.

   RFC 5109:  The "RTP Payload Format for Generic Forward Error
      Correction" [RFC5109] provides an XOR-based Forward Error
      Correction (FEC) of the whole or parts of a number of RTP packets.
      This specification replaced the previous specification for XOR-
      based FEC [RFC2733].  These FEC packets are sent in a separate
      stream or as a redundant encoding using RFC 2198.  This FEC scheme
      has certain restrictions in the number of packets it can protect.
      It is suitable for applications with low-to-medium delay tolerance
      with a limited amount of RTP packets.

   RFC 6015:  "RTP Payload Format for 1-D Interleaved Parity Forward
      Error Correction (FEC)" [RFC6015] provides a variant of the XOR-
      based Generic protection defined in [RFC2733].  The main
      difference is to use interleaving scheme on which packets gets
      included as source packets for a particular protection packet.
      The interleaving is defined by using every L packets as source
      data and then producing protection data over D number of packets.
      Thus, each block of D x L source packets will result in L number
      of Repair packets, each capable of repairing one loss.  The goal
      is to provide better burst-error robustness when the packet rate
      is higher.

   FEC Framework:  "Forward Error Correction (FEC) Framework" [RFC6363]
      defines how to use FEC protection for arbitrary packet flows.
      This framework can be applied for RTP/RTCP packet flows, including
      using RTP for transmission of repair symbols, an example is in
      "RTP Payload Format for Raptor Forward Error Correction (FEC)"
      [RFC6682].

   RTP Retransmission:  The RTP retransmission scheme [RFC4588] is used
      for semi-reliability of the most important RTP packets in a RTP
      stream.  The level of reliability between semi- and in-practice
      full reliability depends on the targeted properties and situation
      where parameters such as round-trip time (RTT) allowed additional
      overhead and allowable delay.  It often requires the application
      to be quite delay tolerant as a minimum of one round-trip time
      plus processing delay is required to perform a retransmission.
      Thus, it is mostly suitable for streaming applications but may
      also be usable in certain other cases when operating in networks
      with short round-trip times.

Top      ToC       Page 11 
   RTP over TCP:  RFC 4571 [RFC4571] defines how one sends RTP and RTCP
      packets over connection-oriented transports like TCP.  If one uses
      TCP, one gets reliability for all packets but loses some of the
      real-time behavior that RTP was designed to provide.  Issues with
      TCP transport of real-time media include head-of-line blocking and
      wasting resources on retransmission of data that is already late.
      TCP is also limited to point-to-point connections, which further
      restricts its applicability.

   There have been both discussion and design of RTP payload formats,
   e.g., Adaptive Multi-Rate (AMR) and AMR Wideband (AMR-WB) [RFC4867],
   supporting the unequal error detection provided by UDP-Lite
   [RFC3828].  The idea is that by not having a checksum over part of
   the RTP payload one can allow bit errors from the lower layers.  By
   allowing bit errors one can increase the efficiency of some link
   layers and also avoid unnecessary discarding of data when the payload
   and media codec can get at least some benefit from the data.  The
   main issue is that one has no idea of the level of bit errors present
   in the unprotected part of the payload.  This makes it hard or
   impossible to determine whether or not one can design something
   usable.  Payload format designers are not recommended to consider
   features for unequal error detection using UDP-Lite unless very clear
   requirements exist.

   There also exist some management and monitoring extensions.

   RFC 2959:  The RTP protocol Management Information Database (MIB)
      [RFC2959] that is used with SNMP [RFC3410] to configure and
      retrieve information about RTP sessions.

   RFC 3611:  The RTCP Extended Reports (RTCP XR) [RFC3611] consists of
      a framework for reports sent within RTCP.  It can easily be
      extended by defining new report formats, which has and is
      occurring.  The XRBLOCK WG in the IETF is chartered (at the time
      of writing) with defining new report formats.  The list of
      specified formats is available in IANA's RTCP XR Block Type
      registry (http://www.iana.org/assignments/rtcp-xr-block-types/).
      The report formats that are defined in RFC 3611 provide report
      information on packet loss, packet duplication, packet reception
      times, RTCP statistics summary, and VoIP Quality.  [RFC3611] also
      defines a mechanism that allows receivers to calculate the RTT to
      other session participants when used.

   RMONMIB:  The Remote Network Monitoring WG has defined a mechanism
      [RFC3577] based on usage of the MIB that can be an alternative to
      RTCP XR.

Top      ToC       Page 12 
   A number of transport optimizations have also been developed for use
   in certain environments.  They are all intended to be transparent and
   do not require special consideration by the RTP payload format
   writer.  Thus, they are primarily listed here for informational
   reasons.

   RFC 2508:  "Compressing IP/UDP/RTP Headers for Low-Speed Serial
      Links" (CRTP) [RFC2508] is the first IETF-developed RTP header
      compression mechanism.  It provides quite good compression;
      however, it has clear performance problems when subject to packet
      loss or reordering between compressor and decompressor.

   RFCs 3095 and 5795:  These are the base specifications of the robust
      header compression (ROHC) protocol version 1 [RFC3095] and version
      2 [RFC5795].  This solution was created as a result of CRTP's lack
      of performance when compressed packets are subject to loss.

   RFC 3545:  Enhanced compressed RTP (E-CRTP) [RFC3545] was developed
      to provide extensions to CRTP that allow for better performance
      over links with long RTTs, packet loss, and/or reordering.

   RFC 4170:  "Tunneling Multiplexed Compressed RTP (TCRTP)" [RFC4170]
      is a solution that allows header compression within a tunnel
      carrying multiple multiplexed RTP flows.  This is primarily used
      in voice trunking.

   There exist a couple of different security mechanisms that may be
   used with RTP.  By definition, generic mechanisms are transparent for
   the RTP payload format and do not need special consideration by the
   format designer.  The main reason that different solutions exist is
   that different applications have different requirements; thus,
   different solutions have been developed.  For more discussion on
   this, please see "Options for Securing RTP Sessions" [RFC7201] and
   "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media
   Security Solution" [RFC7202].  The main properties for an RTP
   security mechanism are to provide confidentiality for the RTP
   payload, integrity protection to detect manipulation of payload and
   headers, and source authentication.  Not all mechanisms provide all
   of these features, a point that will need to be considered when a
   specific mechanisms is chosen.

   The profile for Secure RTP - SRTP (RTP/SAVP) [RFC3711] and the
   derived profile (RTP/SAVPF [RFC5124]) are a solution that enables
   confidentiality, integrity protection, replay protection, and partial
   source authentication.  It is the solution most commonly used with
   RTP at the time of writing this document.  There exist several key-
   management solutions for SRTP, as well other choices, affecting the

Top      ToC       Page 13 
   security properties.  For a more in-depth review of the options and
   solutions other than SRTP consult "Options for Securing RTP Sessions"
   [RFC7201].



(page 13 continued on part 2)

Next Section