idnits 2.17.1 draft-ietf-payload-rtp-howto-04.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 2 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? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 03, 2013) is 3980 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-avt-srtp-not-mandatory-13 == Outdated reference: A later version (-18) exists of draft-ietf-avtcore-rtp-circuit-breakers-02 == Outdated reference: A later version (-10) exists of draft-ietf-avtcore-rtp-security-options-03 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- 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 3009 (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 3979 (Obsoleted by RFC 8179) -- 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 (~~), 5 warnings (==), 11 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 Intended status: Informational June 03, 2013 5 Expires: December 05, 2013 7 How to Write an RTP Payload Format 8 draft-ietf-payload-rtp-howto-04 10 Abstract 12 This document contains information on how to best write an RTP 13 payload format. It provides reading tips, design practices, and 14 practical tips on how to produce an RTP payload format specification 15 quickly and with good results. A template is also included with 16 instructions that can be used when writing an RTP payload format. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 05, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Preparations . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Recommend Reading . . . . . . . . . . . . . . . . . . . . 5 59 3.1.1. IETF Process and Publication . . . . . . . . . . . . 6 60 3.1.2. RTP . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.2. Important RTP details . . . . . . . . . . . . . . . . . . 11 62 3.2.1. The RTP Session . . . . . . . . . . . . . . . . . . . 11 63 3.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . 12 64 3.2.3. RTP Multiplexing . . . . . . . . . . . . . . . . . . 13 65 3.2.4. RTP Synchronization . . . . . . . . . . . . . . . . . 14 66 3.3. Signalling Aspects . . . . . . . . . . . . . . . . . . . 15 67 3.3.1. Media Types . . . . . . . . . . . . . . . . . . . . . 16 68 3.3.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . 17 69 3.4. Transport Characteristics . . . . . . . . . . . . . . . . 20 70 3.4.1. Path MTU . . . . . . . . . . . . . . . . . . . . . . 20 71 4. Specification Process . . . . . . . . . . . . . . . . . . . . 20 72 4.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . 21 73 4.1.1. Steps from Idea to Publication . . . . . . . . . . . 21 74 4.1.2. WG meetings . . . . . . . . . . . . . . . . . . . . . 23 75 4.1.3. Draft Naming . . . . . . . . . . . . . . . . . . . . 23 76 4.1.4. How to speed up the process . . . . . . . . . . . . . 23 77 4.2. Other Standards bodies . . . . . . . . . . . . . . . . . 24 78 4.3. Proprietary and Vendor Specific . . . . . . . . . . . . . 25 79 5. Designing Payload Formats . . . . . . . . . . . . . . . . . . 26 80 5.1. Features of RTP Payload Formats . . . . . . . . . . . . . 26 81 5.1.1. Aggregation . . . . . . . . . . . . . . . . . . . . . 27 82 5.1.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 27 83 5.1.3. Interleaving and Transmission Re-Scheduling . . . . . 27 84 5.1.4. Media Back Channels . . . . . . . . . . . . . . . . . 28 85 5.1.5. Media Scalability . . . . . . . . . . . . . . . . . . 28 86 5.1.6. High Packet Rates . . . . . . . . . . . . . . . . . . 30 87 6. Noteworthy Aspects in Payload Format Design . . . . . . . . . 31 88 6.1. Audio Payloads . . . . . . . . . . . . . . . . . . . . . 31 89 6.2. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 32 90 6.3. Text . . . . . . . . . . . . . . . . . . . . . . . . . . 33 91 6.4. Application . . . . . . . . . . . . . . . . . . . . . . . 33 92 7. Important Specification Sections . . . . . . . . . . . . . . 34 93 7.1. Media Format Description . . . . . . . . . . . . . . . . 34 94 7.2. Security Considerations . . . . . . . . . . . . . . . . . 34 95 7.3. Congestion Control . . . . . . . . . . . . . . . . . . . 36 96 7.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 36 97 8. Authoring Tools . . . . . . . . . . . . . . . . . . . . . . . 37 98 8.1. Editing Tools . . . . . . . . . . . . . . . . . . . . . . 37 99 8.2. Verification Tools . . . . . . . . . . . . . . . . . . . 38 100 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38 102 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 103 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 104 13. Informative References . . . . . . . . . . . . . . . . . . . 39 105 Appendix A. RTP Payload Format Template . . . . . . . . . . . . 45 106 A.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 45 107 A.2. Front page boilerplate . . . . . . . . . . . . . . . . . 45 108 A.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . 45 109 A.4. Table of Content . . . . . . . . . . . . . . . . . . . . 46 110 A.5. Introduction . . . . . . . . . . . . . . . . . . . . . . 46 111 A.6. Conventions, Definitions and Acronyms . . . . . . . . . . 46 112 A.7. Media Format Description . . . . . . . . . . . . . . . . 46 113 A.8. Payload format . . . . . . . . . . . . . . . . . . . . . 46 114 A.8.1. RTP Header Usage . . . . . . . . . . . . . . . . . . 46 115 A.8.2. Payload Header . . . . . . . . . . . . . . . . . . . 46 116 A.8.3. Payload Data . . . . . . . . . . . . . . . . . . . . 46 117 A.9. Payload Examples . . . . . . . . . . . . . . . . . . . . 47 118 A.10. Congestion Control Considerations . . . . . . . . . . . . 47 119 A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 47 120 A.11.1. Media Type Definition . . . . . . . . . . . . . . . 47 121 A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . 49 122 A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 50 123 A.13. Security Considerations . . . . . . . . . . . . . . . . . 50 124 A.14. RFC Editor Considerations . . . . . . . . . . . . . . . . 50 125 A.15. References . . . . . . . . . . . . . . . . . . . . . . . 51 126 A.15.1. Normative References . . . . . . . . . . . . . . . . 51 127 A.15.2. Informative References . . . . . . . . . . . . . . . 51 128 A.16. Author Addresses . . . . . . . . . . . . . . . . . . . . 51 129 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 51 131 1. Introduction 133 RTP [RFC3550] payload formats define how a specific real-time data 134 format is structured in the payload of an RTP packet. A real-time 135 data format without a payload format specification can't be 136 transported using RTP. This creates an interest in many individuals/ 137 organizations with media encoders or other types of real-time data to 138 define RTP payload formats. However, the specification of a well- 139 designed RTP payload format is non-trivial and requires knowledge of 140 both RTP and the real-time data format. 142 This document is intended to help any author of an RTP payload format 143 make important design decisions, consider important features of RTP 144 and RTP security, etc. The document is also intended to be a good 145 starting point for any person with little experience in the IETF and/ 146 or RTP to learn the necessary steps. 148 This document extends and updates the information that is available 149 in "Guidelines for Writers of RTP Payload Format Specifications" 150 [RFC2736]. Since that RFC was written, further experience has been 151 gained on the design and specification of RTP payload formats. 152 Several new RTP profiles have been defined, and robustness tools have 153 also been defined, and these need to be considered. 155 We also discuss the possible venues for defining an RTP payload 156 format, in IETF, by other standard bodies and proprietary ones. 158 1.1. Structure 160 This document has several different parts discussing different 161 aspects of the creation of an RTP payload format specification. 162 Section 3 discusses the preparations the author(s) should do before 163 starting to write a specification. Section 4 discusses the different 164 processes used when specifying and completing a payload format, with 165 focus on working inside the IETF. Section 5 discusses the design of 166 payload formats themselves in detail. Section 6 discusses current 167 design trends and provides good examples of practices that should be 168 followed when applicable. Following that Section 7 provides a 169 discussion on important sections in the RTP payload format 170 specification itself such as security and IANA considerations. This 171 document ends with an appendix containing a template that can be used 172 when writing RTP payload formats. 174 2. Terminology 176 2.1. Definitions 178 Media Stream: A sequence of RTP packets that together carry part or 179 all of the content of a specific medium (audio, video, text, or 180 data whose form and meaning are defined by a specific real-time 181 application) from a specific sender source within a given RTP 182 session. 184 RTP Session: An association among a set of participants 185 communicating with RTP. The distinguishing feature of an RTP 186 session is that each session maintains a full, separate space of 187 SSRC identifiers. See also Section 3.2.1. 189 RTP Payload Format: The RTP payload format specifies how units of a 190 specific encoded medium are put into the RTP packet payloads and 191 how the fields of the RTP packet header are used, thus enabling 192 the format to be used in RTP sessions. 194 2.2. Acronyms 196 ABNF: Augmented Backus-Naur Form [RFC5234] 198 ADU: Application Data Unit 200 ALF: Application Level Framing 202 ASM: Any-Source Multicast 204 BCP: Best Current Practice 206 ID: Internet Draft 208 IESG: Internet Engineering Steering Group 210 MTU: Maximum Transmission Unit 212 WG: Working Group 214 QoS: Quality of Service 216 RFC: Request For Comment 218 RTP: Real-time Transport Protocol 220 RTCP: RTP Control Protocol 222 RTT: Round Trip Time 224 SSM: Source Specific Multicast 226 3. Preparations 228 RTP is a complex real-time media delivery framework and it has a lot 229 of details that needs to be considered when writing an RTP payload 230 format. It is also important to have a good understanding of the 231 media codec/format so that all of its important features and 232 properties are considered. Only when one has sufficient 233 understanding of both parts one can produce an RTP payload format of 234 high quality. On top of this, one needs to understand the process 235 within IETF and especially the Working Group responsible for 236 standardizing payload formats (currently PAYLOAD) to go quickly from 237 initial idea stage to a finished RFC. This and the next section help 238 an author prepare himself in those regards. 240 3.1. Recommend Reading 241 The following sub-sections list a number of documents. Not all need 242 to be read in full detail. However, an author basically needs to be 243 aware of everything listed below. 245 3.1.1. IETF Process and Publication 247 Newcomers to the IETF are strongly recommended to read the "Tao of 248 the IETF" [RFC6722] that goes through most things that one needs to 249 know about the IETF. This contains information about history, 250 organizational structure, how the WG and meetings work and many more 251 details. 253 The main part of the IETF process is formally defined in RFC 2026 254 [RFC2026]. In addition an author needs to understands the IETF rules 255 and rights associated with copyright and IPR documented in BCP 78 256 [RFC5378] and BCP 79 [RFC3979]. RFC 2418 [RFC2418] describes the WG 257 process, the relation between the IESG and the WG, and the 258 responsibilities of WG chairs and participants. 260 It is important to note that the RFC series contains documents of 261 several different publication streams as defined by the The RFC 262 Series and RFC Editor [RFC4844]. The most important stream for RTP 263 payload formats authors are the IETF Stream. In this streams the 264 work of IETF is published. The stream contains documents of several 265 different categories: standards track, informational, experimental, 266 best current practice (BCP), and historic. The standard track 267 previously allowed for documents of three different maturity 268 classifications, proposed, draft and Internet Standard. Since 269 October 2011 this has been reduced to only two levels, Proposed 270 Standard and Internet Standard [RFC6410]. A standards track document 271 must start as proposed; after successful deployment and operational 272 experience with at least two implementations it can be moved to 273 Internet Standard. The Independent Submission Stream could appear to 274 be of interest as it provides a way of publishing documents of 275 certain categories such as experimental and informational with a 276 different review process. However, as long as IETF has a WG which is 277 chartered to work on RTP payload formats this stream should not be 278 used. 280 As the content of a given RFC is not allowed to change once 281 published, the only way to modify an RFC is to write and publish a 282 new one that either updates or replaces the old one. Therefore, 283 whether reading or referencing an RFC, it is important to consider 284 both the Category field in the document header and to check if the 285 RFC is the latest on the subject and still valid. One way of 286 checking the current status of an RFC is to use the RFC-editor's RFC 287 search engine, which displays the current status and which if any RFC 288 update or obsolete it. The RFC-editor search engine will also 289 indicate if there exist any RFC-errata. Any approved Errata is 290 issues of significant importance with the RFC and thus should be 291 known also prior to an update and replacement publication. 293 Before starting to write a draft one should also read the Internet 294 Draft writing guidelines (http://www.ietf.org/ietf/1id- 295 guidelines.txt), the ID checklist (http://www.ietf.org/ID- 296 Checklist.html) and the RFC editorial guidelines and procedures 297 [RFC-ED]. Another document that can be useful is the "Guide for 298 Internet Standards Writers" [RFC2360]. 300 There are also a number of documents to consider in process of 301 writing of drafts intended to become RFCs. These are important when 302 writing certain type of text. 304 RFC 2606: When writing examples using DNS names in Internet drafts, 305 those names shall be chosen from the example.com, example.net, and 306 example.org domains. 308 RFC 3849: Defines the range of IPv6 unicast addresses (2001:DB8::/ 309 32) that should be used in any examples. 311 RFC 5737: Defines the ranges of IPv4 unicast addresses reserved for 312 documentation and examples: 192.0.2.0/24, 198.51.100.0/24, and 313 203.0.113.0/24. 315 RFC 5234: Augmented Backus-Naur Form (ABNF) is often used when 316 writing text field specifications. Not that commonly used in RTP 317 payload formats but may be useful when defining Media Type 318 parameters of some complexity. 320 3.1.2. RTP 322 The recommended reading for RTP consist of several different parts; 323 design guidelines, the RTP protocol, profiles, robustness tools, and 324 media specific recommendations. 326 Any author of RTP payload formats should start by reading Guidelines 327 for Writers of RTP Payload Format Specifications [RFC2736] which 328 contains an introduction to the application layer framing (ALF) 329 principle, the channel characteristics of IP channels, and design 330 guidelines for RTP payload formats. The goal of ALF is to be able to 331 transmit Application Data Units (ADUs) that are independently usable 332 by the receiver in individual RTP packets, thus minimizing 333 dependencies between RTP packets and the effects of packet loss. 335 Then it is advisable to learn more about the RTP protocol, by 336 studying the RTP specification RFC 3550 [RFC3550] and the existing 337 profiles. As a complement to the standards document there exists a 338 book totally dedicated to RTP [CSP-RTP]. There exist several 339 profiles for RTP today, but all are based on the "RTP Profile for 340 Audio and Video Conferences with Minimal Control" (RFC 3551) 341 [RFC3551] (abbreviated AVP). The other profiles that one should know 342 about are Secure RTP (RTP/SAVP) [RFC3711], "Extended RTP Profile for 343 RTCP-based Feedback (RTP/AVPF)" [RFC4585] and "Extended Secure RTP 344 Profile for RTCP-based Feedback (RTP/SAVPF)" [RFC5124]. It is 345 important to understand RTP and the AVP profile in detail. For the 346 other profiles it is sufficient to have an understanding of what 347 functionality they provide and the limitations they create. 349 A number of robustness tools have been developed for RTP. The tools 350 are for different use cases and real-time requirements. 352 RFC 2198: The "RTP Payload for Redundant Audio Data" [RFC2198] 353 provides functionalities to transmit redundant copies of audio or 354 text payloads. These redundant copies are sent together with a 355 primary format in the same RTP payload. This format relies on the 356 RTP timestamp to determine where data belongs in a sequence and 357 therefore is usually most suitable to be used with audio. 358 However, the RTP Payload format for T.140 [RFC4103] text format 359 also uses this format. The format's major property is that it 360 only preserves the timestamp of the redundant payloads, not the 361 original sequence number. This makes it unusable for most video 362 formats. This format is also only suitable for media formats that 363 produce relatively small RTP payloads. 365 RFC 6354: The "Forward-Shifted RTP Redundancy Payload Support" 366 [RFC6354] is a variant of RFC 2198 which allows the redundant data 367 to transmitted prior to the original. 369 RFC 5109: The "RTP Payload Format for Generic Forward Error 370 Correction (FEC)" [RFC5109] provides an XOR based FEC of the whole 371 or parts of a number of RTP packets. These FEC packets are sent 372 in a separate stream or as a redundant encoding using RFC 2198. 373 This FEC scheme has certain restrictions in the number of packets 374 it can protect. It is suitable for low-to-medium delay tolerant 375 applications with limited amount of RTP packets. 377 RFC 6015: The "RTP Payload Format for 1-D Interleaved Parity Forward 378 Error Correction (FEC)" [RFC6015] provides a variant of the XOR 379 based Generic protection defined in RFC 2733. The main difference 380 is to use interleaving scheme on which packets gets included as 381 source packets for a particular protection packet. The 382 interleaving is defined by using every L packets as source data. 383 And then produce protection data over D number of packets. Thus 384 each block of D x L source packets will result in L number of 385 Repair packets, each capable of repairing one loss. The goal is 386 to provide better burst error robustness when the packet rate is 387 higher. 389 FEC Framework: The Forward Error Correction (FEC) Framework 390 [RFC6363] defines how to FEC protect arbitrary packet flows. This 391 can be applied for RTP and also can also use RTP for transmission 392 of repair symbols for the Raptor FEC scheme [RFC6682]. 394 RTP Retransmission: The RTP retransmission scheme [RFC4588] is used 395 for semi-reliability of the most important RTP packets in a media 396 stream. The scheme is not intended, to provide full reliability. 397 It requires the application to be quite delay tolerant as a 398 minimum of one round-trip time plus processing delay is required 399 to perform an retransmission. Thus it is mostly suitable for 400 streaming applications but may also be usable in certain other 401 cases when operating in networks with short round-trip times 402 (RTT). 404 RTP over TCP: RFC 4571 [RFC4571] defines how one sends RTP and RTCP 405 packets over connection-oriented transports like TCP. If one uses 406 TCP, one gets reliability for all packets but loses some of the 407 real-time behavior that RTP was designed to provide. Issues with 408 TCP transport of real-time media include head of line blocking and 409 wasting resources on retransmission of already late data. TCP is 410 also limited to point-to-point connections which further restricts 411 its applicability. 413 There has also been both discussion and design of RTP payload 414 formats, e.g AMR and AMR-WB [RFC4867], supporting the unequal error 415 detection provided by UDP-Lite [RFC3828]. The idea is that by not 416 having a checksum over part of the RTP payload one can allow bit 417 errors from the lower layers. By allowing bit errors one can 418 increase the efficiency of some link layers, and also avoid 419 unnecessary discarding of data when the payload and media codec can 420 get at least some benefit from the data. The main issue is that one 421 has no idea of the level of bit errors present in the unprotected 422 part of the payload. This makes it hard or impossible to determine 423 if one can design something usable or not. Payload format designers 424 are recommended against considering features for unequal error 425 detection unless very clear requirements exist. 427 There also exist some management and monitoring extensions. 429 RFC 2959: The RTP protocol Management Information Database (MIB) 430 [RFC2959] that is used with SNMP [RFC3410] to configure and 431 retrieve information about RTP sessions. 433 RFC 3611: The RTCP Extended Reports (RTCP XR) [RFC3611] consists of 434 a framework for reports sent within RTCP. It can easily be 435 extended by defining new report formats in the future. The report 436 formats that are defined in RFC3611 provide report information on 437 packet loss, packet duplication, packet reception times, RTCP 438 statistics summary and VoIP Quality. [RFC3611] also defines a 439 mechanism that allows receivers to calculate the RTT to other 440 session participants when used. 442 RMONMIB: The remote monitoring WG has defined a mechanism [RFC3577] 443 based on usage of the MIB that can be an alternative to RTCP XR. 445 A number of transport optimizations have also been developed for use 446 in certain environments. They are all intended to be transparent and 447 do not require special consideration by the RTP payload format 448 writer. Thus they are primarily listed here for informational 449 reasons and do not require deeper studies. 451 RFC 2508: Compressing IP/UDP/RTP headers for slow serial links 452 (CRTP) [RFC2508] is the first IETF developed RTP header 453 compression mechanism. It provides quite good compression however 454 it has clear performance problems when subject to packet loss or 455 reordering between compressor and decompressor. 457 RFC 3095 & RFC 5795: This is the base specifications of the robust 458 header compression (ROHC) protocol version 1 [RFC3095] and version 459 2 [RFC5795]. This solution was created as a result of CRTP's lack 460 of performance when compressed packets are subject to loss. 462 RFC 3545: Enhanced compressed RTP (E-CRTP) [RFC3545] was developed 463 to provide extensions to CRTP that allow for better performance 464 over links with long RTTs, packet loss and/or reordering. 466 RFC 4170: Tunneling Multiplexed Compressed RTP (TCRTP) [RFC4170] is 467 a solution that allows header compression within a tunnel carrying 468 multiple multiplexed RTP flows. This is primarily used in voice 469 trunking. 471 There exist a couple of different security mechanisms that may be 472 used with RTP. Generic mechanisms by definition are transparent for 473 the RTP payload format and do not need special consideration by the 474 format designer. The main reason that different solutions exist is 475 that different applications have different requirements thus 476 different solutions have been developed. For more discussion on this 477 please see Options for Securing RTP Sessions 478 [I-D.ietf-avtcore-rtp-security-options] and Why RTP Does Not Mandate 479 a Single Security Mechanism [I-D.ietf-avt-srtp-not-mandatory]. The 480 main properties for a RTP security mechanism are to provide 481 confidentiality for the RTP payload, integrity protection to detect 482 manipulation of payload and headers, and source authentication. Not 483 all mechanisms provide all of these features, a point which will need 484 to be considered when one of these mechanisms is used. 486 The profile for Secure RTP - SRTP (SAVP) [RFC3711] and the derived 487 profile (SAVPF [RFC5124]) are a solution that enables 488 confidentiality, integrity protection, replay protection and partial 489 source authentication. It is the solution most commonly used with 490 RTP at time of writing. There exist several key-management solutions 491 for SRTP, as well other choices, affecting the security properties. 492 For a more in-depth review of the options and also other solutions 493 than SRTP please consult "Options for Securing RTP Sessions" 494 [I-D.ietf-avtcore-rtp-security-options]. 496 3.2. Important RTP details 498 This section does not remove the necessity to read up on RTP. 499 However it does point out a few important details to remember when 500 designing a payload format. 502 3.2.1. The RTP Session 504 The definition of the RTP session from RFC 3550 is: 506 "An association among a set of participants communicating with RTP. 507 A participant may be involved in multiple RTP sessions at the same 508 time. In a multimedia session, each medium is typically carried in a 509 separate RTP session with its own RTCP packets unless the encoding 510 itself multiplexes multiple media into a single data stream. A 511 participant distinguishes multiple RTP sessions by reception of 512 different sessions using different pairs of destination transport 513 addresses, where a pair of transport addresses comprises one network 514 address plus a pair of ports for RTP and RTCP. All participants in 515 an RTP session may share a common destination transport address pair, 516 as in the case of IP multicast, or the pairs may be different for 517 each participant, as in the case of individual unicast network 518 addresses and port pairs. In the unicast case, a participant may 519 receive from all other participants in the session using the same 520 pair of ports, or may use a distinct pair of ports for each." 522 "The distinguishing feature of an RTP session is that each session 523 maintains a full, separate space of SSRC identifiers (defined next). 524 The set of participants included in one RTP session consists of those 525 that can receive an SSRC identifier transmitted by any one of the 526 participants either in RTP as the SSRC or a CSRC (also defined below) 527 or in RTCP. For example, consider a three-party conference 528 implemented using unicast UDP with each participant receiving from 529 the other two on separate port pairs. If each participant sends RTCP 530 feedback about data received from one other participant only back to 531 that participant, then the conference is composed of three separate 532 point-to-point RTP sessions. If each participant provides RTCP 533 feedback about its reception of one other participant to both of the 534 other participants, then the conference is composed of one multi- 535 party RTP session. The latter case simulates the behavior that would 536 occur with IP multicast communication among the three participants." 538 "The RTP framework allows the variations defined here (RFC3550), but 539 a particular control protocol or application design will usually 540 impose constraints on these variations." 542 3.2.2. RTP Header 544 The RTP header contains a number of fields. Two fields always 545 require additional specification by the RTP payload format, namely 546 the RTP Timestamp and the marker bit. Certain RTP payload formats 547 also use the RTP sequence number to realize certain functionalities. 548 The payload type is used to indicate the used payload format. The 549 Sender Source Identifier (SSRC) is used to distinguish RTP packets 550 from multiple senders and media streams. Finally, [RFC5285] 551 specifies how to extend the RTP header to carry metadata relating to 552 the payload when this is desirable. 554 Marker bit: A single bit normally used to provide important 555 indications. In audio it is normally used to indicate the start 556 of an talk burst. This enables jitter buffer adaptation prior to 557 the beginning of the burst with minimal audio quality impact. In 558 video the marker bit is normally used to indicate the last packet 559 part of an frame. This enables a decoder to finish decoding the 560 picture, where it otherwise may need to wait for the next packet 561 to explicitly know that the frame is finished. 563 Timestamp: The RTP timestamp indicates the time instance the media 564 sample belongs to. For discrete media like video, it normally 565 indicates when the media (frame) was sampled. For continuous 566 media it normally indicates the first time instance the media 567 present in the payload represents. For audio this is the sampling 568 time of the first sample. All RTP payload formats must specify 569 the meaning of the timestamp value and the clock rates allowed. 570 Note that clock rates below 1000 Hz are not appropriate because it 571 will cause a too low resolution in the RTCP measurements. RTP 572 payload formats with a timestamp definition which results in no or 573 little correlation between the media time instance and its 574 transmission time cause the RTCP jitter calculation to become 575 unusable due to the errors introduced on the sender side. It 576 should be noted if the payload format has this property or not. 578 Sequence number: The sequence number is monotonically increasing and 579 is set as the packet is sent. This property is used in many 580 payload formats to recover the order of everything from the whole 581 stream down to fragments of application data units (ADUs) and the 582 order they need to be decoded. 584 Payload Type: The payload type is used to indicate on a per packet 585 basis which format is used. Thus certain major configuration 586 information can be bound to a payload type value by out-of-band 587 signalling. An example of this would be video decoder 588 configuration information. Commonly the same payload type is used 589 for a media stream for the whole duration of a session. However 590 in some cases it may be necessary to change the payload format or 591 its configuration during the session. 593 SSRC: The Sender Source ID (SSRC) is normally not used by a payload 594 format other than to identify the RTP timestamp and sequence 595 number space a packet belongs to, allowing simultaneously 596 reception from multiple senders. However, some of the RTP 597 mechanisms for improving resilience to packet loss uses multiple 598 SSRCs to separate original data and repair or redundant data. 600 Header extensions: Some payload formats may specify extensions to 601 the RTP packet header to carry metadata describing the actual 602 payload within the packet. One example is the transport of SMPTE 603 time-codes in the RTP header [RFC5484]. As [RFC5285] specifies, 604 header extensions must not contain information required in order 605 to decode the payload successfully. 607 The remaining fields do not commonly influence the RTP payload 608 format. The padding bit is worth clarifying as it indicates that one 609 or more bytes are appended after the RTP payload. This padding must 610 be removed by a receiver before payload format processing can occur. 611 Thus it is completely separate from any padding that may occur within 612 the payload format itself. 614 3.2.3. RTP Multiplexing 616 RTP has three multiplexing points that are used for different 617 purposes. A proper understanding of this is important to correctly 618 utilize them. 620 The first one is separation of media streams of different types or 621 usages, which is accomplished using different RTP sessions. So for 622 example in the common multi-media session with audio and video, RTP 623 commonly multiplexes audio and video in different RTP sessions. To 624 achieve this separation, transport-level functionalities are used, 625 normally UDP port numbers. Different RTP sessions are also used to 626 realize layered scalability as it allows a receiver to select one or 627 more layers for multicast RTP sessions simply by joining the 628 multicast groups over which the desired layers are transported. This 629 separation also allows different Quality of Service (QoS) to be 630 applied to different media types. 632 The next multiplexing point is separation of different sources within 633 an RTP session. Here RTP uses the SSRC to identify individual 634 sources. An example of individual sources in an audio RTP session 635 would be different microphones, independently of whether they are 636 connected to the same host or different hosts. For each SSRC a 637 unique RTP sequence number and timestamp space is used. 639 The third multiplexing point is the RTP header payload type field. 640 The payload type identifies what format the content in the RTP 641 payload has. This includes different payload format configurations, 642 different codecs, and also usage of robustness mechanisms like the 643 one described in RFC 2198 [RFC2198]. 645 3.2.4. RTP Synchronization 647 There are several types of synchronization and we will here describe 648 how RTP handles the different types: 650 Intra media: The synchronization within a media stream from a source 651 (SSRC) is accomplished using the RTP timestamp field. Each RTP 652 packet carries the RTP timestamp, which specifies the position in 653 time of the media payload contained in this packet relative to the 654 content of other RTP packets in the same RTP media stream (i.e. a 655 given SSRC). This is especially useful in cases of discontinuous 656 transmissions. Discontinuities can be caused by network 657 conditions; when extensive losses occur the RTP timestamp tells 658 the receiver how much later than previously received media the 659 present media should be played out. 661 Inter media: Applications commonly have a desire to use several 662 media sources, possibly of different media types, at the same 663 time. Thus, there exists a need to synchronize also different 664 media from the same end-point. This puts two requirements on RTP: 665 the possibility to determine which media are from the same end- 666 point and if they should be synchronized with each other; and the 667 functionality to facilitate the synchronization itself. 669 The first step in inter-media synchronization is to determine which 670 SSRCs in each session should be synchronized with each other. This 671 is accomplished by comparing the CNAME fields in the RTCP SDES 672 packets. SSRCs with the same CNAME in different RTP sessions can be 673 synchronized. 675 The actual RTCP mechanism for inter-media synchronization is based on 676 the idea that each media stream provides a position on the media 677 specific time line (measured in RTP timestamp ticks) and a common 678 reference time line. The common reference time line is expressed in 679 RTCP as a wall clock time in the Network Time Protocol (NTP) format. 680 It is important to notice that the wall clock time is not required to 681 be synchronized between hosts, for example by using NTP [RFC5905] . 682 It can even have nothing at all to do with the actual time, for 683 example the host system's up-time can be used for this purpose. The 684 important factor is that all media streams from a particular source 685 that are being synchronized use the same reference clock to derive 686 their relative RTP timestamp time scales. 688 Figure 1 illustrates how if one receives RTCP Sender Report (SR) 689 packet P1 in one media stream and RTCP SR packet P2 in the other 690 session, then one can calculate the corresponding RTP timestamp 691 values for any arbitrary point in time T. However to be able to do 692 that it is also required to know the RTP timestamp rates for each 693 medium currently used in the sessions 695 TS1 --+---------------+-------> 696 | | 697 P1 | 698 | | 699 NTP ---+-----+---------T------> 700 | | 701 P2 | 702 | | 703 TS2 ---------+---------+---X--> 705 Figure 1: RTCP Synchronization 707 Assume that medium 1 uses an RTP Timestamp clock rate of 16 kHz, and 708 medium 2 uses a clock rate of 90 kHz. Then TS1 and TS2 for point T 709 can be calculated in the following way: TS1(T) = TS1(P1) + 16000 * 710 (NTP(T)-NTP(P1)) and TS2(T) = TS2(P2) + 90000 * (NTP(T)-NTP(P2)). 711 This calculation is useful as it allows the implementation to 712 generate a common synchronization point for which all time values are 713 provided (TS1(T), TS2(T) and T). So when one wishes to calculate the 714 NTP time that the timestamp value present in packet X corresponds to 715 one can do that in the following way: NTP(X) = NTP(T) + (TS2(X) - 716 TS2(T))/90000. 718 Improved signaling for layered codecs and fast tune-in have been 719 specified in Rapid Synchronization for RTP flows [RFC6051]. 721 3.3. Signalling Aspects 722 RTP payload formats are used in the context of application signalling 723 protocols such as SIP [RFC3261] using the Session Description 724 Protocol (SDP) [RFC4566] with Offer/Answer [RFC3264], RTSP [RFC2326] 725 or SAP [RFC2326]. These examples all use out-of-band signalling to 726 indicate which type of RTP media streams that are desired to be used 727 in the session and how they are configured. To be able to declare or 728 negotiate the media format and RTP payload packetization, the payload 729 format must be given an identifier. In addition to the identifier 730 many payload formats have also the need to signal further 731 configuration information out-of-band for the RTP payloads prior to 732 the media transport session. 734 The above examples of session-establishing protocols all use SDP, but 735 other session description formats may be used. For example there was 736 discussion of a new XML-based session description format within IETF 737 (SDP-NG). In the event, the proposal did not get beyond the initial 738 protocol specification because of the enormous embedded base of SDP 739 implementations. However, to avoid locking the usage of RTP to SDP 740 based out-of-band signalling, the payload formats are identified 741 using a separate definition format for the identifier and associated 742 parameters. That format is the Media Type. 744 3.3.1. Media Types 746 Media types [RFC6838] are identifiers originally created for 747 identifying media formats included in email. In this usage they were 748 known as MIME types, where the expansion of the MIME acronym includes 749 the word "mail". The term "media type" was introduced to reflect a 750 broader usage, which includes HTTP [RFC2616], MSRP [RFC4975] and many 751 other protocols, to identify arbitrary content carried within the 752 protocols. Media types also provide a media hierarchy that fits RTP 753 payload formats well. Media type names are two-part and consist of 754 content type and sub-type separated with a slash, e.g. "audio/PCMA" 755 or "video/h263-2000". It is important to choose the correct content- 756 type when creating the media type identifying an RTP payload format. 757 However in most cases there is little doubt what content type the 758 format belongs to. Guidelines for choosing the correct media type 759 and registration rules for media type names are provided in Media 760 Type Specifications and Registration Procedures [RFC6838]. The 761 additional rules for media types for RTP payload formats are provided 762 in Media Type Registration of RTP Payload Formats [RFC4855]. 764 Registration of the RTP payload name is something that is required to 765 avoid name collision in the future. Note that "x-" names are not 766 suitable for any documented format as they have the same problem with 767 name collision and can't be registered. The list of already 768 registered media types can be found at IANA Web site (http:// 769 www.iana.org). 771 Media types are allowed any number of parameters, which may be 772 required or optional for that media type. They are always specified 773 on the form "name=value". There exists no restrictions on how the 774 value is defined from media type's perspective, except that 775 parameters must have a value. However, the usage of media types in 776 SDP etc. has resulted in the following restrictions that need to be 777 followed to make media types usable for RTP identifying payload 778 formats: 780 1. Arbitrary binary content in the parameters is allowed but needs 781 to be encoded so that it can be placed within text based 782 protocols. Base64 [RFC4648] is recommended, but for shorter 783 content Base16 [RFC4648] may be more appropriate as it is simpler 784 to interpret for humans. This needs to be explicitly stated when 785 defining a media type parameter with binary values. 787 2. The end of the value needs to be easily found when parsing a 788 message. Thus parameter values that are continuous and not 789 interrupted by common text separators, such as space and semi- 790 colon, are recommended. If that is not possible some type of 791 escaping should be used. Usage of quote (") is recommended, and 792 don't forget to provide a method of encoding any character used 793 for quoting inside the quoted element. 795 3. A common representation form for the media type and its 796 parameters is on a single line. In that case the media type is 797 followed by a semicolon-separated list of the parameter value 798 pairs, e.g. 800 audio/amr octet-align=0; mode-set=0,2,5,7; mode-change-period=2 802 3.3.2. Mapping to SDP 804 Since SDP [RFC4566] is so commonly used as an out-of-band signalling 805 protocol, a mapping of the media type into SDP exists. The details 806 on how to map the media type and its parameters into SDP are 807 described in RFC 4855 [RFC4855]. However this is not sufficient to 808 explain how certain parameters must be interpreted for example in the 809 context of Offer/Answer negotiation [RFC3264]. 811 3.3.2.1. The Offer/Answer Model 813 The Offer/Answer (O/A) model allows SIP to negotiate which media 814 formats and payload formats are to be used in a session and how they 815 are to be configured. However O/A does not define a default behavior 816 and instead points out the need to define how parameters behave. To 817 make things even more complex the direction of media within a session 818 has an impact on these rules, so that some cases may require separate 819 descriptions for media streams that are send-only, receive-only or 820 both sent and received as identified by the SDP attributes 821 a=sendonly, a=recvonly, and a=sendrecv. In addition the usage of 822 multicast adds further limitations as the same media stream is 823 delivered to all participants. If those multicast-imposed 824 restrictions are too limiting for unicast then separate rules for 825 unicast and multicast will be required. 827 The simplest and most common O/A interpretation is that a parameter 828 is defined to be declarative; i.e. the SDP offer/answer sending 829 agent can declare a value and that has no direct impact on the other 830 agent's values. This declared value applies to all media that are 831 going to be sent to the declaring entity. For example most video 832 codecs have a level parameter which tells the other participants the 833 highest complexity the video decoder supports. The level parameter 834 can be declared independently by two participants in a unicast 835 session as it will be the media sender's responsibility to transmit a 836 video stream that fulfills the limitation the other has declared. 837 However in multicast it will be necessary to send a stream that 838 follows the limitation of the weakest receiver, i.e. the one that 839 supports the lowest level. To simplify the negotiation in these 840 cases it is common to require any answerer to a multicast session to 841 take a yes or no approach to parameters. 843 A "negotiated" parameter is a different case, for which both sides 844 need to agree on its value. Such a parameter requires that the 845 answerer either accept it as it is offered or remove the payload type 846 the parameter belonged to from its answer. The removal of the 847 payload type from the answer indicates to the offerer the lack of 848 support for the parameter values presented. An unfortunate 849 implication of the need to use complete payload types to indicate 850 each possible configuration so as to maximize the chances of 851 achieving interoperability, is that the number of necessary payload 852 types can quickly grow large. This is one reason to limit the total 853 number of sets of capabilities that may be implemented. 855 The most problematic type of parameters are those that relate to the 856 media the entity sends. They do not really fit the O/A model but can 857 be shoe-horned in. Examples of such parameters can be found in the 858 H.264 video codec's payload format [RFC6184], where the name of all 859 parameters with this property starts with "sprop-". The issue with 860 these parameters is that they declare properties for a media stream 861 that the other party may not accept. The best one can make of the 862 situation is to explain the assumption that the other party will 863 accept the same parameter value for the media it will receive as the 864 offerer of the session has proposed. If the answerer needs to change 865 any declarative parameter relating to streams it will receive then 866 the offerer may be required to make an new offer to update the 867 parameter values for its outgoing media stream. 869 Another issue to consider is the sendonly media streams in offers. 870 Parameters that relate to what the answering entity accepts to 871 receive have no meaning other than to provide a template for the 872 answer. It is worth pointing out in the specification that these 873 really provide a set of parameter values that the sender recommends. 874 Note that sendonly streams in answers will need to indicate the 875 offerer's parameters to ensure that the offerer can match the answer 876 to the offer. 878 A further issue with offer/answer which complicates things is that 879 the answerer is allowed to renumber the payload types between offer 880 and answer. This is not recommended but allowed for support of 881 gateways to the ITU conferencing suite. This means that it must be 882 possible to bind answers for payload types to the payload types in 883 the offer even when the payload type number has been changed, and 884 some of the proposed payload types have been removed. This binding 885 must normally be done by matching the configurations originally 886 offered against those in the answer. 888 3.3.2.2. Declarative usage in RTSP and SAP 890 SAP (Session Announcement Protocol) [RFC2974] is used for announcing 891 multicast sessions. Independently of the usage of Source Specific 892 Multicast (SSM) [RFC3569] or Any-Source Multicast (ASM), the SDP 893 provided by SAP applies to all participants. All media that is sent 894 to the session must follow the media stream definition as specified 895 by the SDP. This enables everyone to receive the session if they 896 support the configuration. Here SDP provides a one way channel with 897 no possibility to affect the configuration that the session creator 898 has decided upon. Any RTP Payload format that requires parameters 899 for the send direction and which needs individual values per 900 implementation or instance will fail in a SAP session for a multicast 901 session allowing anyone to send. 903 Real-Time Streaming Protocol (RTSP) [RFC2326] allows the negotiation 904 of transport parameters for media streams which are part of a 905 streaming session between a server and client. RTSP has divided the 906 transport parameters from the media configuration. SDP is commonly 907 used for media configuration in RTSP and is sent to the client prior 908 to session establishment, either through use of the DESCRIBE method 909 or by means of an out-of-band channel like HTTP, email etc. The SDP 910 is used to determine which media streams and what formats are being 911 used prior to session establishment. 913 Thus both SAP and RTSP use SDP to configure receivers and senders 914 with a predetermined configuration for a media stream including the 915 payload format and any of its parameters. All parameters are used in 916 a declarative fashion. This can result in different treatment of 917 parameters between offer/answer and declarative usage in RTSP and 918 SAP. Any such difference will need to be spelled out by the payload 919 format specification. 921 3.4. Transport Characteristics 923 The general channel characteristics that RTP flows experience are 924 documented in Section 3 of Guidelines for Writers of RTP Payload 925 Format Specifications [RFC2736]. The discussion below provides 926 additional information. 928 3.4.1. Path MTU 930 At the time of writing this document the most common IP Maximum 931 Transmission Unit (MTU) in used link layers is 1500 bytes (Ethernet 932 data payload). However there exist both links with smaller MTUs and 933 links with much larger MTUs. Certain parts of the Internet already 934 today support an IP MTU of 9000 bytes or more. There is a slow 935 ongoing evolution towards larger MTU sizes. However, at the same 936 time it has become common to use tunneling protocols, often multiple 937 ones who's overhead when added together can shrink the MTU 938 significant. This should be considered in the design, especially in 939 regards to features such as aggregation of independently decodable 940 data units. 942 4. Specification Process 944 This section discusses the recommended process to produce an RTP 945 payload format in the described venues. This is to document the best 946 current practice on how to get a well designed and specified payload 947 format as quickly as possible. For specifications that are defined 948 by standards bodies other than the IETF the primary milestone is 949 registration of the RTP payload format name. For proprietary media 950 formats the primary goal depends on whether interoperability is 951 desired at the RTP level. However there is also the issue of 952 ensuring best possible quality of any specification. 954 4.1. IETF 956 For all standardized media formats, it is recommended that the 957 payload format be specified in the IETF. The main reason is to 958 provide an openly available RTP payload format specification that has 959 been reviewed by people experienced with RTP payload formats. At the 960 time of writing, this work is done in the PAYLOAD Working Group (WG), 961 but that may change in the future. 963 4.1.1. Steps from Idea to Publication 965 There are a number of steps that an RTP payload format should go 966 through from the initial idea until it is published. This also 967 documents the process that the PAYLOAD Working Group applies when 968 working with RTP payload formats. 970 Idea: Determined the need for an RTP payload format as an IETF 971 specification. 973 Initial effort: Using this document as guideline one should be able 974 to get started on the work. If one's media codec doesn't fit any 975 of the common design patterns or one has problems understanding 976 what the most suitable way forward is, then one should contact the 977 PAYLOAD Working Group and/or the WG chairs. The goal of this 978 stage is to have an initial individual draft. This draft needs to 979 focus on the introductory parts that describe the real-time media 980 format and the basic idea on how to packetize it. Not all the 981 details are required to be filled in. However, the security 982 chapter is not something that one should skip even initially. It 983 is important to consider from the start any serious security risks 984 that need to be solved. The first step is completed when one has 985 a draft that is sufficiently detailed for a first review by the 986 WG. The less confident one is of the solution, the less work 987 should be spent on details; instead concentrate on the codec 988 properties and what is required to make the packetization work. 990 Submission of first version: When one has performed the above one 991 submits the draft as an individual draft. This can be done at any 992 time except the 3 weeks (current deadline at the time of writing, 993 consult current announcements) prior to an IETF meeting. When the 994 IETF draft announcement has been sent out on the draft 995 announcement list, forward it to the PAYLOAD WG and request that 996 it be reviewed. In the email outline any issues the authors 997 currently have with the design. 999 Iterative improvements: Taking the feedback into account one 1000 updates the draft and tries resolve issues. New revisions of the 1001 draft can be submitted at any time (again except for a buffer 1002 period before meetings). It is recommended to submit a new 1003 version whenever one has made major updates or has new issues that 1004 are easiest to discuss in the context of a new draft version. 1006 Becoming a WG document: Given that the definition of RTP payload 1007 formats is part of the PAYLOAD WG's charter, RTP payload formats 1008 that are going to be published as standards track RFCs need to 1009 become WG documents. Becoming a WG document means that the chairs 1010 are responsible for administrative handling, for example, issuing 1011 publication requests. However be aware that making a document 1012 into a WG document changes the formal ownership and responsibility 1013 from the individual authors to the WG. The initial authors 1014 normally continue being document editors, unless unusual 1015 circumstances occur. The PAYLOAD WG accepts new RTP payload 1016 formats based on their suitability and document maturity. The 1017 document maturity is a requirement to ensure that there are 1018 dedicated document editors and that there exists a good solution. 1020 Iterative improvements: The updates and review cycles continue 1021 until the draft has reached the level of maturity suitable for 1022 publication. 1024 WG Last Call: A WG Last Call of at least 2 weeks is always 1025 performed for payload formats in the PAYLOAD WG. The authors 1026 request WG last call for a draft when they think it is mature 1027 enough for publication. The chairs perform a review to check if 1028 they agree with the authors' assessment. If the chairs agree on 1029 the maturity, the WG Last Call is announced on the WG mailing 1030 list. If there are issues raised these need to be addressed with 1031 an updated draft version. For any more substantial updates of the 1032 draft, a new WG last call is announced for the updated version. 1033 Minor changes, like editorial fixes, can be progressed without an 1034 additional WG last call. 1036 Publication Requested: For WG documents the chairs request 1037 publication of the draft, after it has passed WG Last Call. After 1038 this the approval and publication process described in RFC 2026 1039 [RFC2026] are performed. The status after the publication has 1040 been requested can be tracked using the IETF data tracker. 1041 Documents do not expire as they normally do after publication has 1042 been requested, so authors do not have to issue keep-alive 1043 updates. In addition, any submission of document updates requires 1044 the approval of WG chair(s). The authors are commonly asked to 1045 address comments or issues raised by the IESG. The authors also 1046 do one last review of the document immediately prior to its 1047 publication as an RFC to ensure its correctness. 1049 4.1.2. WG meetings 1051 WG meetings are for discussing issues, not presentations. This means 1052 that most RTP payload formats should never need to be discussed in a 1053 WG meeting. RTP payload formats that would be discussed are either 1054 those with controversial issues that failed to be resolved on the 1055 mailing list, or those including new design concepts worth a general 1056 discussion. 1058 There exists no requirement to present or discuss a draft at a WG 1059 meeting before it becomes published as an RFC. Thus even authors who 1060 lack the possibility to go to WG meetings should be able to 1061 successfully specify an RTP payload format in IETF. WG meetings may 1062 become necessary only if the draft gets stuck in a serious debate 1063 that cannot easily be resolved. 1065 4.1.3. Draft Naming 1067 To simplify the work of the PAYLOAD WG chairs and its WG members a 1068 specific draft file naming convention shall be used for RTP payload 1069 formats. Individual submissions shall be named draft--payload-rtp--. The WG 1071 documents shall be named according to this template: draft-ietf- 1072 payload-rtp--. The inclusion of "payload" 1073 in the draft filename ensures that the search for "payload-" will 1074 find all PAYLOAD related drafts. Inclusion of "rtp" tells us that it 1075 is an RTP payload format draft. The descriptive name should be as 1076 short as possible while still describing what the payload format is 1077 for. It is recommended to use the media format or codec acronym. 1078 Please note that the version must start at 00 and is increased by one 1079 for each submission to the IETF secretary of the draft. No version 1080 numbers may be skipped. 1082 4.1.4. How to speed up the process 1083 There a number of ways to lose a lot of time in the above process. 1084 This section discusses what to do and what to avoid. 1086 o Do not update the draft only for the meeting deadline. An update 1087 to each meeting automatically limits the draft to three updates 1088 per year. Instead, ignore the meeting schedule and publish new 1089 versions as soon as possible. 1091 o Try to avoid requesting reviews when people are busy, like the 1092 weeks before a meeting. It is actually more likely that people 1093 have time for them directly after a meeting. 1095 o Perform draft updates quickly. A common mistake is that the 1096 authors let the draft slip. By performing updates to the draft 1097 text directly after getting resolution on an issue, things are 1098 speed up. This minimizes the delay that the author has direct 1099 control over. The time taken for reviews, responses from area 1100 directors and chairs, etc. can be much harder to speed up. 1102 o Do not fail to take human nature into account. It happens that 1103 people forget or need to be reminded about tasks. Send a kind 1104 reminder to the people you are waiting for if things take longer 1105 than expected. Ask people to estimate when they expect to fulfill 1106 the requested task. 1108 o Ensure there is enough review. It is common that documents take a 1109 long time and many iterations because not enough review is 1110 performed in each iteration. To improve the amount of review you 1111 get on your own document, trade review time with other document 1112 authors. Make a deal with some other document author that you 1113 will review their draft if they review yours. Even inexperienced 1114 reviewers can help with language, editorial or clarity issues. 1115 Try also approaching the more experienced people in the WG and 1116 getting them to commit to a review. The WG chairs cannot, even if 1117 desirable, be expected to review all versions. Due to workload 1118 the chairs may need to concentrate on key points in a draft 1119 evolution, like initial submissions, checking if a draft is ready 1120 to become a WG document or ready for WG last call. 1122 4.2. Other Standards bodies 1124 Other standards bodies may define RTP payloads in their own 1125 specifications. When they do this they are strongly recommended to 1126 contact the PAYLOAD WG chairs and request review of the work. It is 1127 recommended that at least two review steps are performed. The first 1128 should be early in the process when more fundamental issues can be 1129 easily resolved without abandoning a lot of effort. Then when 1130 nearing completion, but while it is still possible to update the 1131 specification, a second review should be scheduled. In that pass the 1132 quality can be assessed and hopefully no updates will be needed. 1133 Using this procedure can avoid both conflicting definitions and 1134 serious mistakes, like breaking certain aspects of the RTP model. 1136 RTP payload Media Types may be registered in the standards tree by 1137 other standard bodies. The requirements on the organization are 1138 outlined in the media types registration document [RFC4855] and 1139 [RFC6838]). This registration requires a request to the IESG, which 1140 ensures that the filled-in registration template is acceptable. To 1141 avoid last-minute problems with these registrations the registration 1142 template must be sent for review both to the PAYLOAD WG and the media 1143 types list (ietf-types@iana.org) and is something that should be 1144 included in the IETF reviews of the payload format specification. 1146 4.3. Proprietary and Vendor Specific 1148 Proprietary RTP payload formats are commonly specified when the real- 1149 time media format is proprietary and not intended to be part of any 1150 standardized system. However there are reasons why also proprietary 1151 formats should be correctly documented and registered: 1153 o Usage in a standardized signalling environment such as SIP/SDP. 1154 RTP needs to be configured with the RTP profiles, payload formats 1155 and their payload types being used. To accomplish this it is 1156 desirable to have registered media type names to ensure that the 1157 names do not collide with those of other formats. 1159 o Sharing with business partners. As RTP payload formats are used 1160 for communication, situations often arise where business partners 1161 would like to support a proprietary format. Having a well written 1162 specification of the format will save time and money for both 1163 sides, as interoperability will be much easier to accomplish. 1165 o To ensure interoperability between different implementations on 1166 different platforms. 1168 To avoid name collisions there is a central register keeping tracks 1169 of the registered Media Type names used by different RTP payload 1170 formats. When it comes to proprietary formats they should be 1171 registered in the vendor's own tree. All vendor specific 1172 registrations use sub-type names that start with "vnd.". 1173 Names in the vendor's own tree are not required to be registered with 1174 IANA. However registration is recommended if the Media Type is used 1175 at all in public environments. 1177 If interoperability at the RTP level is desired, a payload type 1178 specification should be standardized in the IETF following the 1179 process described above. The IETF does not require full disclosure 1180 of the codec when defining an RTP payload format to carry that codec, 1181 but a description must be provided that is sufficient to allow the 1182 IETF to judge whether the payload format is well designed. The Media 1183 Type identifier assigned to a standardized payload format of this 1184 sort will lie in the standards tree rather than the vendor tree. 1186 5. Designing Payload Formats 1188 The best summary of payload format design is KISS (Keep It Simple, 1189 Stupid). A simple payload format is easier to review for 1190 correctness, easier to implement, and has low complexity. 1191 Unfortunately, contradictory requirements sometimes make it hard to 1192 do things simply. Complexity issues and problems that occur for RTP 1193 payload formats are: 1195 Too many configurations: Contradictory requirements lead to the 1196 result that one configuration is created for each conceivable 1197 case. Such contradictory requirements are often between 1198 functionality and bandwidth. This outcome has two big 1199 disadvantages; First all configurations need to be implemented. 1200 Second, the user application must select the most suitable 1201 configuration. Selecting the best configuration can be very 1202 difficult and in negotiating applications, this can create 1203 interoperability problems. The recommendation is to try to select 1204 a very limited set of configurations (preferably one) that perform 1205 well for the most common cases and are capable of handling the 1206 other cases, but maybe not that well. 1208 Hard to implement: Certain payload formats may become difficult to 1209 implement both correctly and efficiently. This needs to be 1210 considered in the design. 1212 Interaction with general mechanisms: Special solutions may create 1213 issues with deployed tools for RTP, such as tools for more robust 1214 transport of RTP. For example, a requirement for a non-broken 1215 sequence number space creates issues for mechanisms relying on 1216 payload type switching interleaving media-independent resilience 1217 within a stream. 1219 5.1. Features of RTP Payload Formats 1221 There are a number of common features in RTP payload formats. There 1222 is no general requirements to support these features; instead, their 1223 applicability must be considered for each payload format. It may in 1224 fact be that certain features are not even applicable. 1226 5.1.1. Aggregation 1228 Aggregation allows for the inclusion of multiple application data 1229 units (ADUs) within the same RTP payload. This is commonly supported 1230 for codecs that produce ADUs of sizes smaller than the IP MTU. Do 1231 remember that the MTU may be significantly larger than 1500 bytes. 1232 An MTU of 9000 bytes is available today and an MTU of 64k may be 1233 available in the future. Many speech codecs have the property of 1234 ADUs of a few fixed sizes. Video encoders may generally produce ADUs 1235 of quite flexible sizes. Thus the need for aggregation may be less. 1236 However in certain use cases the possibility to aggregate multiple 1237 ADUs especially for different playback times is useful. 1239 The main disadvantage of aggregation is the extra delay introduced 1240 (due to buffering until a sufficient number of ADUs have been 1241 collected at the sender) and reduced robustness against packet loss. 1242 Aggregation also introduces buffering requirements at the receiver. 1244 5.1.2. Fragmentation 1246 If the real-time media format has the property that it may produce 1247 ADUs that are larger than common MTU sizes then fragmentation support 1248 should be considered. An RTP Payload format may always fall back on 1249 IP fragmentation, however as discussed in RFC 2736 this has some 1250 drawbacks. Mainly that IP fragmented packets commonly are discarded 1251 in the network, especially by Network Address Translators or 1252 Firewalls. The usage of RTP payload format-level fragmentation 1253 allows for more efficient usage of RTP packet loss recovery 1254 mechanisms. It may also in some cases also allow better usage of 1255 partial ADUs by doing media specific fragmentation at media specific 1256 boundaries. 1258 5.1.3. Interleaving and Transmission Re-Scheduling 1260 Interleaving has been implemented in a number of payload formats to 1261 allow for less quality reduction when packet loss occurs. When 1262 losses are bursty and several consecutive packets are lost, the 1263 impact on quality can be quite severe. Interleaving is used to 1264 convert that burst loss to several spread-out individual packet 1265 losses. It can also be used when several ADUs are aggregated in the 1266 same packets. A loss of an RTP packet with several ADUs in the 1267 payload has the same affect as a burst loss if the ADUs would have 1268 been transmitted in individual packets. To reduce the burstiness of 1269 the loss, the data present in an aggregated payload may be 1270 interleaved, thus spread the loss over a longer time period. 1272 A requirement for doing interleaving within an RTP payload format is 1273 the aggregation of multiple ADUs. For formats that do not use 1274 aggregation there is still a possibility of implementing a 1275 transmission order re-scheduling mechanism. That has the effect that 1276 the packets transmitted consecutively originate from different points 1277 in the media stream. This can be used to mitigate burst losses, 1278 which may be useful if one transmits packets at frequent intervals. 1279 However it may also be used to transmit more significant data earlier 1280 in combination with RTP retransmission to allow for more graceful 1281 degradation and increased possibility to receive the most important 1282 data, e.g. intra frames of video. 1284 The drawback of interleaving is the significantly increased 1285 transmission buffering delay, making it less useful for low-delay 1286 applications. It may also create significant buffering requirements 1287 on the receiver. That buffering is also problematic as it is usually 1288 difficult to indicate when a receiver may start consume data and 1289 still avoid buffer under run caused by the interleaving mechanism 1290 itself. Transmission re-scheduling is only useful in a few specific 1291 cases, as in streaming with retransmissions. The potential gains 1292 must be weighted against the complexity of these schemes. 1294 5.1.4. Media Back Channels 1296 A few RTP payload formats have implemented back channels within the 1297 media format. Those have been for specific features, like the AMR 1298 [RFC4867] codec mode request (CMR) field. The CMR field is used in 1299 the operation of gateways to circuit-switched voice to allow an IP 1300 terminal to react to the circuit-switched network's need for a 1301 specific encoder mode. A common motivation for media back channels 1302 is the need to have signalling in direct relation to the media or the 1303 media path. 1305 If back channels are considered for an RTP payload format they should 1306 be for a specific requirements which cannot be easily satisfied by 1307 more generic mechanisms within RTP or RTCP. 1309 5.1.5. Media Scalability 1311 Some codecs support various types of media scalability, i.e. some 1312 data of a media stream may be removed to adapt the media's 1313 properties, such as bitrate and quality. The adaptation may be 1314 applied in the following dimensions of the media: 1316 Temporal: For video codecs it is possible to adapt the frame rate, 1317 e.g. for H.264 [RFC6184]. 1319 Spatial: Video codecs supporting scalability may adapt the 1320 resolution, e.g. in SVC [RFC6190]. 1322 Quality: The quality of the media stream may be scaled by adapting 1323 the accuracy of the coding process, as, e.g. possible with Signal 1324 to Noise Ratio (SNR) fidelity scalability of SVC [RFC6190]. 1326 At the time of writing this document, codecs that support scalability 1327 have a bit of revival. It has been realized that getting the 1328 required functionality for supporting the features of the media 1329 stream into the RTP framework is quite challenging. One of the 1330 recent examples for layered and scalable codecs is Scalable Video 1331 Coding [RFC6190] (SVC). 1333 SVC is a good example for a payload format supporting media 1334 scalability features, which have been in its basic form already 1335 included in RTP. A layered codec supports the dropping of data parts 1336 of a media stream, i.e. RTP packets may be not transmitted or 1337 forwarded to a client in order to adapt the media stream rate as well 1338 as the media stream quality, while still providing a decodable subset 1339 of the media stream to a client. One example for using the 1340 scalability feature may be an RTP Mixer (Multipoint Control Unit) 1341 which controls the rate and quality sent out to participants in a 1342 communication based on dropping RTP packets. Another example may be 1343 an transport channel which allows for differentiation in Quality of 1344 Service (QoS) parameters based on RTP sessions in a multicast 1345 session. In such a case, the more important packets of the scalable 1346 media stream (base layer) may get better QoS parameters, then the 1347 less important packets (enhancement layer) in order to provide some 1348 kind of graceful degradation. The scalability features required for 1349 allowing an adaptive transport as described in the two examples above 1350 are based on RTP multiplexing in order to identify the packets to be 1351 dropped or transmitted/forwarded. The multiplexing features defined 1352 for Scalable Video Coding [RFC6190] are: 1354 single session transmission (SST), where all media layers of the 1355 media are transported as single source (SSRC) in a single RTP 1356 session; as well as 1358 multi session transmission (MST), in RTP defined as session 1359 multiplexing (Section 3.2.3), where different media layers or a 1360 set of media layers are transported in different RTP sessions. 1362 In the first case (SST), additional in-band as well as out-of-band 1363 signaling is required in order to allow identification of packets 1364 belonging to a specific media layer. Furthermore, an adaptation of 1365 the media stream requires dropping of specific packets in order to 1366 provide the client with a compliant media stream. In case of using 1367 encryption, it is typically required for an adapting network device 1368 to be in the security context to allow packet dropping and providing 1369 an intact RTP session to the client. This typically requires the 1370 network device to be an RTP mixer. 1372 In general having a media unaware network device dropping excessive 1373 packets will be more problematic than having a Media Aware Network 1374 Entity (MANE). First is the need to understand the media format and 1375 know which ADUs or payloads that belongs to the layers, that no other 1376 layer will be dependent on after the dropping. Secondly, if the MANE 1377 can work as RTP mixer or translator it can rewrite the RTP and RTCP 1378 in such a way that the receiver will not suspect non-intentional RTP 1379 packet losses needing repair actions. This as the receiver can't 1380 determine if a lost packet was an important base layer packet or one 1381 of the less important extension layers. 1383 In the second case (MST), the out-of-band signaling typically 1384 provides enough information to identify the media layers and its 1385 properties. The decision for dropping packets is based on the 1386 Network Address which identifies the RTP session to be dropped. In 1387 order to allow correct data provision to a decoder after reception 1388 from different sessions, data re-alignment mechanisms are described 1389 for Scalable Video Coding [RFC6190]. A more generic one is also 1390 described in Rapid Sync for RTP flows [RFC6051], which is purely 1391 based on existing RTP mechanisms, i.e. the NTP timestamp, for inter- 1392 session synchronization. Another signaling feature is the generic 1393 indication of dependencies of RTP sessions in SDP, as defined in the 1394 Media Decoding Dependency Grouping in SDP [RFC5583]. 1396 When QoS settings, e.g. DiffServ markings, are used to ensure that 1397 the extension layers are dropped prior the base layer the receiving 1398 end-point has the benefit in MST to know which layer or set of layers 1399 the missing packets belong as it will be bound to different RTP 1400 sessions. Thus explicitly indicating the importance of the loss. 1402 5.1.6. High Packet Rates 1404 Some media codecs require high packet rates, and in these cases the 1405 RTP sequence number wraps too quickly. As rule of thumb, it must not 1406 be possible to wrap the sequence number space in less than 2 minutes 1407 (TCP maximum segment lifetime). If earlier wrapping may occur then 1408 the payload format should specify an extended sequence number field 1409 to allow the receiver to determine where a specific payload belongs 1410 in the sequence, even in the face of extensive reordering. The RTP 1411 payload format for uncompressed video [RFC4175] can be used as an 1412 example for such a field. 1414 6. Noteworthy Aspects in Payload Format Design 1416 This section provides a few examples of payload formats that are 1417 worth noting for good or bad design in general or specific details of 1418 their design. 1420 6.1. Audio Payloads 1422 The AMR [RFC4867], AMR-WB [RFC4867], EVRC [RFC3558], SMV [RFC3558] 1423 payload formats are all quite similar. They are all for frame-based 1424 audio codecs and use a table of content structure. Each frame has a 1425 table of contents entry that indicates the type of the frame and if 1426 additional frames are present. This is quite flexible but produces 1427 unnecessary overhead if the ADU is of fixed size and if when 1428 aggregating multiple ADUs they are commonly of the same type. In 1429 that case a solution like that in AMR-WB+ [RFC4352] may be more 1430 suitable. 1432 AMR-WB+ does contain one less desirable feature which is dependent on 1433 the media codec itself. The media codec produces a large range of 1434 different frame lengths in time perspective. The RTP timestamp rate 1435 is selected to have the very unusual value of 72 kHz despite the fact 1436 that output normally is at a sample rate of 48kHz. The 72 kHz 1437 timestamp rate is the smallest found value that would make all of the 1438 frames the codec could produce result in an integer frame length in 1439 RTP timestamp ticks. This way, a receiver can always correctly place 1440 the frames in relation to any other frame, even when the frame length 1441 changes. The downside is that the decoder outputs for certain frame 1442 lengths is in fact partial samples. The result is that the output in 1443 samples from the codec will vary from frame to frame, potentially 1444 making implementation more difficult. 1446 The RTP payload format for MIDI [RFC6295] contains some interesting 1447 features. MIDI is an audio format sensitive to packet losses, as the 1448 loss of a "note off" command will result in a note being stuck in an 1449 "on" state. To counter this a recovery journal is defined that 1450 provides a summarized state that allows the receiver to recover from 1451 packet losses quickly. It also uses RTCP and the reported highest 1452 sequence number to be able to prune the state the recovery journal 1453 needs to contain. These features appear limited in applicability to 1454 media formats that are highly stateful and primarily use symbolic 1455 media representations. 1457 There exist a security concern with variable bit-rate audio and 1458 speech codecs that changes their payload length based on the input 1459 data. This can leak information, especially in structured 1460 communication like speech recognition prompt service that asks people 1461 to enter information verbally. This issue also exist to some degree 1462 for discontinuous transmission as that allows the length of phrases 1463 to be determined. The issue is further discussed in Guidelines for 1464 the Use of Variable Bit Rate Audio with Secure RTP [RFC6562] which 1465 needs to read by anyone writing an RTP payload format for an audio or 1466 speech codec with these properties. 1468 6.2. Video 1470 The definition of RTP payload formats for video has seen an evolution 1471 from the early ones such as H.261 towards the latest for VC-1 and 1472 H.264. 1474 The H.264 RTP payload format [RFC3984] can be seen as a smorgasbord 1475 of functionality, some of it such as the interleaving being pretty 1476 advanced. The reason for this was to ensure that the majority of 1477 applications considered by the ITU-T and MPEG that can be supported 1478 by RTP are indeed supported. This has created a payload format that 1479 rarely is fully implemented. Despite that, no major issues with 1480 interoperability has been reported with one exception namely the 1481 offer/answer and parameter signalling, which resulted in a revised 1482 specification [RFC6184]. However, complaints about its complexity 1483 are common. 1485 The RTP payload format for uncompressed video [RFC4175] must be 1486 mentioned in this context as it contains a special feature not 1487 commonly seen in RTP payload formats. Due to the high bit-rate and 1488 thus packet rate of uncompressed video (gigabits rather than 1489 megabits) the payload format includes a field to extend the RTP 1490 sequence number since the normal 16-bit one can wrap in less than a 1491 second. [RFC4175] also specifies a registry of different color sub- 1492 samplings that can be re-used in other video RTP payload formats. 1494 Both, the H.264 and the uncompressed video format enables the 1495 implementor to fulfill the goals of application level framing, i.e. 1496 each individual RTP Packet's payload can be independently decoded and 1497 its content used to create a video frame (or part of) and that 1498 irrespective of whether preceding packets has been lost (See 1499 Section 4) [RFC2736]. For uncompressed this is straightforward as 1500 each pixel is independently represented from others and its location 1501 in the video frame known. H.264 is more dependent on the actual 1502 implementation, configuration of the video encoder and usage of the 1503 RTP payload format. 1505 The common challenge with video is that in most cases a single 1506 compressed video frame don't fit into a single IP packet. Thus, the 1507 compressed representation of a video frame needs to be split over 1508 multiple packets. This can be done unintelligent with a basic 1509 payload level fragmentation method or more integrated by interfacing 1510 with the encoder's possibilities to create ADUs that are 1511 independently and fits the MTU for the RTP packet. The later is more 1512 robust and commonly recommended unless strong packet loss mechanisms 1513 are used and sufficient delay budget for the repair exist. Commonly 1514 both payload level fragmentation as well as explaining how tailored 1515 ADUs can be created are needed in an video payload format. Also the 1516 handling of crucial meta data, like H.264 Parameter Sets needs to be 1517 considered as decoding is not possible without receiving the used 1518 parameter sets. 1520 6.3. Text 1522 Only a single format text format has been standardized in IETF, 1523 namely T.140 [RFC4103]. The 3GPP Timed Text format [RFC4396] should 1524 be considered to be text, even though in the end was registered as a 1525 video format. It was registered in that part of the tree because it 1526 deals with decorated text, usable for subtitles and other 1527 embellishments of video. However, it has many of the properties that 1528 text formats generally have. 1530 The RTP payload format for T.140 was designed with high reliability 1531 in mind as real-time text commonly is an extremely low bit-rate 1532 application. Thus, it recommends the use of RFC 2198 with many 1533 generations of redundancy. However, the format failed to provide a 1534 text block specific sequence number and relies instead of the RTP one 1535 to detect loss. This makes detection of missing text blocks 1536 unnecessarily difficult and hinders deployment with other robustness 1537 mechanisms that would involve switching the payload type as that may 1538 result in erroneous error marking in the T.140 text stream. 1540 6.4. Application 1542 The application content type contains at the time of writing two 1543 media types that aren't RTP transport robustness tools such as FEC 1544 [RFC3009][RFC5109][RFC6015][RFC6682] and RTP retransmission 1545 [RFC4588]. 1547 The first one is H224 [RFC4573] which enables far end camera control 1548 over RTP. This is not an IETF defined RTP format, only an IETF 1549 performed registration. 1551 The second one is the RTP Payload Format for Society of Motion 1552 Picture and Television Engineers (SMPTE) ST 336 Encoded Data 1554 [RFC6597] which carries generic key length value (KLV) triplets. 1555 These pairs may contain arbitrary binary meta data associated with 1556 video transmissions. It has a very basic fragmentation mechanism 1557 requiring packet loss free reception not only of the triplet itself 1558 but also one packet before and after the sequence of fragmented KLV 1559 triplet to ensure correct reception. Specific KLV triplets 1560 themselves may have recommendation on how to handle non-complete ones 1561 allowing the use and repair of them. In general the application 1562 using such a mechanism must be robust to errors and also use some 1563 combination of application level repetition, RTP level transport 1564 robustness tools and network level requirements to achieve low levels 1565 of packet loss rates and repair of KLV triplets. 1567 The application top media type (application/) should be 1568 considered to be used when the payload format defined is not clearly 1569 matching any of the existing media types (audio, video or text) or 1570 are of a generic nature. However, existing limitations in for 1571 example SDP, has resulted in that generic mechanisms normally are 1572 registered in all media types to be possible to have associated with 1573 any existing media types in an RTP session. 1575 7. Important Specification Sections 1577 A number of sections in the payload format draft that need some 1578 special consideration. These include the Security and IANA 1579 Considerations sections. 1581 7.1. Media Format Description 1583 The intention of this section is to enable reviewers and other 1584 readers to get an overview of the capabilities and major properties 1585 of the media format. It should be kept short and concise and is not 1586 a complete replacement for reading the media format specification. 1588 7.2. Security Considerations 1590 All Internet drafts require a Security Considerations section. The 1591 security considerations section in an RTP payload format needs to 1592 concentrate on the security properties this particular format has. 1593 Some payload formats have very few specific issues or properties and 1594 can fully fall back on the security considerations for RTP in general 1595 and those of the profile being used. Because those documents are 1596 always applicable, a reference to these is normally placed first in 1597 the security considerations section. There is suggested text in the 1598 template below. 1600 The security issues of confidentiality, integrity protection, replay 1601 protection and source authentication are common issue for all payload 1602 formats. These should be solved by mechanisms external to the 1603 payload and do not need any special consideration in the payload 1604 format except for an reminder on these issues. There exist 1605 exceptions, such as payload formats that includes security 1606 functionality, like ISMAcrypt [ISMACrypt2]. Reasons for this 1607 division is further documented in "Securing the RTP Protocol 1608 Framework: Why RTP Does Not Mandate a Single Media Security Solution" 1609 [I-D.ietf-avt-srtp-not-mandatory]. For a survey of available 1610 mechanisms to meet these goals, please review "Options for Securing 1611 RTP Sessions" [I-D.ietf-avtcore-rtp-security-options]. This also 1612 includes key-exchange mechanisms for the security mechanisms, which 1613 can be both integrated or separate. The choice of key-management can 1614 have significant impact on the security properties of the RTP based 1615 application. Suitable stock text to inform people about this is 1616 included in the template. 1618 Potential security issues with an RTP payload format and the media 1619 encoding that needs to be considered are: 1621 1. That the decoding of the payload format or its media shows 1622 substantial non-uniformity, either in output or in complexity to 1623 perform the decoding operation. For example a generic non- 1624 destructive compression algorithm may provide an output of almost 1625 an infinite size for a very limited input, thus consuming memory 1626 or storage space out of proportion with what the receiving 1627 application expected. Such inputs can cause some sort of 1628 disruption, i.e. a denial of service attack on the receiver side 1629 by preventing that host from producing any goodput. Certain 1630 decoding operations may also vary in the amount of processing 1631 needed to perform those operations depending on the input. This 1632 may also be a security risk if it is possible to raise processing 1633 load significantly above nominal simply by designing a malicious 1634 input sequence. If such potential attacks exist, this must be 1635 made clear in the security considerations section to make 1636 implementers aware of the need to take precautions against such 1637 behavior. 1639 2. The inclusion of active content in the media format or its 1640 transport. "Active content" means scripts etc. that allow an 1641 attacker to perform potentially arbitrary operations on the 1642 receiver. Most active contents has limited possibility to access 1643 the system or perform operations outside a protected sandbox. 1644 RFC 4855 [RFC4855] has a requirement that it be noted in the 1645 media types registration if the payload format contains active 1646 content or not. If the payload format has active content it is 1647 strongly recommended that references to any security model 1648 applicable for such content are provided. A boilerplate text for 1649 "no active content" is included in the template. This must be 1650 changed if the format actually carries active content. 1652 3. Some media formats allow for the carrying of "user data", or 1653 types of data which are not known at the time of the 1654 specification of the payload format. Such data may be a security 1655 risk and should be mentioned. 1657 4. Audio or Speech codecs supporting variable bit-rate based on 1658 audio/speech input or having discontinuous transmission support 1659 must consider the issues discussed in Guidelines for the Use of 1660 Variable Bit Rate Audio with Secure RTP [RFC6562]. 1662 Suitable stock text for the security considerations section is 1663 provided in the template in the appendix. However, authors do need 1664 to actively consider any security issues from the start. Failure to 1665 address these issues may block approval and publication. 1667 7.3. Congestion Control 1669 RTP and its profiles do discuss congestion control. There are 1670 ongoing work in IETF with both a basic circuit breaker mechanism 1671 [I-D.ietf-avtcore-rtp-circuit-breakers] using basic RTCP messages 1672 intended to prevent persistent congestion, but also work on more 1673 capable congestion avoidance / bit-rate adaptation mechanism in the 1674 RMCAT WG. 1676 Congestion control is an important issue in any usage in non- 1677 dedicated networks. For that reason it is recommended that all RTP 1678 payload format documents discuss the possibilities that exist to 1679 regulate the bit-rate of the transmissions using the described RTP 1680 payload format. Some formats may have limited or step wise 1681 regulation of bit-rate. Such limiting factors should be discussed. 1683 7.4. IANA Considerations 1685 Since all RTP Payload formats contain a Media Type specification, 1686 they also need an IANA Considerations section. The Media Type name 1687 must be registered and this is done by requesting that IANA register 1688 that media name. When that registration request is written it shall 1689 also be requested that the media type is included under the "RTP 1690 Payload Format media types" list part of the RTP registry (http:// 1691 www.iana.org/assignments/rtp-parameters). 1693 Parameters for the payload format needs to be included in this 1694 registration and can be specified as required or optional ones. 1695 Independently the format of these should be such that they can be 1696 included in the SDP attribute "a=fmtp" string (See Section 6 1697 [RFC4566]) which is the common mapping. Some parameters, such as 1698 "Channel" are normally mapped to the rtpmap attribute instead, see 1699 Section 3 of [RFC4855]. 1701 In addition to the above request for media type registration, some 1702 payload formats may have parameters where in the future new parameter 1703 values need to be added. In these cases a registry for that 1704 parameter must be created. This is done by defining the registry in 1705 the IANA Considerations section. BCP 26 [RFC5226] provides 1706 guidelines to specifying such registries. Care should be taken when 1707 defining the policy for new registrations. 1709 Before specifying a new registry it is worth checking the existing 1710 ones in the IANA "MIME Media Type Sub-Parameter Registries" list. 1711 For example video formats needing a media parameter expressing color 1712 sub-sampling may be able to reuse those defined for video/raw 1713 [RFC4175]. 1715 8. Authoring Tools 1717 This section provides information about some tools that may be used. 1718 Don't feel pressured to follow these recommendations. There exist a 1719 number of alternatives. But these suggestions are worth checking out 1720 before deciding that the field is greener somewhere else. 1722 8.1. Editing Tools 1724 There are many choices when it comes to tools to choose for authoring 1725 Internet drafts. However in the end they need to be able to produce 1726 a draft that conforms to the Internet Draft requirements. If you 1727 don't have any previous experience with authoring Internet drafts 1728 XML2RFC does have some advantages. It helps by create a lot of the 1729 necessary boiler plate in accordance with the latest rules, thus 1730 reducing the effort. It also speeds up publication after approval as 1731 the RFC-editor can use the source XML document to produce the RFC 1732 more quickly. 1734 Another common choice is to use Microsoft Word and a suitable 1735 template, see [RFC5385] to produce the draft and print that to file 1736 using the generic text printer. It has some advantages when it comes 1737 to spell checking and change bars. However Word may also produce 1738 some problems, like changing formatting, and inconsistent results 1739 between what one sees in the editor and in the generated text 1740 document, at least according to the authors' personal experience. 1742 8.2. Verification Tools 1744 There are a few tools that are very good to know about when writing a 1745 draft. These help check and verify parts of one's work. These tools 1746 can be found at http://tools.ietf.org. 1748 o ID Nits checker. It checks that the boiler plate and some other 1749 things that are easily verifiable by machine are okay in your 1750 draft. Always use it before submitting a draft to avoid direct 1751 refusal in the submission step. 1753 o ABNF Parser and verification. Checks that your ABNF parses 1754 correctly and warns about loose ends, like undefined symbols. 1755 However the actual content can only be verified by humans knowing 1756 what it intends to describe. 1758 o RFC diff. A diff tool that is optimized for drafts and RFCs. For 1759 example it does not point out that the footer and header have 1760 moved in relation to the text on every page. 1762 9. IANA Considerations 1764 This document makes no request of IANA. 1766 Note to RFC Editor: this section may be removed on publication as an 1767 RFC. 1769 10. Security Considerations 1771 As this is an informational document about writing drafts that are 1772 intended to become RFCs there are no direct security considerations. 1773 However the document does discuss the writing of security 1774 considerations sections and what should be particularly considered 1775 when specifying RTP payload formats. 1777 11. Contributors 1779 The author would like to thank Tom Taylor for the editing pass of the 1780 whole document and contributing text regarding proprietary RTP 1781 payload formats. Thanks also goes to Thomas Schierl who contributed 1782 text regarding Media Scalability features in payload formats. 1784 12. Acknowledgements 1786 The author would like to thank the individuals who have provided 1787 input to this document. These individuals include John Lazzaro, Ali 1788 C. Begen, Colin Perkins and Tom Taylor. 1790 13. Informative References 1792 [CSP-RTP] Perkins, C., "RTP: Audio and Video for the Internet", June 1793 2003. 1795 [I-D.ietf-avt-srtp-not-mandatory] 1796 Perkins, C. and M. Westerlund, "Securing the RTP Protocol 1797 Framework: Why RTP Does Not Mandate a Single Media 1798 Security Solution", draft-ietf-avt-srtp-not-mandatory-13 1799 (work in progress), May 2013. 1801 [I-D.ietf-avtcore-rtp-circuit-breakers] 1802 Perkins, C. and V. Singh, "Multimedia Congestion Control: 1803 Circuit Breakers for Unicast RTP Sessions", draft-ietf- 1804 avtcore-rtp-circuit-breakers-02 (work in progress), 1805 February 2013. 1807 [I-D.ietf-avtcore-rtp-security-options] 1808 Westerlund, M. and C. Perkins, "Options for Securing RTP 1809 Sessions", draft-ietf-avtcore-rtp-security-options-03 1810 (work in progress), May 2013. 1812 [ISMACrypt2] 1813 , "ISMA Encryption and Authentication, Version 2.0 release 1814 version", November 2007. 1816 [MACOSFILETYPES] 1817 Apple Knowledge Base Article 1818 55381, "Mac OS: 1819 File Type and Creator Codes, and File Formats", 1993. 1821 [RFC-ED] http://www.rfc-editor.org/policy.html, "RFC Editorial 1822 Guidelines and Procedures", July 2008. 1824 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1825 3", BCP 9, RFC 2026, October 1996. 1827 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 1828 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 1829 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 1830 September 1997. 1832 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1833 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1835 [RFC2360] Scott, G.D., "Guide for Internet Standards Writers", BCP 1836 22, RFC 2360, June 1998. 1838 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 1839 Procedures", BCP 25, RFC 2418, September 1998. 1841 [RFC2508] Casner, S.L. and V. Jacobson, "Compressing IP/UDP/RTP 1842 Headers for Low-Speed Serial Links", RFC 2508, February 1843 1999. 1845 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1846 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1847 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1849 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 1850 Payload Format Specifications", BCP 36, RFC 2736, December 1851 1999. 1853 [RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time 1854 Transport Protocol Management Information Base", RFC 2959, 1855 October 2000. 1857 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1858 Announcement Protocol", RFC 2974, October 2000. 1860 [RFC3009] Rosenberg, J. and H. Schulzrinne, "Registration of 1861 parityfec MIME types", RFC 3009, November 2000. 1863 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1864 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 1865 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 1866 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 1867 Compression (ROHC): Framework and four profiles: RTP, UDP, 1868 ESP, and uncompressed", RFC 3095, July 2001. 1870 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1871 A., Peterson, J., Sparks, R., Handley, M., and E. 1873 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1874 June 2002. 1876 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1877 with Session Description Protocol (SDP)", RFC 3264, June 1878 2002. 1880 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1881 "Introduction and Applicability Statements for Internet- 1882 Standard Management Framework", RFC 3410, December 2002. 1884 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 1885 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 1886 High Delay, Packet Loss and Reordering", RFC 3545, July 1887 2003. 1889 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1890 Jacobson, "RTP: A Transport Protocol for Real-Time 1891 Applications", STD 64, RFC 3550, July 2003. 1893 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1894 Video Conferences with Minimal Control", STD 65, RFC 3551, 1895 July 2003. 1897 [RFC3558] Li, A., "RTP Payload Format for Enhanced Variable Rate 1898 Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 1899 3558, July 2003. 1901 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1902 Multicast (SSM)", RFC 3569, July 2003. 1904 [RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. 1905 Romascanu, "Introduction to the Remote Monitoring (RMON) 1906 Family of MIB Modules", RFC 3577, August 2003. 1908 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 1909 Protocol Extended Reports (RTCP XR)", RFC 3611, November 1910 2003. 1912 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1913 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1914 RFC 3711, March 2004. 1916 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1917 G. Fairhurst, "The Lightweight User Datagram Protocol 1918 (UDP-Lite)", RFC 3828, July 2004. 1920 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 1921 Technology", BCP 79, RFC 3979, March 2005. 1923 [RFC3984] Wenger, S., Hannuksela, M.M., Stockhammer, T., Westerlund, 1924 M., and D. Singer, "RTP Payload Format for H.264 Video", 1925 RFC 3984, February 2005. 1927 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1928 Conversation", RFC 4103, June 2005. 1930 [RFC4170] Thompson, B., Koren, T., and D. Wing, "Tunneling 1931 Multiplexed Compressed RTP (TCRTP)", BCP 110, RFC 4170, 1932 November 2005. 1934 [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for 1935 Uncompressed Video", RFC 4175, September 2005. 1937 [RFC4352] Sjoberg, J., Westerlund, M., Lakaniemi, A., and S. Wenger, 1938 "RTP Payload Format for the Extended Adaptive Multi-Rate 1939 Wideband (AMR-WB+) Audio Codec", RFC 4352, January 2006. 1941 [RFC4396] Rey, J. and Y. Matsui, "RTP Payload Format for 3rd 1942 Generation Partnership Project (3GPP) Timed Text", RFC 1943 4396, February 2006. 1945 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1946 Description Protocol", RFC 4566, July 2006. 1948 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1949 and RTP Control Protocol (RTCP) Packets over Connection- 1950 Oriented Transport", RFC 4571, July 2006. 1952 [RFC4573] Even, R. and A. Lochbaum, "MIME Type Registration for RTP 1953 Payload Format for H.224", RFC 4573, July 2006. 1955 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1956 "Extended RTP Profile for Real-time Transport Control 1957 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 1958 2006. 1960 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1961 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1962 July 2006. 1964 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1965 Encodings", RFC 4648, October 2006. 1967 [RFC4844] Daigle, L. Internet Architecture Board, "The RFC Series 1968 and RFC Editor", RFC 4844, July 2007. 1970 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1971 Formats", RFC 4855, February 2007. 1973 [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, 1974 "RTP Payload Format and File Storage Format for the 1975 Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband 1976 (AMR-WB) Audio Codecs", RFC 4867, April 2007. 1978 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1979 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1981 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 1982 Correction", RFC 5109, December 2007. 1984 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1985 Real-time Transport Control Protocol (RTCP)-Based Feedback 1986 (RTP/SAVPF)", RFC 5124, February 2008. 1988 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1989 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1990 May 2008. 1992 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1993 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1995 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 1996 Header Extensions", RFC 5285, July 2008. 1998 [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide 1999 to the IETF Trust", BCP 78, RFC 5378, November 2008. 2001 [RFC5385] Touch, J., "Version 2.0 Microsoft Word Template for 2002 Creating Internet Drafts and RFCs", RFC 5385, February 2003 2010. 2005 [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC 2006 5484, March 2009. 2008 [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 2009 Dependency in the Session Description Protocol (SDP)", RFC 2010 5583, July 2009. 2012 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 2013 Header Compression (ROHC) Framework", RFC 5795, March 2014 2010. 2016 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 2017 Time Protocol Version 4: Protocol and Algorithms 2018 Specification", RFC 5905, June 2010. 2020 [RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity 2021 Forward Error Correction (FEC)", RFC 6015, October 2010. 2023 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 2024 Flows", RFC 6051, November 2010. 2026 [RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP 2027 Payload Format for H.264 Video", RFC 6184, May 2011. 2029 [RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. 2030 Eleftheriadis, "RTP Payload Format for Scalable Video 2031 Coding", RFC 6190, May 2011. 2033 [RFC6295] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for 2034 MIDI", RFC 6295, June 2011. 2036 [RFC6354] Xie, Q., "Forward-Shifted RTP Redundancy Payload Support", 2037 RFC 6354, August 2011. 2039 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 2040 Correction (FEC) Framework", RFC 6363, October 2011. 2042 [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the 2043 Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 2044 October 2011. 2046 [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of 2047 Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2048 2012. 2050 [RFC6597] Downs, J. and J. Arbeiter, "RTP Payload Format for Society 2051 of Motion Picture and Television Engineers (SMPTE) ST 336 2052 Encoded Data", RFC 6597, April 2012. 2054 [RFC6682] Watson, M., Stockhammer, T., and M. Luby, "RTP Payload 2055 Format for Raptor Forward Error Correction (FEC)", RFC 2056 6682, August 2012. 2058 [RFC6722] Hoffman, P., "Publishing the "Tao of the IETF" as a Web 2059 Page", RFC 6722, August 2012. 2061 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2062 Specifications and Registration Procedures", BCP 13, RFC 2063 6838, January 2013. 2065 Appendix A. RTP Payload Format Template 2067 This section contains a template for writing an RTP payload format in 2068 form as a Internet draft. Text within [...] are instructions and 2069 must be removed. Some text proposals that are included are 2070 conditional. "..." is used to indicate where further text should be 2071 written. 2073 A.1. Title 2075 [The title shall be descriptive but as compact as possible. RTP is 2076 allowed and recommended abbreviation in the title] 2078 RTP Payload format for ... 2080 A.2. Front page boilerplate 2082 Status of this Memo 2084 [Insert the IPR notice and copyright boiler plate from BCP 78 and 79 2085 that applies to this draft.] 2087 [Insert the current Internet Draft document explanation. At the time 2088 of publishing it was:] 2090 Internet-Drafts are working documents of the Internet Engineering 2091 Task Force (IETF). Note that other groups may also distribute 2092 working documents as Internet-Drafts. The list of current Internet- 2093 Drafts is at http://datatracker.ietf.org/drafts/current/. 2095 Internet-Drafts are draft documents valid for a maximum of six months 2096 and may be updated, replaced, or obsoleted by other documents at any 2097 time. It is inappropriate to use Internet-Drafts as reference 2098 material or to cite them other than as "work in progress." 2100 A.3. Abstract 2102 [A payload format abstract should mention the capabilities of the 2103 format, for which media format is used, and a little about that codec 2104 formats capabilities. Any abbreviation used in the payload format 2105 must be spelled out here except the very well known like RTP. No 2106 references are allowed, no use of RFC 2119 language either.] 2108 A.4. Table of Content 2110 [All drafts over 15 pages in length must have an Table of Content.] 2112 A.5. Introduction 2114 [The introduction should provide a background and overview of the 2115 payload formats capabilities. No normative language in this section, 2116 i.e. no MUST, SHOULDs etc.] 2118 A.6. Conventions, Definitions and Acronyms 2120 [Define conventions, definitions and acronyms used in the document in 2121 this section. The most common definition used in RTP Payload formats 2122 are the RFC 2119 definitions of the upper case normative words, e.g. 2123 MUST and SHOULD.] 2125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 2126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 2127 document are to be interpreted as described in RFC 2119. 2129 A.7. Media Format Description 2131 [The intention of this section is to enable reviewers and persons to 2132 get an overview of the capabilities and major properties of the media 2133 format. It should be kept short and concise and is not a complete 2134 replacement for reading the media format specification.] 2136 A.8. Payload format 2138 [Overview of payload structure] 2140 A.8.1. RTP Header Usage 2142 [RTP header usage needs to be defined. The fields that absolutely 2143 need to be defined are timestamp and marker bit. Further field may 2144 be specified if used. All the rest should be left to their RTP 2145 specification definition] 2147 The remaining RTP header fields are used as specified in RTP [RFC 2148 3550]. 2150 A.8.2. Payload Header 2152 [Define how the payload header, if it exist, is structured and used.] 2154 A.8.3. Payload Data 2156 [The payload data, i.e. what the media codec has produced. Commonly 2157 done through reference to media codec specification which defines how 2158 the data is structured. Rules for padding may need to be defined to 2159 bring data to octet alignment.] 2161 A.9. Payload Examples 2163 [One or more examples are good to help ease the understanding of the 2164 RTP payload format.] 2166 A.10. Congestion Control Considerations 2168 [This section is to describe the possibility to vary the bit-rate as 2169 a response to congestion. Below is also a proposal for an initial 2170 text that reference RTP and profiles definition of congestion 2171 control.] 2173 Congestion control for RTP SHALL be used in accordance with RFC 3550 2174 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 2175 [RFC3551]. An additional requirement if best-effort service is being 2176 used is: users of this payload format MUST monitor packet loss to 2177 ensure that the packet loss rate is within acceptable parameters. 2179 A.11. Payload Format Parameters 2181 This RTP payload format is identified using the ... media type which 2182 is registered in accordance with RFC 4855 [RFC4855] and using the 2183 template of RFC 6838 [RFC6838]. 2185 A.11.1. Media Type Definition 2187 [Here the media type registration template from RFC 6838 is placed 2188 and filled out. This template is provided with some common RTP 2189 boilerplate.] 2191 Type name: 2193 Subtype name: 2195 Required parameters: 2197 Optional parameters: 2199 Encoding considerations: 2201 This media type is framed and binary, see section 4.8 in RFC6838 2202 [RFC6838]. 2204 Security considerations: 2206 Please see security consideration in RFCXXXX 2208 Interoperability considerations: 2210 Published specification: 2212 Applications that use this media type: 2214 Additional information: 2216 Deprecated alias names for this type: 2218 [Only applicable if there exists widely deployed alias for this 2219 media type; see Section 4.2.9 of [RFC6838]. Remove or use N/A 2220 otherwise.] 2222 Magic number(s): 2224 [Only applicable for media types that has file format 2225 specification. Remove or use N/A otherwise.] 2227 File extension(s): 2229 [Only applicable for media types that has file format 2230 specification. Remove or use N/A otherwise.] 2232 Macintosh file type code(s): 2234 [Only applicable for media types that has file format 2235 specification. Remove or use N/A otherwise.] 2237 Person & email address to contact for further information: 2239 Intended usage: 2241 [One of COMMON, LIMITED USE or OBSOLETE.] 2243 Restrictions on usage: 2245 [The below text is for media types that is only defined for RTP 2246 payload formats. There exist certain media types that are defined 2247 both as RTP payload formats and file transfer. The rules for such 2248 types are documented in RFC 4855 [RFC4855].] 2249 This media type depends on RTP framing, and hence is only defined 2250 for transfer via RTP [RFC3550]. Transport within other framing 2251 protocols is not defined at this time. 2253 Author: 2255 Change controller: 2257 IETF Payload working group delegated from the IESG. 2259 Provisional registration? (standards tree only): 2261 No 2263 (Any other information that the author deems interesting may be added 2264 below this line.) 2266 [From RFC 6838: 2268 Some discussion of Macintosh file type codes and their purpose can 2269 be found in [MACOSFILETYPES]. 2271 N/A", written exactly that way, can be used in any field if 2272 desired to emphasize the fact that it does not apply or that the 2273 question was not omitted by accident. Do not use 'none' or other 2274 words that could be mistaken for a response. 2276 Limited-use media types should also note in the applications list 2277 whether or not that list is exhaustive.] 2279 A.11.2. Mapping to SDP 2281 The mapping of the above defined payload format media type and its 2282 parameters SHALL be done according to Section 3 of RFC 4855 2283 [RFC4855]. 2285 [More specific rules only need to be included if some parameter does 2286 not match these rules.] 2288 A.11.2.1. Offer/Answer Considerations 2290 [Here write your offer/answer consideration section, please see 2291 Section 3.3.2.1 for help.] 2293 A.11.2.2. Declarative SDP Considerations 2295 [Here write your considerations for declarative SDP, please see 2296 Section 3.3.2.2 for help.] 2298 A.12. IANA Considerations 2300 This memo requests that IANA registers [insert media type name here] 2301 as specified in Appendix A.11.1. The media type is also requested to 2302 be added to the IANA registry for "RTP Payload Format MIME types" 2303 (http://www.iana.org/assignments/rtp-parameters). 2305 [See Section 7.4 and consider if any of the parameter needs a 2306 registered name space.] 2308 A.13. Security Considerations 2310 [See Section 7.2] 2312 RTP packets using the payload format defined in this specification 2313 are subject to the security considerations discussed in the RTP 2314 specification [RFC3550] , and in any applicable RTP profile such as 2315 RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ 2316 SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: 2317 Why RTP Does Not Mandate a Single Media Security Solution" 2318 [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload 2319 formats responsibility to discuss or mandate what solutions are used 2320 to meet the basic security goals like confidentiality, integrity and 2321 source authenticity for RTP in general. This responsibility lays on 2322 anyone using RTP in an application. They can find guidance on 2323 available security mechanisms and important considerations in Options 2324 for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. 2325 The rest of the this security consideration discusses the security 2326 impacting properties of the payload format itself. 2328 This RTP payload format and its media decoder do not exhibit any 2329 significant non-uniformity in the receiver-side computational 2330 complexity for packet processing, and thus are unlikely to pose a 2331 denial-of-service threat due to the receipt of pathological data. 2332 Nor does the RTP payload format contain any active content. 2334 [The previous paragraph may need editing due to the format breaking 2335 either of the statements. Fill in here any further potential 2336 security threats created by the payload format itself.] 2338 A.14. RFC Editor Considerations 2340 Note to RFC Editor: This section may be removed after carrying out 2341 all the instructions of this section. 2343 RFCXXXX is to be replaced by the RFC number this specification 2344 receives when published. 2346 A.15. References 2348 [References must be classified as either normative or informative and 2349 added to the relevant section. References should use descriptive 2350 reference tags.] 2352 A.15.1. Normative References 2354 [Normative references are those that are required to be used to 2355 correctly implement the payload format.] 2357 A.15.2. Informative References 2359 [All other references.] 2361 A.16. Author Addresses 2363 [All Authors need to include their Name and email addresses as a 2364 minimal. Commonly also surface mail and possibly phone numbers are 2365 included.] 2367 [The Template Ends Here!] 2369 Author's Address 2371 Magnus Westerlund 2372 Ericsson 2373 Farogatan 6 2374 SE-164 80 Kista 2375 Sweden 2377 Phone: +46 10 714 82 87 2378 Email: magnus.westerlund@ericsson.com