Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8088

How to Write an RTP Payload Format

Pages: 65
Informational
Updates:  2736
Part 5 of 5 – Pages 58 to 65
First   Prev   None

Top   ToC   RFC8088 - Page 58   prevText

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].]
Top   ToC   RFC8088 - Page 59

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.]
Top   ToC   RFC8088 - Page 60

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:
Top   ToC   RFC8088 - Page 61
   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.]
Top   ToC   RFC8088 - Page 62
   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.]
Top   ToC   RFC8088 - Page 63
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.]
Top   ToC   RFC8088 - Page 64

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.
Top   ToC   RFC8088 - Page 65

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