idnits 2.17.1 draft-ietf-payload-rtp-howto-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document updates RFC2736, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC2736, updated by this document, for RFC5378 checks: 1998-04-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 13, 2014) is 3753 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3979 (ref. 'BCP79') (Obsoleted by RFC 8179) == Outdated reference: A later version (-16) exists of draft-ietf-avt-srtp-not-mandatory-14 == Outdated reference: A later version (-11) exists of draft-ietf-avtcore-clksrc-09 == Outdated reference: A later version (-08) exists of draft-ietf-avtcore-leap-second-07 == Outdated reference: A later version (-12) exists of draft-ietf-avtcore-multiplex-guidelines-01 == Outdated reference: A later version (-18) exists of draft-ietf-avtcore-rtp-circuit-breakers-03 == Outdated reference: A later version (-10) exists of draft-ietf-avtcore-rtp-security-options-09 == Outdated reference: A later version (-15) exists of draft-ietf-payload-rtp-h265-01 == Outdated reference: A later version (-11) exists of draft-ietf-payload-rtp-opus-01 == Outdated reference: A later version (-17) exists of draft-ietf-payload-vp8-10 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Duplicate reference: RFC2418, mentioned in 'RFC2418', was also mentioned in 'BCP25'. -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2733 (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 3009 (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 3984 (Obsoleted by RFC 6184) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5285 (Obsoleted by RFC 8285) Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Payload Working Group M. Westerlund 3 Internet-Draft Ericsson 4 Updates: 2736 (if approved) January 13, 2014 5 Intended status: Informational 6 Expires: July 17, 2014 8 How to Write an RTP Payload Format 9 draft-ietf-payload-rtp-howto-13 11 Abstract 13 This document contains information on how to best write an RTP 14 payload format specification. It provides reading tips, design 15 practices, and practical tips on how to produce an RTP payload format 16 specification quickly and with good results. A template is also 17 included with instructions. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 17, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.3. Use of Normative Requirements Language . . . . . . . . . 6 59 3. Preparations . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Read and Understand the Media Coding Spec . . . . . . . . 6 61 3.2. Recommended Reading . . . . . . . . . . . . . . . . . . . 6 62 3.2.1. IETF Process and Publication . . . . . . . . . . . . 7 63 3.2.2. RTP . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.3. Important RTP Details . . . . . . . . . . . . . . . . . . 12 65 3.3.1. The RTP Session . . . . . . . . . . . . . . . . . . . 13 66 3.3.2. RTP Header . . . . . . . . . . . . . . . . . . . . . 13 67 3.3.3. RTP Multiplexing . . . . . . . . . . . . . . . . . . 15 68 3.3.4. RTP Synchronization . . . . . . . . . . . . . . . . . 16 69 3.4. Signalling Aspects . . . . . . . . . . . . . . . . . . . 18 70 3.4.1. Media Types . . . . . . . . . . . . . . . . . . . . . 18 71 3.4.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . 20 72 3.5. Transport Characteristics . . . . . . . . . . . . . . . . 22 73 3.5.1. Path MTU . . . . . . . . . . . . . . . . . . . . . . 22 74 3.5.2. Different Queuing Algorithms . . . . . . . . . . . . 23 75 3.5.3. Quality of Service . . . . . . . . . . . . . . . . . 24 76 4. Standardisation Process for an RTP Payload Format . . . . . . 24 77 4.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . 24 78 4.1.1. Steps from Idea to Publication . . . . . . . . . . . 24 79 4.1.2. WG meetings . . . . . . . . . . . . . . . . . . . . . 26 80 4.1.3. Draft Naming . . . . . . . . . . . . . . . . . . . . 26 81 4.1.4. Writing Style . . . . . . . . . . . . . . . . . . . . 27 82 4.1.5. How to speed up the process . . . . . . . . . . . . . 28 83 4.2. Other Standards Bodies . . . . . . . . . . . . . . . . . 29 84 4.3. Proprietary and Vendor Specific . . . . . . . . . . . . . 29 85 4.4. Joint Development of Media Coding Specification and RTP 86 Payload Format . . . . . . . . . . . . . . . . . . . . . 30 87 5. Designing Payload Formats . . . . . . . . . . . . . . . . . . 30 88 5.1. Features of RTP Payload Formats . . . . . . . . . . . . . 31 89 5.1.1. Aggregation . . . . . . . . . . . . . . . . . . . . . 31 90 5.1.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 32 91 5.1.3. Interleaving and Transmission Re-Scheduling . . . . . 32 92 5.1.4. Media Back Channels . . . . . . . . . . . . . . . . . 33 93 5.1.5. Media Scalability . . . . . . . . . . . . . . . . . . 33 94 5.1.6. High Packet Rates . . . . . . . . . . . . . . . . . . 36 95 5.2. Selecting Timestamp Definition . . . . . . . . . . . . . 36 97 6. Noteworthy Aspects in Payload Format Design . . . . . . . . . 38 98 6.1. Audio Payloads . . . . . . . . . . . . . . . . . . . . . 38 99 6.2. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 39 100 6.3. Text . . . . . . . . . . . . . . . . . . . . . . . . . . 40 101 6.4. Application . . . . . . . . . . . . . . . . . . . . . . . 40 102 7. Important Specification Sections . . . . . . . . . . . . . . 41 103 7.1. Media Format Description . . . . . . . . . . . . . . . . 41 104 7.2. Security Considerations . . . . . . . . . . . . . . . . . 42 105 7.3. Congestion Control . . . . . . . . . . . . . . . . . . . 43 106 7.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 44 107 8. Authoring Tools . . . . . . . . . . . . . . . . . . . . . . . 44 108 8.1. Editing Tools . . . . . . . . . . . . . . . . . . . . . . 44 109 8.2. Verification Tools . . . . . . . . . . . . . . . . . . . 45 110 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 111 10. Security Considerations . . . . . . . . . . . . . . . . . . . 45 112 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 46 113 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 114 13. RFC-Editor Note . . . . . . . . . . . . . . . . . . . . . . . 46 115 14. Informative References . . . . . . . . . . . . . . . . . . . 46 116 Appendix A. RTP Payload Format Template . . . . . . . . . . . . 54 117 A.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 54 118 A.2. Front page boilerplate . . . . . . . . . . . . . . . . . 54 119 A.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . 55 120 A.4. Table of Content . . . . . . . . . . . . . . . . . . . . 55 121 A.5. Introduction . . . . . . . . . . . . . . . . . . . . . . 55 122 A.6. Conventions, Definitions and Acronyms . . . . . . . . . . 55 123 A.7. Media Format Description . . . . . . . . . . . . . . . . 55 124 A.8. Payload format . . . . . . . . . . . . . . . . . . . . . 56 125 A.8.1. RTP Header Usage . . . . . . . . . . . . . . . . . . 56 126 A.8.2. Payload Header . . . . . . . . . . . . . . . . . . . 56 127 A.8.3. Payload Data . . . . . . . . . . . . . . . . . . . . 56 128 A.9. Payload Examples . . . . . . . . . . . . . . . . . . . . 56 129 A.10. Congestion Control Considerations . . . . . . . . . . . . 56 130 A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 57 131 A.11.1. Media Type Definition . . . . . . . . . . . . . . . 57 132 A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . 59 133 A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 59 134 A.13. Security Considerations . . . . . . . . . . . . . . . . . 59 135 A.14. RFC Editor Considerations . . . . . . . . . . . . . . . . 60 136 A.15. References . . . . . . . . . . . . . . . . . . . . . . . 60 137 A.15.1. Normative References . . . . . . . . . . . . . . . . 60 138 A.15.2. Informative References . . . . . . . . . . . . . . . 60 139 A.16. Author Addresses . . . . . . . . . . . . . . . . . . . . 60 140 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 61 142 1. Introduction 144 RTP [RFC3550] payload formats define how a specific real-time data 145 format is structured in the payload of an RTP packet. A real-time 146 data format without a payload format specification cannot be 147 transported using RTP. This creates an interest in many individuals/ 148 organizations with media encoders or other types of real-time data to 149 define RTP payload formats. However, the specification of a well- 150 designed RTP payload format is non-trivial and requires knowledge of 151 both RTP and the real-time data format. 153 This document is intended to help any author of an RTP payload format 154 specification make important design decisions, consider important 155 features of RTP and RTP security, etc. The document is also intended 156 to be a good starting point for any person with little experience in 157 the IETF and/or RTP to learn the necessary steps. 159 This document extends and updates the information that is available 160 in "Guidelines for Writers of RTP Payload Format Specifications" 161 [RFC2736]. Since that RFC was written, further experience has been 162 gained on the design and specification of RTP payload formats. 163 Several new RTP profiles have been defined, and robustness tools have 164 also been defined, and these need to be considered. 166 This document also discusses the possible venues for defining an RTP 167 payload format: IETF, other standards bodies and proprietary ones. 169 Note, this document does discuss IETF, IANA and RFC Editor processes 170 and rules as they were when this document was published. This to 171 make clear how the work to specify an RTP payload formats depends, 172 use and interacts with these rules and processes. However, these 173 rules and processes are subject to change and the formal rule and 174 process specifications always takes precedence over what is written 175 here. 177 1.1. Structure 179 This document has several different parts discussing different 180 aspects of the creation of an RTP payload format specification. 181 Section 3 discusses the preparations the author(s) should do before 182 starting to write a specification. Section 4 discusses the different 183 processes used when specifying and completing a payload format, with 184 focus on working inside the IETF. Section 5 discusses the design of 185 payload formats themselves in detail. Section 6 discusses current 186 design trends and provides good examples of practices that should be 187 followed when applicable. Following that Section 7 provides a 188 discussion on important sections in the RTP payload format 189 specification itself such as security and IANA considerations 190 sections. This document ends with an appendix containing a template 191 that can be used when writing RTP payload formats specifications. 193 2. Terminology 195 2.1. Definitions 197 Media Stream: A sequence of RTP packets that together carry part or 198 all of the content of a specific media (audio, video, text, or 199 data whose form and meaning are defined by a specific real-time 200 application) from a specific sender source within a given RTP 201 session. 203 RTP Session: An association among a set of participants 204 communicating with RTP. The distinguishing feature of an RTP 205 session is that each session maintains a full, separate space of 206 SSRC identifiers. See also Section 3.3.1. 208 RTP Payload Format: The RTP payload format specifies how units of a 209 specific encoded media are put into the RTP packet payloads and 210 how the fields of the RTP packet header are used, thus enabling 211 the format to be used in RTP applications. 213 2.2. Acronyms 215 ABNF: Augmented Backus-Naur Form [RFC5234] 217 ADU: Application Data Unit 219 ALF: Application Level Framing 221 ASM: Any-Source Multicast 223 BCP: Best Current Practice 225 ID: Internet Draft 227 IESG: Internet Engineering Steering Group 229 MTU: Maximum Transmission Unit 231 WG: Working Group 233 QoS: Quality of Service 235 RFC: Request For Comments 237 RTP: Real-time Transport Protocol 238 RTCP: RTP Control Protocol 240 RTT: Round-Trip Time 242 SSM: Source-Specific Multicast 244 2.3. Use of Normative Requirements Language 246 As this document is an both in the informational category and being 247 an instruction rather than a specification, this document does not 248 use any RFC 2119 language and the interpretation of "may", "should", 249 "recommended" and "must" are the ones of the English language. 251 3. Preparations 253 RTP is a complex real-time media delivery framework and it has a lot 254 of details that need to be considered when writing an RTP payload 255 format. It is also important to have a good understanding of the 256 media codec/format so that all of its important features and 257 properties are considered. Only when one has sufficient 258 understanding of both parts one can produce an RTP payload format of 259 high quality. On top of this, one needs to understand the process 260 within the IETF and especially the Working Group responsible for 261 standardizing payload formats (currently the PAYLOAD WG) to go 262 quickly from the initial idea stage to a finished RFC. This and the 263 next sections help an author prepare himself in those regards. 265 3.1. Read and Understand the Media Coding Spec 267 It may be obvious, but it is necessary for an author of an RTP 268 payload specification to have a solid understanding of the media to 269 be transported. Important are not only the specifically spelled out 270 transport aspects (if any) in the media coding specification, but 271 also core concepts of the underlying technology. For example, an RTP 272 payload format for video coded with inter-picture prediction will 273 perform poorly if the payload designer does not take the use of 274 inter-picture prediction into account. On the other hand, some 275 (mostly older) media codecs offer error-resilience tools against bit 276 errors, which, when misapplied over RTP, in almost all cases would 277 only introduce overhead with no measurable return. 279 3.2. Recommended Reading 281 The following sub-sections list a number of documents. Not all need 282 to be read in full detail. However, an author basically needs to be 283 aware of everything listed below. 285 3.2.1. IETF Process and Publication 287 Newcomers to the IETF are strongly recommended to read the "Tao of 288 the IETF" [TAO] that goes through most things that one needs to know 289 about the IETF. This contains information about history, 290 organizational structure, how the WG and meetings work and many more 291 details. 293 It is very important to note and understand the IETF Intellectual 294 Property Rights (IPR) policy that requires early disclosures based on 295 personal knowledge from anyone contributing in IETF. The IETF 296 policies associated with IPR are documented in BCP 78 [BCP78] 297 (related to copyright, including software copyright for example code) 298 and BCP 79 [BCP79] (related to patent rights). These rules may be 299 different from other standardization organizations. For example a 300 person that has a patent or a patent application that he or she 301 reasonably and personally believes to cover a mechanism that gets 302 added to the Internet draft they are contributing to (e.g. by 303 submitting the draft, posting comments or suggestions on the mailing 304 list or speaking at a meeting) they will need to make a timely IPR 305 disclosure. Read the above documents for the authoritative rules. 306 Failure to follow the IPR rules can have dire implications for the 307 specification and the author(s) as discussed in [RFC6701]. 309 Note: These IPR rules applies on what is specified in the RTP 310 Payload format Internet Draft (and later RFC), IPRs that relates 311 to a codec specification from an external body does not require 312 IETF IPR disclosure. Informative text explaining the nature of 313 the codec would not normally require an IETF IPR declaration. 314 Appropriate IPR declarations for the codec itself would normally 315 be found in files of the external body defining the codec, in 316 accordance with that external bodies own IPR rules. 318 The main part of the IETF process is formally defined in BCP 9 319 [BCP9]. BCP 25 [BCP25] describes the WG process, the relation 320 between the IESG and the WG, and the responsibilities of WG chairs 321 and participants. 323 It is important to note that the RFC series contains documents of 324 several different publication streams as defined by the The RFC 325 Series and RFC Editor [RFC4844]. The most important stream for RTP 326 payload formats authors are the IETF Stream. In this streams the 327 work of IETF is published. The stream contains documents of several 328 different categories: standards track, informational, experimental, 329 best current practice (BCP), and historic. The standards track 330 contains two maturity levels: Proposed Standard and Internet Standard 331 [RFC6410]. A standards track document must start as proposed; after 332 successful deployment and operational experience with at least two 333 implementations it can be moved to Internet Standard. The 334 Independent Submission Stream could appear to be of interest as it 335 provides a way of publishing documents of certain categories such as 336 experimental and informational with a different review process. 337 However, as long as IETF has a WG which is chartered to work on RTP 338 payload formats this stream should not be used. 340 As the content of a given RFC is not allowed to change once 341 published, the only way to modify an RFC is to write and publish a 342 new one that either updates or replaces the old one. Therefore, 343 whether reading or referencing an RFC, it is important to consider 344 both the Category field in the document header and to check if the 345 RFC is the latest on the subject and still valid. One way of 346 checking the current status of an RFC is to use the RFC-editor's RFC 347 search engine, which displays the current status and which if any RFC 348 has updated or obsoleted it. The RFC-editor search engine will also 349 indicate if there exist any RFC-errata. Any approved Errata is 350 issues of significant importance with the RFC and thus should be 351 known also prior to an update and replacement publication. 353 Before starting to write a draft one should also read the Internet 354 Draft writing guidelines (http://www.ietf.org/ietf/1id- 355 guidelines.txt), the ID checklist (http://www.ietf.org/ID- 356 Checklist.html) and the RFC editorial guidelines and procedures 357 [RFC-ED]. Another document that can be useful is the "Guide for 358 Internet Standards Writers" [RFC2360]. 360 There are also a number of documents to consider in the process of 361 writing drafts intended to become RFCs. These are important when 362 writing certain type of text. 364 RFC 2606: When writing examples using DNS names in Internet drafts, 365 those names shall be chosen from the example.com, example.net, and 366 example.org domains. 368 RFC 3849: Defines the range of IPv6 unicast addresses (2001:DB8::/ 369 32) that should be used in any examples. 371 RFC 5737: Defines the ranges of IPv4 unicast addresses reserved for 372 documentation and examples: 192.0.2.0/24, 198.51.100.0/24, and 373 203.0.113.0/24. 375 RFC 5234: Augmented Backus-Naur Form (ABNF) is often used when 376 writing text field specifications. Not that commonly used in RTP 377 payload formats but may be useful when defining Media Type 378 parameters of some complexity. 380 3.2.2. RTP 382 The recommended reading for RTP consists of several different parts; 383 design guidelines, the RTP protocol, profiles, robustness tools, and 384 media specific recommendations. 386 Any author of RTP payload formats should start by reading Guidelines 387 for Writers of RTP Payload Format Specifications [RFC2736] which 388 contains an introduction to the application layer framing (ALF) 389 principle, the channel characteristics of IP channels, and design 390 guidelines for RTP payload formats. The goal of ALF is to be able to 391 transmit Application Data Units (ADUs) that are independently usable 392 by the receiver in individual RTP packets, thus minimizing 393 dependencies between RTP packets and the effects of packet loss. 395 Then it is advisable to learn more about the RTP protocol, by 396 studying the RTP specification RFC 3550 [RFC3550] and the existing 397 profiles. As a complement to the standards documents there exists a 398 book totally dedicated to RTP [CSP-RTP]. There exist several 399 profiles for RTP today, but all are based on the "RTP Profile for 400 Audio and Video Conferences with Minimal Control" (RFC 3551) 401 [RFC3551] (abbreviated as RTP/AVP). The other profiles that one 402 should know about are Secure RTP (RTP/SAVP) [RFC3711], "Extended RTP 403 Profile for RTCP-based Feedback (RTP/AVPF)" [RFC4585] and "Extended 404 Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)" [RFC5124]. 405 It is important to understand RTP and the RTP/AVP profile in detail. 406 For the other profiles it is sufficient to have an understanding of 407 what functionality they provide and the limitations they create. 409 A number of robustness tools have been developed for RTP. The tools 410 are for different use cases and real-time requirements. 412 RFC 2198: The "RTP Payload for Redundant Audio Data" [RFC2198] 413 provides functionalities to transmit redundant copies of audio or 414 text payloads. These redundant copies are sent together with a 415 primary format in the same RTP payload. This format relies on the 416 RTP timestamp to determine where data belongs in a sequence and 417 therefore is usually most suitable to be used with audio. 418 However, the RTP Payload format for T.140 [RFC4103] text format 419 also uses this format. The format's major property is that it 420 only preserves the timestamp of the redundant payloads, not the 421 original sequence number. This makes it unusable for most video 422 formats. This format is also only suitable for media formats that 423 produce relatively small RTP payloads. 425 RFC 6354: The "Forward-Shifted RTP Redundancy Payload Support" 426 [RFC6354] is a variant of RFC 2198 which allows the redundant data 427 to be transmitted prior to the original. 429 RFC 5109: The "RTP Payload Format for Generic Forward Error 430 Correction (FEC)" [RFC5109] provides an XOR-based FEC of the whole 431 or parts of a number of RTP packets. This specification replaced 432 the previous specification for XOR-based FEC [RFC2733]. These FEC 433 packets are sent in a separate stream or as a redundant encoding 434 using RFC 2198. This FEC scheme has certain restrictions in the 435 number of packets it can protect. It is suitable for low-to- 436 medium delay tolerant applications with limited amount of RTP 437 packets. 439 RFC 6015: The "RTP Payload Format for 1-D Interleaved Parity Forward 440 Error Correction (FEC)" [RFC6015] provides a variant of the XOR- 441 based Generic protection defined in [RFC2733]. The main 442 difference is to use interleaving scheme on which packets gets 443 included as source packets for a particular protection packet. 444 The interleaving is defined by using every L packets as source 445 data. And then produce protection data over D number of packets. 446 Thus each block of D x L source packets will result in L number of 447 Repair packets, each capable of repairing one loss. The goal is 448 to provide better burst error robustness when the packet rate is 449 higher. 451 FEC Framework: The Forward Error Correction (FEC) Framework 452 [RFC6363] defines how to use FEC protection for arbitrary packet 453 flows. This framework can be applied for RTP/RTCP packet flows, 454 including using RTP for transmission of repair symbols, an example 455 is the RTP Payload for Raptor FEC [RFC6682]. 457 RTP Retransmission: The RTP retransmission scheme [RFC4588] is used 458 for semi-reliability of the most important RTP packets in a media 459 stream. The level of reliability between semi and in practice 460 full reliability depends on the targeted properties and situation 461 where parameters such as round-trip time (RTT) allowed additional 462 overhead, and allowable delay. It often requires the application 463 to be quite delay tolerant as a minimum of one round-trip time 464 plus processing delay is required to perform a retransmission. 465 Thus it is mostly suitable for streaming applications but may also 466 be usable in certain other cases when operating in networks with 467 short round-trip times. 469 RTP over TCP: RFC 4571 [RFC4571] defines how one sends RTP and RTCP 470 packets over connection-oriented transports like TCP. If one uses 471 TCP, one gets reliability for all packets but loses some of the 472 real-time behavior that RTP was designed to provide. Issues with 473 TCP transport of real-time media include head-of-line blocking and 474 wasting resources on retransmission of already late data. TCP is 475 also limited to point-to-point connections which further restricts 476 its applicability. 478 There has also been both discussion and design of RTP payload 479 formats, e.g., AMR and AMR-WB [RFC4867], supporting the unequal error 480 detection provided by UDP-Lite [RFC3828]. The idea is that by not 481 having a checksum over part of the RTP payload one can allow bit 482 errors from the lower layers. By allowing bit errors one can 483 increase the efficiency of some link layers, and also avoid 484 unnecessary discarding of data when the payload and media codec can 485 get at least some benefit from the data. The main issue is that one 486 has no idea of the level of bit errors present in the unprotected 487 part of the payload. This makes it hard or impossible to determine 488 if one can design something usable or not. Payload format designers 489 are recommended against considering features for unequal error 490 detection using UDP-Lite unless very clear requirements exist. 492 There also exist some management and monitoring extensions. 494 RFC 2959: The RTP protocol Management Information Database (MIB) 495 [RFC2959] that is used with SNMP [RFC3410] to configure and 496 retrieve information about RTP sessions. 498 RFC 3611: The RTCP Extended Reports (RTCP XR) [RFC3611] consists of 499 a framework for reports sent within RTCP. It can easily be 500 extended by defining new report formats, which has and is 501 occurring. The XRBLOCK WG in IETF is chartered (at the time of 502 writing) with defining new report formats. The list of specified 503 formats are available in IANA's RTCP XR Block Type registry (http: 504 //www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block- 505 types.xhtml). The report formats that are defined in RFC3611 506 provide report information on packet loss, packet duplication, 507 packet reception times, RTCP statistics summary and VoIP Quality. 508 [RFC3611] also defines a mechanism that allows receivers to 509 calculate the RTT to other session participants when used. 511 RMONMIB: The remote monitoring WG has defined a mechanism [RFC3577] 512 based on usage of the MIB that can be an alternative to RTCP XR. 514 A number of transport optimizations have also been developed for use 515 in certain environments. They are all intended to be transparent and 516 do not require special consideration by the RTP payload format 517 writer. Thus they are primarily listed here for informational 518 reasons. 520 RFC 2508: Compressing IP/UDP/RTP headers for slow serial links 521 (CRTP) [RFC2508] is the first IETF developed RTP header 522 compression mechanism. It provides quite good compression, 523 however, it has clear performance problems when subject to packet 524 loss or reordering between compressor and decompressor. 526 RFC 3095 & RFC 5795: These are the base specifications of the robust 527 header compression (ROHC) protocol version 1 [RFC3095] and version 528 2 [RFC5795]. This solution was created as a result of CRTP's lack 529 of performance when compressed packets are subject to loss. 531 RFC 3545: Enhanced compressed RTP (E-CRTP) [RFC3545] was developed 532 to provide extensions to CRTP that allow for better performance 533 over links with long RTTs, packet loss and/or reordering. 535 RFC 4170: Tunneling Multiplexed Compressed RTP (TCRTP) [RFC4170] is 536 a solution that allows header compression within a tunnel carrying 537 multiple multiplexed RTP flows. This is primarily used in voice 538 trunking. 540 There exist a couple of different security mechanisms that may be 541 used with RTP. Generic mechanisms by definition are transparent for 542 the RTP payload format and do not need special consideration by the 543 format designer. The main reason that different solutions exist is 544 that different applications have different requirements thus 545 different solutions have been developed. For more discussion on this 546 please see Options for Securing RTP Sessions 547 [I-D.ietf-avtcore-rtp-security-options] and Why RTP Does Not Mandate 548 a Single Security Mechanism [I-D.ietf-avt-srtp-not-mandatory]. The 549 main properties for an RTP security mechanism are to provide 550 confidentiality for the RTP payload, integrity protection to detect 551 manipulation of payload and headers, and source authentication. Not 552 all mechanisms provide all of these features, a point which will need 553 to be considered when a specific mechanisms is chosen. 555 The profile for Secure RTP - SRTP (RTP/SAVP) [RFC3711] and the 556 derived profile (RTP/SAVPF [RFC5124]) are a solution that enables 557 confidentiality, integrity protection, replay protection and partial 558 source authentication. It is the solution most commonly used with 559 RTP at time of writing this documet. There exist several key- 560 management solutions for SRTP, as well other choices, affecting the 561 security properties. For a more in-depth review of the options and 562 also other solutions than SRTP consult "Options for Securing RTP 563 Sessions" [I-D.ietf-avtcore-rtp-security-options]. 565 3.3. Important RTP Details 567 This section reviews a number of RTP features and concepts that are 568 available in RTP independent of the payload format. The RTP payload 569 format can make use of these when appropriate, and even affect the 570 behaviour (RTP timestamp and marker bit), but it is important to note 571 that not all features and concepts are relevant to every payload 572 format. This section does not remove the necessity to read up on 573 RTP. However, it does point out a few important details to remember 574 when designing a payload format. 576 3.3.1. The RTP Session 578 The definition of the RTP session from RFC 3550 is: 580 "An association among a set of participants communicating with RTP. 581 A participant may be involved in multiple RTP sessions at the same 582 time. In a multimedia session, each medium is typically carried in a 583 separate RTP session with its own RTCP packets unless the encoding 584 itself multiplexes multiple media into a single data stream. A 585 participant distinguishes multiple RTP sessions by reception of 586 different sessions using different pairs of destination transport 587 addresses, where a pair of transport addresses comprises one network 588 address plus a pair of ports for RTP and RTCP. All participants in 589 an RTP session may share a common destination transport address pair, 590 as in the case of IP multicast, or the pairs may be different for 591 each participant, as in the case of individual unicast network 592 addresses and port pairs. In the unicast case, a participant may 593 receive from all other participants in the session using the same 594 pair of ports, or may use a distinct pair of ports for each." 596 "The distinguishing feature of an RTP session is that each session 597 maintains a full, separate space of SSRC identifiers (defined next). 598 The set of participants included in one RTP session consists of those 599 that can receive an SSRC identifier transmitted by any one of the 600 participants either in RTP as the SSRC or a CSRC (also defined below) 601 or in RTCP. For example, consider a three-party conference 602 implemented using unicast UDP with each participant receiving from 603 the other two on separate port pairs. If each participant sends RTCP 604 feedback about data received from one other participant only back to 605 that participant, then the conference is composed of three separate 606 point-to-point RTP sessions. If each participant provides RTCP 607 feedback about its reception of one other participant to both of the 608 other participants, then the conference is composed of one multi- 609 party RTP session. The latter case simulates the behavior that would 610 occur with IP multicast communication among the three participants." 612 "The RTP framework allows the variations defined here (RFC3550), but 613 a particular control protocol or application design will usually 614 impose constraints on these variations." 616 3.3.2. RTP Header 618 The RTP header contains a number of fields. Two fields always 619 require additional specification by the RTP payload format, namely 620 the RTP Timestamp and the marker bit. Certain RTP payload formats 621 also use the RTP sequence number to realize certain functionalities, 622 primarily related to the order of their application data units. The 623 payload type is used to indicate the used payload format. The Sender 624 Source Identifier (SSRC) is used to distinguish RTP packets from 625 multiple senders and media streams. Finally, [RFC5285] specifies how 626 to transport payload format independent metadata relating to the RTP 627 packet. 629 Marker Bit: A single bit normally used to provide important 630 indications. In audio it is normally used to indicate the start 631 of a talk burst. This enables jitter buffer adaptation prior to 632 the beginning of the burst with minimal audio quality impact. In 633 video the marker bit is normally used to indicate the last packet 634 part of a frame. This enables a decoder to finish decoding the 635 picture, where it otherwise may need to wait for the next packet 636 to explicitly know that the frame is finished. 638 Timestamp: The RTP timestamp indicates the time instant the media 639 sample belongs to. For discrete media like video, it normally 640 indicates when the media (frame) was sampled. For continuous 641 media it normally indicates the first time instance the media 642 present in the payload represents. For audio this is the sampling 643 time of the first sample. All RTP payload formats must specify 644 the meaning of the timestamp value and the clock rates allowed. 645 Selecting timestamp rate is an active design choice and is further 646 discussed in Section 5.2. 648 Discontinuous transmissions (DTX) that is common among speech 649 codecs, typically results in gaps or jumps in the timestamp values 650 due to that there is no media payload to transmit and the next 651 used timestamp value represent the actual sampling time of the 652 data transmitted. 654 Sequence Number: The sequence number is monotonically increasing and 655 is set as the packet is sent. This property is used in many 656 payload formats to recover the order of everything from the whole 657 stream down to fragments of application data units (ADUs) and the 658 order they need to be decoded. Discontinuous transmissions do not 659 result in gaps in the sequence number, as it is monotonically 660 increasing for each sent RTP packet. 662 Payload Type: The payload type is used to indicate on a per packet 663 basis which format is used. The binding between a payload type 664 number and a payload format and its configuration are dynamically 665 bound and RTP session specific. The configuration information can 666 be bound to a payload type value by out-of-band signalling 667 (Section 3.4). An example of this would be video decoder 668 configuration information. Commonly the same payload type is used 669 for a media stream for the whole duration of a session. However, 670 in some cases it may be necessary to change the payload format or 671 its configuration during the session. 673 SSRC: The Synchronisation Source Identifier (SSRC) is normally not 674 used by a payload format other than to identify the RTP timestamp 675 and sequence number space a packet belongs to, allowing 676 simultaneously reception of multiple media sources. However, some 677 of the RTP mechanisms for improving resilience to packet loss uses 678 multiple SSRCs to separate original data and repair or redundant 679 data. 681 Header Extensions: RTP payload formats often need to include 682 metadata relating to the payload data being transported. Such 683 metadata is sent as a payload header, at the start of the payload 684 section of the RTP packet. The RTP packet also includes space for 685 a header extension [RFC5285]; this can be used to transport 686 payload format independent metadata, for example a SMPTE time code 687 for the packet [RFC5484]. The RTP header extensions are not 688 intended to carry headers that relate to a particular payload 689 format., and must not contain information needed in order to 690 decode the payload. 692 The remaining fields do not commonly influence the RTP payload 693 format. The padding bit is worth clarifying as it indicates that one 694 or more bytes are appended after the RTP payload. This padding must 695 be removed by a receiver before payload format processing can occur. 696 Thus it is completely separate from any padding that may occur within 697 the payload format itself. 699 3.3.3. RTP Multiplexing 701 RTP has three multiplexing points that are used for different 702 purposes. A proper understanding of this is important to correctly 703 use them. 705 The first one is separation of media streams of different types or 706 usages, which is accomplished using different RTP sessions. So for 707 example in the common multimedia session with audio and video, RTP 708 commonly multiplexes audio and video in different RTP sessions. To 709 achieve this separation, transport-level functionalities are used, 710 normally UDP port numbers. Different RTP sessions are also used to 711 realize layered scalability as it allows a receiver to select one or 712 more layers for multicast RTP sessions simply by joining the 713 multicast groups over which the desired layers are transported. This 714 separation also allows different Quality of Service (QoS) to be 715 applied to different media types. Use of multiple transport flows 716 has potential issues due to NAT and Firewall traversal. The choices 717 how one applies RTP sessions as well as transport flows can affect 718 the transport properties a RTP media stream experiences. 720 The next multiplexing point is separation of different sources within 721 an RTP session. Here RTP uses the SSRC to identify individual 722 sources. An example of individual sources in an audio RTP session 723 would be different microphones, independently of whether they are 724 connected to the same host or different hosts. For each SSRC a 725 unique RTP sequence number and timestamp space is used. 727 The third multiplexing point is the RTP header payload type field. 728 The payload type identifies what format the content in the RTP 729 payload has. This includes different payload format configurations, 730 different codecs, and also usage of robustness mechanisms like the 731 one described in RFC 2198 [RFC2198]. 733 For more discussion and consideration of how and when to use the 734 different RTP multiplexing points see 735 [I-D.ietf-avtcore-multiplex-guidelines]. 737 3.3.4. RTP Synchronization 739 There are several types of synchronization and we will here describe 740 how RTP handles the different types: 742 Intra media: The synchronization within a media stream from a source 743 (SSRC) is accomplished using the RTP timestamp field. Each RTP 744 packet carries the RTP timestamp, which specifies the position in 745 time of the media payload contained in this packet relative to the 746 content of other RTP packets in the same RTP media stream (i.e., a 747 given SSRC). This is especially useful in cases of discontinuous 748 transmissions. Discontinuities can be caused by network 749 conditions; when extensive losses occur the RTP timestamp tells 750 the receiver how much later than previously received media the 751 present media should be played out. 753 Inter media: Applications commonly have a desire to use several 754 media sources, possibly of different media types, at the same 755 time. Thus, there exists a need to synchronize also different 756 media from the same end-point. This puts two requirements on RTP: 757 the possibility to determine which media are from the same end- 758 point and if they should be synchronized with each other; and the 759 functionality to facilitate the synchronization itself. 761 The first step in inter-media synchronization is to determine which 762 SSRCs in each session should be synchronized with each other. This 763 is accomplished by comparing the CNAME fields in the RTCP SDES 764 packets. SSRCs with the same CNAME sent in any of multiple RTP 765 sessions can be synchronized. 767 The actual RTCP mechanism for inter-media synchronization is based on 768 the idea that each media stream provides a position on the media 769 specific time line (measured in RTP timestamp ticks) and a common 770 reference time line. The common reference time line is expressed in 771 RTCP as a wall clock time in the Network Time Protocol (NTP) format. 772 It is important to notice that the wall clock time is not required to 773 be synchronized between hosts, for example by using NTP [RFC5905] . 774 It can even have nothing at all to do with the actual time, for 775 example the host system's up-time can be used for this purpose. The 776 important factor is that all media streams from a particular source 777 that are being synchronized use the same reference clock to derive 778 their relative RTP timestamp time scales. The type of reference 779 clock and its timebase can be signalled using RTP Clock Source 780 Signalling [I-D.ietf-avtcore-clksrc]. 782 Figure 1 illustrates how if one receives RTCP Sender Report (SR) 783 packet P1 in one media stream and RTCP SR packet P2 in the other 784 session, then one can calculate the corresponding RTP timestamp 785 values for any arbitrary point in time T. However, to be able to do 786 that it is also required to know the RTP timestamp rates for each 787 medium currently used in the sessions. 789 TS1 --+---------------+-------> 790 | | 791 P1 | 792 | | 793 NTP ---+-----+---------T------> 794 | | 795 P2 | 796 | | 797 TS2 ---------+---------+---X--> 799 Figure 1: RTCP Synchronization 801 Assume that medium 1 uses an RTP Timestamp clock rate of 16 kHz, and 802 medium 2 uses a clock rate of 90 kHz. Then TS1 and TS2 for point T 803 can be calculated in the following way: TS1(T) = TS1(P1) + 16000 * 804 (NTP(T)-NTP(P1)) and TS2(T) = TS2(P2) + 90000 * (NTP(T)-NTP(P2)). 805 This calculation is useful as it allows the implementation to 806 generate a common synchronization point for which all time values are 807 provided (TS1(T), TS2(T) and T). So when one wishes to calculate the 808 NTP time that the timestamp value present in packet X corresponds to 809 one can do that in the following way: NTP(X) = NTP(T) + (TS2(X) - 810 TS2(T))/90000. 812 Improved signaling for layered codecs and fast tune-in have been 813 specified in Rapid Synchronization for RTP flows [RFC6051]. 815 Leap Seconds are extra seconds added or seconds removed to keep our 816 clocks in sync with earth's rotation. Adding or removing seconds can 817 impact first of all the reference clock as discussed in "RTP and Leap 818 Seconds" [I-D.ietf-avtcore-leap-second]. But also in cases where the 819 RTP timestamp values are derived using the wall clock during the leap 820 second event errors can occur. Implementations need to consider leap 821 seconds and should consider the recommendations in 822 [I-D.ietf-avtcore-leap-second]. 824 3.4. Signalling Aspects 826 RTP payload formats are used in the context of application signalling 827 protocols such as SIP [RFC3261] using the Session Description 828 Protocol (SDP) [RFC4566] with Offer/Answer [RFC3264], RTSP [RFC2326] 829 or SAP [RFC2326]. These examples all use out-of-band signalling to 830 indicate which type of RTP media streams that are desired to be used 831 in the session and how they are configured. To be able to declare or 832 negotiate the media format and RTP payload packetization, the payload 833 format must be given an identifier. In addition to the identifier 834 many payload formats have also the need to signal further 835 configuration information out-of-band for the RTP payloads prior to 836 the media transport session. 838 The above examples of session-establishing protocols all use SDP, but 839 other session description formats may be used. For example there was 840 discussion of a new XML-based session description format within IETF 841 (SDP-NG). In the event, the proposal did not get beyond the initial 842 protocol specification because of the enormous installed base of SDP 843 implementations. However, to avoid locking the usage of RTP to SDP 844 based out-of-band signalling, the payload formats are identified 845 using a separate definition format for the identifier and associated 846 parameters. That format is the Media Type. 848 3.4.1. Media Types 850 Media types [RFC6838] are identifiers originally created for 851 identifying media formats included in email. In this usage they were 852 known as MIME types, where the expansion of the MIME acronym includes 853 the word "mail". The term "media type" was introduced to reflect a 854 broader usage, which includes HTTP [RFC2616], MSRP [RFC4975] and many 855 other protocols, to identify arbitrary content carried within the 856 protocols. Media types also provide a media hierarchy that fits RTP 857 payload formats well. Media type names are two-part and consist of 858 content type and sub-type separated with a slash, e.g. "audio/PCMA" 859 or "video/h263-2000". It is important to choose the correct content- 860 type when creating the media type identifying an RTP payload format. 861 However, in most cases there is little doubt what content type the 862 format belongs to. Guidelines for choosing the correct media type 863 and registration rules for media type names are provided in Media 864 Type Specifications and Registration Procedures [RFC6838]. The 865 additional rules for media types for RTP payload formats are provided 866 in Media Type Registration of RTP Payload Formats [RFC4855]. 868 Registration of the RTP payload name is something that is required to 869 avoid name collision in the future. Note that "x-" names are not 870 suitable for any documented format as they have the same problem with 871 name collision and can't be registered. The list of already 872 registered media types can be found at IANA Web site (http:// 873 www.iana.org). 875 Media types are allowed any number of parameters, which may be 876 required or optional for that media type. They are always specified 877 on the form "name=value". There exist no restrictions on how the 878 value is defined from media type's perspective, except that 879 parameters must have a value. However, the usage of media types in 880 SDP, etc. has resulted in the following restrictions that need to be 881 followed to make media types usable for RTP identifying payload 882 formats: 884 1. Arbitrary binary content in the parameters is allowed but needs 885 to be encoded so that it can be placed within text based 886 protocols. Base64 [RFC4648] is recommended, but for shorter 887 content Base16 [RFC4648] may be more appropriate as it is simpler 888 to interpret for humans. This needs to be explicitly stated when 889 defining a media type parameter with binary values. 891 2. The end of the value needs to be easily found when parsing a 892 message. Thus parameter values that are continuous and not 893 interrupted by common text separators, such as space and semi- 894 colon, are recommended. If that is not possible some type of 895 escaping should be used. Usage of quote (") is recommended, and 896 do not forget to provide a method of encoding any character used 897 for quoting inside the quoted element. 899 3. A common representation form for the media type and its 900 parameters is on a single line. In that case the media type is 901 followed by a semicolon-separated list of the parameter value 902 pairs, e.g.: 904 audio/amr octet-align=0; mode-set=0,2,5,7; mode-change-period=2 906 3.4.2. Mapping to SDP 908 Since SDP [RFC4566] is so commonly used as an out-of-band signalling 909 protocol, a mapping of the media type into SDP exists. The details 910 on how to map the media type and its parameters into SDP are 911 described in RFC 4855 [RFC4855]. However, this is not sufficient to 912 explain how certain parameters must be interpreted for example in the 913 context of Offer/Answer negotiation [RFC3264]. 915 3.4.2.1. The Offer/Answer Model 917 The Offer/Answer (O/A) model allows SIP to negotiate which media 918 formats and payload formats are to be used in a session and how they 919 are to be configured. However, O/A does not define a default 920 behavior and instead points out the need to define how parameters 921 behave. To make things even more complex the direction of media 922 within a session has an impact on these rules, so that some cases may 923 require separate descriptions for media streams that are send-only, 924 receive-only or both sent and received as identified by the SDP 925 attributes a=sendonly, a=recvonly, and a=sendrecv. In addition the 926 usage of multicast adds further limitations as the same media stream 927 is delivered to all participants. If those multicast-imposed 928 restrictions are too limiting for unicast then separate rules for 929 unicast and multicast will be required. 931 The simplest and most common O/A interpretation is that a parameter 932 is defined to be declarative; i.e., the SDP offer/answer sending 933 agent can declare a value and that has no direct impact on the other 934 agent's values. This declared value applies to all media that are 935 going to be sent to the declaring entity. For example most video 936 codecs have a level parameter which tells the other participants the 937 highest complexity the video decoder supports. The level parameter 938 can be declared independently by two participants in a unicast 939 session as it will be the media sender's responsibility to transmit a 940 video stream that fulfills the limitation the other side has 941 declared. However, in multicast it will be necessary to send a 942 stream that follows the limitation of the weakest receiver, i.e., the 943 one that supports the lowest level. To simplify the negotiation in 944 these cases it is common to require any answerer to a multicast 945 session to take a yes or no approach to parameters. 947 A "negotiated" parameter is a different case, for which both sides 948 need to agree on its value. Such a parameter requires the answerer 949 to either accept it as it is offered or remove the payload type the 950 parameter belonged to from its answer. The removal of the payload 951 type from the answer indicates to the offerer the lack of support for 952 the parameter values presented. An unfortunate implication of the 953 need to use complete payload types to indicate each possible 954 configuration so as to maximize the chances of achieving 955 interoperability, is that the number of necessary payload types can 956 quickly grow large. This is one reason to limit the total number of 957 sets of capabilities that may be implemented. 959 The most problematic type of parameters are those that relate to the 960 media the entity sends. They do not really fit the O/A model but can 961 be shoe-horned in. Examples of such parameters can be found in the 962 H.264 video codec's payload format [RFC6184], where the name of all 963 parameters with this property starts with "sprop-". The issue with 964 these parameters is that they declare properties for a media stream 965 that the other party may not accept. The best one can make of the 966 situation is to explain the assumption that the other party will 967 accept the same parameter value for the media it will receive as the 968 offerer of the session has proposed. If the answerer needs to change 969 any declarative parameter relating to streams it will receive then 970 the offerer may be required to make an new offer to update the 971 parameter values for its outgoing media stream. 973 Another issue to consider is the send-only media streams in offers. 974 Parameters that relate to what the answering entity accepts to 975 receive have no meaning other than to provide a template for the 976 answer. It is worth pointing out in the specification that these 977 really provide a set of parameter values that the sender recommends. 978 Note that send-only streams in answers will need to indicate the 979 offerer's parameters to ensure that the offerer can match the answer 980 to the offer. 982 A further issue with offer/answer which complicates things is that 983 the answerer is allowed to renumber the payload types between offer 984 and answer. This is not recommended but allowed for support of 985 gateways to the ITU conferencing suite. This means that it must be 986 possible to bind answers for payload types to the payload types in 987 the offer even when the payload type number has been changed, and 988 some of the proposed payload types have been removed. This binding 989 must normally be done by matching the configurations originally 990 offered against those in the answer. This may require specification 991 in the payload format of which parameters that constitute a 992 configuration, for example as done in Section 8.2.2 of the H.264 RTP 993 Payload format [RFC6184]; "The parameters identifying a media format 994 configuration for H.264 are profile-level-id and packetization-mode". 996 3.4.2.2. Declarative Usage in RTSP and SAP 998 SAP (Session Announcement Protocol) [RFC2974] was experimentally used 999 for announcing multicast sessions. Similar but better protocols are 1000 using SDP in a declarative style to configure multicast based 1001 applications. Independently of the usage of Source-specific 1002 Multicast (SSM) [RFC3569] or Any-source Multicast (ASM), the SDP 1003 provided by these configuration delivery protocols applies to all 1004 participants. All media that is sent to the session must follow the 1005 media stream definition as specified by the SDP. This enables 1006 everyone to receive the session if they support the configuration. 1007 Here SDP provides a one way channel with no possibility to affect the 1008 configuration that the session creator has decided upon. Any RTP 1009 Payload format that requires parameters for the send direction and 1010 which needs individual values per implementation or instance will 1011 fail in a SAP session for a multicast session allowing anyone to 1012 send. 1014 Real-Time Streaming Protocol (RTSP) [RFC2326] allows the negotiation 1015 of transport parameters for media streams which are part of a 1016 streaming session between a server and client. RTSP has divided the 1017 transport parameters from the media configuration. SDP is commonly 1018 used for media configuration in RTSP and is sent to the client prior 1019 to session establishment, either through use of the DESCRIBE method 1020 or by means of an out-of-band channel like HTTP, email etc. The SDP 1021 is used to determine which media streams and what formats are being 1022 used prior to session establishment. 1024 Thus both SAP and RTSP use SDP to configure receivers and senders 1025 with a predetermined configuration for a media stream including the 1026 payload format and any of its parameters. All parameters are used in 1027 a declarative fashion. This can result in different treatment of 1028 parameters between offer/answer and declarative usage in RTSP and 1029 SAP. Any such difference will need to be spelled out by the payload 1030 format specification. 1032 3.5. Transport Characteristics 1034 The general channel characteristics that RTP flows experience are 1035 documented in Section 3 of Guidelines for Writers of RTP Payload 1036 Format Specifications [RFC2736]. The discussion below provides 1037 additional information. 1039 3.5.1. Path MTU 1041 At the time of writing, the most common IP Maximum Transmission Unit 1042 (MTU) in commonly deployed link layers is 1500 bytes (Ethernet data 1043 payload). However, there exist both links with smaller MTUs and 1044 links with much larger MTUs. An example for links with small MTU 1045 size is older generation cellular links. Certain parts of the 1046 Internet already support an IP MTU of 8000 bytes or more, but these 1047 are limited islands. The most likely places to find MTUs larger than 1048 1500 bytes are within enterprise networks, university networks, data 1049 centers, storage networks as well as over high capacity (10 Gbps or 1050 more) links. There is a slow ongoing evolution towards larger MTU 1051 sizes. However, at the same time it has become common to use 1052 tunneling protocols, often multiple ones whose overhead when added 1053 together can shrink the MTU significantly. Thus, there exists a need 1054 to consider both limited MTUs as well as enable support of larger 1055 MTUs. This should be considered in the design, especially in regards 1056 to features such as aggregation of independently decodable data 1057 units. 1059 3.5.2. Different Queuing Algorithms 1061 Routers and switches on the network path between an IP sender and a 1062 particular receiver can exhibit different behaviors affecting the 1063 end-to-end characteristics. One of the more important aspects of 1064 this is queuing behavior. Routers and switches have some amount of 1065 queuing to handle temporary bursts of data that designated to leave 1066 the switch or router on the same egress link. A queue when not empty 1067 results in an increased path delay. 1069 The implementation of the queuing affects the delay and also how 1070 congestion signals (Explicit Congestion Marking (ECN) [RFC6679] or 1071 packet drops) are provided to the flow. The other aspects are if the 1072 flow shares the queue with other flows and how the implementation 1073 affects the flow interaction. This becomes important for example 1074 when real-time flows interact with long-lived TCP flows. TCP has a 1075 built-in behavior in its congestion control that strive to fill the 1076 buffer, thus all flows sharing the buffer experienced the delay build 1077 up. 1079 A common but quite poor queue handling mechanism is tail-drop, i.e., 1080 only drop packets when the incoming packet doesn't fit in the queue. 1081 If a bad queuing algorithm is combined with too much queue space the 1082 queuing time can grow very significant and can even become multiple 1083 seconds. This is called bufferbloat [BLOAT]. Active Queue 1084 Management (AQM) is a term covering mechanisms that try to do 1085 something smarter by actively managing the queue, for example by 1086 sending congestion signals earlier by dropping packets earlier in the 1087 queue. The behavior also affects the flow interactions. For 1088 example, Random Early Drop (RED) selects which packet(s) to drop 1089 randomly. This give flows that have more packets in the queue a 1090 higher probability to experience the packet loss (congestion signal). 1091 There is ongoing work to find suitable mechanisms to recommend for 1092 implementation and reduce the use of tail-drop. 1094 3.5.3. Quality of Service 1096 Using best effort Internet has no guarantees for the paths 1097 properties. Quality of Service (QoS) mechanism are intended to 1098 provide the possibility to bound the path properties. Where Diffserv 1099 [RFC2475] markings effects the queuing and forwarding behaviors of 1100 routers, the mechanism provides only statistical guarantees and care 1101 in how much marked packets of different types that are entering the 1102 network. Flow-based QoS like IntServ [RFC1633] has the potential for 1103 stricter guarantees as the properties are agreed on by each hop on 1104 the path at the cost of per-flow state in the network. 1106 4. Standardisation Process for an RTP Payload Format 1108 This section discusses the recommended process to produce an RTP 1109 payload format in the described venues. This is to document the best 1110 current practice on how to get a well-designed and specified payload 1111 format as quickly as possible. For specifications that are defined 1112 by standards bodies other than the IETF, the primary milestone is the 1113 registration of the Media Type for the RTP payload format. For 1114 proprietary media formats, the primary goal depends on whether 1115 interoperability is desired at the RTP level. However, there is also 1116 the issue of ensuring best possible quality of any specification. 1118 4.1. IETF 1120 For all standardized media formats, it is recommended that the 1121 payload format be specified in the IETF. The main reason is to 1122 provide an openly available RTP payload format specification that has 1123 been reviewed by people experienced with RTP payload formats. At the 1124 time of writing, this work is done in the PAYLOAD Working Group (WG), 1125 but that may change in the future. 1127 4.1.1. Steps from Idea to Publication 1129 There are a number of steps that an RTP payload format should go 1130 through from the initial idea until it is published. This also 1131 documents the process that the PAYLOAD Working Group applies when 1132 working with RTP payload formats. 1134 Idea: Determined the need for an RTP payload format as an IETF 1135 specification. 1137 Initial effort: Using this document as guideline one should be able 1138 to get started on the work. If one's media codec doesn't fit any 1139 of the common design patterns or one has problems understanding 1140 what the most suitable way forward is, then one should contact the 1141 PAYLOAD Working Group and/or the WG chairs. The goal of this 1142 stage is to have an initial individual draft. This draft needs to 1143 focus on the introductory parts that describe the real-time media 1144 format and the basic idea on how to packetize it. Not all the 1145 details are required to be filled in. However, the security 1146 chapter is not something that one should skip even initially. It 1147 is important to consider from the start any serious security risks 1148 that need to be solved. The first step is completed when one has 1149 a draft that is sufficiently detailed for a first review by the 1150 WG. The less confident one is of the solution, the less work 1151 should be spent on details; instead concentrate on the codec 1152 properties and what is required to make the packetization work. 1154 Submission of the first version: When one has performed the above 1155 one submits the draft as an individual draft. This can be done at 1156 any time except for a period prior to an IETF meeting. See 1157 important dates related to the next IETF meeting for draft 1158 submission cut-off date. When the IETF draft announcement has 1159 been sent out on the draft announcement list, forward it to the 1160 PAYLOAD WG and request that it be reviewed. In the email outline 1161 any issues the authors currently have with the design. 1163 Iterative improvements: Taking the feedback into account one 1164 updates the draft and tries resolve issues. New revisions of the 1165 draft can be submitted at any time (again except for a short 1166 period before meetings). It is recommended to submit a new 1167 version whenever one has made major updates or has new issues that 1168 are easiest to discuss in the context of a new draft version. 1170 Becoming a WG document: Given that the definition of RTP payload 1171 formats is part of the PAYLOAD WG's charter, RTP payload formats 1172 that are going to be published as standards track RFCs need to 1173 become WG documents. Becoming a WG document means that the chairs 1174 are responsible for administrative handling, for example, issuing 1175 publication requests. However, be aware that making a document 1176 into a WG document changes the formal ownership and responsibility 1177 from the individual authors to the WG. The initial authors 1178 normally continue being the document editors, unless unusual 1179 circumstances occur. The PAYLOAD WG accepts new RTP payload 1180 formats based on their suitability and document maturity. The 1181 document maturity is a requirement to ensure that there are 1182 dedicated document editors and that there exists a good solution. 1184 Iterative improvements: The updates and review cycles continue 1185 until the draft has reached the level of maturity suitable for 1186 publication. 1188 WG Last Call: A WG Last Call of at least 2 weeks is always 1189 performed for payload formats in the PAYLOAD WG (See Section 7.4 1190 of [RFC2418]). The authors request WG last call for a draft when 1191 they think it is mature enough for publication. The chairs 1192 perform a review to check if they agree with the authors' 1193 assessment. If the chairs agree on the maturity, the WG Last Call 1194 is announced on the WG mailing list. If there are issues raised, 1195 these need to be addressed with an updated draft version. For any 1196 more substantial updates of the draft, a new WG last call is 1197 announced for the updated version. Minor changes, like editorial 1198 fixes, can be progressed without an additional WG last call. 1200 Publication Requested: For WG documents the chairs request 1201 publication of the draft, after it has passed WG Last Call. After 1202 this, the approval and publication process described in BCP 9 1203 [BCP9] is performed. The status after the publication has been 1204 requested can be tracked using the IETF data tracker [TRACKER]. 1205 Documents do not expire as they normally do after publication has 1206 been requested, so authors do not have to issue keep-alive 1207 updates. In addition, any submission of document updates requires 1208 the approval of WG chair(s). The authors are commonly asked to 1209 address comments or issues raised by the IESG. The authors also 1210 do one last review of the document immediately prior to its 1211 publication as an RFC to ensure that no errors or formatting 1212 problems have been introduced during the publication process. 1214 4.1.2. WG meetings 1216 WG meetings are for discussing issues, not presentations. This means 1217 that most RTP payload formats should never need to be discussed in a 1218 WG meeting. RTP payload formats that would be discussed are either 1219 those with controversial issues that failed to be resolved on the 1220 mailing list, or those including new design concepts worth a general 1221 discussion. 1223 There exists no requirement to present or discuss a draft at a WG 1224 meeting before it becomes published as an RFC. Thus, even authors 1225 who lack the possibility to go to WG meetings should be able to 1226 successfully specify an RTP payload format in the IETF. WG meetings 1227 may become necessary only if the draft gets stuck in a serious debate 1228 that cannot easily be resolved. 1230 4.1.3. Draft Naming 1232 To simplify the work of the PAYLOAD WG chairs and its WG members a 1233 specific draft file naming convention shall be used for RTP payload 1234 formats. Individual submissions shall be named draft--payload-rtp--. The WG 1236 documents shall be named according to this template: draft-ietf- 1237 payload-rtp--. The inclusion of "payload" 1238 in the draft file name ensures that the search for "payload-" will 1239 find all PAYLOAD related drafts. Inclusion of "rtp" tells us that it 1240 is an RTP payload format draft. The descriptive name should be as 1241 short as possible while still describing what the payload format is 1242 for. It is recommended to use the media format or codec acronym. 1243 Please note that the version must start at 00 and is increased by one 1244 for each submission to the IETF secretary of the draft. No version 1245 numbers may be skipped. For more details on IETF draft naming please 1246 see Section 7 of [ID-GUIDE]. 1248 4.1.4. Writing Style 1250 When writing an IETF draft for an RTP payload format one should 1251 observe some few considerations (that may be somewhat diverging from 1252 the style other IETF documents and/or the media coding spec's author 1253 group may use): 1255 Include Motivations: In the IETF, it is common to include the 1256 motivation for why a particular design or technical choice was 1257 chosen. These are not long statements, a sentence here and there 1258 explaining why suffice. 1260 Use the defined Terminology: There exists defined terminology both 1261 in RTP and in the media codec specification for which the RTP 1262 payload format is designed. A payload format specification needs 1263 to use both to make clear the relation of features and their 1264 functions. It is unwise to introduce or, worse, use without 1265 introduction, terminology that appears to be more accessible to 1266 average readers but may miss certain nuances that the defined 1267 terms imply. An RTP payload format author can assume the reader 1268 to be reasonably familiar with the terminology in the media coding 1269 spec. 1271 Keeping It Simple: The IETF has a history of specifications that are 1272 focused on their main usage. Historically, some RTP Payload 1273 formats have a lot of modes and features, while the actually 1274 deployments have only included the most basic features that had 1275 very clear requirements. Time and effort can be saved by focusing 1276 on only the most important use cases, and keep the solution 1277 simple. An extension mechanism should be provided to enable 1278 backward-compatible extensions, if that is an organic fit. 1280 Normative Requirements: When writing specifications there is 1281 commonly a need to make it clear when something is normative and 1282 at what level. In IETF the most common method is to use "Key 1283 words for use in RFCs to Indicate Requirement Levels" [RFC2119] 1284 that defines the meaning of "MUST", "MUST NOT", "REQUIRED", 1285 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 1286 RECOMMENDED", "MAY", and "OPTIONAL". 1288 4.1.5. How to speed up the process 1290 There a number of ways to lose a lot of time in the above process. 1291 This section discusses what to do and what to avoid. 1293 o Do not update the draft only for the meeting deadline. An update 1294 to each meeting automatically limits the draft to three updates 1295 per year. Instead, ignore the meeting schedule and publish new 1296 versions as soon as possible. 1298 o Try to avoid requesting reviews when people are busy, like the few 1299 weeks before a meeting. It is actually more likely that people 1300 have time for them directly after a meeting. 1302 o Perform draft updates quickly. A common mistake is that the 1303 authors let the draft slip. By performing updates to the draft 1304 text directly after getting resolution on an issue, things speed 1305 up. This minimizes the delay that the author has direct control 1306 over. The time taken for reviews, responses from area directors 1307 and chairs, etc. can be much harder to speed up. 1309 o Do not fail to take human nature into account. It happens that 1310 people forget or need to be reminded about tasks. Send a kind 1311 reminder to the people you are waiting for if things take longer 1312 than expected. Ask people to estimate when they expect to fulfill 1313 the requested task. 1315 o Ensure there is enough review. It is common that documents take a 1316 long time and many iterations because not enough review is 1317 performed in each iteration. To improve the amount of review you 1318 get on your own document, trade review time with other document 1319 authors. Make a deal with some other document author that you 1320 will review their draft if they review yours. Even inexperienced 1321 reviewers can help with language, editorial or clarity issues. 1322 Try also approaching the more experienced people in the WG and 1323 getting them to commit to a review. The WG chairs cannot, even if 1324 desirable, be expected to review all versions. Due to workload 1325 the chairs may need to concentrate on key points in a draft 1326 evolution, like initial submissions, checking if a draft is ready 1327 to become a WG document or ready for WG last call. 1329 4.2. Other Standards Bodies 1331 Other standards bodies may define RTP payloads in their own 1332 specifications. When they do this they are strongly recommended to 1333 contact the PAYLOAD WG chairs and request review of the work. It is 1334 recommended that at least two review steps are performed. The first 1335 should be early in the process when more fundamental issues can be 1336 easily resolved without abandoning a lot of effort. Then when 1337 nearing completion, but while it is still possible to update the 1338 specification, a second review should be scheduled. In that pass the 1339 quality can be assessed and hopefully no updates will be needed. 1340 Using this procedure can avoid both conflicting definitions and 1341 serious mistakes, like breaking certain aspects of the RTP model. 1343 RTP payload Media Types may be registered in the standards tree by 1344 other standard bodies. The requirements on the organization are 1345 outlined in the media types registration document [RFC4855] and 1346 [RFC6838]). This registration requires a request to the IESG, which 1347 ensures that the filled-in registration template is acceptable. To 1348 avoid last-minute problems with these registrations the registration 1349 template must be sent for review both to the PAYLOAD WG and the media 1350 types list (ietf-types@iana.org) and is something that should be 1351 included in the IETF reviews of the payload format specification. 1353 4.3. Proprietary and Vendor Specific 1355 Proprietary RTP payload formats are commonly specified when the real- 1356 time media format is proprietary and not intended to be part of any 1357 standardized system. However, there are reasons why also proprietary 1358 formats should be correctly documented and registered: 1360 o Usage in a standardized signalling environment such as SIP/SDP. 1361 RTP needs to be configured with the RTP profiles, payload formats 1362 and their payload types being used. To accomplish this it is 1363 desirable to have registered media type names to ensure that the 1364 names do not collide with those of other formats. 1366 o Sharing with business partners. As RTP payload formats are used 1367 for communication, situations often arise where business partners 1368 would like to support a proprietary format. Having a well written 1369 specification of the format will save time and money for both 1370 parties, as interoperability will be much easier to accomplish. 1372 o To ensure interoperability between different implementations on 1373 different platforms. 1375 To avoid name collisions there is a central registry keeping tracks 1376 of the registered Media Type names used by different RTP payload 1377 formats. When it comes to proprietary formats they should be 1378 registered in the vendor's own tree. All vendor specific 1379 registrations use sub-type names that start with "vnd.". 1380 Names in the vendor's own tree are not required to be registered with 1381 IANA. However registration [RFC6838] is recommended if the Media 1382 Type is used at all in public environments. 1384 If interoperability at the RTP level is desired, a payload type 1385 specification should be standardized in the IETF following the 1386 process described above. The IETF does not require full disclosure 1387 of the codec when defining an RTP payload format to carry that codec, 1388 but a description must be provided that is sufficient to allow the 1389 IETF to judge whether the payload format is well designed. The Media 1390 Type identifier assigned to a standardized payload format of this 1391 sort will lie in the standards tree rather than the vendor tree. 1393 4.4. Joint Development of Media Coding Specification and RTP Payload 1394 Format 1396 In the last decade there have been a few cases where the media codec 1397 and the associated RTP payload format have been developed 1398 concurrently and jointly. Developing the two specs not only 1399 concurrently but also jointly, in close cooperation with the group 1400 developing the media codec, allows to leverage the benefits joint 1401 source/channel coding can provide. Doing so has historically 1402 resulted in well performing payload formats and in success of both 1403 media coding spec and associated RTP payload format. Insofar, 1404 whenever the opportunity presents it, it may be useful to closely 1405 keep the media coding group in the loop (through appropriate liaison 1406 means whatever those may be) and influence the media coding spec to 1407 be RTP friendly. One example for such a media coding spec is H.264, 1408 where the RTP payload header co-serves as the H.264 NAL unit header 1409 and vice versa, and is documented in both specs. 1411 5. Designing Payload Formats 1413 The best summary of payload format design is KISS (Keep It Simple, 1414 Stupid). A simple payload format is easier to review for 1415 correctness, easier to implement, and has low complexity. 1416 Unfortunately, contradictory requirements sometimes make it hard to 1417 do things simply. Complexity issues and problems that occur for RTP 1418 payload formats are: 1420 Too many configurations: Contradictory requirements lead to the 1421 result that one configuration is created for each conceivable 1422 case. Such contradictory requirements are often between 1423 functionality and bandwidth. This outcome has two big 1424 disadvantages; First all configurations need to be implemented. 1426 Second, the user application must select the most suitable 1427 configuration. Selecting the best configuration can be very 1428 difficult and in negotiating applications, this can create 1429 interoperability problems. The recommendation is to try to select 1430 a very limited set of configurations (preferably one) that perform 1431 well for the most common cases and are capable of handling the 1432 other cases, but maybe not that well. 1434 Hard to implement: Certain payload formats may become difficult to 1435 implement both correctly and efficiently. This needs to be 1436 considered in the design. 1438 Interaction with general mechanisms: Special solutions may create 1439 issues with deployed tools for RTP, such as tools for more robust 1440 transport of RTP. For example, a requirement for a non-broken 1441 sequence number space creates issues for mechanisms relying on 1442 payload type switching interleaving media-independent resilience 1443 within a stream. 1445 5.1. Features of RTP Payload Formats 1447 There are a number of common features in RTP payload formats. There 1448 is no general requirements to support these features; instead, their 1449 applicability must be considered for each payload format. It may in 1450 fact be that certain features are not even applicable. 1452 5.1.1. Aggregation 1454 Aggregation allows for the inclusion of multiple application data 1455 units (ADUs) within the same RTP payload. This is commonly supported 1456 for codecs that produce ADUs of sizes smaller than the IP MTU. One 1457 reason for the use of aggregation is the reduction of header overhead 1458 (IP/UDP/RTP headers). When setting into relation the ADU size and 1459 the MTU size, do remember that the MTU may be significantly larger 1460 than 1500 bytes. An MTU of 9000 bytes is available today and an MTU 1461 of 64k may be available in the future. Many speech codecs have the 1462 property of ADUs of a few fixed sizes. Video encoders may generally 1463 produce ADUs of quite flexible sizes. Thus the need for aggregation 1464 may be less. But some codecs produces small ADUs mixed with large, 1465 for example H.264 SEI messages. Sending individual SEI message in 1466 separate packets are not efficient compared to combing the with other 1467 ADUs. Also, some small ADUs are, within the media domain, 1468 semantically coupled to the larger ADUs (for example in-band 1469 parameter sets in H.264 [RFC6184]). In such cases, aggregation is 1470 sensible even if not required from a payload/header overhead 1471 viewpoint. There also exist cases when the ADUs are pre-produced and 1472 can't be adopted to a specific networks MTU. Instead their 1473 packetization needs to be adopted to the network. All above factors 1474 should be taken into account when deciding of the inclusion of 1475 aggregation, and weighting its benefits against the complexity of 1476 defining them (which can be significant especially when aggregation 1477 is performed over ADUs with different playback times). 1479 The main disadvantage of aggregation beyond implementation complexity 1480 is the extra delay introduced (due to buffering until a sufficient 1481 number of ADUs have been collected at the sender) and reduced 1482 robustness against packet loss. Aggregation also introduces 1483 buffering requirements at the receiver. 1485 5.1.2. Fragmentation 1487 If the real-time media format has the property that it may produce 1488 ADUs that are larger than common MTU sizes then fragmentation support 1489 should be considered. An RTP Payload format may always fall back on 1490 IP fragmentation, however, as discussed in RFC 2736 this has some 1491 drawbacks. The perhaps most important reason to avoid IP 1492 fragmentation is that IP fragmented packets commonly are discarded in 1493 the network, especially by Network Address Translators or Firewalls. 1494 The usage of RTP payload format-level fragmentation allows for more 1495 efficient usage of RTP packet loss recovery mechanisms. It may also 1496 in some cases also allow better usage of partial ADUs by doing media 1497 specific fragmentation at media specific boundaries. In use cases 1498 where the ADUs are pre-produced and can't be adopted to the network's 1499 MTU size, support for fragmentation can be crucial. 1501 5.1.3. Interleaving and Transmission Re-Scheduling 1503 Interleaving has been implemented in a number of payload formats to 1504 allow for less quality reduction when packet loss occurs. When 1505 losses are bursty and several consecutive packets are lost, the 1506 impact on quality can be quite severe. Interleaving is used to 1507 convert that burst loss to several spread-out individual packet 1508 losses. It can also be used when several ADUs are aggregated in the 1509 same packets. A loss of an RTP packet with several ADUs in the 1510 payload has the same effect as a burst loss if the ADUs would have 1511 been transmitted in individual packets. To reduce the burstiness of 1512 the loss, the data present in an aggregated payload may be 1513 interleaved, thus spread the loss over a longer time period. 1515 A requirement for doing interleaving within an RTP payload format is 1516 the aggregation of multiple ADUs. For formats that do not use 1517 aggregation there is still a possibility of implementing a 1518 transmission order re-scheduling mechanism. That has the effect that 1519 the packets transmitted consecutively originate from different points 1520 in the media stream. This can be used to mitigate burst losses, 1521 which may be useful if one transmits packets at frequent intervals. 1523 However it may also be used to transmit more significant data earlier 1524 in combination with RTP retransmission to allow for more graceful 1525 degradation and increased possibility to receive the most important 1526 data, e.g., intra frames of video. 1528 The drawback of interleaving is the significantly increased 1529 transmission buffering delay, making it less useful for low-delay 1530 applications. It may also create significant buffering requirements 1531 on the receiver. That buffering is also problematic as it is usually 1532 difficult to indicate when a receiver may start consume data and 1533 still avoid buffer under run caused by the interleaving mechanism 1534 itself. Transmission re-scheduling is only useful in a few specific 1535 cases, as in streaming with retransmissions. The potential gains 1536 must be weighed against the complexity of these schemes. 1538 5.1.4. Media Back Channels 1540 A few RTP payload formats have implemented back channels within the 1541 media format. Those have been for specific features, like the AMR 1542 [RFC4867] codec mode request (CMR) field. The CMR field is used in 1543 the operation of gateways to circuit-switched voice to allow an IP 1544 terminal to react to the circuit-switched network's need for a 1545 specific encoder mode. A common motivation for media back channels 1546 is the need to have signalling in direct relation to the media or the 1547 media path. 1549 If back channels are considered for an RTP payload format they should 1550 be for a specific requirements which cannot be easily satisfied by 1551 more generic mechanisms within RTP or RTCP. 1553 5.1.5. Media Scalability 1555 Some codecs support various types of media scalability, i.e. some 1556 data of a media stream may be removed to adapt the media's 1557 properties, such as bitrate and quality. The adaptation may be 1558 applied in the following dimensions of the media: 1560 Temporal: For most video codecs it is possible to adapt the frame 1561 rate without any specific definition of a temporal scalability 1562 mode, e.g., for H.264 [RFC6184]. In these cases the sender change 1563 which frames it delivers and the RTP timestamp makes it clear the 1564 frame interval and each frames relative capture time. H.264 1565 Scalable Video Coding (SVC) [RFC6190] has more explicit support 1566 for temporal scalability. 1568 Spatial: Video codecs supporting scalability may adapt the 1569 resolution, e.g., in SVC [RFC6190]. 1571 Quality: The quality of the media stream may be scaled by adapting 1572 the accuracy of the coding process, as, e.g. possible with Signal 1573 to Noise Ratio (SNR) fidelity scalability of SVC [RFC6190]. 1575 At the time of writing this document, codecs that support scalability 1576 have a bit of revival. It has been realized that getting the 1577 required functionality for supporting the features of the media 1578 stream into the RTP framework is quite challenging. One of the 1579 recent examples for layered and scalable codecs is Scalable Video 1580 Coding [RFC6190] (SVC). 1582 SVC is a good example for a payload format supporting media 1583 scalability features, which have been in its basic form already 1584 included in RTP. A layered codec supports the dropping of data parts 1585 of a media stream, i.e., RTP packets may be not transmitted or 1586 forwarded to a client in order to adapt the media stream rate as well 1587 as the media stream quality, while still providing a decodable subset 1588 of the media stream to a client. One example for using the 1589 scalability feature may be an RTP Mixer (Multipoint Control Unit) 1590 which controls the rate and quality sent out to participants in a 1591 communication based on dropping RTP packets or removing part of the 1592 payload. Another example may be a transport channel which allows for 1593 differentiation in Quality of Service (QoS) parameters based on RTP 1594 sessions in a multicast session. In such a case, the more important 1595 packets of the scalable media stream (base layer) may get better QoS 1596 parameters, then the less important packets (enhancement layer) in 1597 order to provide some kind of graceful degradation. The scalability 1598 features required for allowing an adaptive transport as described in 1599 the two examples above are based on RTP multiplexing in order to 1600 identify the packets to be dropped or transmitted/forwarded. The 1601 multiplexing features defined for Scalable Video Coding [RFC6190] 1602 are: 1604 single session transmission (SST), where all media layers of the 1605 media are transported as single source (SSRC) in a single RTP 1606 session; as well as 1608 multi session transmission (MST), which should more accurately be 1609 called multi stream transmission, where different media layers or 1610 a set of media layers are transported in different RTP streams, 1611 i.e., using multiple sources (SSRCs). 1613 In the first case (SST), additional in-band as well as out-of-band 1614 signaling is required in order to allow identification of packets 1615 belonging to a specific media layer. Furthermore, an adaptation of 1616 the media stream requires dropping of specific packets in order to 1617 provide the client with a compliant media stream. In case of using 1618 encryption, it is typically required for an adapting network device 1619 to be in the security context to allow packet dropping and providing 1620 an intact RTP session to the client. This typically requires the 1621 network device to be an RTP mixer. 1623 In general having a media unaware network device dropping excessive 1624 packets will be more problematic than having a Media Aware Network 1625 Entity (MANE). First is the need to understand the media format and 1626 know which ADUs or payloads that belongs to the layers, that no other 1627 layer will be dependent on after the dropping. Secondly, if the MANE 1628 can work as RTP mixer or translator it can rewrite the RTP and RTCP 1629 in such a way that the receiver will not suspect non-intentional RTP 1630 packet losses needing repair actions. This as the receiver can't 1631 determine if a lost packet was an important base layer packet or one 1632 of the less important extension layers. 1634 In the second case (MST), the RTP packet streams can be sent using a 1635 single or multiple RTP sessions, and thus transport flows, e.g., on 1636 different multicast groups. Transmitting the streams in different 1637 RTP sessions, then the out-of-band signaling typically provides 1638 enough information to identify the media layers and its properties. 1639 The decision for dropping packets is based on the Network Address 1640 which identifies the RTP session to be dropped. In order to allow 1641 correct data provisioning to a decoder after reception from different 1642 sessions, data re-alignment mechanisms are required. In some cases, 1643 existing generic tools as described below can be employed to enable 1644 such re-alignment, and when those generic mechanisms are sufficient, 1645 they should be used. For example, Rapid Sync for RTP flows 1646 [RFC6051], uses existing RTP mechanisms, i.e. the NTP timestamp, to 1647 ensure timely inter-session synchronization. Another is the 1648 signaling feature for indicating dependencies of RTP sessions in SDP, 1649 as defined in the Media Decoding Dependency Grouping in SDP 1650 [RFC5583]. 1652 Using MST within a single RTP session is also possible and allows 1653 stream level handling instead of looking deeper into the packets by a 1654 MANE. However, transport flow level properties will be the same 1655 unless packet based mechanisms like DiffServ is used. 1657 When QoS settings, e.g., DiffServ markings, are used to ensure that 1658 the extension layers are dropped prior the base layer the receiving 1659 end-point has the benefit in MST to know which layer or set of layers 1660 the missing packets belong as it will be bound to different RTP 1661 sessions or RTP packet streams (SSRCs), thus explicitly indicating 1662 the importance of the loss. 1664 5.1.6. High Packet Rates 1666 Some media codecs require high packet rates, and in these cases the 1667 RTP sequence number wraps too quickly. As rule of thumb, it must not 1668 be possible to wrap the sequence number space within at least three 1669 RTCP reporting intervals. As the reporting interval can vary widely 1670 due to configuration and session properties, and also must take into 1671 account the randomization of the interval, one can use the TCP 1672 maximum segment lifetime (MSL), i.e. 2 minutes, in ones 1673 consideration. If earlier wrapping may occur then the payload format 1674 should specify an extended sequence number field to allow the 1675 receiver to determine where a specific payload belongs in the 1676 sequence, even in the face of extensive reordering. The RTP payload 1677 format for uncompressed video [RFC4175] can be used as an example for 1678 such a field. 1680 RTCP is also affected by high packet rates. For RTCP mechanism that 1681 do not use extended counters there is significant risk that they wrap 1682 multiple times between RTCP reporting or feedback, thus producing 1683 uncertainty about which packet(s) are referenced. The payload 1684 designer can't effect the RTCP packet formats used and their design, 1685 but can note this considerations when configuring RTCP bandwidth and 1686 reporting intervals to avoid to wrapping issues. 1688 5.2. Selecting Timestamp Definition 1690 The RTP Timestamp is an important part and has two design choices 1691 associated with it. The first is the definition that determines what 1692 the timestamp value in a particular RTP packet will be, the second is 1693 which timestamp rate should be used. 1695 The timestamp definition needs to explicitly define what the 1696 timestamp value in the RTP packet represent for a particular payload 1697 format. Two common definitions are used; for discretely sampled 1698 media, like video frames, the sampling time of the earliest included 1699 video frame which the data represent (fully or partially) is used; 1700 for continuous media like audio, the sampling time of the earliest 1701 sample which the payload data represent. There exist cases where 1702 more elaborate or other definitions are used. 1704 RTP payload formats with a timestamp definition which results in no 1705 or little correlation between the media time instance and its 1706 transmission time cause the RTCP jitter calculation to become 1707 unusable due to the errors introduced on the sender side. A common 1708 example is a payload format for a video codec where the RTP timestamp 1709 represents the capture time of the video frame, but frames are large 1710 enough that multiple RTP packets need to be sent for each frame 1711 spread across the framing interval. It should be noted if the 1712 payload format has this property or not. 1714 A RTP payload format also needs to define what timestamp rates, or 1715 clock rates (as it is also called), that may be used. Depending on 1716 the RTP payload format this may be a single rate or multiple ones or 1717 theoretically any rate. So what needs to be considered when 1718 selecting rate? 1720 The rate needs be selected so that one can determine where in the 1721 time line of the media a particular sample (e.g., individual audio 1722 sample, or video frame) or set of samples (e.g., audio frames) 1723 belong. To enable correct synchronization of this data with previous 1724 frames, including over periods of discontinuous transmission or 1725 irregularities. 1727 For audio it is common to require audio sample accuracy. Thus one 1728 commonly selects the input sampling rate as the timestamp rate. This 1729 can, however, be challenging for audio codecs that support multiple 1730 different sampling frequencies, either as codec input or being used 1731 internally but effecting output, for example frame duration. 1732 Depending on how one expects to use these different sampling rates 1733 one can allow multiple timestamp rates, each matching a particular 1734 codec input or sampling rate. However, due to the issues with using 1735 multiple different RTP timestamp rates for the same source (SSRC) 1736 [I-D.ietf-avtext-multiple-clock-rates] this should be avoided if one 1737 expects to need to switch between modes. 1739 An alternatives then is to find a common denominator frequency 1740 between the different modes, e.g. OPUS [I-D.ietf-payload-rtp-opus] 1741 that uses 48 KHz. If the different modes uses or can use a common 1742 input/output frequency then selecting this also needs to be 1743 considered. However, it is important to consider all aspects as the 1744 case of AMR-WB+ [RFC4352] illustrates. AMR-WB+'s RTP timestamp rate 1745 has the very unusual value of 72 kHz, despite the fact that output 1746 normally is at a sample rate of 48kHz. The design is motivated by 1747 the media codec's production of a large range of different frame 1748 lengths in time perspective. The 72 kHz timestamp rate is the 1749 smallest found value that would make all of the frames the codec 1750 could produce result in an integer frame length in RTP timestamp 1751 ticks. This way, a receiver can always correctly place the frames in 1752 relation to any other frame, even when the frame length changes. The 1753 downside is that the decoder outputs for certain frame lengths is in 1754 fact partial samples. The result is that the output in samples from 1755 the codec will vary from frame to frame, potentially making 1756 implementation more difficult. 1758 Video codecs have commonly been using 90 kHz, the reason is this is a 1759 common denominator between the usually used frame rates such as 24, 1760 25, 30, 50 and 60, and NTSC's odd 29.97 Hz. There does, however, 1761 exist at least one exception in the payload format for SMPTE 292M 1762 video [RFC3497] that uses a clock rate of 148.5 MHz. The reason here 1763 is that the timestamp then identify the exact start sample within a 1764 video frame. 1766 Timestamp rates below 1000 Hz are not appropriate because it will 1767 cause a too low resolution in the RTCP measurements that are 1768 expressed in RTP timestamps. This is the main reason that the text 1769 RTP payload formats, like T.140 [RFC4103] uses 1000 Hz. 1771 6. Noteworthy Aspects in Payload Format Design 1773 This section provides a few examples of payload formats that are 1774 worth noting for good or bad design in general or specific details of 1775 their design. 1777 6.1. Audio Payloads 1779 The AMR [RFC4867], AMR-WB [RFC4867], EVRC [RFC3558], SMV [RFC3558] 1780 payload formats are all quite similar. They are all for frame-based 1781 audio codecs and use a table of content structure. Each frame has a 1782 table of contents entry that indicates the type of the frame and if 1783 additional frames are present. This is quite flexible but produces 1784 unnecessary overhead if the ADU is of fixed size and if when 1785 aggregating multiple ADUs they are commonly of the same type. In 1786 that case a solution like that in AMR-WB+ [RFC4352] may be more 1787 suitable. 1789 The RTP payload format for MIDI [RFC6295] contains some interesting 1790 features. MIDI is an audio format sensitive to packet losses, as the 1791 loss of a "note off" command will result in a note being stuck in an 1792 "on" state. To counter this a recovery journal is defined that 1793 provides a summarized state that allows the receiver to recover from 1794 packet losses quickly. It also uses RTCP and the reported highest 1795 sequence number to be able to prune the state the recovery journal 1796 needs to contain. These features appear limited in applicability to 1797 media formats that are highly stateful and primarily use symbolic 1798 media representations. 1800 There exist a security concern with variable bit-rate audio and 1801 speech codecs that changes their payload length based on the input 1802 data. This can leak information, especially in structured 1803 communication like speech recognition prompt service that asks people 1804 to enter information verbally. This issue also exists to some degree 1805 for discontinuous transmission as that allows the length of phrases 1806 to be determined. The issue is further discussed in Guidelines for 1807 the Use of Variable Bit Rate Audio with Secure RTP [RFC6562] which 1808 needs to be read by anyone writing an RTP payload format for an audio 1809 or speech codec with these properties. 1811 6.2. Video 1813 The definition of RTP payload formats for video has seen an evolution 1814 from the early ones such as H.261 [RFC4587] towards the latest for 1815 VP8 [I-D.ietf-payload-vp8] and H.265/HEVC 1816 [I-D.ietf-payload-rtp-h265]. 1818 The H.264 RTP payload format [RFC3984] can be seen as a smorgasbord 1819 of functionality, some of it such as the interleaving being pretty 1820 advanced. The reason for this was to ensure that the majority of 1821 applications considered by the ITU-T and MPEG that can be supported 1822 by RTP are indeed supported. This has created a payload format that 1823 rarely is fully implemented. Despite that, no major issues with 1824 interoperability has been reported with one exception namely the 1825 offer/answer and parameter signalling, which resulted in a revised 1826 specification [RFC6184]. However, complaints about its complexity 1827 are common. 1829 The RTP payload format for uncompressed video [RFC4175] must be 1830 mentioned in this context as it contains a special feature not 1831 commonly seen in RTP payload formats. Due to the high bit-rate and 1832 thus packet rate of uncompressed video (gigabits rather than megabits 1833 per second) the payload format includes a field to extend the RTP 1834 sequence number since the normal 16-bit one can wrap in less than a 1835 second. [RFC4175] also specifies a registry of different color sub- 1836 samplings that can be re-used in other video RTP payload formats. 1838 Both, the H.264 and the uncompressed video format enable the 1839 implementer to fulfill the goals of application level framing, i.e. 1840 each individual RTP Packet's payload can be independently decoded and 1841 its content used to create a video frame (or part of) and that 1842 irrespective of whether preceding packets has been lost (See 1843 Section 4) [RFC2736]. For uncompressed this is straightforward as 1844 each pixel is independently represented from others and its location 1845 in the video frame known. H.264 is more dependent on the actual 1846 implementation, configuration of the video encoder and usage of the 1847 RTP payload format. 1849 The common challenge with video is that in most cases a single 1850 compressed video frame don't fit into a single IP packet. Thus, the 1851 compressed representation of a video frame needs to be split over 1852 multiple packets. This can be done unintelligently with a basic 1853 payload level fragmentation method or more integrated by interfacing 1854 with the encoder's possibilities to create ADUs that are independent 1855 and fit the MTU for the RTP packet. The latter is more robust and 1856 commonly recommended unless strong packet loss mechanisms are used 1857 and sufficient delay budget for the repair exist. Commonly both 1858 payload level fragmentation as well as explaining how tailored ADUs 1859 can be created are needed in a video payload format. Also the 1860 handling of crucial meta data, like H.264 Parameter Sets needs to be 1861 considered as decoding is not possible without receiving the used 1862 parameter sets. 1864 6.3. Text 1866 Only a single format text format has been standardized in the IETF, 1867 namely T.140 [RFC4103]. The 3GPP Timed Text format [RFC4396] should 1868 be considered to be text, even though in the end was registered as a 1869 video format. It was registered in that part of the tree because it 1870 deals with decorated text, usable for subtitles and other 1871 embellishments of video. However, it has many of the properties that 1872 text formats generally have. 1874 The RTP payload format for T.140 was designed with high reliability 1875 in mind as real-time text commonly is an extremely low bit-rate 1876 application. Thus, it recommends the use of RFC 2198 with many 1877 generations of redundancy. However, the format failed to provide a 1878 text block specific sequence number and relies instead of the RTP one 1879 to detect loss. This makes detection of missing text blocks 1880 unnecessarily difficult and hinders deployment with other robustness 1881 mechanisms that would involve switching the payload type as that may 1882 result in erroneous error marking in the T.140 text stream. 1884 6.4. Application 1886 The application content type contains at the time of writing two 1887 media types that aren't RTP transport robustness tools such as FEC 1888 [RFC3009][RFC5109][RFC6015][RFC6682] and RTP retransmission 1889 [RFC4588]. 1891 The first one is H.224 [RFC4573] which enables far end camera control 1892 over RTP. This is not an IETF defined RTP format, only an IETF 1893 performed registration. 1895 The second one is the RTP Payload Format for Society of Motion 1896 Picture and Television Engineers (SMPTE) ST 336 Encoded Data 1897 [RFC6597] which carries generic key length value (KLV) triplets. 1898 These pairs may contain arbitrary binary meta data associated with 1899 video transmissions. It has a very basic fragmentation mechanism 1900 requiring packet loss free reception not only of the triplet itself 1901 but also one packet before and after the sequence of fragmented KLV 1902 triplet to ensure correct reception. Specific KLV triplets 1903 themselves may have recommendation on how to handle non-complete ones 1904 allowing the use and repair of them. In general the application 1905 using such a mechanism must be robust to errors and also use some 1906 combination of application level repetition, RTP level transport 1907 robustness tools and network level requirements to achieve low levels 1908 of packet loss rates and repair of KLV triplets. 1910 The application top media type (application/) should be 1911 considered to be used when the payload format defined is not clearly 1912 matching any of the existing media types (audio, video or text) or 1913 are of a generic nature. However, existing limitations in for 1914 example SDP, has resulted in that generic mechanisms normally are 1915 registered in all media types to be possible to have associated with 1916 any existing media types in an RTP session. 1918 7. Important Specification Sections 1920 A number of sections in the payload format draft need special 1921 consideration. These include the Security and IANA Considerations 1922 sections that are required in all drafts. Payload formats are also 1923 strongly recommended to have the media format description and 1924 congestion control considerations. The included RTP Payload format 1925 template (Appendix A) contains draft text for some of these sections. 1927 7.1. Media Format Description 1929 The intention of this section is to enable reviewers and other 1930 readers to get an overview of the capabilities and major properties 1931 of the media format. It should be kept short and concise and is not 1932 a complete replacement for reading the media format specification. 1934 The actual specification of the RTP payload format generally uses 1935 normative references to the codec format specification to define how 1936 codec data elements are included in the payload format. This 1937 normative reference can be to anything that have sufficient stability 1938 for a normative reference. There exist no formal requirement on the 1939 codec format specification being publicly available or free to 1940 access. However, it significantly helps in the review process if 1941 that specification is made available to any reviewer. There exist 1942 RTP payload format RFCs for open source project specifications as 1943 well as an individual company's proprietary format, and a large 1944 variety of standards development organizations or industrial forums. 1946 7.2. Security Considerations 1948 All Internet drafts require a Security Considerations section. The 1949 security considerations section in an RTP payload format needs to 1950 concentrate on the security properties this particular format has. 1951 Some payload formats have very few specific issues or properties and 1952 can fully fall back on the security considerations for RTP in general 1953 and those of the profile being used. Because those documents are 1954 always applicable, a reference to these is normally placed first in 1955 the security considerations section. There is suggested text in the 1956 template below. 1958 The security issues of confidentiality, integrity protection, replay 1959 protection and source authentication are common issue for all payload 1960 formats. These should be solved by mechanisms external to the 1961 payload and do not need any special consideration in the payload 1962 format except for an reminder on these issues. There exist 1963 exceptions, such as payload formats that includes security 1964 functionality, like ISMAcrypt [ISMACrypt2]. Reasons for this 1965 division is further documented in "Securing the RTP Protocol 1966 Framework: Why RTP Does Not Mandate a Single Media Security Solution" 1967 [I-D.ietf-avt-srtp-not-mandatory]. For a survey of available 1968 mechanisms to meet these goals, review "Options for Securing RTP 1969 Sessions" [I-D.ietf-avtcore-rtp-security-options]. This also 1970 includes key-exchange mechanisms for the security mechanisms, which 1971 can be both integrated or separate. The choice of key-management can 1972 have significant impact on the security properties of the RTP based 1973 application. Suitable stock text to inform people about this is 1974 included in the template. 1976 Potential security issues with an RTP payload format and the media 1977 encoding that need to be considered if they are applicable: 1979 1. The decoding of the payload format or its media results in 1980 substantial non-uniformity, either in output or in complexity to 1981 perform the decoding operation. For example a generic non- 1982 destructive compression algorithm may provide an output of almost 1983 an infinite size for a very limited input, thus consuming memory 1984 or storage space out of proportion with what the receiving 1985 application expected. Such inputs can cause some sort of 1986 disruption, i.e., a denial of service attack on the receiver side 1987 by preventing that host from performing usable work. Certain 1988 decoding operations may also vary in the amount of processing 1989 needed to perform those operations depending on the input. This 1990 may also be a security risk if it is possible to raise processing 1991 load significantly above nominal simply by designing a malicious 1992 input sequence. If such potential attacks exist, this must be 1993 made clear in the security considerations section to make 1994 implementers aware of the need to take precautions against such 1995 behavior. 1997 2. The inclusion of active content in the media format or its 1998 transport. "Active content" means scripts etc. that allow an 1999 attacker to perform potentially arbitrary operations on the 2000 receiver. Most active contents has limited possibility to access 2001 the system or perform operations outside a protected sandbox. 2002 RFC 4855 [RFC4855] has a requirement that it be noted in the 2003 media types registration if the payload format contains active 2004 content or not. If the payload format has active content it is 2005 strongly recommended that references to any security model 2006 applicable for such content are provided. A boilerplate text for 2007 "no active content" is included in the template. This must be 2008 changed if the format actually carries active content. 2010 3. Some media formats allow for the carrying of "user data", or 2011 types of data which are not known at the time of the 2012 specification of the payload format. Such data may be a security 2013 risk and should be mentioned. 2015 4. Audio or Speech codecs supporting variable bit-rate based on 2016 audio/speech input or having discontinuous transmission support 2017 must consider the issues discussed in Guidelines for the Use of 2018 Variable Bit Rate Audio with Secure RTP [RFC6562]. 2020 Suitable stock text for the security considerations section is 2021 provided in the template in the appendix. However, authors do need 2022 to actively consider any security issues from the start. Failure to 2023 address these issues may block approval and publication. 2025 7.3. Congestion Control 2027 RTP and its profiles do discuss congestion control. There is ongoing 2028 work in the IETF with both a basic circuit breaker mechanism 2029 [I-D.ietf-avtcore-rtp-circuit-breakers] using basic RTCP messages 2030 intended to prevent persistent congestion, but also work on more 2031 capable congestion avoidance / bit-rate adaptation mechanism in the 2032 RMCAT WG. 2034 Congestion control is an important issue in any usage in non- 2035 dedicated networks. For that reason it is recommended that all RTP 2036 payload format documents discuss the possibilities that exist to 2037 regulate the bit-rate of the transmissions using the described RTP 2038 payload format. Some formats may have limited or step wise 2039 regulation of bit-rate. Such limiting factors should be discussed. 2041 7.4. IANA Considerations 2043 Since all RTP Payload formats contain a Media Type specification, 2044 they also need an IANA Considerations section. The Media Type name 2045 must be registered and this is done by requesting that IANA register 2046 that media name. When that registration request is written it shall 2047 also be requested that the media type is included under the "RTP 2048 Payload Format media types" list part of the RTP registry (http:// 2049 www.iana.org/assignments/rtp-parameters). 2051 Parameters for the payload format needs to be included in this 2052 registration and can be specified as required or optional ones. The 2053 format of these parameter should be such that they can be included in 2054 the SDP attribute "a=fmtp" string (See Section 6 [RFC4566]) which is 2055 the common mapping. Some parameters, such as "Channel" are normally 2056 mapped to the rtpmap attribute instead, see Section 3 of [RFC4855]. 2058 In addition to the above request for media type registration, some 2059 payload formats may have parameters where in the future new parameter 2060 values need to be added. In these cases a registry for that 2061 parameter must be created. This is done by defining the registry in 2062 the IANA Considerations section. BCP 26 [RFC5226] provides 2063 guidelines to specifying such registries. Care should be taken when 2064 defining the policy for new registrations. 2066 Before specifying a new registry it is worth checking the existing 2067 ones in the IANA "MIME Media Type Sub-Parameter Registries" list. 2068 For example video formats needing a media parameter expressing color 2069 sub-sampling may be able to reuse those defined for video/raw 2070 [RFC4175]. 2072 8. Authoring Tools 2074 This section provides information about some tools that may be used. 2075 Don't feel pressured to follow these recommendations. There exist a 2076 number of alternatives, including the ones listed at http:// 2077 tools.ietf.org/. But these suggestions are worth checking out before 2078 deciding that the field is greener somewhere else. 2080 8.1. Editing Tools 2082 There are many choices when it comes to tools to choose for authoring 2083 Internet drafts. However in the end they need to be able to produce 2084 a draft that conforms to the Internet Draft requirements. If you 2085 don't have any previous experience with authoring Internet drafts 2086 XML2RFC does have some advantages. It helps by create a lot of the 2087 necessary boiler plate in accordance with the latest rules, thus 2088 reducing the effort. It also speeds up publication after approval as 2089 the RFC-editor can use the source XML document to produce the RFC 2090 more quickly. 2092 Another common choice is to use Microsoft Word and a suitable 2093 template, see [RFC5385] to produce the draft and print that to file 2094 using the generic text printer. It has some advantages when it comes 2095 to spell checking and change bars. However, Word may also produce 2096 some problems, like changing formatting, and inconsistent results 2097 between what one sees in the editor and in the generated text 2098 document, at least according to the authors' personal experience. 2100 8.2. Verification Tools 2102 There are a few tools that are very good to know about when writing a 2103 draft. These help check and verify parts of one's work. These tools 2104 can be found at http://tools.ietf.org. 2106 o ID Nits checker. It checks that the boiler plate and some other 2107 things that are easily verifiable by machine are okay in your 2108 draft. Always use it before submitting a draft to avoid direct 2109 refusal in the submission step. 2111 o ABNF Parser and verification. Checks that your ABNF parses 2112 correctly and warns about loose ends, like undefined symbols. 2113 However the actual content can only be verified by humans knowing 2114 what it intends to describe. 2116 o RFC diff. A diff tool that is optimized for drafts and RFCs. For 2117 example it does not point out that the footer and header have 2118 moved in relation to the text on every page. 2120 9. IANA Considerations 2122 This document makes no request of IANA. 2124 Note to RFC Editor: this section may be removed on publication as an 2125 RFC. 2127 10. Security Considerations 2129 As this is an informational document about writing drafts that are 2130 intended to become RFCs there are no direct security considerations. 2131 However, the document does discuss the writing of security 2132 considerations sections and what should be particularly considered 2133 when specifying RTP payload formats. 2135 11. Contributors 2137 The author would like to thank Tom Taylor for the editing pass of the 2138 whole document and contributing text regarding proprietary RTP 2139 payload formats. Thanks also goes to Thomas Schierl who contributed 2140 text regarding Media Scalability features in payload formats 2141 (Section 5.1.5). Stephan Wenger has contributed text on the need to 2142 understand the media coding (Section 3.1) as well as joint 2143 development of payload format with the media coding (Section 4.4). 2145 12. Acknowledgements 2147 The author would like to thank the individuals who have provided 2148 input to this document. These individuals include Richard Barnes, 2149 Ali C. Begen, Bo Burman, Russ Housley, John Lazzaro, Jonathan 2150 Lennox, Colin Perkins, Tom Taylor, Stephan Wenger, and Qin Wu. 2152 13. RFC-Editor Note 2154 RFC-Editor, please correct the BCP references in the below section, 2155 i.e. [BCP9], [BCP25], [BCP78], and [BCP79]. Then please remove this 2156 section prior to publication as RFC. 2158 14. Informative References 2160 [BCP25] Bradner, S., "IETF Working Group Guidelines and 2161 Procedures", BCP 25, RFC 2418, September 1998. 2163 Wasserman, M., "Updates to RFC 2418 Regarding the 2164 Management of IETF Mailing Lists", BCP 25, RFC 3934, 2165 October 2004. 2167 [BCP78] Bradner, S. and J. Contreras, "Rights Contributors Provide 2168 to the IETF Trust", BCP 78, RFC 5378, November 2008. 2170 [BCP79] Bradner, S., "Intellectual Property Rights in IETF 2171 Technology", BCP 79, RFC 3979, March 2005. 2173 Narten, T., "Clarification of the Third Party Disclosure 2174 Procedure in RFC 3979", BCP 79, RFC 4879, April 2007. 2176 [BCP9] Bradner, S., "The Internet Standards Process -- Revision 2177 3", BCP 9, RFC 2026, October 1996. 2179 Dusseault, L. and R. Sparks, "Guidance on Interoperation 2180 and Implementation Reports for Advancement to Draft 2181 Standard", BCP 9, RFC 5657, September 2009. Housley, R., 2182 Crocker, D., and E. Burger, "Reducing the Standards Track 2183 to Two Maturity Levels", BCP 9, RFC 6410, October 2011. 2184 Resnick, P., "Retirement of the "Internet Official 2185 Protocol Standards" Summary Document", BCP 9, RFC 7100, 2186 December 2013. 2188 [BLOAT] Nichols, K. and V. Jacobson, "Controlling Queue Delay", 2189 May 2012, . 2191 ACM Networks Vol. 10 No. 5 - May 2012 2193 [CSP-RTP] Perkins, C., "RTP: Audio and Video for the Internet", June 2194 2003. 2196 [I-D.ietf-avt-srtp-not-mandatory] 2197 Perkins, C. and M. Westerlund, "Securing the RTP Protocol 2198 Framework: Why RTP Does Not Mandate a Single Media 2199 Security Solution", draft-ietf-avt-srtp-not-mandatory-14 2200 (work in progress), October 2013. 2202 [I-D.ietf-avtcore-clksrc] 2203 Williams, A., Gross, K., Brandenburg, R., and H. Stokking, 2204 "RTP Clock Source Signalling", draft-ietf-avtcore- 2205 clksrc-09 (work in progress), December 2013. 2207 [I-D.ietf-avtcore-leap-second] 2208 Gross, K. and R. Brandenburg, "RTP and Leap Seconds", 2209 draft-ietf-avtcore-leap-second-07 (work in progress), 2210 December 2013. 2212 [I-D.ietf-avtcore-multiplex-guidelines] 2213 Westerlund, M., Perkins, C., and H. Alvestrand, 2214 "Guidelines for using the Multiplexing Features of RTP to 2215 Support Multiple Media Streams", draft-ietf-avtcore- 2216 multiplex-guidelines-01 (work in progress), July 2013. 2218 [I-D.ietf-avtcore-rtp-circuit-breakers] 2219 Perkins, C. and V. Singh, "Multimedia Congestion Control: 2220 Circuit Breakers for Unicast RTP Sessions", draft-ietf- 2221 avtcore-rtp-circuit-breakers-03 (work in progress), July 2222 2013. 2224 [I-D.ietf-avtcore-rtp-security-options] 2225 Westerlund, M. and C. Perkins, "Options for Securing RTP 2226 Sessions", draft-ietf-avtcore-rtp-security-options-09 2227 (work in progress), November 2013. 2229 [I-D.ietf-avtext-multiple-clock-rates] 2230 Petit-Huguenin, M. and G. Zorn, "Support for Multiple 2231 Clock Rates in an RTP Session", draft-ietf-avtext- 2232 multiple-clock-rates-11 (work in progress), November 2013. 2234 [I-D.ietf-payload-rtp-h265] 2235 Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. 2236 Hannuksela, "RTP Payload Format for High Efficiency Video 2237 Coding", draft-ietf-payload-rtp-h265-01 (work in 2238 progress), September 2013. 2240 [I-D.ietf-payload-rtp-opus] 2241 Spittka, J., Vos, K., and J. Valin, "RTP Payload Format 2242 for Opus Speech and Audio Codec", draft-ietf-payload-rtp- 2243 opus-01 (work in progress), August 2013. 2245 [I-D.ietf-payload-vp8] 2246 Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 2247 Galligan, "RTP Payload Format for VP8 Video", draft-ietf- 2248 payload-vp8-10 (work in progress), October 2013. 2250 [ID-GUIDE] 2251 Housley, R., "Guidelines to Authors of Internet-Drafts", 2252 January 2014, 2253 . 2255 [ISMACrypt2] 2256 "ISMA Encryption and Authentication, Version 2.0 release 2257 version", November 2007, . 2260 [MACOSFILETYPES] 2261 Apple Knowledge Base Article 55381, 2262 , "Mac OS: File 2263 Type and Creator Codes, and File Formats", 1993. 2265 [RFC-ED] "RFC Editorial Guidelines and Procedures", July 2008, 2266 . 2268 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 2269 Services in the Internet Architecture: an Overview", RFC 2270 1633, June 1994. 2272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2273 Requirement Levels", BCP 14, RFC 2119, March 1997. 2275 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 2276 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 2277 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 2278 September 1997. 2280 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 2281 Streaming Protocol (RTSP)", RFC 2326, April 1998. 2283 [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, 2284 RFC 2360, June 1998. 2286 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 2287 Procedures", BCP 25, RFC 2418, September 1998. 2289 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2290 and W. Weiss, "An Architecture for Differentiated 2291 Services", RFC 2475, December 1998. 2293 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 2294 Headers for Low-Speed Serial Links", RFC 2508, February 2295 1999. 2297 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2298 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2299 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2301 [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format 2302 for Generic Forward Error Correction", RFC 2733, December 2303 1999. 2305 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 2306 Payload Format Specifications", BCP 36, RFC 2736, December 2307 1999. 2309 [RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time 2310 Transport Protocol Management Information Base", RFC 2959, 2311 October 2000. 2313 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2314 Announcement Protocol", RFC 2974, October 2000. 2316 [RFC3009] Rosenberg, J. and H. Schulzrinne, "Registration of 2317 parityfec MIME types", RFC 3009, November 2000. 2319 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 2320 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 2321 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 2322 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 2323 Compression (ROHC): Framework and four profiles: RTP, UDP, 2324 ESP, and uncompressed", RFC 3095, July 2001. 2326 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2327 A., Peterson, J., Sparks, R., Handley, M., and E. 2328 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2329 June 2002. 2331 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2332 with Session Description Protocol (SDP)", RFC 3264, June 2333 2002. 2335 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 2336 "Introduction and Applicability Statements for Internet- 2337 Standard Management Framework", RFC 3410, December 2002. 2339 [RFC3497] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP 2340 Payload Format for Society of Motion Picture and 2341 Television Engineers (SMPTE) 292M Video", RFC 3497, March 2342 2003. 2344 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 2345 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 2346 High Delay, Packet Loss and Reordering", RFC 3545, July 2347 2003. 2349 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2350 Jacobson, "RTP: A Transport Protocol for Real-Time 2351 Applications", STD 64, RFC 3550, July 2003. 2353 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2354 Video Conferences with Minimal Control", STD 65, RFC 3551, 2355 July 2003. 2357 [RFC3558] Li, A., "RTP Payload Format for Enhanced Variable Rate 2358 Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 2359 3558, July 2003. 2361 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 2362 Multicast (SSM)", RFC 3569, July 2003. 2364 [RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. 2365 Romascanu, "Introduction to the Remote Monitoring (RMON) 2366 Family of MIB Modules", RFC 3577, August 2003. 2368 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 2369 Protocol Extended Reports (RTCP XR)", RFC 3611, November 2370 2003. 2372 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2373 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2374 RFC 3711, March 2004. 2376 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 2377 G. Fairhurst, "The Lightweight User Datagram Protocol 2378 (UDP-Lite)", RFC 3828, July 2004. 2380 [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, 2381 M., and D. Singer, "RTP Payload Format for H.264 Video", 2382 RFC 3984, February 2005. 2384 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 2385 Conversation", RFC 4103, June 2005. 2387 [RFC4170] Thompson, B., Koren, T., and D. Wing, "Tunneling 2388 Multiplexed Compressed RTP (TCRTP)", BCP 110, RFC 4170, 2389 November 2005. 2391 [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for 2392 Uncompressed Video", RFC 4175, September 2005. 2394 [RFC4352] Sjoberg, J., Westerlund, M., Lakaniemi, A., and S. Wenger, 2395 "RTP Payload Format for the Extended Adaptive Multi-Rate 2396 Wideband (AMR-WB+) Audio Codec", RFC 4352, January 2006. 2398 [RFC4396] Rey, J. and Y. Matsui, "RTP Payload Format for 3rd 2399 Generation Partnership Project (3GPP) Timed Text", RFC 2400 4396, February 2006. 2402 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2403 Description Protocol", RFC 4566, July 2006. 2405 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 2406 and RTP Control Protocol (RTCP) Packets over Connection- 2407 Oriented Transport", RFC 4571, July 2006. 2409 [RFC4573] Even, R. and A. Lochbaum, "MIME Type Registration for RTP 2410 Payload Format for H.224", RFC 4573, July 2006. 2412 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2413 "Extended RTP Profile for Real-time Transport Control 2414 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2415 2006. 2417 [RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", 2418 RFC 4587, August 2006. 2420 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 2421 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 2422 July 2006. 2424 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2425 Encodings", RFC 4648, October 2006. 2427 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 2428 Series and RFC Editor", RFC 4844, July 2007. 2430 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 2431 Formats", RFC 4855, February 2007. 2433 [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, 2434 "RTP Payload Format and File Storage Format for the 2435 Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband 2436 (AMR-WB) Audio Codecs", RFC 4867, April 2007. 2438 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 2439 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 2441 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 2442 Correction", RFC 5109, December 2007. 2444 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 2445 Real-time Transport Control Protocol (RTCP)-Based Feedback 2446 (RTP/SAVPF)", RFC 5124, February 2008. 2448 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2449 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2450 May 2008. 2452 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2453 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2455 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 2456 Header Extensions", RFC 5285, July 2008. 2458 [RFC5385] Touch, J., "Version 2.0 Microsoft Word Template for 2459 Creating Internet Drafts and RFCs", RFC 5385, February 2460 2010. 2462 [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC 2463 5484, March 2009. 2465 [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 2466 Dependency in the Session Description Protocol (SDP)", RFC 2467 5583, July 2009. 2469 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 2470 Header Compression (ROHC) Framework", RFC 5795, March 2471 2010. 2473 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 2474 Time Protocol Version 4: Protocol and Algorithms 2475 Specification", RFC 5905, June 2010. 2477 [RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity 2478 Forward Error Correction (FEC)", RFC 6015, October 2010. 2480 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 2481 Flows", RFC 6051, November 2010. 2483 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 2484 Payload Format for H.264 Video", RFC 6184, May 2011. 2486 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 2487 "RTP Payload Format for Scalable Video Coding", RFC 6190, 2488 May 2011. 2490 [RFC6295] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for 2491 MIDI", RFC 6295, June 2011. 2493 [RFC6354] Xie, Q., "Forward-Shifted RTP Redundancy Payload Support", 2494 RFC 6354, August 2011. 2496 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 2497 Correction (FEC) Framework", RFC 6363, October 2011. 2499 [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the 2500 Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 2501 October 2011. 2503 [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of 2504 Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2505 2012. 2507 [RFC6597] Downs, J. and J. Arbeiter, "RTP Payload Format for Society 2508 of Motion Picture and Television Engineers (SMPTE) ST 336 2509 Encoded Data", RFC 6597, April 2012. 2511 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 2512 and K. Carlberg, "Explicit Congestion Notification (ECN) 2513 for RTP over UDP", RFC 6679, August 2012. 2515 [RFC6682] Watson, M., Stockhammer, T., and M. Luby, "RTP Payload 2516 Format for Raptor Forward Error Correction (FEC)", RFC 2517 6682, August 2012. 2519 [RFC6701] Farrel, A. and P. Resnick, "Sanctions Available for 2520 Application to Violators of IETF IPR Policy", RFC 6701, 2521 August 2012. 2523 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2524 Specifications and Registration Procedures", BCP 13, RFC 2525 6838, January 2013. 2527 [TAO] "The Tao of IETF: A Novice's Guide to the Internet 2528 Engineering Task Force", November 2012, 2529 . 2531 [TRACKER] "Internet Engineering Task Force Data Tracker", January 2532 2014, . 2534 Appendix A. RTP Payload Format Template 2536 This section contains a template for writing an RTP payload format in 2537 form as a Internet draft. Text within [...] are instructions and 2538 must be removed. Some text proposals that are included are 2539 conditional. "..." is used to indicate where further text should be 2540 written. 2542 A.1. Title 2544 [The title shall be descriptive but as compact as possible. RTP is 2545 allowed and recommended abbreviation in the title] 2547 RTP Payload format for ... 2549 A.2. Front page boilerplate 2551 Status of this Memo 2553 [Insert the IPR notice and copyright boiler plate from BCP 78 and 79 2554 that applies to this draft.] 2556 [Insert the current Internet Draft document explanation. At the time 2557 of publishing it was:] 2558 Internet-Drafts are working documents of the Internet Engineering 2559 Task Force (IETF). Note that other groups may also distribute 2560 working documents as Internet-Drafts. The list of current Internet- 2561 Drafts is at http://datatracker.ietf.org/drafts/current/. 2563 Internet-Drafts are draft documents valid for a maximum of six months 2564 and may be updated, replaced, or obsoleted by other documents at any 2565 time. It is inappropriate to use Internet-Drafts as reference 2566 material or to cite them other than as "work in progress." 2568 A.3. Abstract 2570 [A payload format abstract should mention the capabilities of the 2571 format, for which media format is used, and a little about that codec 2572 formats capabilities. Any abbreviation used in the payload format 2573 must be spelled out here except the very well known like RTP. No 2574 references are allowed, no use of RFC 2119 language either.] 2576 A.4. Table of Content 2578 [All drafts over 15 pages in length must have an Table of Content.] 2580 A.5. Introduction 2582 [The introduction should provide a background and overview of the 2583 payload formats capabilities. No normative language in this section, 2584 i.e., no MUST, SHOULDs etc.] 2586 A.6. Conventions, Definitions and Acronyms 2588 [Define conventions, definitions and acronyms used in the document in 2589 this section. The most common definition used in RTP Payload formats 2590 are the RFC 2119 definitions of the upper case normative words, e.g. 2591 MUST and SHOULD.] 2593 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 2594 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 2595 document are to be interpreted as described in RFC 2119. 2597 A.7. Media Format Description 2599 [The intention of this section is to enable reviewers and persons to 2600 get an overview of the capabilities and major properties of the media 2601 format. It should be kept short and concise and is not a complete 2602 replacement for reading the media format specification.] 2604 A.8. Payload format 2606 [Overview of payload structure] 2608 A.8.1. RTP Header Usage 2610 [RTP header usage needs to be defined. The fields that absolutely 2611 need to be defined are timestamp and marker bit. Further field may 2612 be specified if used. All the rest should be left to their RTP 2613 specification definition] 2615 The remaining RTP header fields are used as specified in RTP [RFC 2616 3550]. 2618 A.8.2. Payload Header 2620 [Define how the payload header, if it exists, is structured and 2621 used.] 2623 A.8.3. Payload Data 2625 [The payload data, i.e., what the media codec has produced. Commonly 2626 done through reference to media codec specification which defines how 2627 the data is structured. Rules for padding may need to be defined to 2628 bring data to octet alignment.] 2630 A.9. Payload Examples 2632 [One or more examples are good to help ease the understanding of the 2633 RTP payload format.] 2635 A.10. Congestion Control Considerations 2637 [This section is to describe the possibility to vary the bit-rate as 2638 a response to congestion. Below is also a proposal for an initial 2639 text that reference RTP and profiles definition of congestion 2640 control.] 2642 Congestion control for RTP SHALL be used in accordance with RFC 3550 2643 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 2644 [RFC3551]. An additional requirement if best-effort service is being 2645 used is: users of this payload format MUST monitor packet loss to 2646 ensure that the packet loss rate is within acceptable parameters. 2647 Circuit Breakers [I-D.ietf-avtcore-rtp-circuit-breakers] is an update 2648 to RTP [RFC3550] that defines criteria for when one is required to 2649 stop sending RTP Packet Streams. The circuit breakers is to be 2650 implemented and followed. 2652 A.11. Payload Format Parameters 2654 This RTP payload format is identified using the ... media type which 2655 is registered in accordance with RFC 4855 [RFC4855] and using the 2656 template of RFC 6838 [RFC6838]. 2658 A.11.1. Media Type Definition 2660 [Here the media type registration template from RFC 6838 is placed 2661 and filled out. This template is provided with some common RTP 2662 boilerplate.] 2664 Type name: 2666 Subtype name: 2668 Required parameters: 2670 Optional parameters: 2672 Encoding considerations: 2674 This media type is framed and binary, see section 4.8 in RFC6838 2675 [RFC6838]. 2677 Security considerations: 2679 Please see security consideration in RFCXXXX 2681 Interoperability considerations: 2683 Published specification: 2685 Applications that use this media type: 2687 Additional information: 2689 Deprecated alias names for this type: 2691 [Only applicable if there exists widely deployed alias for this 2692 media type; see Section 4.2.9 of [RFC6838]. Remove or use N/A 2693 otherwise.] 2695 Magic number(s): 2697 [Only applicable for media types that has file format 2698 specification. Remove or use N/A otherwise.] 2700 File extension(s): 2702 [Only applicable for media types that has file format 2703 specification. Remove or use N/A otherwise.] 2705 Macintosh file type code(s): 2707 [Only applicable for media types that has file format 2708 specification. Remove or use N/A otherwise.] 2710 Person & email address to contact for further information: 2712 Intended usage: 2714 [One of COMMON, LIMITED USE or OBSOLETE.] 2716 Restrictions on usage: 2718 [The below text is for media types that is only defined for RTP 2719 payload formats. There exist certain media types that are defined 2720 both as RTP payload formats and file transfer. The rules for such 2721 types are documented in RFC 4855 [RFC4855].] 2723 This media type depends on RTP framing, and hence is only defined 2724 for transfer via RTP [RFC3550]. Transport within other framing 2725 protocols is not defined at this time. 2727 Author: 2729 Change controller: 2731 IETF Payload working group delegated from the IESG. 2733 Provisional registration? (standards tree only): 2735 No 2737 (Any other information that the author deems interesting may be added 2738 below this line.) 2740 [From RFC 6838: 2742 Some discussion of Macintosh file type codes and their purpose can 2743 be found in [MACOSFILETYPES]. 2745 N/A", written exactly that way, can be used in any field if 2746 desired to emphasize the fact that it does not apply or that the 2747 question was not omitted by accident. Do not use 'none' or other 2748 words that could be mistaken for a response. 2750 Limited-use media types should also note in the applications list 2751 whether or not that list is exhaustive.] 2753 A.11.2. Mapping to SDP 2755 The mapping of the above defined payload format media type and its 2756 parameters SHALL be done according to Section 3 of RFC 4855 2757 [RFC4855]. 2759 [More specific rules only need to be included if some parameter does 2760 not match these rules.] 2762 A.11.2.1. Offer/Answer Considerations 2764 [Here write your offer/answer consideration section, please see 2765 Section 3.4.2.1 for help.] 2767 A.11.2.2. Declarative SDP Considerations 2769 [Here write your considerations for declarative SDP, please see 2770 Section 3.4.2.2 for help.] 2772 A.12. IANA Considerations 2774 This memo requests that IANA registers [insert media type name here] 2775 as specified in Appendix A.11.1. The media type is also requested to 2776 be added to the IANA registry for "RTP Payload Format MIME types" 2777 (http://www.iana.org/assignments/rtp-parameters). 2779 [See Section 7.4 and consider if any of the parameter needs a 2780 registered name space.] 2782 A.13. Security Considerations 2784 [See Section 7.2] 2786 RTP packets using the payload format defined in this specification 2787 are subject to the security considerations discussed in the RTP 2788 specification [RFC3550] , and in any applicable RTP profile such as 2789 RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ 2790 SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: 2791 Why RTP Does Not Mandate a Single Media Security Solution" 2792 [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload 2793 formats responsibility to discuss or mandate what solutions are used 2794 to meet the basic security goals like confidentiality, integrity and 2795 source authenticity for RTP in general. This responsibility lays on 2796 anyone using RTP in an application. They can find guidance on 2797 available security mechanisms and important considerations in Options 2798 for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. 2799 The rest of the this security consideration discusses the security 2800 impacting properties of the payload format itself. 2802 This RTP payload format and its media decoder do not exhibit any 2803 significant non-uniformity in the receiver-side computational 2804 complexity for packet processing, and thus are unlikely to pose a 2805 denial-of-service threat due to the receipt of pathological data. 2806 Nor does the RTP payload format contain any active content. 2808 [The previous paragraph may need editing due to the format breaking 2809 either of the statements. Fill in here any further potential 2810 security threats created by the payload format itself.] 2812 A.14. RFC Editor Considerations 2814 Note to RFC Editor: This section may be removed after carrying out 2815 all the instructions of this section. 2817 RFCXXXX is to be replaced by the RFC number this specification 2818 receives when published. 2820 A.15. References 2822 [References must be classified as either normative or informative and 2823 added to the relevant section. References should use descriptive 2824 reference tags.] 2826 A.15.1. Normative References 2828 [Normative references are those that are required to be used to 2829 correctly implement the payload format.] 2831 A.15.2. Informative References 2833 [All other references.] 2835 A.16. Author Addresses 2837 [All Authors need to include their Name and email addresses as a 2838 minimal. Commonly also surface mail and possibly phone numbers are 2839 included.] 2841 [The Template Ends Here!] 2843 Author's Address 2845 Magnus Westerlund 2846 Ericsson 2847 Farogatan 6 2848 SE-164 80 Kista 2849 Sweden 2851 Phone: +46 10 714 82 87 2852 Email: magnus.westerlund@ericsson.com