Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8088

How to Write an RTP Payload Format

Pages: 65
Informational
Updates:  2736
Part 1 of 5 – Pages 1 to 13
None   None   Next

Top   ToC   RFC8088 - 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   ToC   RFC8088 - 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   RFC8088 - 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   RFC8088 - 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   RFC8088 - 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   RFC8088 - 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   RFC8088 - 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   RFC8088 - 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   RFC8088 - 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   RFC8088 - 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   RFC8088 - 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   RFC8088 - 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   RFC8088 - 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