From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8088.txt | 3643 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 3643 insertions(+) create mode 100644 doc/rfc/rfc8088.txt (limited to 'doc/rfc/rfc8088.txt') diff --git a/doc/rfc/rfc8088.txt b/doc/rfc/rfc8088.txt new file mode 100644 index 0000000..6e24307 --- /dev/null +++ b/doc/rfc/rfc8088.txt @@ -0,0 +1,3643 @@ + + + + + + +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. + + + + +Westerlund Informational [Page 1] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +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 + + + + + + +Westerlund Informational [Page 2] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + 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 + + + + + + + + + +Westerlund Informational [Page 3] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +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 + + + +Westerlund Informational [Page 4] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + 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 + + + +Westerlund Informational [Page 5] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + 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. + + + + + +Westerlund Informational [Page 6] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +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 + + + +Westerlund Informational [Page 7] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + 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. + + + + +Westerlund Informational [Page 8] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + 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 + + + +Westerlund Informational [Page 9] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + 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. + + + +Westerlund Informational [Page 10] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + 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. + + + + + +Westerlund Informational [Page 11] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + 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 + + + + +Westerlund Informational [Page 12] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + security properties. For a more in-depth review of the options and + solutions other than SRTP consult "Options for Securing RTP Sessions" + [RFC7201]. + +3.3. Important RTP Details + + This section reviews a number of RTP features and concepts that are + available in RTP, independent of the payload format. The RTP payload + format can make use of these when appropriate, and even affect the + behavior (RTP timestamp and marker bit), but it is important to note + that not all features and concepts are relevant to every payload + format. This section does not remove the necessity to read up on + RTP. However, it does point out a few important details to remember + when designing a payload format. + +3.3.1. The RTP Session + + The definition of the RTP session from RFC 3550 is: + + An association among a set of participants communicating with RTP. + A participant may be involved in multiple RTP sessions at the same + time. In a multimedia session, each medium is typically carried + in a separate RTP session with its own RTCP packets unless the + encoding itself multiplexes multiple media into a single data + stream. A participant distinguishes multiple RTP sessions by + reception of different sessions using different pairs of + destination transport addresses, where a pair of transport + addresses comprises one network address plus a pair of ports for + RTP and RTCP. All participants in an RTP session may share a + common destination transport address pair, as in the case of IP + multicast, or the pairs may be different for each participant, as + in the case of individual unicast network addresses and port + pairs. In the unicast case, a participant may receive from all + other participants in the session using the same pair of ports, or + may use a distinct pair of ports for each. + + The distinguishing feature of an RTP session is that each session + maintains a full, separate space of SSRC identifiers (defined + next). The set of participants included in one RTP session + consists of those that can receive an SSRC identifier transmitted + by any one of the participants either in RTP as the SSRC or a CSRC + (also defined below) or in RTCP. For example, consider a three- + party conference implemented using unicast UDP with each + participant receiving from the other two on separate port pairs. + If each participant sends RTCP feedback about data received from + one other participant only back to that participant, then the + conference is composed of three separate point-to-point RTP + sessions. If each participant provides RTCP feedback about its + + + +Westerlund Informational [Page 13] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + reception of one other participant to both of the other + participants, then the conference is composed of one multi-party + RTP session. The latter case simulates the behavior that would + occur with IP multicast communication among the three + participants. + + The RTP framework allows the variations defined here, but a + particular control protocol or application design will usually + impose constraints on these variations. + +3.3.2. RTP Header + + The RTP header contains a number of fields. Two fields always + require additional specification by the RTP payload format, namely + the RTP timestamp and the marker bit. Certain RTP payload formats + also use the RTP sequence number to realize certain functionalities, + primarily related to the order of their application data units. The + payload type is used to indicate the used payload format. The SSRC + is used to distinguish RTP packets from multiple senders and media + sources identifying the RTP stream. Finally, [RFC5285] specifies how + to transport payload format independent metadata relating to the RTP + packet or stream. + + Marker Bit: A single bit normally used to provide important + indications. In audio, it is normally used to indicate the start + of a talk burst. This enables jitter buffer adaptation prior to + the beginning of the burst with minimal audio quality impact. In + video, the marker bit is normally used to indicate the last packet + part of a frame. This enables a decoder to finish decoding the + picture, where it otherwise may need to wait for the next packet + to explicitly know that the frame is finished. + + Timestamp: The RTP timestamp indicates the time instance the media + sample belongs to. For discrete media like video, it normally + indicates when the media (frame) was sampled. For continuous + media, it normally indicates the first time instance the media + present in the payload represents. For audio, this is the + sampling time of the first sample. All RTP payload formats must + specify the meaning of the timestamp value and the clock rates + allowed. Selecting a timestamp rate is an active design choice + and is further discussed in Section 5.2. + + Discontinuous Transmission (DTX) that is common among speech + codecs, typically results in gaps or jumps in the timestamp values + due to that there is no media payload to transmit and the next + used timestamp value represent the actual sampling time of the + data transmitted. + + + + +Westerlund Informational [Page 14] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + Sequence Number: The sequence number is monotonically increasing and + is set as the packet is sent. This property is used in many + payload formats to recover the order of everything from the whole + stream down to fragments of application data units (ADUs) and the + order they need to be decoded. Discontinuous transmissions do not + result in gaps in the sequence number, as it is monotonically + increasing for each sent RTP packet. + + Payload Type: The payload type is used to indicate, on a per-packet + basis, which format is used. The binding between a payload type + number and a payload format and its configuration are dynamically + bound and RTP session specific. The configuration information can + be bound to a payload type value by out-of-band signaling + (Section 3.4). An example of this would be video decoder + configuration information. Commonly, the same payload type is + used for a media stream for the whole duration of a session. + However, in some cases it may be necessary to change the payload + format or its configuration during the session. + + SSRC: The synchronization source (SSRC) identifier is normally not + used by a payload format other than to identify the RTP timestamp + and sequence number space a packet belongs to, allowing + simultaneously reception of multiple media sources. However, some + of the RTP mechanisms for improving resilience to packet loss uses + multiple SSRCs to separate original data and repair or redundant + data, as well as multi-stream transmission of scalable codecs. + + Header Extensions: RTP payload formats often need to include + metadata relating to the payload data being transported. Such + metadata is sent as a payload header, at the start of the payload + section of the RTP packet. The RTP packet also includes space for + a header extension [RFC5285]; this can be used to transport + payload format independent metadata, for example, an SMPTE time + code for the packet [RFC5484]. The RTP header extensions are not + intended to carry headers that relate to a particular payload + format, and must not contain information needed in order to decode + the payload. + + The remaining fields do not commonly influence the RTP payload + format. The padding bit is worth clarifying as it indicates that one + or more bytes are appended after the RTP payload. This padding must + be removed by a receiver before payload format processing can occur. + Thus, it is completely separate from any padding that may occur + within the payload format itself. + + + + + + + +Westerlund Informational [Page 15] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +3.3.3. RTP Multiplexing + + RTP has three multiplexing points that are used for different + purposes. A proper understanding of this is important to correctly + use them. + + The first one is separation of RTP streams of different types or + usages, which is accomplished using different RTP sessions. So, for + example, in the common multimedia session with audio and video, RTP + commonly multiplexes audio and video in different RTP sessions. To + achieve this separation, transport-level functionalities are used, + normally UDP port numbers. Different RTP sessions can also be used + to realize layered scalability as it allows a receiver to select one + or more layers for multicast RTP sessions simply by joining the + multicast groups over which the desired layers are transported. This + separation also allows different Quality of Service (QoS) to be + applied to different media types. Use of multiple transport flows + has potential issues due to NAT and firewall traversal. The choices + how one applies RTP sessions as well as transport flows can affect + the transport properties an RTP media stream experiences. + + The next multiplexing point is separation of different RTP streams + within an RTP session. Here, RTP uses the SSRC to identify + individual sources of RTP streams. An example of individual media + sources would be the capture of different microphones that are + carried in an RTP session for audio, independently of whether they + are connected to the same host or different hosts. There also exist + cases where a single media source, is transmitted using multiple RTP + streams. For each SSRC, a unique RTP sequence number and timestamp + space is used. + + The third multiplexing point is the RTP header payload type field. + The payload type identifies what format the content in the RTP + payload has. This includes different payload format configurations, + different codecs, and also usage of robustness mechanisms like the + one described in RFC 2198 [RFC2198]. + +3.3.4. RTP Synchronization + + There are several types of synchronization, and we will here describe + how RTP handles the different types: + + Intra media: The synchronization within a media stream from a + synchronization source (SSRC) is accomplished using the RTP + timestamp field. Each RTP packet carries the RTP timestamp, which + specifies the position in time of the media payload contained in + this packet relative to the content of other RTP packets in the + same RTP stream (i.e., a given SSRC). This is especially useful + + + +Westerlund Informational [Page 16] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + in cases of discontinuous transmissions. Discontinuities can be + caused by network conditions; when extensive losses occur the RTP + timestamp tells the receiver how much later than previously + received media the present media should be played out. + + Inter-media: Applications commonly have a desire to use several + media sources, possibly of different media types, at the same + time. Thus, there exists a need to synchronize different media + from the same endpoint. This puts two requirements on RTP: the + possibility to determine which media are from the same endpoint + and if they should be synchronized with each other and the + functionality to facilitate the synchronization itself. + + The first step in inter-media synchronization is to determine which + SSRCs in each session should be synchronized with each other. This + is accomplished by comparing the CNAME fields in the RTCP source + description (SDES) packets. SSRCs with the same CNAME sent in any of + multiple RTP sessions can be synchronized. + + The actual RTCP mechanism for inter-media synchronization is based on + the idea that each RTP stream provides a position on the media + specific time line (measured in RTP timestamp ticks) and a common + reference time line. The common reference time line is expressed in + RTCP as a wall-clock time in the Network Time Protocol (NTP) format. + It is important to notice that the wall-clock time is not required to + be synchronized between hosts, for example, by using NTP [RFC5905]. + It can even have nothing at all to do with the actual time; for + example, the host system's up-time can be used for this purpose. The + important factor is that all media streams from a particular source + that are being synchronized use the same reference clock to derive + their relative RTP timestamp time scales. The type of reference + clock and its timebase can be signaled using RTP Clock Source + Signaling [RFC7273]. + + Figure 1 illustrates how if one receives RTCP Sender Report (SR) + packet P1 for one RTP stream and RTCP SR packet P2 for the other RTP + stream, then one can calculate the corresponding RTP timestamp values + for any arbitrary point in time T. However, to be able to do that, + it is also required to know the RTP timestamp rates for each RTP + stream currently used in the sessions. + + + + + + + + + + + +Westerlund Informational [Page 17] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + TS1 --+---------------+-------> + | | + P1 | + | | + NTP ---+-----+---------T------> + | | + P2 | + | | + TS2 ---------+---------+---X--> + + Figure 1: RTCP Synchronization + + Assume that medium 1 uses an RTP timestamp clock rate of 16 kHz, and + medium 2 uses a clock rate of 90 kHz. Then, TS1 and TS2 for point T + can be calculated in the following way: TS1(T) = TS1(P1) + 16000 * + (NTP(T)-NTP(P1)) and TS2(T) = TS2(P2) + 90000 * (NTP(T)-NTP(P2)). + This calculation is useful as it allows the implementation to + generate a common synchronization point for which all time values are + provided (TS1(T), TS2(T) and T). So, when one wishes to calculate + the NTP time that the timestamp value present in packet X corresponds + to, one can do that in the following way: NTP(X) = NTP(T) + (TS2(X) - + TS2(T))/90000. + + Improved signaling for layered codecs and fast tune-in have been + specified in "Rapid Synchronization for RTP Flows" [RFC6051]. + + Leap seconds are extra seconds added or seconds removed to keep our + clocks in sync with the earth's rotation. Adding or removing seconds + can impact the reference clock as discussed in "RTP and Leap Seconds" + [RFC7164]; also, in cases where the RTP timestamp values are derived + using the wall clock during the leap second event, errors can occur. + Implementations need to consider leap seconds and should consider the + recommendations in [RFC7164]. + +3.4. Signaling Aspects + + RTP payload formats are used in the context of application signaling + protocols such as SIP [RFC3261] using the Session Description + Protocol (SDP) [RFC4566] with Offer/Answer [RFC3264], RTSP [RFC7826], + or the Session Announcement Protocol [RFC2974]. These examples all + use out-of-band signaling to indicate which type of RTP streams are + desired to be used in the session and how they are configured. To be + able to declare or negotiate the media format and RTP payload + packetization, the payload format must be given an identifier. In + addition to the identifier, many payload formats also have the need + to signal further configuration information out-of-band for the RTP + payloads prior to the media transport session. + + + + +Westerlund Informational [Page 18] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + The above examples of session-establishing protocols all use SDP, but + other session description formats may be used. For example, there + was discussion of a new XML-based session description format within + the IETF (SDP-NG). In the end, the proposal did not get beyond draft + protocol specification because of the enormous installed base of SDP + implementations. However, to avoid locking the usage of RTP to SDP + based out-of-band signaling, the payload formats are identified using + a separate definition format for the identifier and associated + parameters. That format is the media type. + +3.4.1. Media Types + + Media types [RFC6838] are identifiers originally created for + identifying media formats included in email. In this usage, they + were known as MIME types, where the expansion of the MIME acronym + includes the word "mail". The term "media type" was introduced to + reflect a broader usage, which includes HTTP [RFC7231], Message + Session Relay Protocol (MSRP) [RFC4975], and many other protocols to + identify arbitrary content carried within the protocols. Media types + also provide a media hierarchy that fits RTP payload formats well. + Media type names are of two parts and consist of content type and + sub-type separated with a slash, e.g., 'audio/PCMA' or 'video/ + h263-2000'. It is important to choose the correct content-type when + creating the media type identifying an RTP payload format. However, + in most cases, there is little doubt what content type the format + belongs to. Guidelines for choosing the correct media type and + registration rules for media type names are provided in "Media Type + Specifications and Registration Procedures" [RFC6838]. The + additional rules for media types for RTP payload formats are provided + in "Media Type Registration of RTP Payload Formats" [RFC4855]. + + Registration of the RTP payload name is something that is required to + avoid name collision in the future. Note that "x-" names are not + suitable for any documented format as they have the same problem with + name collision and can't be registered. The list of already- + registered media types can be found at + . + + Media types are allowed any number of parameters, which may be + required or optional for that media type. They are always specified + on the form "name=value". There exist no restrictions on how the + value is defined from the media type's perspective, except that + parameters must have a value. However, the usage of media types in + + + + + + + + +Westerlund Informational [Page 19] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + SDP, etc., has resulted in the following restrictions that need to be + followed to make media types usable for RTP-identifying payload + formats: + + 1. Arbitrary binary content in the parameters is allowed, but it + needs to be encoded so that it can be placed within text-based + protocols. Base64 [RFC4648] is recommended, but for shorter + content Base16 [RFC4648] may be more appropriate as it is simpler + to interpret for humans. This needs to be explicitly stated when + defining a media type parameter with binary values. + + 2. The end of the value needs to be easily found when parsing a + message. Thus, parameter values that are continuous and not + interrupted by common text separators, such as space and + semicolon characters, are recommended. If that is not possible, + some type of escaping should be used. Usage of quote (") is + recommended; do not forget to provide a method of encoding any + character used for quoting inside the quoted element. + + 3. A common representation form for the media type and its + parameters is on a single line. In that case, the media type is + followed by a semicolon-separated list of the parameter value + pairs, e.g.: + + audio/amr octet-align=0; mode-set=0,2,5,7; mode-change-period=2 + +3.4.2. Mapping to SDP + + Since SDP [RFC4566] is so commonly used as an out-of-band signaling + protocol, a mapping of the media type into SDP exists. The details + on how to map the media type and its parameters into SDP are + described in [RFC4855]. However, this is not sufficient to explain + how certain parameters must be interpreted, for example, in the + context of Offer/Answer negotiation [RFC3264]. + +3.4.2.1. The Offer/Answer Model + + The Offer/Answer (O/A) model allows SIP to negotiate which media + formats and payload formats are to be used in a session and how they + are to be configured. However, O/A does not define a default + behavior; instead, it points out the need to define how parameters + behave. To make things even more complex, the direction of media + within a session has an impact on these rules, so that some cases may + require separate descriptions for RTP streams that are send-only, + receive-only, or both sent and received as identified by the SDP + attributes a=sendonly, a=recvonly, and a=sendrecv. In addition, the + usage of multicast adds further limitations as the same RTP stream is + + + + +Westerlund Informational [Page 20] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + delivered to all participants. If those multicast-imposed + restrictions are too limiting for unicast, then separate rules for + unicast and multicast will be required. + + The simplest and most common O/A interpretation is that a parameter + is defined to be declarative; i.e., the SDP Offer/Answer sending + agent can declare a value and that has no direct impact on the other + agent's values. This declared value applies to all media that are + going to be sent to the declaring entity. For example, most video + codecs have a level parameter that tells the other participants the + highest complexity the video decoder supports. The level parameter + can be declared independently by two participants in a unicast + session as it will be the media sender's responsibility to transmit a + video stream that fulfills the limitation the other side has + declared. However, in multicast, it will be necessary to send a + stream that follows the limitation of the weakest receiver, i.e., the + one that supports the lowest level. To simplify the negotiation in + these cases, it is common to require any answerer to a multicast + session to take a yes or no approach to parameters. + + A "negotiated" parameter is a different case, for which both sides + need to agree on its value. Such a parameter requires the answerer + to either accept it as it is offered or remove the payload type the + parameter belonged to from its answer. The removal of the payload + type from the answer indicates to the offerer the lack of support for + the parameter values presented. An unfortunate implication of the + need to use complete payload types to indicate each possible + configuration so as to maximize the chances of achieving + interoperability, is that the number of necessary payload types can + quickly grow large. This is one reason to limit the total number of + sets of capabilities that may be implemented. + + The most problematic type of parameters are those that relate to the + media the entity sends. They do not really fit the O/A model, but + can be shoehorned in. Examples of such parameters can be found in + the H.264 video codec's payload format [RFC6184], where the name of + all parameters with this property starts with "sprop-". The issue + with these parameters is that they declare properties for a RTP + stream that the other party may not accept. The best one can make of + the situation is to explain the assumption that the other party will + accept the same parameter value for the media it will receive as the + offerer of the session has proposed. If the answerer needs to change + any declarative parameter relating to streams it will receive, then + the offerer may be required to make a new offer to update the + parameter values for its outgoing RTP stream. + + + + + + +Westerlund Informational [Page 21] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + Another issue to consider is the send-only RTP streams in offers. + Parameters that relate to what the answering entity accepts to + receive have no meaning other than to provide a template for the + answer. It is worth pointing out in the specification that these + really provide a set of parameter values that the sender recommends. + Note that send-only streams in answers will need to indicate the + offerer's parameters to ensure that the offerer can match the answer + to the offer. + + A further issue with Offer/Answer that complicates things is that the + answerer is allowed to renumber the payload types between offer and + answer. This is not recommended, but allowed for support of gateways + to the ITU conferencing suite. This means that it must be possible + to bind answers for payload types to the payload types in the offer + even when the payload type number has been changed, and some of the + proposed payload types have been removed. This binding must normally + be done by matching the configurations originally offered against + those in the answer. This may require specification in the payload + format of which parameters that constitute a configuration, for + example, as done in Section 8.2.2 of the H.264 RTP Payload format + [RFC6184], which states: "The parameters identifying a media format + configuration for H.264 are profile-level-id and packetization-mode". + +3.4.2.2. Declarative Usage in RTSP and SAP + + SAP (Session Announcement Protocol) [RFC2974] was experimentally used + for announcing multicast sessions. Similar but better protocols are + using SDP in a declarative style to configure multicast-based + applications. Independently of the usage of Source-Specific + Multicast (SSM) [RFC3569] or Any-Source Multicast (ASM), the SDP + provided by these configuration delivery protocols applies to all + participants. All media that is sent to the session must follow the + RTP stream definition as specified by the SDP. This enables everyone + to receive the session if they support the configuration. Here, SDP + provides a one-way channel with no possibility to affect the + configuration that the session creator has decided upon. Any RTP + payload format that requires parameters for the send direction and + that needs individual values per implementation or instance will fail + in a SAP session for a multicast session allowing anyone to send. + + Real-Time Streaming Protocol (RTSP) [RFC7826] allows the negotiation + of transport parameters for RTP streams that are part of a streaming + session between a server and client. RTSP has divided the transport + parameters from the media configuration. SDP is commonly used for + media configuration in RTSP and is sent to the client prior to + session establishment, either through use of the DESCRIBE method or + + + + + +Westerlund Informational [Page 22] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + by means of an out-of-band channel like HTTP, email, etc. The SDP is + used to determine which RTP streams and what formats are being used + prior to session establishment. + + Thus, both SAP and RTSP use SDP to configure receivers and senders + with a predetermined configuration for a RTP stream including the + payload format and any of its parameters. All parameters are used in + a declarative fashion. This can result in different treatment of + parameters between Offer/Answer and declarative usage in RTSP and + SAP. Any such difference will need to be spelled out by the payload + format specification. + +3.5. Transport Characteristics + + The general channel characteristics that RTP flows experience are + documented in Section 3 of "Guidelines for Writers of RTP Payload + Format Specifications" [RFC2736]. The discussion below provides + additional information. + +3.5.1. Path MTU + + At the time of writing, the most common IP Maximum Transmission Unit + (MTU) in commonly deployed link layers is 1500 bytes (Ethernet data + payload). However, there exist both links with smaller MTUs and + links with much larger MTUs. An example for links with small MTU + size is older generation cellular links. Certain parts of the + Internet already support an IP MTU of 8000 bytes or more, but these + are limited islands. The most likely places to find MTUs larger than + 1500 bytes are within enterprise networks, university networks, data + centers, storage networks, and over high capacity (10 Gbps or more) + links. There is a slow, ongoing evolution towards larger MTU sizes. + However, at the same time, it has become common to use tunneling + protocols, often multiple ones, whose overhead when added together + can shrink the MTU significantly. Thus, there exists a need both to + consider limited MTUs as well as enable support of larger MTUs. This + should be considered in the design, especially in regard to features + such as aggregation of independently decodable data units. + +3.5.2. Different Queuing Algorithms + + Routers and switches on the network path between an IP sender and a + particular receiver can exhibit different behaviors affecting the + end-to-end characteristics. One of the more important aspects of + this is queuing behavior. Routers and switches have some amount of + queuing to handle temporary bursts of data that designated to leave + the switch or router on the same egress link. A queue, when not + empty, results in an increased path delay. + + + + +Westerlund Informational [Page 23] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + The implementation of the queuing affects the delay and also how + congestion signals (Explicit Congestion Notification (ECN) [RFC6679] + or packet drops) are provided to the flow. The other aspects are if + the flow shares the queue with other flows and how the implementation + affects the flow interaction. This becomes important, for example, + when real-time flows interact with long-lived TCP flows. TCP has a + built-in behavior in its congestion control that strives to fill the + buffer; thus, all flows sharing the buffer experienced the delay + build up. + + A common, but quite poor, queue-handling mechanism is tail-drop, + i.e., only drop packets when the incoming packet doesn't fit in the + queue. If a bad queuing algorithm is combined with too much queue + space, the queuing time can grow to be very significant and can even + become multiple seconds. This is called "bufferbloat" [BLOAT]. + Active Queue Management (AQM) is a term covering mechanisms that try + to do something smarter by actively managing the queue, for example, + sending congestion signals earlier by dropping packets earlier in the + queue. The behavior also affects the flow interactions. For + example, Random Early Detection (RED) [RED] selects which packet(s) + to drop randomly. This gives flows that have more packets in the + queue a higher probability to experience the packet loss (congestion + signal). There is ongoing work in the IETF WG AQM to find suitable + mechanisms to recommend for implementation and reduce the use of + tail-drop. + +3.5.3. Quality of Service + + Using best-effort Internet has no guarantees for the path's + properties. QoS mechanisms are intended to provide the possibility + to bound the path properties. Where Diffserv [RFC2475] markings + affect the queuing and forwarding behaviors of routers, the mechanism + provides only statistical guarantees and care in how much marked + packets of different types that are entering the network. Flow-based + QoS, like IntServ [RFC1633], has the potential for stricter + guarantees as the properties are agreed on by each hop on the path, + at the cost of per-flow state in the network. + +4. Standardization Process for an RTP Payload Format + + This section discusses the recommended process to produce an RTP + payload format in the described venues. This is to document the best + current practice on how to get a well-designed and specified payload + format as quickly as possible. For specifications that are defined + by standards bodies other than the IETF, the primary milestone is the + registration of the media type for the RTP payload format. For + + + + + +Westerlund Informational [Page 24] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + proprietary media formats, the primary goal depends on whether + interoperability is desired at the RTP level. However, there is also + the issue of ensuring best possible quality of any specification. + +4.1. IETF + + For all standardized media formats, it is recommended that the + payload format be specified in the IETF. The main reason is to + provide an openly available RTP payload format specification that has + been reviewed by people experienced with RTP payload formats. At the + time of writing, this work is done in the PAYLOAD Working Group (WG), + but that may change in the future. + +4.1.1. Steps from Idea to Publication + + There are a number of steps that an RTP payload format should go + through from the initial idea until it is published. This also + documents the process that the PAYLOAD WG applies when working with + RTP payload formats. + + Idea: Determine the need for an RTP payload format as an IETF + specification. + + Initial effort: Using this document as a guideline, one should be + able to get started on the work. If one's media codec doesn't fit + any of the common design patterns or one has problems + understanding what the most suitable way forward is, then one + should contact the PAYLOAD WG and/or the WG Chairs. The goal of + this stage is to have an initial individual draft. This draft + needs to focus on the introductory parts that describe the real- + time media format and the basic idea on how to packetize it. Not + all the details are required to be filled in. However, the + security chapter is not something that one should skip, even + initially. From the start, it is important to consider any + serious security risks that need to be solved. The first step is + completed when one has a draft that is sufficiently detailed for a + first review by the WG. The less confident one is of the + solution, the less work should be spent on details; instead, + concentrate on the codec properties and what is required to make + the packetization work. + + Submission of the first version: When one has performed the above, + one submits the draft as an individual draft + (https://datatracker.ietf.org/submit/). This can be done at any + time, except for a period prior to an IETF meeting (see important + dates related to the next IETF meeting for draft submission cutoff + date). When the Internet-Draft announcement has been sent out on + + + + +Westerlund Informational [Page 25] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + the draft announcement list + (https://www.ietf.org/mailman/listinfo/I-D-Announce), forward it + to the PAYLOAD WG (https://www.ietf.org/mailman/listinfo/payload) + and request that it be reviewed. In the email, outline any issues + the authors currently have with the design. + + Iterative improvements: Taking the feedback received into account, + one updates the draft and tries resolve issues. New revisions of + the draft can be submitted at any time (again except for a short + period before meetings). It is recommended to submit a new + version whenever one has made major updates or has new issues that + are easiest to discuss in the context of a new draft version. + + Becoming a WG document: Given that the definition of RTP payload + formats is part of the PAYLOAD WG's charter, RTP payload formats + that are going to be published as Standards Track RFCs need to + become WG documents. Becoming a WG document means that the WG + Chairs or an appointed document shepherd are responsible for + administrative handling, for example, issuing publication + requests. However, be aware that making a document into a WG + document changes the formal ownership and responsibility from the + individual authors to the WG. The initial authors normally + continue being the document editors, unless unusual circumstances + occur. The PAYLOAD WG accepts new RTP payload formats based on + their suitability and document maturity. The document maturity is + a requirement to ensure that there are dedicated document editors + and that there exists a good solution. + + Iterative improvements: The updates and review cycles continue until + the draft has reached the level of maturity suitable for + publication. The authors are responsible for judging when the + document is ready for the next step, most likely WG Last Call, but + they can ask the WG chairs or Shepherd. + + WG Last Call: A WG Last Call of at least two weeks is always + performed for payload formats in the PAYLOAD WG (see Section 7.4 + of [RFC2418]). The authors request WG Last Call for a draft when + they think it is mature enough for publication. The WG Chairs or + shepherd perform a review to check if they agree with the authors' + assessment. If the WG Chairs or shepherd agree on the maturity, + the WG Last Call is announced on the WG mailing list. If there + are issues raised, these need to be addressed with an updated + draft version. For any more substantial changes to the draft, a + new WG Last Call is announced for the updated version. Minor + changes, like editorial fixes, can be progressed without an + additional WG Last Call. + + + + + +Westerlund Informational [Page 26] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + Publication requested: For WG documents, the WG Chairs or shepherd + request publication of the draft after it has passed WG Last Call. + After this, the approval and publication process described in BCP + 9 [BCP9] is performed. The status after the publication has been + requested can be tracked using the IETF Datatracker [TRACKER]. + Documents do not expire as they normally do after publication has + been requested, so authors do not have to issue keep-alive + updates. In addition, any submission of document updates requires + the approval of WG Chair(s). The authors are commonly asked to + address comments or issues raised by the IESG. The authors also + do one last review of the document immediately prior to its + publication as an RFC to ensure that no errors or formatting + problems have been introduced during the publication process. + +4.1.2. WG Meetings + + WG meetings are for discussing issues, not presentations. This means + that most RTP payload formats should never need to be discussed in a + WG meeting. RTP payload formats that would be discussed are either + those with controversial issues that failed to be resolved on the + mailing list or those including new design concepts worth a general + discussion. + + There exists no requirement to present or discuss a draft at a WG + meeting before it becomes published as an RFC. Thus, even authors + who lack the possibility to go to WG meetings should be able to + successfully specify an RTP payload format in the IETF. WG meetings + may become necessary only if the draft gets stuck in a serious debate + that cannot easily be resolved. + +4.1.3. Draft Naming + + To simplify the work of the PAYLOAD WG Chairs and WG members, a + specific Internet-Draft file-naming convention shall be used for RTP + payload formats. Individual submissions shall be named using the + template: draft--payload-rtp--. The WG documents shall be named according to this + template: draft-ietf-payload-rtp--. The + inclusion of "payload" in the draft file name ensures that the search + for "payload-" will find all PAYLOAD-related drafts. Inclusion of + "rtp" tells us that it is an RTP payload format draft. The + descriptive name should be as short as possible while still + describing what the payload format is for. It is recommended to use + the media format or codec abbreviation. Please note that the version + must start at 00 and is increased by one for each submission to the + IETF secretary of the draft. No version numbers may be skipped. For + more details on draft naming, please see Section 7 of [ID-GUIDE]. + + + + +Westerlund Informational [Page 27] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +4.1.4. Writing Style + + When writing an Internet-Draft for an RTP payload format, one should + observe some few considerations (that may be somewhat divergent from + the style of other IETF documents and/or the media coding spec's + author group may use): + + Include Motivations: In the IETF, it is common to include the + motivation for why a particular design or technical path was + chosen. These are not long statements: a sentence here and there + explaining why suffice. + + Use the Defined Terminology: There exists defined terminology both + in RTP and in the media codec specification for which the RTP + payload format is designed. A payload format specification needs + to use both to make clear the relation of features and their + functions. It is unwise to introduce or, worse, use without + introduction, terminology that appears to be more accessible to + average readers but may miss certain nuances that the defined + terms imply. An RTP payload format author can assume the reader + to be reasonably familiar with the terminology in the media coding + specification. + + Keeping It Simple: The IETF has a history of specifications that are + focused on their main usage. Historically, some RTP payload + formats have a lot of modes and features, while the actual + deployments have only included the most basic features that had + very clear requirements. Time and effort can be saved by focusing + on only the most important use cases and keeping the solution + simple. An extension mechanism should be provided to enable + backward-compatible extensions, if that is an organic fit. + + Normative Requirements: When writing specifications, there is + commonly a need to make it clear when something is normative and + at what level. In the IETF, the most common method is to use "Key + words for use in RFCs to Indicate Requirement Levels" [RFC2119], + which defines the meaning of "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT + RECOMMENDED", "MAY", and "OPTIONAL". + + + + + + + + + + + + +Westerlund Informational [Page 28] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +4.1.5. How to Speed Up the Process + + There a number of ways to lose a lot of time in the above process. + This section discusses what to do and what to avoid. + + o Do not update the draft only for the meeting deadline. An update + to each meeting automatically limits the draft to three updates + per year. Instead, ignore the meeting schedule and publish new + versions as soon as possible. + + o Try to avoid requesting reviews when people are busy, like the few + weeks before a meeting. It is actually more likely that people + have time for them directly after a meeting. + + o Perform draft updates quickly. A common mistake is that the + authors let the draft slip. By performing updates to the draft + text directly after getting resolution on an issue, things speed + up. This minimizes the delay that the author has direct control + over. The time taken for reviews, responses from Area Directors + and WG Chairs, etc., can be much harder to speed up. + + o Do not fail to take human nature into account. It happens that + people forget or need to be reminded about tasks. Send a kind + reminder to the people you are waiting for if things take longer + than expected. Ask people to estimate when they expect to fulfill + the requested task. + + o Ensure there is enough review. It is common that documents take a + long time and many iterations because not enough review is + performed in each iteration. To improve the amount of review you + get on your own document, trade review time with other document + authors. Make a deal with some other document author that you + will review their draft if they review yours. Even inexperienced + reviewers can help with language, editorial, or clarity issues. + Also, try approaching the more experienced people in the WG and + getting them to commit to a review. The WG Chairs cannot, even if + desirable, be expected to review all versions. Due to workload, + the Chairs may need to concentrate on key points in a draft + evolution like checking on initial submissions, a draft's + readiness to become a WG document, or its readiness for WG Last + Call. + +4.2. Other Standards Bodies + + Other standards bodies may define RTP payloads in their own + specifications. When they do this, they are strongly recommended to + contact the PAYLOAD WG Chairs and request review of the work. It is + recommended that at least two review steps are performed. The first + + + +Westerlund Informational [Page 29] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + should be early in the process when more fundamental issues can be + easily resolved without abandoning a lot of effort. Then, when + nearing completion, but while it is still possible to update the + specification, a second review should be scheduled. In that pass, + the quality can be assessed; hopefully, no updates will be needed. + Using this procedure can avoid both conflicting definitions and + serious mistakes, like breaking certain aspects of the RTP model. + + RTP payload media types may be registered in the standards tree by + other standards bodies. The requirements on the organization are + outlined in the media types registration documents [RFC4855] and + [RFC6838]). This registration requires a request to the IESG, which + ensures that the filled-in registration template is acceptable. To + avoid last-minute problems with these registrations the registration + template must be sent for review both to the PAYLOAD WG and the media + types list (ietf-types@iana.org) and is something that should be + included in the IETF reviews of the payload format specification. + +4.3. Proprietary and Vendor Specific + + Proprietary RTP payload formats are commonly specified when the real- + time media format is proprietary and not intended to be part of any + standardized system. However, there are reasons why also proprietary + formats should be correctly documented and registered: + + o Usage in a standardized signaling environment, such as SIP/SDP. + RTP needs to be configured with the RTP profiles, payload formats, + and their payload types being used. To accomplish this, it is + desirable to have registered media type names to ensure that the + names do not collide with those of other formats. + + o Sharing with business partners. As RTP payload formats are used + for communication, situations often arise where business partners + would like to support a proprietary format. Having a well-written + specification of the format will save time and money for both + parties, as interoperability will be much easier to accomplish. + + o To ensure interoperability between different implementations on + different platforms. + + To avoid name collisions, there is a central registry keeping track + of the registered media type names used by different RTP payload + formats. When it comes to proprietary formats, they should be + registered in the vendor's own tree. All vendor-specific + registrations use sub-type names that start with "vnd.". + Names in the vendor's own tree are not required to be registered with + IANA. However, registration [RFC6838] is recommended if the media + type is used at all in public environments. + + + +Westerlund Informational [Page 30] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + If interoperability at the RTP level is desired, a payload type + specification should be standardized in the IETF following the + process described above. The IETF does not require full disclosure + of the codec when defining an RTP payload format to carry that codec, + but a description must be provided that is sufficient to allow the + IETF to judge whether the payload format is well designed. The media + type identifier assigned to a standardized payload format of this + sort will lie in the standards tree rather than the vendor tree. + +4.4. Joint Development of Media Coding Specification and RTP Payload + Format + + In the last decade, there have been a few cases where the media codec + and the associated RTP payload format have been developed + concurrently and jointly. Developing the two specs not only + concurrently but also jointly, in close cooperation with the group + developing the media codec, allows one to leverage the benefits joint + source/channel coding can provide. Doing so has historically + resulted in well-performing payload formats and in success of both + the media coding specification and associated RTP payload format. + Insofar, whenever the opportunity presents it, it may be useful to + closely keep the media coding group in the loop (through appropriate + liaison means whatever those may be) and influence the media coding + specification to be RTP friendly. One example for such a media + coding specification is H.264, where the RTP payload header co-serves + as the H.264 NAL unit header and vice versa, and is documented in + both specifications. + +5. Designing Payload Formats + + The best summary of payload format design is KISS (Keep It Simple, + Stupid). A simple payload format is easier to review for + correctness, easier to implement, and has low complexity. + Unfortunately, contradictory requirements sometimes make it hard to + do things simply. Complexity issues and problems that occur for RTP + payload formats are: + + Too many configurations: Contradictory requirements lead to the + result that one configuration is created for each conceivable + case. Such contradictory requirements are often between + functionality and bandwidth. This outcome has two big + disadvantages; First all configurations need to be implemented. + Second, the user application must select the most suitable + configuration. Selecting the best configuration can be very + difficult and, in negotiating applications, this can create + interoperability problems. The recommendation is to try to select + + + + + +Westerlund Informational [Page 31] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + a very limited set of configurations (preferably one) that perform + well for the most common cases and are capable of handling the + other cases, but maybe not that well. + + Hard to implement: Certain payload formats may become difficult to + implement both correctly and efficiently. This needs to be + considered in the design. + + Interaction with general mechanisms: Special solutions may create + issues with deployed tools for RTP, such as tools for more robust + transport of RTP. For example, a requirement for an unbroken + sequence number space creates issues for mechanisms relying on + payload type switching interleaving media-independent resilience + within a stream. + +5.1. Features of RTP Payload Formats + + There are a number of common features in RTP payload formats. There + is no general requirement to support these features; instead, their + applicability must be considered for each payload format. In fact, + it may be that certain features are not even applicable. + +5.1.1. Aggregation + + Aggregation allows for the inclusion of multiple Application Data + Units (ADUs) within the same RTP payload. This is commonly supported + for codecs that produce ADUs of sizes smaller than the IP MTU. One + reason for the use of aggregation is the reduction of header overhead + (IP/UDP/RTP headers). When setting into relation the ADU size and + the MTU size, do remember that the MTU may be significantly larger + than 1500 bytes. An MTU of 9000 bytes is available today and an MTU + of 64k may be available in the future. Many speech codecs have the + property of ADUs of a few fixed sizes. Video encoders may generally + produce ADUs of quite flexible sizes. Thus, the need for aggregation + may be less. But some codecs produce small ADUs mixed with large + ones, for example, H.264 Supplemental Enhancement Information (SEI) + messages. Sending individual SEI message in separate packets are not + efficient compared to combing the with other ADUs. Also, some small + ADUs are, within the media domain, semantically coupled to the larger + ADUs (for example, in-band parameter sets in H.264 [RFC6184]). In + such cases, aggregation is sensible, even if not required from a + payload/header overhead viewpoint. There also exist cases when the + ADUs are pre-produced and can't be adopted to a specific networks + MTU. Instead, their packetization needs to be adopted to the + network. All above factors should be taken into account when + deciding on the inclusion of aggregation, and weighting its benefits + + + + + +Westerlund Informational [Page 32] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + against the complexity of defining them (which can be significant + especially when aggregation is performed over ADUs with different + playback times). + + The main disadvantage of aggregation, beyond implementation + complexity, is the extra delay introduced (due to buffering until a + sufficient number of ADUs have been collected at the sender) and + reduced robustness against packet loss. Aggregation also introduces + buffering requirements at the receiver. + +5.1.2. Fragmentation + + If the real-time media format has the property that it may produce + ADUs that are larger than common MTU sizes, then fragmentation + support should be considered. An RTP payload format may always fall + back on IP fragmentation; however, as discussed in RFC 2736, this has + some drawbacks. Perhaps the most important reason to avoid IP + fragmentation is that IP fragmented packets commonly are discarded in + the network, especially by NATs or firewalls. The usage of + fragmentation at the RTP payload format level allows for more + efficient usage of RTP packet loss recovery mechanisms. It may also + in some cases also allow better usage of partial ADUs by doing media + specific fragmentation at media-specific boundaries. In use cases + where the ADUs are pre-produced and can't be adopted to the network's + MTU size, support for fragmentation can be crucial. + +5.1.3. Interleaving and Transmission Rescheduling + + Interleaving has been implemented in a number of payload formats to + allow for less quality reduction when packet loss occurs. When + losses are bursty and several consecutive packets are lost, the + impact on quality can be quite severe. Interleaving is used to + convert that burst loss to several spread-out individual packet + losses. It can also be used when several ADUs are aggregated in the + same packets. A loss of an RTP packet with several ADUs in the + payload has the same effect as a burst loss if the ADUs would have + been transmitted in individual packets. To reduce the burstiness of + the loss, the data present in an aggregated payload may be + interleaved, thus, spreading the loss over a longer time period. + + A requirement for doing interleaving within an RTP payload format is + the aggregation of multiple ADUs. For formats that do not use + aggregation, there is still a possibility of implementing a + transmission order rescheduling mechanism. That has the effect that + the packets transmitted consecutively originate from different points + in the RTP stream. This can be used to mitigate burst losses, which + may be useful if one transmits packets at frequent intervals. + However, it may also be used to transmit more significant data + + + +Westerlund Informational [Page 33] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + earlier in combination with RTP retransmission to allow for more + graceful degradation and increased possibility to receive the most + important data, e.g., intra frames of video. + + The drawback of interleaving is the significantly increased + transmission buffering delay, making it less useful for low-delay + applications. It may also create significant buffering requirements + on the receiver. That buffering is also problematic, as it is + usually difficult to indicate when a receiver may start consume data + and still avoid buffer under run caused by the interleaving mechanism + itself. Transmission rescheduling is only useful in a few specific + cases, as in streaming with retransmissions. The potential gains + must be weighed against the complexity of these schemes. + +5.1.4. Media Back Channels + + A few RTP payload formats have implemented back channels within the + media format. Those have been for specific features, like the AMR + [RFC4867] codec mode request (CMR) field. The CMR field is used in + the operation of gateways to circuit-switched voice to allow an IP + terminal to react to the circuit-switched network's need for a + specific encoder mode. A common motivation for media back channels + is the need to have signaling in direct relation to the media or the + media path. + + If back channels are considered for an RTP payload format they should + be for a specific requirements which cannot be easily satisfied by + more generic mechanisms within RTP or RTCP. + +5.1.5. Media Scalability + + Some codecs support various types of media scalability, i.e. some + data of a RTP stream may be removed to adapt the media's properties, + such as bitrate and quality. The adaptation may be applied in the + following dimensions of the media: + + Temporal: For most video codecs it is possible to adapt the frame + rate without any specific definition of a temporal scalability + mode, e.g., for H.264 [RFC6184]. In these cases, the sender + changes which frames it delivers and the RTP timestamp makes it + clear the frame interval and each frames relative capture time. + H.264 Scalable Video Coding (SVC) [RFC6190] has more explicit + support for temporal scalability. + + Spatial: Video codecs supporting scalability may adapt the + resolution, e.g., in SVC [RFC6190]. + + + + + +Westerlund Informational [Page 34] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + Quality: The quality of the encoded stream may be scaled by adapting + the accuracy of the coding process, as, e.g. possible with Signal + to Noise Ratio (SNR) fidelity scalability of SVC [RFC6190]. + + At the time of writing this document, codecs that support scalability + have a bit of a revival. It has been realized that getting the + required functionality for supporting the features of the media + stream into the RTP framework is quite challenging. One of the + recent examples for layered and scalable codecs is SVC [RFC6190]. + + SVC is a good example for a payload format supporting media + scalability features, which have been in its basic form already + included in RTP. A layered codec supports the dropping of data parts + of a RTP stream, i.e., RTP packets may not be transmitted or + forwarded to a client in order to adapt the RTP streams bitrate as + well as the received encoded stream's quality, while still providing + a decodable subset of the encoded stream to a client. One example + for using the scalability feature may be an RTP Mixer (Multipoint + Control Unit) [RFC7667], which controls the rate and quality sent out + to participants in a communication based on dropping RTP packets or + removing part of the payload. Another example may be a transport + channel, which allows for differentiation in Quality of Service (QoS) + parameters based on RTP sessions in a multicast session. In such a + case, the more important packets of the scalable encoded stream (base + layer) may get better QoS parameters than the less important packets + (enhancement layer) in order to provide some kind of graceful + degradation. The scalability features required for allowing an + adaptive transport, as described in the two examples above, are based + on RTP multiplexing in order to identify the packets to be dropped or + transmitted/forwarded. The multiplexing features defined for + Scalable Video Coding [RFC6190] are: + + Single Session Transmission (SST), where all media layers of the + media are transported as a single synchronization source (SSRC) in + a single RTP session; as well as + + Multi-Session Transmission (MST), which should more accurately be + called multi-stream transmission, where different media layers or + a set of media layers are transported in different RTP streams, + i.e., using multiple sources (SSRCs). + + In the first case (SST), additional in-band as well as out-of-band + signaling is required in order to allow identification of packets + belonging to a specific media layer. Furthermore, an adaptation of + the encoded stream requires dropping of specific packets in order to + provide the client with a compliant encoded stream. In case of using + encryption, it is typically required for an adapting network device + + + + +Westerlund Informational [Page 35] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + to be in the security context to allow packet dropping and providing + an intact RTP session to the client. This typically requires the + network device to be an RTP mixer. + + In general, having a media-unaware network device dropping excessive + packets will be more problematic than having a Media-Aware Network + Entity (MANE). First is the need to understand the media format and + know which ADUs or payloads belong to the layers, that no other layer + will be dependent on after the dropping. Second, if the MANE can + work as an RTP mixer or translator, it can rewrite the RTP and RTCP + in such a way that the receiver will not suspect unintentional RTP + packet losses needing repair actions. This as the receiver can't + determine if a lost packet was an important base layer packet or one + of the less important extension layers. + + In the second case (MST), the RTP packet streams can be sent using a + single or multiple RTP session, and thus transport flows, e.g., on + different multicast groups. Transmitting the streams in different + RTP sessions, then the out-of-band signaling typically provides + enough information to identify the media layers and its properties. + The decision on dropping packets is based on the Network Address that + identifies the RTP session to be dropped. In order to allow correct + data provisioning to a decoder after reception from different + sessions, data realignment mechanisms are required. In some cases, + existing generic tools, as described below, can be employed to enable + such realignment; when those generic mechanisms are sufficient, they + should be used. For example, "Rapid Synchronisation for RTP Flows" + [RFC6051], uses existing RTP mechanisms, i.e. the NTP timestamp, to + ensure timely inter-session synchronization. Another is the + signaling feature for indicating dependencies of RTP sessions in SDP, + as defined in the Media Decoding Dependency Grouping in SDP + [RFC5583]. + + Using MST within a single RTP session is also possible and allows + stream level handling instead of looking deeper into the packets by a + MANE. However, transport flow-level properties will be the same + unless packet based mechanisms like Diffserv is used. + + When QoS settings, e.g., Diffserv markings, are used to ensure that + the extension layers are dropped prior the base layer the receiving + endpoint has the benefit in MST to know which layer or set of layers + the missing packets belong to as it will be bound to different RTP + sessions or RTP packet streams (SSRCs), thus, explicitly indicating + the importance of the loss. + + + + + + + +Westerlund Informational [Page 36] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +5.1.6. High Packet Rates + + Some media codecs require high packet rates; in these cases, the RTP + sequence number wraps too quickly. As a rule of thumb, it must not + be possible to wrap the sequence number space within at least three + RTCP reporting intervals. As the reporting interval can vary widely + due to configuration and session properties, and also must take into + account the randomization of the interval, one can use the TCP + maximum segment lifetime (MSL), i.e., 2 minutes, in ones + consideration. If earlier wrapping may occur, then the payload + format should specify an extended sequence number field to allow the + receiver to determine where a specific payload belongs in the + sequence, even in the face of extensive reordering. The RTP payload + format for uncompressed video [RFC4175] can be used as an example for + such a field. + + RTCP is also affected by high packet rates. For RTCP mechanisms that + do not use extended counters, there is significant risk that they + wrap multiple times between RTCP reporting or feedback; thus, + producing uncertainty about which packet(s) are referenced. The + payload designer can't effect the RTCP packet formats used and their + design, but can note this considerations when configuring RTCP + bandwidth and reporting intervals to avoid to wrapping issues. + +5.2. Selecting Timestamp Definition + + The RTP timestamp is an important part and has two design choices + associated with it. The first is the definition that determines what + the timestamp value in a particular RTP packet will be, the second is + which timestamp rate should be used. + + The timestamp definition needs to explicitly define what the + timestamp value in the RTP packet represent for a particular payload + format. Two common definitions are used; for discretely sampled + media, like video frames, the sampling time of the earliest included + video frame which the data represent (fully or partially) is used; + for continuous media like audio, the sampling time of the earliest + sample which the payload data represent. There exist cases where + more elaborate or other definitions are used. + + RTP payload formats with a timestamp definition that results in no or + little correlation between the media time instance and its + transmission time cause the RTCP jitter calculation to become + unusable due to the errors introduced on the sender side. A common + example is a payload format for a video codec where the RTP timestamp + represents the capture time of the video frame, but frames are large + + + + + +Westerlund Informational [Page 37] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + enough that multiple RTP packets need to be sent for each frame + spread across the framing interval. It should be noted whether or + not the payload format has this property. + + An RTP payload format also needs to define what timestamp rates, or + clock rates (as it is also called), may be used. Depending on the + RTP payload format, this may be a single rate or multiple ones or + theoretically any rate. So what needs to be considered when + selecting a rate? + + The rate needs be selected so that one can determine where in the + time line of the media a particular sample (e.g., individual audio + sample, or video frame) or set of samples (e.g., audio frames) + belong. To enable correct synchronization of this data with previous + frames, including over periods of discontinuous transmission or + irregularities. + + For audio, it is common to require audio sample accuracy. Thus, one + commonly selects the input sampling rate as the timestamp rate. This + can, however, be challenging for audio codecs that support multiple + different sampling frequencies, either as codec input or being used + internally but effecting output, for example, frame duration. + Depending on how one expects to use these different sampling rates + one can allow multiple timestamp rates, each matching a particular + codec input or sampling rate. However, due to the issues with using + multiple different RTP timestamp rates for the same source (SSRC) + [RFC7160], this should be avoided if one expects to need to switch + between modes. + + Then, an alternative is to find a common denominator frequency + between the different modes, e.g., OPUS [RFC7587] that uses 48 kHz. + If the different modes uses or can use a common input/output + frequency, then selecting this also needs to be considered. However, + it is important to consider all aspects as the case of AMR-WB+ + [RFC4352] illustrates. AMR-WB+'s RTP timestamp rate has the very + unusual value of 72 kHz, despite the fact that output normally is at + a sample rate of 48kHz. The design is motivated by the media codec's + production of a large range of different frame lengths in time + perspective. The 72 kHz timestamp rate is the smallest found value + that would make all of the frames the codec could produce result in + an integer frame length in RTP timestamp ticks. This way, a receiver + can always correctly place the frames in relation to any other frame, + even when the frame length changes. The downside is that the decoder + outputs for certain frame lengths are, in fact, partial samples. The + result is that the output in samples from the codec will vary from + frame to frame, potentially making implementation more difficult. + + + + + +Westerlund Informational [Page 38] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + Video codecs have commonly been using 90 kHz; the reason is this is a + common denominator between the usually used frame rates such as 24, + 25, 30, 50 and 60, and NTSC's odd 29.97 Hz. There does, however, + exist at least one exception in the payload format for SMPTE 292M + video [RFC3497] that uses a clock rate of 148.5 MHz. The reason here + is that the timestamp then identify the exact start sample within a + video frame. + + Timestamp rates below 1000 Hz are not appropriate, because this will + cause a resolution too low in the RTCP measurements that are + expressed in RTP timestamps. This is the main reason that the text + RTP payload formats, like T.140 [RFC4103], use 1000 Hz. + +6. Noteworthy Aspects in Payload Format Design + + This section provides a few examples of payload formats that are + worth noting for good or bad design in general or in specific + details. + +6.1. Audio Payloads + + The AMR [RFC4867], AMR-WB [RFC4867], EVRC [RFC3558], SMV [RFC3558] + payload formats are all quite similar. They are all for frame-based + audio codecs and use a table of contents structure. Each frame has a + table of contents entry that indicates the type of the frame and if + additional frames are present. This is quite flexible, but produces + unnecessary overhead if the ADU is of fixed size and if, when + aggregating multiple ADUs, they are commonly of the same type. In + that case, a solution like the one in AMR-WB+ [RFC4352] may be more + suitable. + + The RTP payload format for MIDI [RFC6295] contains some interesting + features. MIDI is an audio format sensitive to packet losses, as the + loss of a "note off" command will result in a note being stuck in an + "on" state. To counter this, a recovery journal is defined that + provides a summarized state that allows the receiver to recover from + packet losses quickly. It also uses RTCP and the reported highest + sequence number to be able to prune the state the recovery journal + needs to contain. These features appear limited in applicability to + media formats that are highly stateful and primarily use symbolic + media representations. + + There exists a security concern with variable bitrate audio and + speech codecs that changes their payload length based on the input + data. This can leak information, especially in structured + communication like a speech recognition prompt service that asks + people to enter information verbally. This issue also exists to some + degree for discontinuous transmission as that allows the length of + + + +Westerlund Informational [Page 39] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + phrases to be determined. The issue is further discussed in + "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP" + [RFC6562], which needs to be read by anyone writing an RTP payload + format for an audio or speech codec with these properties. + +6.2. Video + + The definition of RTP payload formats for video has seen an evolution + from the early ones such as H.261 [RFC4587] towards the latest for + VP8 [RFC7741] and H.265/HEVC [RFC7798]. + + The H.264 RTP payload format [RFC3984] can be seen as a smorgasbord + of functionality: some of it, such as the interleaving, being pretty + advanced. The reason for this was to ensure that the majority of + applications considered by the ITU-T and MPEG that can be supported + by RTP are indeed supported. This has created a payload format that + rarely is fully implemented. Despite that, no major issues with + interoperability has been reported with one exception namely the + Offer/Answer and parameter signaling, which resulted in a revised + specification [RFC6184]. However, complaints about its complexity + are common. + + The RTP payload format for uncompressed video [RFC4175] must be + mentioned in this context as it contains a special feature not + commonly seen in RTP payload formats. Due to the high bitrate and + thus packet rate of uncompressed video (gigabits rather than megabits + per second) the payload format includes a field to extend the RTP + sequence number since the normal 16-bit one can wrap in less than a + second. [RFC4175] also specifies a registry of different color sub- + samplings that can be reused in other video RTP payload formats. + + Both the H.264 and the uncompressed video format enable the + implementer to fulfill the goals of application-level framing, i.e., + each individual RTP Packet's payload can be independently decoded and + its content used to create a video frame (or part of) and that + irrespective of whether preceding packets has been lost (see + Section 4) [RFC2736]. For uncompressed, this is straightforward as + each pixel is independently represented from others and its location + in the video frame known. H.264 is more dependent on the actual + implementation, configuration of the video encoder and usage of the + RTP payload format. + + The common challenge with video is that, in most cases, a single + compressed video frame doesn't fit into a single IP packet. Thus, + the compressed representation of a video frame needs to be split over + multiple packets. This can be done unintelligently with a basic + payload level fragmentation method or more integrated by interfacing + with the encoder's possibilities to create ADUs that are independent + + + +Westerlund Informational [Page 40] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + and fit the MTU for the RTP packet. The latter is more robust and + commonly recommended unless strong packet loss mechanisms are used + and sufficient delay budget for the repair exist. Commonly, both + payload-level fragmentation as well as explaining how tailored ADUs + can be created are needed in a video payload format. Also, the + handling of crucial metadata, like H.264 Parameter Sets, needs to be + considered as decoding is not possible without receiving the used + parameter sets. + +6.3. Text + + Only a single format text format has been standardized in the IETF, + namely T.140 [RFC4103]. The 3GPP Timed Text format [RFC4396] should + be considered to be text, even though in the end was registered as a + video format. It was registered in that part of the tree because it + deals with decorated text, usable for subtitles and other + embellishments of video. However, it has many of the properties that + text formats generally have. + + The RTP payload format for T.140 was designed with high reliability + in mind as real-time text commonly is an extremely low bitrate + application. Thus, it recommends the use of RFC 2198 with many + generations of redundancy. However, the format failed to provide a + text-block-specific sequence number and instead relies on the RTP one + to detect loss. This makes detection of missing text blocks + unnecessarily difficult and hinders deployment with other robustness + mechanisms that would involve switching the payload type, as that may + result in erroneous error marking in the T.140 text stream. + +6.4. Application + + At the time of writing, the application content type contains two + media types that aren't RTP transport robustness tools such as FEC + [RFC3009] [RFC5109] [RFC6015] [RFC6682] and RTP retransmission + [RFC4588]. + + The first one is H.224 [RFC4573], which enables far-end camera + control over RTP. This is not an IETF-defined RTP format, only an + IETF-performed registration. + + The second one is "RTP Payload Format for Society of Motion Picture + and Television Engineers (SMPTE) ST 336 Encoded Data" [RFC6597], + which carries generic key length value (KLV) triplets. These pairs + may contain arbitrary binary metadata associated with video + transmissions. It has a very basic fragmentation mechanism requiring + reception without packet loss, not only of the triplet itself but + also one packet before and after the sequence of fragmented KLV + triplet, to ensure correct reception. Specific KLV triplets + + + +Westerlund Informational [Page 41] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + themselves may have recommendations on how to handle incomplete ones + allowing the use and repair of them. In general, the application + using such a mechanism must be robust to errors and also use some + combination of application-level repetition, RTP-level transport + robustness tools, and network-level requirements to achieve low + levels of packet loss rates and repair of KLV triplets. + + An author should consider applying for a media subtype under the + application media type (application/) when the payload format is + of a generic nature or does not clearly match any of the media types + described above (audio, video, or text). However, existing + limitations in, for example, SDP, have resulted in generic mechanisms + normally registered in all media types possibly having been + associated with any existing media types in an RTP session. + +7. Important Specification Sections + + A number of sections in the payload format draft need special + consideration. These include the Security Considerations and IANA + Considerations sections that are required in all drafts. Payload + formats are also strongly recommended to have the media format + description and congestion control considerations. The included RTP + payload format template (Appendix A) contains sample text for some of + these sections. + +7.1. Media Format Description + + The intention of this section is to enable reviewers and other + readers to get an overview of the capabilities and major properties + of the media format. It should be kept short and concise and is not + a complete replacement for reading the media format specification. + + The actual specification of the RTP payload format generally uses + normative references to the codec format specification to define how + codec data elements are included in the payload format. This + normative reference can be to anything that have sufficient stability + for a normative reference. There exist no formal requirement on the + codec format specification being publicly available or free to + access. However, it significantly helps in the review process if + that specification is made available to any reviewer. There exist + RTP payload format RFCs for open-source project specifications as + well as an individual company's proprietary format, and a large + variety of standards development organizations or industrial forums. + + + + + + + + +Westerlund Informational [Page 42] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +7.2. Security Considerations + + All Internet-Drafts require a Security Considerations section. The + Security Considerations section in an RTP payload format needs to + concentrate on the security properties this particular format has. + Some payload formats have very few specific issues or properties and + can fully fall back on the security considerations for RTP in general + and those of the profile being used. Because those documents are + always applicable, a reference to these is normally placed first in + the Security Considerations section. There is suggested text in the + template below. + + The security issues of confidentiality, integrity protection, replay + protection and source authentication are common issue for all payload + formats. These should be solved by mechanisms external to the + payload and do not need any special consideration in the payload + format except for a reminder on these issues. There exist + exceptions, such as payload formats that includes security + functionality, like ISMAcrypt [ISMACrypt2]. Reasons for this + division is further documented in "Securing the RTP Protocol + Framework: Why RTP Does Not Mandate a Single Media Security Solution" + [RFC7202]. For a survey of available mechanisms to meet these goals, + review "Options for Securing RTP Sessions" [RFC7201]. This also + includes key-exchange mechanisms for the security mechanisms, which + can be both integrated or separate. The choice of key-management can + have significant impact on the security properties of the RTP-based + application. Suitable stock text to inform people about this is + included in the template. + + Potential security issues with an RTP payload format and the media + encoding that need to be considered if they are applicable: + + 1. The decoding of the payload format or its media results in + substantial non-uniformity, either in output or in complexity to + perform the decoding operation. For example, a generic non- + destructive compression algorithm may provide an output of almost + an infinite size for a very limited input, thus consuming memory + or storage space out of proportion with what the receiving + application expected. Such inputs can cause some sort of + disruption, i.e., a denial-of-service attack on the receiver side + by preventing that host from performing usable work. Certain + decoding operations may also vary in the amount of processing + needed to perform those operations depending on the input. This + may also be a security risk if it is possible to raise processing + load significantly above nominal simply by designing a malicious + input sequence. If such potential attacks exist, this must be + + + + + +Westerlund Informational [Page 43] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + made clear in the Security Considerations section to make + implementers aware of the need to take precautions against such + behavior. + + 2. The inclusion of active content in the media format or its + transport. "Active content" means scripts, etc., that allow an + attacker to perform potentially arbitrary operations on the + receiver. Most active contents has limited possibility to access + the system or perform operations outside a protected sandbox. + RFC 4855 [RFC4855] has a requirement that it be noted in the + media types registration whether or not the payload format + contains active content. If the payload format has active + content, it is strongly recommended that references to any + security model applicable for such content are provided. A + boilerplate text for "no active content" is included in the + template. This must be changed if the format actually carries + active content. + + 3. Some media formats allow for the carrying of "user data", or + types of data which are not known at the time of the + specification of the payload format. Such data may be a security + risk and should be mentioned. + + 4. Audio or Speech codecs supporting variable bitrate based on + 'audio/speech' input or having discontinuous transmission support + must consider the issues discussed in "Guidelines for the Use of + Variable Bit Rate Audio with Secure RTP" [RFC6562]. + + Suitable stock text for the Security Considerations section is + provided in the template in Appendix A. However, authors do need to + actively consider any security issues from the start. Failure to + address these issues may block approval and publication. + +7.3. Congestion Control + + RTP and its profiles do discuss congestion control. There is ongoing + work in the IETF with both a basic circuit-breaker mechanism + [RFC8083] using basic RTCP messages intended to prevent persistent + congestion and also work on more capable congestion avoidance / + bitrate adaptation mechanism in the RMCAT WG. + + Congestion control is an important issue in any usage in networks + that are not dedicated. For that reason, it is recommended that all + RTP payload format documents discuss the possibilities that exist to + regulate the bitrate of the transmissions using the described RTP + payload format. Some formats may have limited or step-wise + regulation of bitrate. Such limiting factors should be discussed. + + + + +Westerlund Informational [Page 44] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +7.4. IANA Considerations + + Since all RTP payload formats contain a media type specification, + they also need an IANA Considerations section. The media type name + must be registered, and this is done by requesting that IANA register + that media name. When that registration request is written, it shall + also be requested that the media type is included under the "RTP + Payload Format media types" subregistry of the RTP registry + (http://www.iana.org/assignments/rtp-parameters). + + Parameters for the payload format need to be included in this + registration and can be specified as required or optional ones. The + format of these parameters should be such that they can be included + in the SDP attribute "a=fmtp" string (see Section 6 [RFC4566]), which + is the common mapping. Some parameters, such as "Channel" are + normally mapped to the rtpmap attribute instead; see Section 3 of + [RFC4855]. + + In addition to the above request for media type registration, some + payload formats may have parameters where, in the future, new + parameter values need to be added. In these cases, a registry for + that parameter must be created. This is done by defining the + registry in the IANA Considerations section. BCP 26 [BCP26] provides + guidelines to specifying such registries. Care should be taken when + defining the policy for new registrations. + + Before specifying a new registry, it is worth checking the existing + ones in the IANA "MIME Media Type Sub-Parameter Registries". For + example, video formats that need a media parameter expressing color + sub-sampling may be able to reuse those defined for 'video/raw' + [RFC4175]. + +8. Authoring Tools + + This section provides information about some tools that may be used. + Don't feel pressured to follow these recommendations. There exist a + number of alternatives, including the ones listed at + . But these suggestions are worth checking + out before deciding that the grass is greener somewhere else. + + Note that these options are related to the old text only RFC format, + and do not cover tools for at the time of publication recently + approved new RFC format, see [RFC7990]. + + + + + + + + +Westerlund Informational [Page 45] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +8.1. Editing Tools + + There are many choices when it comes to tools to choose for authoring + Internet-Drafts. However, in the end, they need to be able to + produce a draft that conforms to the Internet-Draft requirements. If + you don't have any previous experience with authoring Internet- + Drafts, xml2rfc does have some advantages. It helps by creating a + lot of the necessary boilerplate in accordance with the latest rules, + thus reducing the effort. It also speeds up publication after + approval as the RFC Editor can use the source XML document to produce + the RFC more quickly. + + Another common choice is to use Microsoft Word and a suitable + template (see [RFC5385]) to produce the draft and print that to file + using the generic text printer. It has some advantages when it comes + to spell checking and change bars. However, Word may also produce + some problems, like changing formatting, and inconsistent results + between what one sees in the editor and in the generated text + document, at least according to the author's personal experience. + +8.2. Verification Tools + + There are a few tools that are very good to know about when writing a + draft. These help check and verify parts of one's work. These tools + can be found at . + + o I-D Nits checker (https://tools.ietf.org/tools/idnits/). It + checks that the boilerplate and some other things that are easily + verifiable by machine are okay in your draft. Always use it + before submitting a draft to avoid direct refusal in the + submission step. + + o ABNF Parser and verification (https://tools.ietf.org/tools/bap/ + abnf.cgi). Checks that your ABNF parses correctly and warns about + loose ends, like undefined symbols. However, the actual content + can only be verified by humans knowing what it intends to + describe. + + o RFC diff (https://tools.ietf.org/rfcdiff). A diff tool that is + optimized for drafts and RFCs. For example, it does not point out + that the footer and header have moved in relation to the text on + every page. + + + + + + + + + +Westerlund Informational [Page 46] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +9. Security Considerations + + As this is an Informational RFC about writing drafts that are + intended to become RFCs, there are no direct security considerations. + However, the document does discuss the writing of Security + Considerations sections and what should be particularly considered + when specifying RTP payload formats. + +10. Informative References + + + [BCP9] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + Kolkman, O., Bradner, S., and S. Turner, "Characterization + of Proposed Standards", BCP 9, RFC 7127, January 2014. + + Dusseault, L. and R. Sparks, "Guidance on Interoperation + and Implementation Reports for Advancement to Draft + Standard", BCP 9, RFC 5657, September 2009. + + Housley, R., Crocker, D., and E. Burger, "Reducing the + Standards Track to Two Maturity Levels", BCP 9, RFC 6410, + October 2011. + + Resnick, P., "Retirement of the "Internet Official + Protocol Standards" Summary Document", BCP 9, RFC 7100, + December 2013. + + Dawkins, S., "Increasing the Number of Area Directors in + an IETF Area", BCP 9, RFC 7475, March 2015. + + + + [BCP25] Wasserman, M., "Updates to RFC 2418 Regarding the + Management of IETF Mailing Lists", BCP 25, RFC 3934, + October 2004. + + Bradner, S., "IETF Working Group Guidelines and + Procedures", BCP 25, RFC 2418, September 1998. + + Resnick, P. and A. Farrel, "IETF Anti-Harassment + Procedures", BCP 25, RFC 7776, March 2016. + + + + + + + + +Westerlund Informational [Page 47] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008, . + + [BCP78] Bradner, S., Ed. and J. Contreras, Ed., "Rights + Contributors Provide to the IETF Trust", BCP 78, RFC 5378, + November 2008, . + + [BCP79] Bradner, S., Ed., "Intellectual Property Rights in IETF + Technology", BCP 79, RFC 3979, March 2005. + + Narten, T., "Clarification of the Third Party Disclosure + Procedure in RFC 3979", BCP 79, RFC 4879, April 2007. + + + + [BLOAT] Nichols, K. and V. Jacobson, "Controlling Queue Delay", + ACM Networks, Vol. 10, No. 5, DOI 10.1145/2208917.2209336, + May 2012, . + + [CSP-RTP] Perkins, C., "RTP: Audio and Video for the Internet", + Addison-Wesley Professional, ISBN 0-672-32249-8, June + 2003. + + [ID-GUIDE] Housley, R., "Guidelines to Authors of Internet-Drafts", + December 2010, + . + + [ISMACrypt2] + Internet Streaming Media Alliance (ISMA), "ISMA Encryption + and Authentication, Version 2.0 release version", November + 2007, . + + [RED] Floyd, S. and V. Jacobson, "Random Early Detection (RED) + gateways for Congestion Avoidance", IEEE/ACM Transactions + on Networking 1(4) 397--413, August 1993, + . + + [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated + Services in the Internet Architecture: an Overview", + RFC 1633, DOI 10.17487/RFC1633, June 1994, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + + + +Westerlund Informational [Page 48] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., + Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- + Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, + DOI 10.17487/RFC2198, September 1997, + . + + [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, + RFC 2360, DOI 10.17487/RFC2360, June 1998, + . + + [RFC2418] Bradner, S., "IETF Working Group Guidelines and + Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, + September 1998, . + + [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., + and W. Weiss, "An Architecture for Differentiated + Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, + . + + [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP + Headers for Low-Speed Serial Links", RFC 2508, + DOI 10.17487/RFC2508, February 1999, + . + + [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format + for Generic Forward Error Correction", RFC 2733, + DOI 10.17487/RFC2733, December 1999, + . + + [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP + Payload Format Specifications", BCP 36, RFC 2736, + DOI 10.17487/RFC2736, December 1999, + . + + [RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time + Transport Protocol Management Information Base", RFC 2959, + DOI 10.17487/RFC2959, October 2000, + . + + [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session + Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, + October 2000, . + + [RFC3009] Rosenberg, J. and H. Schulzrinne, "Registration of + parityfec MIME types", RFC 3009, DOI 10.17487/RFC3009, + November 2000, . + + + + + +Westerlund Informational [Page 49] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., + Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, + K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., + Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header + Compression (ROHC): Framework and four profiles: RTP, UDP, + ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, + July 2001, . + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + . + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + DOI 10.17487/RFC3264, June 2002, + . + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + [RFC3497] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP + Payload Format for Society of Motion Picture and + Television Engineers (SMPTE) 292M Video", RFC 3497, + DOI 10.17487/RFC3497, March 2003, + . + + [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and + P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with + High Delay, Packet Loss and Reordering", RFC 3545, + DOI 10.17487/RFC3545, July 2003, + . + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, . + + [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and + Video Conferences with Minimal Control", STD 65, RFC 3551, + DOI 10.17487/RFC3551, July 2003, + . + + + + + +Westerlund Informational [Page 50] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + [RFC3558] Li, A., "RTP Payload Format for Enhanced Variable Rate + Codecs (EVRC) and Selectable Mode Vocoders (SMV)", + RFC 3558, DOI 10.17487/RFC3558, July 2003, + . + + [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific + Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July + 2003, . + + [RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. + Romascanu, "Introduction to the Remote Monitoring (RMON) + Family of MIB Modules", RFC 3577, DOI 10.17487/RFC3577, + August 2003, . + + [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., + "RTP Control Protocol Extended Reports (RTCP XR)", + RFC 3611, DOI 10.17487/RFC3611, November 2003, + . + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, DOI 10.17487/RFC3711, March 2004, + . + + [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., + and G. Fairhurst, Ed., "The Lightweight User Datagram + Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July + 2004, . + + [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, + M., and D. Singer, "RTP Payload Format for H.264 Video", + RFC 3984, DOI 10.17487/RFC3984, February 2005, + . + + [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text + Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, + . + + [RFC4170] Thompson, B., Koren, T., and D. Wing, "Tunneling + Multiplexed Compressed RTP (TCRTP)", BCP 110, RFC 4170, + DOI 10.17487/RFC4170, November 2005, + . + + [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for + Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175, + September 2005, . + + + + + +Westerlund Informational [Page 51] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + [RFC4352] Sjoberg, J., Westerlund, M., Lakaniemi, A., and S. Wenger, + "RTP Payload Format for the Extended Adaptive Multi-Rate + Wideband (AMR-WB+) Audio Codec", RFC 4352, + DOI 10.17487/RFC4352, January 2006, + . + + [RFC4396] Rey, J. and Y. Matsui, "RTP Payload Format for 3rd + Generation Partnership Project (3GPP) Timed Text", + RFC 4396, DOI 10.17487/RFC4396, February 2006, + . + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, DOI 10.17487/RFC4566, + July 2006, . + + [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) + and RTP Control Protocol (RTCP) Packets over Connection- + Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July + 2006, . + + [RFC4573] Even, R. and A. Lochbaum, "MIME Type Registration for RTP + Payload Format for H.224", RFC 4573, DOI 10.17487/RFC4573, + July 2006, . + + [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, + "Extended RTP Profile for Real-time Transport Control + Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, + DOI 10.17487/RFC4585, July 2006, + . + + [RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", + RFC 4587, DOI 10.17487/RFC4587, August 2006, + . + + [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. + Hakenberg, "RTP Retransmission Payload Format", RFC 4588, + DOI 10.17487/RFC4588, July 2006, + . + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, + . + + [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC + Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, + July 2007, . + + + + + +Westerlund Informational [Page 52] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + [RFC4855] Casner, S., "Media Type Registration of RTP Payload + Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, + . + + [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, + "RTP Payload Format and File Storage Format for the + Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband + (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, + April 2007, . + + [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., + "The Message Session Relay Protocol (MSRP)", RFC 4975, + DOI 10.17487/RFC4975, September 2007, + . + + [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error + Correction", RFC 5109, DOI 10.17487/RFC5109, December + 2007, . + + [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for + Real-time Transport Control Protocol (RTCP)-Based Feedback + (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February + 2008, . + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + . + + [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP + Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July + 2008, . + + [RFC5385] Touch, J., "Version 2.0 Microsoft Word Template for + Creating Internet Drafts and RFCs", RFC 5385, + DOI 10.17487/RFC5385, February 2010, + . + + [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", + RFC 5484, DOI 10.17487/RFC5484, March 2009, + . + + [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding + Dependency in the Session Description Protocol (SDP)", + RFC 5583, DOI 10.17487/RFC5583, July 2009, + . + + + + + +Westerlund Informational [Page 53] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust + Header Compression (ROHC) Framework", RFC 5795, + DOI 10.17487/RFC5795, March 2010, + . + + [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, + "Network Time Protocol Version 4: Protocol and Algorithms + Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, + . + + [RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity + Forward Error Correction (FEC)", RFC 6015, + DOI 10.17487/RFC6015, October 2010, + . + + [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP + Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, + . + + [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP + Payload Format for H.264 Video", RFC 6184, + DOI 10.17487/RFC6184, May 2011, + . + + [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, + "RTP Payload Format for Scalable Video Coding", RFC 6190, + DOI 10.17487/RFC6190, May 2011, + . + + [RFC6295] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for + MIDI", RFC 6295, DOI 10.17487/RFC6295, June 2011, + . + + [RFC6354] Xie, Q., "Forward-Shifted RTP Redundancy Payload Support", + RFC 6354, DOI 10.17487/RFC6354, August 2011, + . + + [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error + Correction (FEC) Framework", RFC 6363, + DOI 10.17487/RFC6363, October 2011, + . + + [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the + Standards Track to Two Maturity Levels", BCP 9, RFC 6410, + DOI 10.17487/RFC6410, October 2011, + . + + + + + +Westerlund Informational [Page 54] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of + Variable Bit Rate Audio with Secure RTP", RFC 6562, + DOI 10.17487/RFC6562, March 2012, + . + + [RFC6597] Downs, J., Ed. and J. Arbeiter, Ed., "RTP Payload Format + for Society of Motion Picture and Television Engineers + (SMPTE) ST 336 Encoded Data", RFC 6597, + DOI 10.17487/RFC6597, April 2012, + . + + [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., + and K. Carlberg, "Explicit Congestion Notification (ECN) + for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August + 2012, . + + [RFC6682] Watson, M., Stockhammer, T., and M. Luby, "RTP Payload + Format for Raptor Forward Error Correction (FEC)", + RFC 6682, DOI 10.17487/RFC6682, August 2012, + . + + [RFC6701] Farrel, A. and P. Resnick, "Sanctions Available for + Application to Violators of IETF IPR Policy", RFC 6701, + DOI 10.17487/RFC6701, August 2012, + . + + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + . + + [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple + Clock Rates in an RTP Session", RFC 7160, + DOI 10.17487/RFC7160, April 2014, + . + + [RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds", + RFC 7164, DOI 10.17487/RFC7164, March 2014, + . + + [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP + Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, + . + + [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP + Framework: Why RTP Does Not Mandate a Single Media + Security Solution", RFC 7202, DOI 10.17487/RFC7202, April + 2014, . + + + +Westerlund Informational [Page 55] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + DOI 10.17487/RFC7231, June 2014, + . + + [RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H. + Stokking, "RTP Clock Source Signalling", RFC 7273, + DOI 10.17487/RFC7273, June 2014, + . + + [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, + DOI 10.17487/RFC7322, September 2014, + . + + [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format + for the Opus Speech and Audio Codec", RFC 7587, + DOI 10.17487/RFC7587, June 2015, + . + + [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and + B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms + for Real-Time Transport Protocol (RTP) Sources", RFC 7656, + DOI 10.17487/RFC7656, November 2015, + . + + [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, + DOI 10.17487/RFC7667, November 2015, + . + + [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. + Galligan, "RTP Payload Format for VP8 Video", RFC 7741, + DOI 10.17487/RFC7741, March 2016, + . + + [RFC7798] Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. + Hannuksela, "RTP Payload Format for High Efficiency Video + Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798, March + 2016, . + + [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., + and M. Stiemerling, Ed., "Real-Time Streaming Protocol + Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December + 2016, . + + [RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990, + DOI 10.17487/RFC7990, December 2016, + . + + + + +Westerlund Informational [Page 56] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: + Circuit Breakers for Unicast RTP Sessions", RFC 8083, + DOI 10.17487/RFC8083, March 2017, + . + + [TAO] Hoffman, P., Ed., "The Tao of IETF: A Novice's Guide to + the Internet Engineering Task Force", November 2012, + . + + [TRACKER] "IETF Datatracker", . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Westerlund Informational [Page 57] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +Appendix A. RTP Payload Format Template + + This section contains a template for writing an RTP payload format in + the form of an Internet-Draft. Text within [...] are instructions + and must be removed from the draft itself. Some text proposals that + are included are conditional. "..." is used to indicate where further + text should be written. + +A.1. Title + + [The title shall be descriptive but as compact as possible. RTP is + allowed and recommended abbreviation in the title] + + RTP payload format for ... + +A.2. Front-Page Boilerplate + + Status of this Memo + + [Insert the IPR notice and copyright boilerplate from BCP 78 and 79 + that applies to this draft.] + + [Insert the current Internet-Draft document explanation. At the time + of publishing it was:] + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + +A.3. Abstract + + [A payload format abstract should mention the capabilities of the + format, for which media format is used, and a little about that codec + formats capabilities. Any abbreviation used in the payload format + must be spelled out here except the very well known like RTP. No + citations are allowed, and no use of language from RFC 2119 either.] + +A.4. Table of Contents + + [If your draft is approved for publication as an RFC, a Table of + Contents is required, per [RFC7322].] + + + + +Westerlund Informational [Page 58] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +A.5. Introduction + + [The Introduction should provide a background and overview of the + payload format's capabilities. No normative language in this + section, i.e., no MUST, SHOULDs etc.] + +A.6. Conventions, Definitions, and Abbreviations + + [Define conventions, definitions, and abbreviations used in the + document in this section. The most common definition used in RTP + payload formats are the RFC 2119 definitions of the uppercase + normative words, e.g., MUST and SHOULD.] + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. + +A.7. Media Format Description + + [The intention of this section is to enable reviewers and persons to + get an overview of the capabilities and major properties of the media + format. It should be kept short and concise and is not a complete + replacement for reading the media format specification.] + +A.8. Payload Format + + [Overview of payload structure] + +A.8.1. RTP Header Usage + + [RTP header usage needs to be defined. The fields that absolutely + need to be defined are timestamp and marker bit. Further fields may + be specified if used. All the rest should be left to their RTP + specification definition.] + + The remaining RTP header fields are used as specified in RTP + [RFC3550]. + +A.8.2. Payload Header + + [Define how the payload header, if it exists, is structured and + used.] + + + + + + + + + +Westerlund Informational [Page 59] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +A.8.3. Payload Data + + [The payload data, i.e., what the media codec has produced. Commonly + done through reference to the media codec specification, which + defines how the data is structured. Rules for padding may need to be + defined to bring data to octet alignment.] + +A.9. Payload Examples + + [One or more examples are good to help ease the understanding of the + RTP payload format.] + +A.10. Congestion Control Considerations + + [This section is to describe the possibility to vary the bitrate as a + response to congestion. Below is also a proposal for an initial text + that reference RTP and profiles definition of congestion control.] + + Congestion control for RTP SHALL be used in accordance with RFC 3550 + [RFC3550], and with any applicable RTP profile: e.g., RFC 3551 + [RFC3551]. An additional requirement if best-effort service is being + used is users of this payload format MUST monitor packet loss to + ensure that the packet loss rate is within acceptable parameters. + Circuit Breakers [RFC8083] is an update to RTP [RFC3550] that defines + criteria for when one is required to stop sending RTP Packet Streams. + The circuit breakers is to be implemented and followed. + +A.11. Payload Format Parameters + + This RTP payload format is identified using the ... media type, which + is registered in accordance with RFC 4855 [RFC4855] and using the + template of RFC 6838 [RFC6838]. + +A.11.1. Media Type Definition + + [Here the media type registration template from RFC 6838 is placed + and filled out. This template is provided with some common RTP + boilerplate.] + + Type name: + + Subtype name: + + Required parameters: + + Optional parameters: + + + + + +Westerlund Informational [Page 60] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + Encoding considerations: + + This media type is framed and binary; see Section 4.8 in RFC 6838 + [RFC6838]. + + Security considerations: + + Please see the Security Considerations section in RFC XXXX + + Interoperability considerations: + + Published specification: + + Applications that use this media type: + + Additional information: + + Deprecated alias names for this type: + + [Only applicable if there exists widely deployed alias for this + media type; see Section 4.2.9 of [RFC6838]. Remove or use N/A + otherwise.] + + Magic number(s): + + [Only applicable for media types that has file format + specification. Remove or use N/A otherwise.] + + File extension(s): + + [Only applicable for media types that has file format + specification. Remove or use N/A otherwise.] + + Macintosh file type code(s): + + [Only applicable for media types that has file format + specification. Even for file formats they can be skipped as + they are not relied on after Mac OS 9.X. Remove or use N/A + otherwise.] + + Person & email address to contact for further information: + + Intended usage: + + [One of COMMON, LIMITED USE, or OBSOLETE.] + + + + + + +Westerlund Informational [Page 61] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + + Restrictions on usage: + + [The below text is for media types that is only defined for RTP + payload formats. There exist certain media types that are defined + both as RTP payload formats and file transfer. The rules for such + types are documented in RFC 4855 [RFC4855].] + + This media type depends on RTP framing and, hence, is only defined + for transfer via RTP [RFC3550]. Transport within other framing + protocols is not defined at this time. + + Author: + + Change controller: + + IETF Payload working group delegated from the IESG. + + Provisional registration? (standards tree only): + + No + + (Any other information that the author deems interesting may be added + below this line.) + + [From RFC 6838: + + "N/A", written exactly that way, can be used in any field if + desired to emphasize the fact that it does not apply or that the + question was not omitted by accident. Do not use 'none' or other + words that could be mistaken for a response. + + Limited-use media types should also note in the applications list + whether or not that list is exhaustive.] + +A.11.2. Mapping to SDP + + The mapping of the above defined payload format media type and its + parameters SHALL be done according to Section 3 of RFC 4855 + [RFC4855]. + + [More specific rules only need to be included if some parameter does + not match these rules.] + +A.11.2.1. Offer/Answer Considerations + + [Here write your Offer/Answer considerations section; please see + Section 3.4.2.1 for help.] + + + + +Westerlund Informational [Page 62] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +A.11.2.2. Declarative SDP Considerations + + [Here write your considerations for declarative SDP, please see + Section 3.4.2.2 for help.] + +A.12. IANA Considerations + + This memo requests that IANA registers [insert media type name here] + as specified in Appendix A.11.1. The media type is also requested to + be added to the IANA registry for "RTP Payload Format MIME types" + . + + [See Section 7.4 and consider if any of the parameter needs a + registered name space.] + +A.13. Security Considerations + + [See Section 7.2.] + + RTP packets using the payload format defined in this specification + are subject to the security considerations discussed in the RTP + specification [RFC3550] , and in any applicable RTP profile such as + RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/ + SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: + Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] + discusses, it is not an RTP payload format's responsibility to + discuss or mandate what solutions are used to meet the basic security + goals like confidentiality, integrity, and source authenticity for + RTP in general. This responsibility lays on anyone using RTP in an + application. They can find guidance on available security mechanisms + and important considerations in "Options for Securing RTP Sessions" + [RFC7201]. Applications SHOULD use one or more appropriate strong + security mechanisms. The rest of this Security Considerations + section discusses the security impacting properties of the payload + format itself. + + This RTP payload format and its media decoder do not exhibit any + significant non-uniformity in the receiver-side computational + complexity for packet processing, and thus are unlikely to pose a + denial-of-service threat due to the receipt of pathological data. + Nor does the RTP payload format contain any active content. + + [The previous paragraph may need editing due to the format breaking + either of the statements. Fill in here any further potential + security threats created by the payload format itself.] + + + + + + +Westerlund Informational [Page 63] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +A.14. RFC Editor Considerations + + Note to RFC Editor: This section may be removed after carrying out + all the instructions of this section. + + RFC XXXX is to be replaced by the RFC number this specification + receives when published. + +A.15. References + + [References must be classified as either normative or informative and + added to the relevant section. References should use descriptive + reference tags.] + +A.15.1. Normative References + + [Normative references are those that are required to be used to + correctly implement the payload format. Also, when requirements + language is used, as in the sample text for "Congestion Control + Considerations" above, there should be a normative reference to + [RFC2119].] + +A.15.2. Informative References + + [All other references.] + +A.16. Authors' Addresses + + [All authors need to include their name and email address as a + minimum: postal mail and possibly phone numbers are included + commonly.] + + [The Template Ends Here!] + +Acknowledgements + + The author would like to thank the individuals who have provided + input to this document. These individuals include Richard Barnes, + Ali C. Begen, Bo Burman, Ross Finlayson, Russ Housley, John Lazzaro, + Jonathan Lennox, Colin Perkins, Tom Taylor, Stephan Wenger, and Qin + Wu. + + + + + + + + + + +Westerlund Informational [Page 64] + +RFC 8088 HOWTO: RTP Payload Formats May 2017 + + +Contributors + + The author would like to thank Tom Taylor for the editing pass of the + whole document and contributing text regarding proprietary RTP + payload formats. Thanks also goes to Thomas Schierl who contributed + text regarding Media Scalability features in payload formats + (Section 5.1.5). Stephan Wenger has contributed text on the need to + understand the media coding (Section 3.1) as well as joint + development of payload format with the media coding (Section 4.4). + +Author's Address + + Magnus Westerlund + Ericsson + Farogatan 2 + SE-164 80 Kista + Sweden + + Phone: +46 10 714 82 87 + Email: magnus.westerlund@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Westerlund Informational [Page 65] + -- cgit v1.2.3