RFC 8088
How to Write an RTP Payload Format
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 FormatAbstract
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.
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
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
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
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
QoS: Quality of Service RFC: Request For Comments RTP: Real-time Transport Protocol RTCP: RTP Control Protocol RTT: Round-Trip Time SSM: Source-Specific Multicast2.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.
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
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.
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
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.
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.
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
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)
