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].]

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.]

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:

   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.]

   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.]

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.]

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.

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