doc: Add RFC documents

1 files changed, 3643 insertions, 0 deletions

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
+   <https://www.iana.org/assignments/media-types/media-types.xhtml>.
+
+   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-<lead author family name>-payload-rtp-<descriptive
+   name>-<version>.  The WG documents shall be named according to this
+   template: draft-ietf-payload-rtp-<descriptive name>-<version>.  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.<vendor-name>".
+   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/<foo>) 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
+   <http://tools.ietf.org>.  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 <http://tools.ietf.org>.
+
+   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.
+
+              <http://www.rfc-editor.org/info/bcp9>
+
+   [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.
+
+              <http://www.rfc-editor.org/info/bcp25>
+
+
+
+
+
+
+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, <http://www.rfc-editor.org/info/bcp26>.
+
+   [BCP78]    Bradner, S., Ed. and J. Contreras, Ed., "Rights
+              Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
+              November 2008, <http://www.rfc-editor.org/info/bcp78>.
+
+   [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.
+
+              <http://www.rfc-editor.org/info/bcp79>
+
+   [BLOAT]    Nichols, K. and V. Jacobson, "Controlling Queue Delay",
+              ACM Networks, Vol. 10, No. 5, DOI 10.1145/2208917.2209336,
+              May 2012, <http://queue.acm.org/detail.cfm?id=2209336>.
+
+   [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,
+              <http://www.ietf.org/id-info/guidelines.html>.
+
+   [ISMACrypt2]
+              Internet Streaming Media Alliance (ISMA), "ISMA Encryption
+              and Authentication, Version 2.0 release version", November
+              2007, <http://www.oipf.tv/docs/mpegif/isma_easpec2.0.pdf>.
+
+   [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,
+              <http://www.aciri.org/floyd/papers/early.pdf>.
+
+   [RFC1633]  Braden, R., Clark, D., and S. Shenker, "Integrated
+              Services in the Internet Architecture: an Overview",
+              RFC 1633, DOI 10.17487/RFC1633, June 1994,
+              <http://www.rfc-editor.org/info/rfc1633>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+
+
+
+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,
+              <http://www.rfc-editor.org/info/rfc2198>.
+
+   [RFC2360]  Scott, G., "Guide for Internet Standards Writers", BCP 22,
+              RFC 2360, DOI 10.17487/RFC2360, June 1998,
+              <http://www.rfc-editor.org/info/rfc2360>.
+
+   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
+              Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
+              September 1998, <http://www.rfc-editor.org/info/rfc2418>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc2475>.
+
+   [RFC2508]  Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
+              Headers for Low-Speed Serial Links", RFC 2508,
+              DOI 10.17487/RFC2508, February 1999,
+              <http://www.rfc-editor.org/info/rfc2508>.
+
+   [RFC2733]  Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format
+              for Generic Forward Error Correction", RFC 2733,
+              DOI 10.17487/RFC2733, December 1999,
+              <http://www.rfc-editor.org/info/rfc2733>.
+
+   [RFC2736]  Handley, M. and C. Perkins, "Guidelines for Writers of RTP
+              Payload Format Specifications", BCP 36, RFC 2736,
+              DOI 10.17487/RFC2736, December 1999,
+              <http://www.rfc-editor.org/info/rfc2736>.
+
+   [RFC2959]  Baugher, M., Strahm, B., and I. Suconick, "Real-Time
+              Transport Protocol Management Information Base", RFC 2959,
+              DOI 10.17487/RFC2959, October 2000,
+              <http://www.rfc-editor.org/info/rfc2959>.
+
+   [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
+              Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
+              October 2000, <http://www.rfc-editor.org/info/rfc2974>.
+
+   [RFC3009]  Rosenberg, J. and H. Schulzrinne, "Registration of
+              parityfec MIME types", RFC 3009, DOI 10.17487/RFC3009,
+              November 2000, <http://www.rfc-editor.org/info/rfc3009>.
+
+
+
+
+
+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, <http://www.rfc-editor.org/info/rfc3095>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264,
+              DOI 10.17487/RFC3264, June 2002,
+              <http://www.rfc-editor.org/info/rfc3264>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc3410>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc3497>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc3545>.
+
+   [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, <http://www.rfc-editor.org/info/rfc3550>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc3551>.
+
+
+
+
+
+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,
+              <http://www.rfc-editor.org/info/rfc3558>.
+
+   [RFC3569]  Bhattacharyya, S., Ed., "An Overview of Source-Specific
+              Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July
+              2003, <http://www.rfc-editor.org/info/rfc3569>.
+
+   [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, <http://www.rfc-editor.org/info/rfc3577>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc3611>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc3711>.
+
+   [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, <http://www.rfc-editor.org/info/rfc3828>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc3984>.
+
+   [RFC4103]  Hellstrom, G. and P. Jones, "RTP Payload for Text
+              Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005,
+              <http://www.rfc-editor.org/info/rfc4103>.
+
+   [RFC4170]  Thompson, B., Koren, T., and D. Wing, "Tunneling
+              Multiplexed Compressed RTP (TCRTP)", BCP 110, RFC 4170,
+              DOI 10.17487/RFC4170, November 2005,
+              <http://www.rfc-editor.org/info/rfc4170>.
+
+   [RFC4175]  Gharai, L. and C. Perkins, "RTP Payload Format for
+              Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175,
+              September 2005, <http://www.rfc-editor.org/info/rfc4175>.
+
+
+
+
+
+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,
+              <http://www.rfc-editor.org/info/rfc4352>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc4396>.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
+              July 2006, <http://www.rfc-editor.org/info/rfc4566>.
+
+   [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, <http://www.rfc-editor.org/info/rfc4571>.
+
+   [RFC4573]  Even, R. and A. Lochbaum, "MIME Type Registration for RTP
+              Payload Format for H.224", RFC 4573, DOI 10.17487/RFC4573,
+              July 2006, <http://www.rfc-editor.org/info/rfc4573>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc4585>.
+
+   [RFC4587]  Even, R., "RTP Payload Format for H.261 Video Streams",
+              RFC 4587, DOI 10.17487/RFC4587, August 2006,
+              <http://www.rfc-editor.org/info/rfc4587>.
+
+   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
+              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
+              DOI 10.17487/RFC4588, July 2006,
+              <http://www.rfc-editor.org/info/rfc4588>.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
+              <http://www.rfc-editor.org/info/rfc4648>.
+
+   [RFC4844]  Daigle, L., Ed. and Internet Architecture Board, "The RFC
+              Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
+              July 2007, <http://www.rfc-editor.org/info/rfc4844>.
+
+
+
+
+
+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,
+              <http://www.rfc-editor.org/info/rfc4855>.
+
+   [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, <http://www.rfc-editor.org/info/rfc4867>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc4975>.
+
+   [RFC5109]  Li, A., Ed., "RTP Payload Format for Generic Forward Error
+              Correction", RFC 5109, DOI 10.17487/RFC5109, December
+              2007, <http://www.rfc-editor.org/info/rfc5109>.
+
+   [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, <http://www.rfc-editor.org/info/rfc5124>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <http://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
+              Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
+              2008, <http://www.rfc-editor.org/info/rfc5285>.
+
+   [RFC5385]  Touch, J., "Version 2.0 Microsoft Word Template for
+              Creating Internet Drafts and RFCs", RFC 5385,
+              DOI 10.17487/RFC5385, February 2010,
+              <http://www.rfc-editor.org/info/rfc5385>.
+
+   [RFC5484]  Singer, D., "Associating Time-Codes with RTP Streams",
+              RFC 5484, DOI 10.17487/RFC5484, March 2009,
+              <http://www.rfc-editor.org/info/rfc5484>.
+
+   [RFC5583]  Schierl, T. and S. Wenger, "Signaling Media Decoding
+              Dependency in the Session Description Protocol (SDP)",
+              RFC 5583, DOI 10.17487/RFC5583, July 2009,
+              <http://www.rfc-editor.org/info/rfc5583>.
+
+
+
+
+
+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,
+              <http://www.rfc-editor.org/info/rfc5795>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc5905>.
+
+   [RFC6015]  Begen, A., "RTP Payload Format for 1-D Interleaved Parity
+              Forward Error Correction (FEC)", RFC 6015,
+              DOI 10.17487/RFC6015, October 2010,
+              <http://www.rfc-editor.org/info/rfc6015>.
+
+   [RFC6051]  Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
+              Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010,
+              <http://www.rfc-editor.org/info/rfc6051>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc6184>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc6190>.
+
+   [RFC6295]  Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for
+              MIDI", RFC 6295, DOI 10.17487/RFC6295, June 2011,
+              <http://www.rfc-editor.org/info/rfc6295>.
+
+   [RFC6354]  Xie, Q., "Forward-Shifted RTP Redundancy Payload Support",
+              RFC 6354, DOI 10.17487/RFC6354, August 2011,
+              <http://www.rfc-editor.org/info/rfc6354>.
+
+   [RFC6363]  Watson, M., Begen, A., and V. Roca, "Forward Error
+              Correction (FEC) Framework", RFC 6363,
+              DOI 10.17487/RFC6363, October 2011,
+              <http://www.rfc-editor.org/info/rfc6363>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc6410>.
+
+
+
+
+
+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,
+              <http://www.rfc-editor.org/info/rfc6562>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc6597>.
+
+   [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, <http://www.rfc-editor.org/info/rfc6679>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc6682>.
+
+   [RFC6701]  Farrel, A. and P. Resnick, "Sanctions Available for
+              Application to Violators of IETF IPR Policy", RFC 6701,
+              DOI 10.17487/RFC6701, August 2012,
+              <http://www.rfc-editor.org/info/rfc6701>.
+
+   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
+              Specifications and Registration Procedures", BCP 13,
+              RFC 6838, DOI 10.17487/RFC6838, January 2013,
+              <http://www.rfc-editor.org/info/rfc6838>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc7160>.
+
+   [RFC7164]  Gross, K. and R. Brandenburg, "RTP and Leap Seconds",
+              RFC 7164, DOI 10.17487/RFC7164, March 2014,
+              <http://www.rfc-editor.org/info/rfc7164>.
+
+   [RFC7201]  Westerlund, M. and C. Perkins, "Options for Securing RTP
+              Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
+              <http://www.rfc-editor.org/info/rfc7201>.
+
+   [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, <http://www.rfc-editor.org/info/rfc7202>.
+
+
+
+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,
+              <http://www.rfc-editor.org/info/rfc7231>.
+
+   [RFC7273]  Williams, A., Gross, K., van Brandenburg, R., and H.
+              Stokking, "RTP Clock Source Signalling", RFC 7273,
+              DOI 10.17487/RFC7273, June 2014,
+              <http://www.rfc-editor.org/info/rfc7273>.
+
+   [RFC7322]  Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
+              DOI 10.17487/RFC7322, September 2014,
+              <http://www.rfc-editor.org/info/rfc7322>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc7587>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc7656>.
+
+   [RFC7667]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
+              DOI 10.17487/RFC7667, November 2015,
+              <http://www.rfc-editor.org/info/rfc7667>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc7741>.
+
+   [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, <http://www.rfc-editor.org/info/rfc7798>.
+
+   [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, <http://www.rfc-editor.org/info/rfc7826>.
+
+   [RFC7990]  Flanagan, H., "RFC Format Framework", RFC 7990,
+              DOI 10.17487/RFC7990, December 2016,
+              <http://www.rfc-editor.org/info/rfc7990>.
+
+
+
+
+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,
+              <http://www.rfc-editor.org/info/rfc8083>.
+
+   [TAO]      Hoffman, P., Ed., "The Tao of IETF: A Novice's Guide to
+              the Internet Engineering Task Force", November 2012,
+              <http://www.ietf.org/tao.html>.
+
+   [TRACKER]  "IETF Datatracker", <https://datatracker.ietf.org/>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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"
+   <http://www.iana.org/assignments/rtp-parameters>.
+
+   [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]
+