idnits 2.17.1 draft-ietf-payload-rtp-howto-03.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 (April 12, 2013) is 4032 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-12 == Outdated reference: A later version (-10) exists of draft-ietf-avtcore-rtp-security-options-02 -- 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 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5285 (Obsoleted by RFC 8285) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 13 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 April 12, 2013 5 Expires: October 14, 2013 7 How to Write an RTP Payload Format 8 draft-ietf-payload-rtp-howto-03 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 October 14, 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 . . . . . . . . . . . . . . . . . . 14 65 3.2.4. RTP Synchronization . . . . . . . . . . . . . . . . . 15 66 3.3. Signalling Aspects . . . . . . . . . . . . . . . . . . . 16 67 3.3.1. Media Types . . . . . . . . . . . . . . . . . . . . . 17 68 3.3.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . 18 69 3.4. Transport Characteristics . . . . . . . . . . . . . . . . 21 70 3.4.1. Path MTU . . . . . . . . . . . . . . . . . . . . . . 21 71 4. Specification Process . . . . . . . . . . . . . . . . . . . . 21 72 4.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . 21 73 4.1.1. Steps from Idea to Publication . . . . . . . . . . . 21 74 4.1.2. WG meetings . . . . . . . . . . . . . . . . . . . . . 24 75 4.1.3. Draft Naming . . . . . . . . . . . . . . . . . . . . 24 76 4.1.4. How to speed up the process . . . . . . . . . . . . . 24 77 4.2. Other Standards bodies . . . . . . . . . . . . . . . . . 25 78 4.3. Proprietary and Vendor Specific . . . . . . . . . . . . . 26 79 5. Designing Payload Formats . . . . . . . . . . . . . . . . . . 27 80 5.1. Features of RTP Payload Formats . . . . . . . . . . . . . 27 81 5.1.1. Aggregation . . . . . . . . . . . . . . . . . . . . . 27 82 5.1.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 28 83 5.1.3. Interleaving and Transmission Re-Scheduling . . . . . 28 84 5.1.4. Media Back Channels . . . . . . . . . . . . . . . . . 29 85 5.1.5. Media Scalability . . . . . . . . . . . . . . . . . . 29 86 5.1.6. High Packet Rates . . . . . . . . . . . . . . . . . . 31 87 6. Noteworthy Aspects in Payload Format Design . . . . . . . . . 32 88 6.1. Audio Payloads . . . . . . . . . . . . . . . . . . . . . 32 89 6.2. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 33 90 6.3. Text . . . . . . . . . . . . . . . . . . . . . . . . . . 33 91 6.4. Application . . . . . . . . . . . . . . . . . . . . . . . 34 92 7. Important Specification Sections . . . . . . . . . . . . . . 34 93 7.1. Media Format Description . . . . . . . . . . . . . . . . 34 94 7.2. Security Considerations . . . . . . . . . . . . . . . . . 35 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 . . . . . . . . . . . . . . . . . . . 37 100 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38 102 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38 103 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 104 13. Informative References . . . . . . . . . . . . . . . . . . . 38 105 Appendix A. RTP Payload Format Template . . . . . . . . . . . . 44 106 A.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 44 107 A.2. Front page boilerplate . . . . . . . . . . . . . . . . . 45 108 A.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . 45 109 A.4. Table of Content . . . . . . . . . . . . . . . . . . . . 45 110 A.5. Introduction . . . . . . . . . . . . . . . . . . . . . . 45 111 A.6. Conventions, Definitions and Acronyms . . . . . . . . . . 45 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 . . . . . . . . . . . . . . . . . . . . 46 118 A.10. Congestion Control Considerations . . . . . . . . . . . . 46 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 . . . . . . . . . . . . . . . . . . . 49 123 A.13. Security Considerations . . . . . . . . . . . . . . . . . 49 124 A.14. RFC Editor Considerations . . . . . . . . . . . . . . . . 50 125 A.15. References . . . . . . . . . . . . . . . . . . . . . . . 50 126 A.15.1. Normative References . . . . . . . . . . . . . . . . 50 127 A.15.2. Informative References . . . . . . . . . . . . . . . 50 128 A.16. Author Addresses . . . . . . . . . . . . . . . . . . . . 50 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 RTP Encryption: Section 9 of RFC 3550 describes a mechanism to 487 provide confidentiality of the RTP and RTCP packets, using default 488 DES encryption. It may use other encryption algorithms if both 489 end-points agree on one. This mechanism is not recommended due to 490 the weak security properties of the encryption algorithms used. 491 It also lacks integrity and source authentication capability. 493 SRTP: The profile for Secure RTP (SAVP) [RFC3711] and the derived 494 profile (SAVPF [RFC5124]) are a solution that provides 495 confidentiality, integrity protection and partial source 496 authentication. 498 IPsec: IPsec [RFC4301] may also be used to protect RTP and RTCP 499 packets. 501 TLS: TLS [RFC5246] may also be used to provide transport security 502 between two end-points of the TLS connection for a flow of RTP 503 packets that are framed over TCP. 505 DTLS: Datagram TLS [RFC6347] is an alternative to TLS that allows 506 TLS to be used over datagrams, like UDP. Thus it has the 507 potential for being used to protect RTP over UDP. However the 508 necessary signalling mechanisms for using it have not been 509 developed yet in any of the IETF real-time media application 510 signalling protocols. 512 DTSL-SRTP: This combination of DTLS [RFC6347] and SRTP [RFC3711] 513 uses DTLS as mechanism to negotiate key material and cipher suits 514 for SRTP and SRTP to protect the actual media transported by RTP. 515 DTLS-SRTP is a recommended solution for point-to-point RTP 516 sessions. "Framework for Establishing a Secure Real-time 517 Transport Protocol (SRTP) Security Context Using Datagram 518 Transport Layer Security (DTLS)" [RFC5763] is the core document, 519 protocol extensions for DTLS are defined in [RFC5764]. 521 3.2. Important RTP details 523 This section does not remove the necessity to read up on RTP. 524 However it does point out a few important details to remember when 525 designing a payload format. 527 3.2.1. The RTP Session 528 The definition of the RTP session from RFC 3550 is: 530 "An association among a set of participants communicating with RTP. 531 A participant may be involved in multiple RTP sessions at the same 532 time. In a multimedia session, each medium is typically carried in a 533 separate RTP session with its own RTCP packets unless the encoding 534 itself multiplexes multiple media into a single data stream. A 535 participant distinguishes multiple RTP sessions by reception of 536 different sessions using different pairs of destination transport 537 addresses, where a pair of transport addresses comprises one network 538 address plus a pair of ports for RTP and RTCP. All participants in 539 an RTP session may share a common destination transport address pair, 540 as in the case of IP multicast, or the pairs may be different for 541 each participant, as in the case of individual unicast network 542 addresses and port pairs. In the unicast case, a participant may 543 receive from all other participants in the session using the same 544 pair of ports, or may use a distinct pair of ports for each." 546 "The distinguishing feature of an RTP session is that each session 547 maintains a full, separate space of SSRC identifiers (defined next). 548 The set of participants included in one RTP session consists of those 549 that can receive an SSRC identifier transmitted by any one of the 550 participants either in RTP as the SSRC or a CSRC (also defined below) 551 or in RTCP. For example, consider a three-party conference 552 implemented using unicast UDP with each participant receiving from 553 the other two on separate port pairs. If each participant sends RTCP 554 feedback about data received from one other participant only back to 555 that participant, then the conference is composed of three separate 556 point-to-point RTP sessions. If each participant provides RTCP 557 feedback about its reception of one other participant to both of the 558 other participants, then the conference is composed of one multi- 559 party RTP session. The latter case simulates the behavior that would 560 occur with IP multicast communication among the three participants." 562 "The RTP framework allows the variations defined here (RFC3550), but 563 a particular control protocol or application design will usually 564 impose constraints on these variations." 566 3.2.2. RTP Header 567 The RTP header contains a number of fields. Two fields always 568 require additional specification by the RTP payload format, namely 569 the RTP Timestamp and the marker bit. Certain RTP payload formats 570 also use the RTP sequence number to realize certain functionalities. 571 The payload type is used to indicate the used payload format. The 572 Sender Source Identifier (SSRC) is used to distinguish RTP packets 573 from multiple senders and media streams. Finally, [RFC5285] 574 specifies how to extend the RTP header to carry metadata relating to 575 the payload when this is desirable. 577 Marker bit: A single bit normally used to provide important 578 indications. In audio it is normally used to indicate the start 579 of an talk burst. This enables jitter buffer adaptation prior to 580 the beginning of the burst with minimal audio quality impact. In 581 video the marker bit is normally used to indicate the last packet 582 part of an frame. This enables a decoder to finish decoding the 583 picture, where it otherwise may need to wait for the next packet 584 to explicitly know that the frame is finished. 586 Timestamp: The RTP timestamp indicates the time instance the media 587 sample belongs to. For discrete media like video, it normally 588 indicates when the media (frame) was sampled. For continuous 589 media it normally indicates the first time instance the media 590 present in the payload represents. For audio this is the sampling 591 time of the first sample. All RTP payload formats must specify 592 the meaning of the timestamp value and the clock rates allowed. 593 Note that clock rates below 1000 Hz are not appropriate because it 594 will cause a too low resolution in the RTCP measurements. RTP 595 payload formats with a timestamp definition which results in no or 596 little correlation between the media time instance and its 597 transmission time cause the RTCP jitter calculation to become 598 unusable due to the errors introduced on the sender side. It 599 should be noted if the payload format has this property or not. 601 Sequence number: The sequence number is monotonically increasing and 602 is set as the packet is sent. This property is used in many 603 payload formats to recover the order of everything from the whole 604 stream down to fragments of application data units (ADUs) and the 605 order they need to be decoded. 607 Payload Type: The payload type is used to indicate on a per packet 608 basis which format is used. Thus certain major configuration 609 information can be bound to a payload type value by out-of-band 610 signalling. An example of this would be video decoder 611 configuration information. Commonly the same payload type is used 612 for a media stream for the whole duration of a session. However 613 in some cases it may be necessary to change the payload format or 614 its configuration during the session. 616 SSRC: The Sender Source ID (SSRC) is normally not used by a payload 617 format other than to identify the RTP timestamp and sequence 618 number space a packet belongs to, allowing simultaneously 619 reception from multiple senders. However, some of the RTP 620 mechanisms for improving resilience to packet loss uses multiple 621 SSRCs to separate original data and repair or redundant data. 623 Header extensions: Some payload formats may specify extensions to 624 the RTP packet header to carry metadata describing the actual 625 payload within the packet. One example is the transport of SMPTE 626 time-codes in the RTP header [RFC5484]. As [RFC5285] specifies, 627 header extensions must not contain information required in order 628 to decode the payload successfully. 630 The remaining fields do not commonly influence the RTP payload 631 format. The padding bit is worth clarifying as it indicates that one 632 or more bytes are appended after the RTP payload. This padding must 633 be removed by a receiver before payload format processing can occur. 634 Thus it is completely separate from any padding that may occur within 635 the payload format itself. 637 3.2.3. RTP Multiplexing 639 RTP has three multiplexing points that are used for different 640 purposes. A proper understanding of this is important to correctly 641 utilize them. 643 The first one is separation of media streams of different types or 644 usages, which is accomplished using different RTP sessions. So for 645 example in the common multi-media session with audio and video, RTP 646 commonly multiplexes audio and video in different RTP sessions. To 647 achieve this separation, transport-level functionalities are used, 648 normally UDP port numbers. Different RTP sessions are also used to 649 realize layered scalability as it allows a receiver to select one or 650 more layers for multicast RTP sessions simply by joining the 651 multicast groups over which the desired layers are transported. This 652 separation also allows different Quality of Service (QoS) to be 653 applied to different media types. 655 The next multiplexing point is separation of different sources within 656 an RTP session. Here RTP uses the SSRC to identify individual 657 sources. An example of individual sources in an audio RTP session 658 would be different microphones, independently of whether they are 659 connected to the same host or different hosts. For each SSRC a 660 unique RTP sequence number and timestamp space is used. 662 The third multiplexing point is the RTP header payload type field. 663 The payload type identifies what format the content in the RTP 664 payload has. This includes different payload format configurations, 665 different codecs, and also usage of robustness mechanisms like the 666 one described in RFC 2198 [RFC2198]. 668 3.2.4. RTP Synchronization 670 There are several types of synchronization and we will here describe 671 how RTP handles the different types: 673 Intra media: The synchronization within a media stream from a source 674 (SSRC) is accomplished using the RTP timestamp field. Each RTP 675 packet carries the RTP timestamp, which specifies the position in 676 time of the media payload contained in this packet relative to the 677 content of other RTP packets in the same RTP media stream (i.e. a 678 given SSRC). This is especially useful in cases of discontinuous 679 transmissions. Discontinuities can be caused by network 680 conditions; when extensive losses occur the RTP timestamp tells 681 the receiver how much later than previously received media the 682 present media should be played out. 684 Inter media: Applications commonly have a desire to use several 685 media sources, possibly of different media types, at the same 686 time. Thus, there exists a need to synchronize also different 687 media from the same end-point. This puts two requirements on RTP: 688 the possibility to determine which media are from the same end- 689 point and if they should be synchronized with each other; and the 690 functionality to facilitate the synchronization itself. 692 The first step in inter-media synchronization is to determine which 693 SSRCs in each session should be synchronized with each other. This 694 is accomplished by comparing the CNAME fields in the RTCP SDES 695 packets. SSRCs with the same CNAME in different RTP sessions can be 696 synchronized. 698 The actual RTCP mechanism for inter-media synchronization is based on 699 the idea that each media stream provides a position on the media 700 specific time line (measured in RTP timestamp ticks) and a common 701 reference time line. The common reference time line is expressed in 702 RTCP as a wall clock time in the Network Time Protocol (NTP) format. 703 It is important to notice that the wall clock time is not required to 704 be synchronized between hosts, for example by using NTP [RFC5905] . 705 It can even have nothing at all to do with the actual time, for 706 example the host system's up-time can be used for this purpose. The 707 important factor is that all media streams from a particular source 708 that are being synchronized use the same reference clock to derive 709 their relative RTP timestamp time scales. 711 Figure 1 illustrates how if one receives RTCP Sender Report (SR) 712 packet P1 in one media stream and RTCP SR packet P2 in the other 713 session, then one can calculate the corresponding RTP timestamp 714 values for any arbitrary point in time T. However to be able to do 715 that it is also required to know the RTP timestamp rates for each 716 medium currently used in the sessions 718 TS1 --+---------------+-------> 719 | | 720 P1 | 721 | | 722 NTP ---+-----+---------T------> 723 | | 724 P2 | 725 | | 726 TS2 ---------+---------+---X--> 728 Figure 1: RTCP Synchronization 730 Assume that medium 1 uses an RTP Timestamp clock rate of 16 kHz, and 731 medium 2 uses a clock rate of 90 kHz. Then TS1 and TS2 for point T 732 can be calculated in the following way: TS1(T) = TS1(P1) + 16000 * 733 (NTP(T)-NTP(P1)) and TS2(T) = TS2(P2) + 90000 * (NTP(T)-NTP(P2)). 734 This calculation is useful as it allows the implementation to 735 generate a common synchronization point for which all time values are 736 provided (TS1(T), TS2(T) and T). So when one wishes to calculate the 737 NTP time that the timestamp value present in packet X corresponds to 738 one can do that in the following way: NTP(X) = NTP(T) + (TS2(X) - 739 TS2(T))/90000. 741 Improved signaling for layered codecs and fast tune-in have been 742 specified in Rapid Synchronization for RTP flows [RFC6051]. 744 3.3. Signalling Aspects 746 RTP payload formats are used in the context of application signalling 747 protocols such as SIP [RFC3261] using the Session Description 748 Protocol (SDP) [RFC4566] with Offer/Answer [RFC3264], RTSP [RFC2326] 749 or SAP [RFC2326]. These examples all use out-of-band signalling to 750 indicate which type of RTP media streams that are desired to be used 751 in the session and how they are configured. To be able to declare or 752 negotiate the media format and RTP payload packetization, the payload 753 format must be given an identifier. In addition to the identifier 754 many payload formats have also the need to signal further 755 configuration information out-of-band for the RTP payloads prior to 756 the media transport session. 758 The above examples of session-establishing protocols all use SDP, but 759 other session description formats may be used. For example there was 760 discussion of a new XML-based session description format within IETF 761 (SDP-NG). In the event, the proposal did not get beyond the initial 762 protocol specification because of the enormous embedded base of SDP 763 implementations. However, to avoid locking the usage of RTP to SDP 764 based out-of-band signalling, the payload formats are identified 765 using a separate definition format for the identifier and associated 766 parameters. That format is the Media Type. 768 3.3.1. Media Types 770 Media types [RFC6838] are identifiers originally created for 771 identifying media formats included in email. In this usage they were 772 known as MIME types, where the expansion of the MIME acronym includes 773 the word "mail". The term "media type" was introduced to reflect a 774 broader usage, which includes HTTP [RFC2616], MSRP [RFC4975] and many 775 other protocols, to identify arbitrary content carried within the 776 protocols. Media types also provide a media hierarchy that fits RTP 777 payload formats well. Media type names are two-part and consist of 778 content type and sub-type separated with a slash, e.g. "audio/PCMA" 779 or "video/h263-2000". It is important to choose the correct content- 780 type when creating the media type identifying an RTP payload format. 781 However in most cases there is little doubt what content type the 782 format belongs to. Guidelines for choosing the correct media type 783 and registration rules for media type names are provided in Media 784 Type Specifications and Registration Procedures [RFC6838]. The 785 additional rules for media types for RTP payload formats are provided 786 in Media Type Registration of RTP Payload Formats [RFC4855]. 788 Registration of the RTP payload name is something that is required to 789 avoid name collision in the future. Note that "x-" names are not 790 suitable for any documented format as they have the same problem with 791 name collision and can't be registered. The list of already 792 registered media types can be found at IANA Web site (http:// 793 www.iana.org). 795 Media types are allowed any number of parameters, which may be 796 required or optional for that media type. They are always specified 797 on the form "name=value". There exists no restrictions on how the 798 value is defined from media type's perspective, except that 799 parameters must have a value. However, the usage of media types in 800 SDP etc. has resulted in the following restrictions that need to be 801 followed to make media types usable for RTP identifying payload 802 formats: 804 1. Arbitrary binary content in the parameters is allowed but needs 805 to be encoded so that it can be placed within text based 806 protocols. Base64 [RFC4648] is recommended, but for shorter 807 content Base16 [RFC4648] may be more appropriate as it is simpler 808 to interpret for humans. This needs to be explicitly stated when 809 defining a media type parameter with binary values. 811 2. The end of the value needs to be easily found when parsing a 812 message. Thus parameter values that are continuous and not 813 interrupted by common text separators, such as space and semi- 814 colon, are recommended. If that is not possible some type of 815 escaping should be used. Usage of quote (") is recommended, and 816 don't forget to provide a method of encoding any character used 817 for quoting inside the quoted element. 819 3. A common representation form for the media type and its 820 parameters is on a single line. In that case the media type is 821 followed by a semicolon-separated list of the parameter value 822 pairs, e.g. 824 audio/amr octet-align=0; mode-set=0,2,5,7; mode-change-period=2 826 3.3.2. Mapping to SDP 828 Since SDP [RFC4566] is so commonly used as an out-of-band signalling 829 protocol, a mapping of the media type into SDP exists. The details 830 on how to map the media type and its parameters into SDP are 831 described in RFC 4855 [RFC4855]. However this is not sufficient to 832 explain how certain parameters must be interpreted for example in the 833 context of Offer/Answer negotiation [RFC3264]. 835 3.3.2.1. The Offer/Answer Model 837 The Offer/Answer (O/A) model allows SIP to negotiate which media 838 formats and payload formats are to be used in a session and how they 839 are to be configured. However O/A does not define a default behavior 840 and instead points out the need to define how parameters behave. To 841 make things even more complex the direction of media within a session 842 has an impact on these rules, so that some cases may require separate 843 descriptions for media streams that are send-only, receive-only or 844 both sent and received as identified by the SDP attributes 845 a=sendonly, a=recvonly, and a=sendrecv. In addition the usage of 846 multicast adds further limitations as the same media stream is 847 delivered to all participants. If those multicast-imposed 848 restrictions are too limiting for unicast then separate rules for 849 unicast and multicast will be required. 851 The simplest and most common O/A interpretation is that a parameter 852 is defined to be declarative; i.e. the SDP offer/answer sending 853 agent can declare a value and that has no direct impact on the other 854 agent's values. This declared value applies to all media that are 855 going to be sent to the declaring entity. For example most video 856 codecs have a level parameter which tells the other participants the 857 highest complexity the video decoder supports. The level parameter 858 can be declared independently by two participants in a unicast 859 session as it will be the media sender's responsibility to transmit a 860 video stream that fulfills the limitation the other has declared. 861 However in multicast it will be necessary to send a stream that 862 follows the limitation of the weakest receiver, i.e. the one that 863 supports the lowest level. To simplify the negotiation in these 864 cases it is common to require any answerer to a multicast session to 865 take a yes or no approach to parameters. 867 A "negotiated" parameter is a different case, for which both sides 868 need to agree on its value. Such a parameter requires that the 869 answerer either accept it as it is offered or remove the payload type 870 the parameter belonged to from its answer. The removal of the 871 payload type from the answer indicates to the offerer the lack of 872 support for the parameter values presented. An unfortunate 873 implication of the need to use complete payload types to indicate 874 each possible configuration so as to maximize the chances of 875 achieving interoperability, is that the number of necessary payload 876 types can quickly grow large. This is one reason to limit the total 877 number of sets of capabilities that may be implemented. 879 The most problematic type of parameters are those that relate to the 880 media the entity sends. They do not really fit the O/A model but can 881 be shoe-horned in. Examples of such parameters can be found in the 882 H.264 video codec's payload format [RFC6184], where the name of all 883 parameters with this property starts with "sprop-". The issue with 884 these parameters is that they declare properties for a media stream 885 that the other party may not accept. The best one can make of the 886 situation is to explain the assumption that the other party will 887 accept the same parameter value for the media it will receive as the 888 offerer of the session has proposed. If the answerer needs to change 889 any declarative parameter relating to streams it will receive then 890 the offerer may be required to make an new offer to update the 891 parameter values for its outgoing media stream. 893 Another issue to consider is the sendonly media streams in offers. 894 Parameters that relate to what the answering entity accepts to 895 receive have no meaning other than to provide a template for the 896 answer. It is worth pointing out in the specification that these 897 really provide a set of parameter values that the sender recommends. 898 Note that sendonly streams in answers will need to indicate the 899 offerer's parameters to ensure that the offerer can match the answer 900 to the offer. 902 A further issue with offer/answer which complicates things is that 903 the answerer is allowed to renumber the payload types between offer 904 and answer. This is not recommended but allowed for support of 905 gateways to the ITU conferencing suite. This means that it must be 906 possible to bind answers for payload types to the payload types in 907 the offer even when the payload type number has been changed, and 908 some of the proposed payload types have been removed. This binding 909 must normally be done by matching the configurations originally 910 offered against those in the answer. 912 3.3.2.2. Declarative usage in RTSP and SAP 914 SAP (Session Announcement Protocol) [RFC2974] is used for announcing 915 multicast sessions. Independently of the usage of Source Specific 916 Multicast (SSM) [RFC3569] or Any-Source Multicast (ASM), the SDP 917 provided by SAP applies to all participants. All media that is sent 918 to the session must follow the media stream definition as specified 919 by the SDP. This enables everyone to receive the session if they 920 support the configuration. Here SDP provides a one way channel with 921 no possibility to affect the configuration that the session creator 922 has decided upon. Any RTP Payload format that requires parameters 923 for the send direction and which needs individual values per 924 implementation or instance will fail in a SAP session for a multicast 925 session allowing anyone to send. 927 Real-Time Streaming Protocol (RTSP) [RFC2326] allows the negotiation 928 of transport parameters for media streams which are part of a 929 streaming session between a server and client. RTSP has divided the 930 transport parameters from the media configuration. SDP is commonly 931 used for media configuration in RTSP and is sent to the client prior 932 to session establishment, either through use of the DESCRIBE method 933 or by means of an out-of-band channel like HTTP, email etc. The SDP 934 is used to determine which media streams and what formats are being 935 used prior to session establishment. 937 Thus both SAP and RTSP use SDP to configure receivers and senders 938 with a predetermined configuration for a media stream including the 939 payload format and any of its parameters. All parameters are used in 940 a declarative fashion. This can result in different treatment of 941 parameters between offer/answer and declarative usage in RTSP and 942 SAP. Any such difference will need to be spelled out by the payload 943 format specification. 945 3.4. Transport Characteristics 947 The general channel characteristics that RTP flows experience are 948 documented in Section 3 of Guidelines for Writers of RTP Payload 949 Format Specifications [RFC2736]. The discussion below provides 950 additional information. 952 3.4.1. Path MTU 954 At the time of writing this document the most common IP Maximum 955 Transmission Unit (MTU) in used link layers is 1500 bytes (Ethernet 956 data payload). However there exist both links with smaller MTUs and 957 links with much larger MTUs. Certain parts of the Internet already 958 today support an IP MTU of 9000 bytes or more. There is a slow 959 ongoing evolution towards larger MTU sizes. However, at the same 960 time it has become common to use tunneling protocols, often multiple 961 ones who's overhead when added together can shrink the MTU 962 significant. This should be considered in the design, especially in 963 regards to features such as aggregation of independently decodable 964 data units. 966 4. Specification Process 968 This section discusses the recommended process to produce an RTP 969 payload format in the described venues. This is to document the best 970 current practice on how to get a well designed and specified payload 971 format as quickly as possible. For specifications that are defined 972 by standards bodies other than the IETF the primary milestone is 973 registration of the RTP payload format name. For proprietary media 974 formats the primary goal depends on whether interoperability is 975 desired at the RTP level. However there is also the issue of 976 ensuring best possible quality of any specification. 978 4.1. IETF 980 For all standardized media formats, it is recommended that the 981 payload format be specified in the IETF. The main reason is to 982 provide an openly available RTP payload format specification that has 983 been reviewed by people experienced with RTP payload formats. At the 984 time of writing, this work is done in the PAYLOAD Working Group (WG), 985 but that may change in the future. 987 4.1.1. Steps from Idea to Publication 989 There are a number of steps that an RTP payload format should go 990 through from the initial idea until it is published. This also 991 documents the process that the PAYLOAD Working Group applies when 992 working with RTP payload formats. 994 Idea: Determined the need for an RTP payload format as an IETF 995 specification. 997 Initial effort: Using this document as guideline one should be able 998 to get started on the work. If one's media codec doesn't fit any 999 of the common design patterns or one has problems understanding 1000 what the most suitable way forward is, then one should contact the 1001 PAYLOAD Working Group and/or the WG chairs. The goal of this 1002 stage is to have an initial individual draft. This draft needs to 1003 focus on the introductory parts that describe the real-time media 1004 format and the basic idea on how to packetize it. Not all the 1005 details are required to be filled in. However, the security 1006 chapter is not something that one should skip even initially. It 1007 is important to consider from the start any serious security risks 1008 that need to be solved. The first step is completed when one has 1009 a draft that is sufficiently detailed for a first review by the 1010 WG. The less confident one is of the solution, the less work 1011 should be spent on details; instead concentrate on the codec 1012 properties and what is required to make the packetization work. 1014 Submission of first version: When one has performed the above one 1015 submits the draft as an individual draft. This can be done at any 1016 time except the 3 weeks (current deadline at the time of writing, 1017 consult current announcements) prior to an IETF meeting. When the 1018 IETF draft announcement has been sent out on the draft 1019 announcement list, forward it to the PAYLOAD WG and request that 1020 it be reviewed. In the email outline any issues the authors 1021 currently have with the design. 1023 Iterative improvements: Taking the feedback into account one 1024 updates the draft and tries resolve issues. New revisions of the 1025 draft can be submitted at any time (again except for a buffer 1026 period before meetings). It is recommended to submit a new 1027 version whenever one has made major updates or has new issues that 1028 are easiest to discuss in the context of a new draft version. 1030 Becoming a WG document: Given that the definition of RTP payload 1031 formats is part of the PAYLOAD WG's charter, RTP payload formats 1032 that are going to be published as standards track RFCs need to 1033 become WG documents. Becoming a WG document means that the chairs 1034 are responsible for administrative handling, for example, issuing 1035 publication requests. However be aware that making a document 1036 into a WG document changes the formal ownership and responsibility 1037 from the individual authors to the WG. The initial authors 1038 normally continue being document editors, unless unusual 1039 circumstances occur. The PAYLOAD WG accepts new RTP payload 1040 formats based on their suitability and document maturity. The 1041 document maturity is a requirement to ensure that there are 1042 dedicated document editors and that there exists a good solution. 1044 Iterative improvements: The updates and review cycles continue 1045 until the draft has reached the level of maturity suitable for 1046 publication. 1048 WG Last Call: A WG Last Call of at least 2 weeks is always 1049 performed for payload formats in the PAYLOAD WG. The authors 1050 request WG last call for a draft when they think it is mature 1051 enough for publication. The chairs perform a review to check if 1052 they agree with the authors' assessment. If the chairs agree on 1053 the maturity, the WG Last Call is announced on the WG mailing 1054 list. If there are issues raised these need to be addressed with 1055 an updated draft version. For any more substantial updates of the 1056 draft, a new WG last call is announced for the updated version. 1057 Minor changes, like editorial fixes, can be progressed without an 1058 additional WG last call. 1060 Publication Requested: For WG documents the chairs request 1061 publication of the draft, after it has passed WG Last Call. After 1062 this the approval and publication process described in RFC 2026 1063 [RFC2026] are performed. The status after the publication has 1064 been requested can be tracked using the IETF data tracker. 1065 Documents do not expire as they normally do after publication has 1066 been requested, so authors do not have to issue keep-alive 1067 updates. In addition, any submission of document updates requires 1068 the approval of WG chair(s). The authors are commonly asked to 1069 address comments or issues raised by the IESG. The authors also 1070 do one last review of the document immediately prior to its 1071 publication as an RFC to ensure its correctness. 1073 4.1.2. WG meetings 1075 WG meetings are for discussing issues, not presentations. This means 1076 that most RTP payload formats should never need to be discussed in a 1077 WG meeting. RTP payload formats that would be discussed are either 1078 those with controversial issues that failed to be resolved on the 1079 mailing list, or those including new design concepts worth a general 1080 discussion. 1082 There exists no requirement to present or discuss a draft at a WG 1083 meeting before it becomes published as an RFC. Thus even authors who 1084 lack the possibility to go to WG meetings should be able to 1085 successfully specify an RTP payload format in IETF. WG meetings may 1086 become necessary only if the draft gets stuck in a serious debate 1087 that cannot easily be resolved. 1089 4.1.3. Draft Naming 1091 To simplify the work of the PAYLOAD WG chairs and its WG members a 1092 specific draft file naming convention shall be used for RTP payload 1093 formats. Individual submissions shall be named draft--payload-rtp--. The WG 1095 documents shall be named according to this template: draft-ietf- 1096 payload-rtp--. The inclusion of "payload" 1097 in the draft filename ensures that the search for "payload-" will 1098 find all PAYLOAD related drafts. Inclusion of "rtp" tells us that it 1099 is an RTP payload format draft. The descriptive name should be as 1100 short as possible while still describing what the payload format is 1101 for. It is recommended to use the media format or codec acronym. 1102 Please note that the version must start at 00 and is increased by one 1103 for each submission to the IETF secretary of the draft. No version 1104 numbers may be skipped. 1106 4.1.4. How to speed up the process 1108 There a number of ways to lose a lot of time in the above process. 1109 This section discusses what to do and what to avoid. 1111 o Do not update the draft only for the meeting deadline. An update 1112 to each meeting automatically limits the draft to three updates 1113 per year. Instead, ignore the meeting schedule and publish new 1114 versions as soon as possible. 1116 o Try to avoid requesting reviews when people are busy, like the 1117 weeks before a meeting. It is actually more likely that people 1118 have time for them directly after a meeting. 1120 o Perform draft updates quickly. A common mistake is that the 1121 authors let the draft slip. By performing updates to the draft 1122 text directly after getting resolution on an issue, things are 1123 speed up. This minimizes the delay that the author has direct 1124 control over. The time taken for reviews, responses from area 1125 directors and chairs, etc. can be much harder to speed up. 1127 o Do not fail to take human nature into account. It happens that 1128 people forget or need to be reminded about tasks. Send a kind 1129 reminder to the people you are waiting for if things take longer 1130 than expected. Ask people to estimate when they expect to fulfill 1131 the requested task. 1133 o Ensure there is enough review. It is common that documents take a 1134 long time and many iterations because not enough review is 1135 performed in each iteration. To improve the amount of review you 1136 get on your own document, trade review time with other document 1137 authors. Make a deal with some other document author that you 1138 will review their draft if they review yours. Even inexperienced 1139 reviewers can help with language, editorial or clarity issues. 1140 Try also approaching the more experienced people in the WG and 1141 getting them to commit to a review. The WG chairs cannot, even if 1142 desirable, be expected to review all versions. Due to workload 1143 the chairs may need to concentrate on key points in a draft 1144 evolution, like initial submissions, checking if a draft is ready 1145 to become a WG document or ready for WG last call. 1147 4.2. Other Standards bodies 1149 Other standards bodies may define RTP payloads in their own 1150 specifications. When they do this they are strongly recommended to 1151 contact the PAYLOAD WG chairs and request review of the work. It is 1152 recommended that at least two review steps are performed. The first 1153 should be early in the process when more fundamental issues can be 1154 easily resolved without abandoning a lot of effort. Then when 1155 nearing completion, but while it is still possible to update the 1156 specification, a second review should be scheduled. In that pass the 1157 quality can be assessed and hopefully no updates will be needed. 1158 Using this procedure can avoid both conflicting definitions and 1159 serious mistakes, like breaking certain aspects of the RTP model. 1161 RTP payload Media Types may be registered in the standards tree by 1162 other standard bodies. The requirements on the organization are 1163 outlined in the media types registration document [RFC4855] and 1164 [RFC6838]). This registration requires a request to the IESG, which 1165 ensures that the filled-in registration template is acceptable. To 1166 avoid last-minute problems with these registrations the registration 1167 template must be sent for review both to the PAYLOAD WG and the media 1168 types list (ietf-types@iana.org) and is something that should be 1169 included in the IETF reviews of the payload format specification. 1171 4.3. Proprietary and Vendor Specific 1173 Proprietary RTP payload formats are commonly specified when the real- 1174 time media format is proprietary and not intended to be part of any 1175 standardized system. However there are reasons why also proprietary 1176 formats should be correctly documented and registered: 1178 o Usage in a standardized signalling environment such as SIP/SDP. 1179 RTP needs to be configured with the RTP profiles, payload formats 1180 and their payload types being used. To accomplish this it is 1181 desirable to have registered media type names to ensure that the 1182 names do not collide with those of other formats. 1184 o Sharing with business partners. As RTP payload formats are used 1185 for communication, situations often arise where business partners 1186 would like to support a proprietary format. Having a well written 1187 specification of the format will save time and money for both 1188 sides, as interoperability will be much easier to accomplish. 1190 o To ensure interoperability between different implementations on 1191 different platforms. 1193 To avoid name collisions there is a central register keeping tracks 1194 of the registered Media Type names used by different RTP payload 1195 formats. When it comes to proprietary formats they should be 1196 registered in the vendor's own tree. All vendor specific 1197 registrations use sub-type names that start with "vnd.". 1198 Names in the vendor's own tree are not required to be registered with 1199 IANA. However registration is recommended if the Media Type is used 1200 at all in public environments. 1202 If interoperability at the RTP level is desired, a payload type 1203 specification should be standardized in the IETF following the 1204 process described above. The IETF does not require full disclosure 1205 of the codec when defining an RTP payload format to carry that codec, 1206 but a description must be provided that is sufficient to allow the 1207 IETF to judge whether the payload format is well designed. The Media 1208 Type identifier assigned to a standardized payload format of this 1209 sort will lie in the standards tree rather than the vendor tree. 1211 5. Designing Payload Formats 1213 The best summary of payload format design is KISS (Keep It Simple, 1214 Stupid). A simple payload format is easier to review for 1215 correctness, easier to implement, and has low complexity. 1216 Unfortunately, contradictory requirements sometimes make it hard to 1217 do things simply. Complexity issues and problems that occur for RTP 1218 payload formats are: 1220 Too many configurations: Contradictory requirements lead to the 1221 result that one configuration is created for each conceivable 1222 case. Such contradictory requirements are often between 1223 functionality and bandwidth. This outcome has two big 1224 disadvantages; First all configurations need to be implemented. 1225 Second, the user application must select the most suitable 1226 configuration. Selecting the best configuration can be very 1227 difficult and in negotiating applications, this can create 1228 interoperability problems. The recommendation is to try to select 1229 a very limited set of configurations (preferably one) that perform 1230 well for the most common cases and are capable of handling the 1231 other cases, but maybe not that well. 1233 Hard to implement: Certain payload formats may become difficult to 1234 implement both correctly and efficiently. This needs to be 1235 considered in the design. 1237 Interaction with general mechanisms: Special solutions may create 1238 issues with deployed tools for RTP, such as tools for more robust 1239 transport of RTP. For example, a requirement for a non-broken 1240 sequence number space creates issues for mechanisms relying on 1241 payload type switching interleaving media-independent resilience 1242 within a stream. 1244 5.1. Features of RTP Payload Formats 1246 There are a number of common features in RTP payload formats. There 1247 is no general requirements to support these features; instead, their 1248 applicability must be considered for each payload format. It may in 1249 fact be that certain features are not even applicable. 1251 5.1.1. Aggregation 1253 Aggregation allows for the inclusion of multiple application data 1254 units (ADUs) within the same RTP payload. This is commonly supported 1255 for codecs that produce ADUs of sizes smaller than the IP MTU. Do 1256 remember that the MTU may be significantly larger than 1500 bytes. 1257 An MTU of 9000 bytes is available today and an MTU of 64k may be 1258 available in the future. Many speech codecs have the property of 1259 ADUs of a few fixed sizes. Video encoders may generally produce ADUs 1260 of quite flexible sizes. Thus the need for aggregation may be less. 1261 However in certain use cases the possibility to aggregate multiple 1262 ADUs especially for different playback times is useful. 1264 The main disadvantage of aggregation is the extra delay introduced 1265 (due to buffering until a sufficient number of ADUs have been 1266 collected at the sender) and reduced robustness against packet loss. 1267 Aggregation also introduces buffering requirements at the receiver. 1269 5.1.2. Fragmentation 1271 If the real-time media format has the property that it may produce 1272 ADUs that are larger than common MTU sizes then fragmentation support 1273 should be considered. An RTP Payload format may always fall back on 1274 IP fragmentation, however as discussed in RFC 2736 this has some 1275 drawbacks. Mainly that IP fragmented packets commonly are discarded 1276 in the network, especially by Network Address Translators or 1277 Firewalls. The usage of RTP payload format-level fragmentation 1278 allows for more efficient usage of RTP packet loss recovery 1279 mechanisms. It may also in some cases also allow better usage of 1280 partial ADUs by doing media specific fragmentation at media specific 1281 boundaries. 1283 5.1.3. Interleaving and Transmission Re-Scheduling 1285 Interleaving has been implemented in a number of payload formats to 1286 allow for less quality reduction when packet loss occurs. When 1287 losses are bursty and several consecutive packets are lost, the 1288 impact on quality can be quite severe. Interleaving is used to 1289 convert that burst loss to several spread-out individual packet 1290 losses. It can also be used when several ADUs are aggregated in the 1291 same packets. A loss of an RTP packet with several ADUs in the 1292 payload has the same affect as a burst loss if the ADUs would have 1293 been transmitted in individual packets. To reduce the burstiness of 1294 the loss, the data present in an aggregated payload may be 1295 interleaved, thus spread the loss over a longer time period. 1297 A requirement for doing interleaving within an RTP payload format is 1298 the aggregation of multiple ADUs. For formats that do not use 1299 aggregation there is still a possibility of implementing a 1300 transmission order re-scheduling mechanism. That has the effect that 1301 the packets transmitted consecutively originate from different points 1302 in the media stream. This can be used to mitigate burst losses, 1303 which may be useful if one transmits packets at frequent intervals. 1304 However it may also be used to transmit more significant data earlier 1305 in combination with RTP retransmission to allow for more graceful 1306 degradation and increased possibility to receive the most important 1307 data, e.g. intra frames of video. 1309 The drawback of interleaving is the significantly increased 1310 transmission buffering delay, making it less useful for low-delay 1311 applications. It may also create significant buffering requirements 1312 on the receiver. That buffering is also problematic as it is usually 1313 difficult to indicate when a receiver may start consume data and 1314 still avoid buffer under run caused by the interleaving mechanism 1315 itself. Transmission re-scheduling is only useful in a few specific 1316 cases, as in streaming with retransmissions. The potential gains 1317 must be weighted against the complexity of these schemes. 1319 5.1.4. Media Back Channels 1321 A few RTP payload formats have implemented back channels within the 1322 media format. Those have been for specific features, like the AMR 1323 [RFC4867] codec mode request (CMR) field. The CMR field is used in 1324 the operation of gateways to circuit-switched voice to allow an IP 1325 terminal to react to the circuit-switched network's need for a 1326 specific encoder mode. A common motivation for media back channels 1327 is the need to have signalling in direct relation to the media or the 1328 media path. 1330 If back channels are considered for an RTP payload format they should 1331 be for a specific requirements which cannot be easily satisfied by 1332 more generic mechanisms within RTP or RTCP. 1334 5.1.5. Media Scalability 1336 Some codecs support various types of media scalability, i.e. some 1337 data of a media stream may be removed to adapt the media's 1338 properties, such as bitrate and quality. The adaptation may be 1339 applied in the following dimensions of the media: 1341 Temporal: For video codecs it is possible to adapt the frame rate, 1342 e.g. for H.264 [RFC6184]. 1344 Spatial: Video codecs supporting scalability may adapt the 1345 resolution, e.g. in SVC [RFC6190]. 1347 Quality: The quality of the media stream may be scaled by adapting 1348 the accuracy of the coding process, as, e.g. possible with Signal 1349 to Noise Ratio (SNR) fidelity scalability of SVC [RFC6190]. 1351 At the time of writing this document, codecs that support scalability 1352 have a bit of revival. It has been realized that getting the 1353 required functionality for supporting the features of the media 1354 stream into the RTP framework is quite challenging. One of the 1355 recent examples for layered and scalable codecs is Scalable Video 1356 Coding [RFC6190] (SVC). 1358 SVC is a good example for a payload format supporting media 1359 scalability features, which have been in its basic form already 1360 included in RTP. A layered codec supports the dropping of data parts 1361 of a media stream, i.e. RTP packets may be not transmitted or 1362 forwarded to a client in order to adapt the media stream rate as well 1363 as the media stream quality, while still providing a decodable subset 1364 of the media stream to a client. One example for using the 1365 scalability feature may be an RTP Mixer (Multipoint Control Unit) 1366 which controls the rate and quality sent out to participants in a 1367 communication based on dropping RTP packets. Another example may be 1368 an transport channel which allows for differentiation in Quality of 1369 Service (QoS) parameters based on RTP sessions in a multicast 1370 session. In such a case, the more important packets of the scalable 1371 media stream (base layer) may get better QoS parameters, then the 1372 less important packets (enhancement layer) in order to provide some 1373 kind of graceful degradation. The scalability features required for 1374 allowing an adaptive transport as described in the two examples above 1375 are based on RTP multiplexing in order to identify the packets to be 1376 dropped or transmitted/forwarded. The multiplexing features defined 1377 for Scalable Video Coding [RFC6190] are: 1379 single session transmission (SST), where all media layers of the 1380 media are transported as single source (SSRC) in a single RTP 1381 session; as well as 1383 multi session transmission (MST), in RTP defined as session 1384 multiplexing (Section 3.2.3), where different media layers or a 1385 set of media layers are transported in different RTP sessions. 1387 In the first case (SST), additional in-band as well as out-of-band 1388 signaling is required in order to allow identification of packets 1389 belonging to a specific media layer. Furthermore, an adaptation of 1390 the media stream requires dropping of specific packets in order to 1391 provide the client with a compliant media stream. In case of using 1392 encryption, it is typically required for an adapting network device 1393 to be in the security context to allow packet dropping and providing 1394 an intact RTP session to the client. This typically requires the 1395 network device to be an RTP mixer. 1397 In general having a media unaware network device dropping excessive 1398 packets will be more problematic than having a Media Aware Network 1399 Entity (MANE). First is the need to understand the media format and 1400 know which ADUs or payloads that belongs to the layers, that no other 1401 layer will be dependent on after the dropping. Secondly, if the MANE 1402 can work as RTP mixer or translator it can rewrite the RTP and RTCP 1403 in such a way that the receiver will not suspect non-intentional RTP 1404 packet losses needing repair actions. This as the receiver can't 1405 determine if a lost packet was an important base layer packet or one 1406 of the less important extension layers. 1408 In the second case (MST), the out-of-band signaling typically 1409 provides enough information to identify the media layers and its 1410 properties. The decision for dropping packets is based on the 1411 Network Address which identifies the RTP session to be dropped. In 1412 order to allow correct data provision to a decoder after reception 1413 from different sessions, data re-alignment mechanisms are described 1414 for Scalable Video Coding [RFC6190]. A more generic one is also 1415 described in Rapid Sync for RTP flows [RFC6051], which is purely 1416 based on existing RTP mechanisms, i.e. the NTP timestamp, for inter- 1417 session synchronization. Another signaling feature is the generic 1418 indication of dependencies of RTP sessions in SDP, as defined in the 1419 Media Decoding Dependency Grouping in SDP [RFC5583]. 1421 When QoS settings, e.g. DiffServ markings, are used to ensure that 1422 the extension layers are dropped prior the base layer the receiving 1423 end-point has the benefit in MST to know which layer or set of layers 1424 the missing packets belong as it will be bound to different RTP 1425 sessions. Thus explicitly indicating the importance of the loss. 1427 5.1.6. High Packet Rates 1429 Some media codecs require high packet rates, and in these cases the 1430 RTP sequence number wraps too quickly. As rule of thumb, it must not 1431 be possible to wrap the sequence number space in less than 2 minutes 1432 (TCP maximum segment lifetime). If earlier wrapping may occur then 1433 the payload format should specify an extended sequence number field 1434 to allow the receiver to determine where a specific payload belongs 1435 in the sequence, even in the face of extensive reordering. The RTP 1436 payload format for uncompressed video [RFC4175] can be used as an 1437 example for such a field. 1439 6. Noteworthy Aspects in Payload Format Design 1441 This section provides a few examples of payload formats that are 1442 worth noting for good or bad design in general or specific details of 1443 their design. 1445 6.1. Audio Payloads 1447 The AMR [RFC4867], AMR-WB [RFC4867], EVRC [RFC3558], SMV [RFC3558] 1448 payload formats are all quite similar. They are all for frame-based 1449 audio codecs and use a table of content structure. Each frame has a 1450 table of contents entry that indicates the type of the frame and if 1451 additional frames are present. This is quite flexible but produces 1452 unnecessary overhead if the ADU is of fixed size and if when 1453 aggregating multiple ADUs they are commonly of the same type. In 1454 that case a solution like that in AMR-WB+ [RFC4352] may be more 1455 suitable. 1457 AMR-WB+ does contain one less desirable feature which is dependent on 1458 the media codec itself. The media codec produces a large range of 1459 different frame lengths in time perspective. The RTP timestamp rate 1460 is selected to have the very unusual value of 72 kHz despite the fact 1461 that output normally is at a sample rate of 48kHz. The 72 kHz 1462 timestamp rate is the smallest found value that would make all of the 1463 frames the codec could produce result in an integer frame length in 1464 RTP timestamp ticks. This way, a receiver can always correctly place 1465 the frames in relation to any other frame, even when the frame length 1466 changes. The downside is that the decoder outputs for certain frame 1467 lengths is in fact partial samples. The result is that the output in 1468 samples from the codec will vary from frame to frame, potentially 1469 making implementation more difficult. 1471 The RTP payload format for MIDI [RFC6295] contains some interesting 1472 features. MIDI is an audio format sensitive to packet losses, as the 1473 loss of a "note off" command will result in a note being stuck in an 1474 "on" state. To counter this a recovery journal is defined that 1475 provides a summarized state that allows the receiver to recover from 1476 packet losses quickly. It also uses RTCP and the reported highest 1477 sequence number to be able to prune the state the recovery journal 1478 needs to contain. These features appear limited in applicability to 1479 media formats that are highly stateful and primarily use symbolic 1480 media representations. 1482 There exist a security concern with variable bit-rate audio and 1483 speech codecs that changes their payload length based on the input 1484 data. This can leak information, especially in structured 1485 communication like speech recognition prompt service that asks people 1486 to enter information verbaly. This issue also exist to some degree 1487 for discontinuous transmission as that allows the length of phrases 1488 to be determined. The issue is further discussed in Guidelines for 1489 the Use of Variable Bit Rate Audio with Secure RTP [RFC6562] which 1490 needs to read by anyone writing an RTP payload format for an audio or 1491 speech codec with these properties. 1493 6.2. Video 1495 The definition of RTP payload formats for video has seen an evolution 1496 from the early ones such as H.261 towards the latest for VC-1 and 1497 H.264. 1499 The H.264 RTP payload format [RFC3984] can be seen as a smorgasbord 1500 of functionality, some of it such as the interleaving being pretty 1501 advanced. The reason for this was to ensure that the majority of 1502 applications considered by the ITU-T and MPEG that can be supported 1503 by RTP are indeed supported. This has created a payload format that 1504 rarely is fully implemented. Despite that, no major issues with 1505 interoperability has been reported with one exception namely the 1506 offer/answer and parameter signalling, which resulted in a revised 1507 specification [RFC6184]. However, complaints about its complexity 1508 are common. 1510 The RTP payload format for uncompressed video [RFC4175] must be 1511 mentioned in this context as it contains a special feature not 1512 commonly seen in RTP payload formats. Due to the high bit-rate and 1513 thus packet rate of uncompressed video (gigabits rather than 1514 megabits) the payload format includes a field to extend the RTP 1515 sequence number since the normal 16-bit one can wrap in less than a 1516 second. [RFC4175] also specifies a registry of different color sub- 1517 samplings that can be re-used in other video RTP payload formats. 1519 6.3. Text 1521 Only a single format text format has been standardized in IETF, 1522 namely T.140 [RFC4103]. The 3GPP Timed Text format [RFC4396] should 1523 be considered to be text, even though in the end was registered as a 1524 video format. It was registered in that part of the tree because it 1525 deals with decorated text, usable for subtitles and other 1526 embellishments of video. However, it has many of the properties that 1527 text formats generally have. 1529 The RTP payload format for T.140 was designed with high reliability 1530 in mind as real-time text commonly is an extremely low bit-rate 1531 application. Thus, it recommends the use of RFC 2198 with many 1532 generations of redundancy. However, the format failed to provide a 1533 text block specific sequence number and relies instead of the RTP one 1534 to detect loss. This makes detection of missing text blocks 1535 unnecessarily difficult and hinders deployment with other robustness 1536 mechanisms that would involve switching the payload type as that may 1537 result in erroneous error marking in the T.140 text stream. 1539 6.4. Application 1541 The application content type contains at the time of writing two 1542 media types that aren't RTP transport robustness tools such as FEC 1543 [RFC3009][RFC5109][RFC6015][RFC6682] and RTP retransmission 1544 [RFC4588]. 1546 The first one is H224 [RFC4573] which enables far end camera control 1547 over RTP. This is not an IETF defined RTP format, only an IETF 1548 performed registration. 1550 The second one is the RTP Payload Format for Society of Motion 1551 Picture and Television Engineers (SMPTE) ST 336 Encoded Data 1552 [RFC6597] which carries generic key length value (KLV) triplets. 1553 These pairs may contain arbitrary binary meta data associated with 1554 video transmissions. It has a very basic fragmentation mechanism 1555 requiring packet loss free reception not only of the triplet itself 1556 but also one packet before and after the sequence of fragmented KLV 1557 triplet to ensure correct reception. Specific KLV triplets 1558 themselves may have recommendation on how to handle non-complete ones 1559 allowing the use and repair of them. In general the application 1560 using such a mechanism must be robust to errors and also use some 1561 combination of application level repetition, RTP level transport 1562 robustness tools and network level requirements to achieve low levels 1563 of packet loss rates and repair of KLV triplets. 1565 7. Important Specification Sections 1567 A number of sections in the payload format draft that need some 1568 special consideration. These include the Security and IANA 1569 Considerations sections. 1571 7.1. Media Format Description 1573 The intention of this section is to enable reviewers and other 1574 readers to get an overview of the capabilities and major properties 1575 of the media format. It should be kept short and concise and is not 1576 a complete replacement for reading the media format specification. 1578 7.2. Security Considerations 1580 All Internet drafts require a Security Considerations section. The 1581 security considerations section in an RTP payload format needs to 1582 concentrate on the security properties this particular format has. 1583 Some payload formats have very few specific issues or properties and 1584 can fully fall back on the security considerations for RTP in general 1585 and those of the profile being used. Because those documents are 1586 always applicable, a reference to these is normally placed first in 1587 the security considerations section. There is suggested text in the 1588 template below. 1590 The security issues of confidentiality, integrity protection and 1591 source authentication are common issue for all payload formats. 1592 These should be solved by mechanisms external to the payload and do 1593 not need any special consideration in the payload format except for 1594 an reminder on these issues. Reasons for this division is further 1595 documented in "Securing the RTP Protocol Framework: Why RTP Does Not 1596 Mandate a Single Media Security Solution" 1597 [I-D.ietf-avt-srtp-not-mandatory]. For a survey of available 1598 mechanisms to meet these goals, please review "Options for Securing 1599 RTP Sessions" [I-D.ietf-avtcore-rtp-security-options]. Suitable 1600 stock text to inform people about this is included in the template. 1602 Potential security issues with an RTP payload format and the media 1603 encoding that needs to be considered are: 1605 1. That the decoding of the payload format or its media shows 1606 substantial non-uniformity, either in output or in complexity to 1607 perform the decoding operation. For example a generic non- 1608 destructive compression algorithm may provide an output of almost 1609 an infinite size for a very limited input, thus consuming memory 1610 or storage space out of proportion with what the receiving 1611 application expected. Such inputs can cause some sort of 1612 disruption, i.e. a denial of service attack on the receiver side 1613 by preventing that host from producing any goodput. Certain 1614 decoding operations may also vary in the amount of processing 1615 needed to perform those operations depending on the input. This 1616 may also be a security risk if it is possible to raise processing 1617 load significantly above nominal simply by designing a malicious 1618 input sequence. If such potential attacks exist, this must be 1619 made clear in the security considerations section to make 1620 implementers aware of the need to take precautions against such 1621 behavior. 1623 2. The inclusion of active content in the media format or its 1624 transport. "Active content" means scripts etc. that allow an 1625 attacker to perform potentially arbitrary operations on the 1626 receiver. Most active contents has limited possibility to access 1627 the system or perform operations outside a protected sandbox. 1628 RFC 4855 [RFC4855] has a requirement that it be noted in the 1629 media types registration if the payload format contains active 1630 content or not. If the payload format has active content it is 1631 strongly recommended that references to any security model 1632 applicable for such content are provided. A boilerplate text for 1633 "no active content" is included in the template. This must be 1634 changed if the format actually carries active content. 1636 3. Some media formats allow for the carrying of "user data", or 1637 types of data which are not known at the time of the 1638 specification of the payload format. Such data may be a security 1639 risk and should be mentioned. 1641 4. Audio or Speech codecs supporting variable bit-rate based on 1642 audio/speech input or having discontinuous transmission support 1643 must consider the issues discussed in Guidelines for the Use of 1644 Variable Bit Rate Audio with Secure RTP [RFC6562]. 1646 Suitable stock text for the security considerations section is 1647 provided in the template in the appendix. However, authors do need 1648 to actively consider any security issues from the start. Failure to 1649 address these issues may block approval and publication. 1651 7.3. Congestion Control 1653 RTP and its profiles do discuss congestion control. Congestion 1654 control is an important issue in any usage in non-dedicated networks. 1655 For that reason it is recommended that all RTP payload format 1656 documents discuss the possibilities that exist to regulate the bit- 1657 rate of the transmissions using the described RTP payload format. 1658 Some formats may have limited or step wise regulation of bit-rate. 1659 Such limiting factors should be discussed. 1661 7.4. IANA Considerations 1663 Since all RTP Payload formats contain a Media Type specification, 1664 they also need an IANA Considerations section. The Media Type name 1665 must be registered and this is done by requesting that IANA register 1666 that media name. When that registration request is written it shall 1667 also be requested that the media type is included under the "RTP 1668 Payload Format media types" list part of the RTP registry (http:// 1669 www.iana.org/assignments/rtp-parameters). 1671 In addition to the above request for media type registration, some 1672 payload formats may have parameters where in the future new parameter 1673 values need to be added. In these cases a registry for that 1674 parameter must be created. This is done by defining the registry in 1675 the IANA Considerations section. BCP 26 [RFC5226] provides 1676 guidelines to specifying such registries. Care should be taken when 1677 defining the policy for new registrations. 1679 Before specifying a new registry it is worth checking the existing 1680 ones in the IANA "MIME Media Type Sub-Parameter Registries" list. 1681 For example video formats needing a media parameter expressing color 1682 sub-sampling may be able to reuse those defined for video/raw 1683 [RFC4175]. 1685 8. Authoring Tools 1687 This section provides information about some tools that may be used. 1688 Don't feel pressured to follow these recommendations. There exist a 1689 number of alternatives. But these suggestions are worth checking out 1690 before deciding that the field is greener somewhere else. 1692 8.1. Editing Tools 1694 There are many choices when it comes to tools to choose for authoring 1695 Internet drafts. However in the end they need to be able to produce 1696 a draft that conforms to the Internet Draft requirements. If you 1697 don't have any previous experience with authoring Internet drafts 1698 XML2RFC does have some advantages. It helps by create a lot of the 1699 necessary boiler plate in accordance with the latest rules, thus 1700 reducing the effort. It also speeds up publication after approval as 1701 the RFC-editor can use the source XML document to produce the RFC 1702 more quickly. 1704 Another common choice is to use Microsoft Word and a suitable 1705 template, see [RFC5385] to produce the draft and print that to file 1706 using the generic text printer. It has some advantages when it comes 1707 to spell checking and change bars. However Word may also produce 1708 some problems, like changing formatting, and inconsistent results 1709 between what one sees in the editor and in the generated text 1710 document, at least according to the authors' personal experience. 1712 8.2. Verification Tools 1714 There are a few tools that are very good to know about when writing a 1715 draft. These help check and verify parts of one's work. These tools 1716 can be found at http://tools.ietf.org. 1718 o ID Nits checker. It checks that the boiler plate and some other 1719 things that are easily verifiable by machine are okay in your 1720 draft. Always use it before submitting a draft to avoid direct 1721 refusal in the submission step. 1723 o ABNF Parser and verification. Checks that your ABNF parses 1724 correctly and warns about loose ends, like undefined symbols. 1725 However the actual content can only be verified by humans knowing 1726 what it intends to describe. 1728 o RFC diff. A diff tool that is optimized for drafts and RFCs. For 1729 example it does not point out that the footer and header have 1730 moved in relation to the text on every page. 1732 9. IANA Considerations 1734 This document makes no request of IANA. 1736 Note to RFC Editor: this section may be removed on publication as an 1737 RFC. 1739 10. Security Considerations 1741 As this is an informational document about writing drafts that are 1742 intended to become RFCs there are no direct security considerations. 1743 However the document does discuss the writing of security 1744 considerations sections and what should be particularly considered 1745 when specifying RTP payload formats. 1747 11. Contributors 1749 The author would like to thank Tom Taylor for the editing pass of the 1750 whole document and contributing text regarding proprietary RTP 1751 payload formats. Thanks also goes to Thomas Schierl who contributed 1752 text regarding Media Scalability features in payload formats. 1754 12. Acknowledgements 1756 The author would like to thank the individuals who have provided 1757 input to this document. These individuals include John Lazzaro, Ali 1758 C. Begen and Tom Taylor. 1760 13. Informative References 1762 [CSP-RTP] Perkins, C., "RTP: Audio and Video for the Internet", June 1763 2003. 1765 [I-D.ietf-avt-srtp-not-mandatory] 1766 Perkins, C. and M. Westerlund, "Securing the RTP Protocol 1767 Framework: Why RTP Does Not Mandate a Single Media 1768 Security Solution", draft-ietf-avt-srtp-not-mandatory-12 1769 (work in progress), February 2013. 1771 [I-D.ietf-avtcore-rtp-security-options] 1772 Westerlund, M. and C. Perkins, "Options for Securing RTP 1773 Sessions", draft-ietf-avtcore-rtp-security-options-02 1774 (work in progress), February 2013. 1776 [MACOSFILETYPES] 1777 Apple Knowledge Base Article 1778 55381, "Mac OS: 1779 File Type and Creator Codes, and File Formats", 1993. 1781 [RFC-ED] http://www.rfc-editor.org/policy.html, "RFC Editorial 1782 Guidelines and Procedures", July 2008. 1784 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1785 3", BCP 9, RFC 2026, October 1996. 1787 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 1788 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 1789 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 1790 September 1997. 1792 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1793 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1795 [RFC2360] Scott, G.D., "Guide for Internet Standards Writers", BCP 1796 22, RFC 2360, June 1998. 1798 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 1799 Procedures", BCP 25, RFC 2418, September 1998. 1801 [RFC2508] Casner, S.L. and V. Jacobson, "Compressing IP/UDP/RTP 1802 Headers for Low-Speed Serial Links", RFC 2508, February 1803 1999. 1805 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1806 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1807 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1809 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 1810 Payload Format Specifications", BCP 36, RFC 2736, December 1811 1999. 1813 [RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time 1814 Transport Protocol Management Information Base", RFC 2959, 1815 October 2000. 1817 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1818 Announcement Protocol", RFC 2974, October 2000. 1820 [RFC3009] Rosenberg, J. and H. Schulzrinne, "Registration of 1821 parityfec MIME types", RFC 3009, November 2000. 1823 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1824 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 1825 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 1826 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 1827 Compression (ROHC): Framework and four profiles: RTP, UDP, 1828 ESP, and uncompressed", RFC 3095, July 2001. 1830 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1831 A., Peterson, J., Sparks, R., Handley, M., and E. 1832 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1833 June 2002. 1835 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1836 with Session Description Protocol (SDP)", RFC 3264, June 1837 2002. 1839 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1840 "Introduction and Applicability Statements for Internet- 1841 Standard Management Framework", RFC 3410, December 2002. 1843 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 1844 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 1845 High Delay, Packet Loss and Reordering", RFC 3545, July 1846 2003. 1848 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1849 Jacobson, "RTP: A Transport Protocol for Real-Time 1850 Applications", STD 64, RFC 3550, July 2003. 1852 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1853 Video Conferences with Minimal Control", STD 65, RFC 3551, 1854 July 2003. 1856 [RFC3558] Li, A., "RTP Payload Format for Enhanced Variable Rate 1857 Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 1858 3558, July 2003. 1860 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1861 Multicast (SSM)", RFC 3569, July 2003. 1863 [RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. 1864 Romascanu, "Introduction to the Remote Monitoring (RMON) 1865 Family of MIB Modules", RFC 3577, August 2003. 1867 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 1868 Protocol Extended Reports (RTCP XR)", RFC 3611, November 1869 2003. 1871 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1872 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1873 RFC 3711, March 2004. 1875 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1876 G. Fairhurst, "The Lightweight User Datagram Protocol 1877 (UDP-Lite)", RFC 3828, July 2004. 1879 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 1880 Technology", BCP 79, RFC 3979, March 2005. 1882 [RFC3984] Wenger, S., Hannuksela, M.M., Stockhammer, T., Westerlund, 1883 M., and D. Singer, "RTP Payload Format for H.264 Video", 1884 RFC 3984, February 2005. 1886 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1887 Conversation", RFC 4103, June 2005. 1889 [RFC4170] Thompson, B., Koren, T., and D. Wing, "Tunneling 1890 Multiplexed Compressed RTP (TCRTP)", BCP 110, RFC 4170, 1891 November 2005. 1893 [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for 1894 Uncompressed Video", RFC 4175, September 2005. 1896 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1897 Internet Protocol", RFC 4301, December 2005. 1899 [RFC4352] Sjoberg, J., Westerlund, M., Lakaniemi, A., and S. Wenger, 1900 "RTP Payload Format for the Extended Adaptive Multi-Rate 1901 Wideband (AMR-WB+) Audio Codec", RFC 4352, January 2006. 1903 [RFC4396] Rey, J. and Y. Matsui, "RTP Payload Format for 3rd 1904 Generation Partnership Project (3GPP) Timed Text", RFC 1905 4396, February 2006. 1907 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1908 Description Protocol", RFC 4566, July 2006. 1910 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1911 and RTP Control Protocol (RTCP) Packets over Connection- 1912 Oriented Transport", RFC 4571, July 2006. 1914 [RFC4573] Even, R. and A. Lochbaum, "MIME Type Registration for RTP 1915 Payload Format for H.224", RFC 4573, July 2006. 1917 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1918 "Extended RTP Profile for Real-time Transport Control 1919 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 1920 2006. 1922 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1923 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1924 July 2006. 1926 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1927 Encodings", RFC 4648, October 2006. 1929 [RFC4844] Daigle, L. Internet Architecture Board, "The RFC Series 1930 and RFC Editor", RFC 4844, July 2007. 1932 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1933 Formats", RFC 4855, February 2007. 1935 [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, 1936 "RTP Payload Format and File Storage Format for the 1937 Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband 1938 (AMR-WB) Audio Codecs", RFC 4867, April 2007. 1940 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1941 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1943 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 1944 Correction", RFC 5109, December 2007. 1946 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1947 Real-time Transport Control Protocol (RTCP)-Based Feedback 1948 (RTP/SAVPF)", RFC 5124, February 2008. 1950 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1951 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1952 May 2008. 1954 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1955 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1957 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1958 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1960 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 1961 Header Extensions", RFC 5285, July 2008. 1963 [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide 1964 to the IETF Trust", BCP 78, RFC 5378, November 2008. 1966 [RFC5385] Touch, J., "Version 2.0 Microsoft Word Template for 1967 Creating Internet Drafts and RFCs", RFC 5385, February 1968 2010. 1970 [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC 1971 5484, March 2009. 1973 [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 1974 Dependency in the Session Description Protocol (SDP)", RFC 1975 5583, July 2009. 1977 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1978 for Establishing a Secure Real-time Transport Protocol 1979 (SRTP) Security Context Using Datagram Transport Layer 1980 Security (DTLS)", RFC 5763, May 2010. 1982 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1983 Security (DTLS) Extension to Establish Keys for the Secure 1984 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1986 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 1987 Header Compression (ROHC) Framework", RFC 5795, March 1988 2010. 1990 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1991 Time Protocol Version 4: Protocol and Algorithms 1992 Specification", RFC 5905, June 2010. 1994 [RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity 1995 Forward Error Correction (FEC)", RFC 6015, October 2010. 1997 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 1998 Flows", RFC 6051, November 2010. 2000 [RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP 2001 Payload Format for H.264 Video", RFC 6184, May 2011. 2003 [RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. 2004 Eleftheriadis, "RTP Payload Format for Scalable Video 2005 Coding", RFC 6190, May 2011. 2007 [RFC6295] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for 2008 MIDI", RFC 6295, June 2011. 2010 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2011 Security Version 1.2", RFC 6347, January 2012. 2013 [RFC6354] Xie, Q., "Forward-Shifted RTP Redundancy Payload Support", 2014 RFC 6354, August 2011. 2016 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 2017 Correction (FEC) Framework", RFC 6363, October 2011. 2019 [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the 2020 Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 2021 October 2011. 2023 [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of 2024 Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2025 2012. 2027 [RFC6597] Downs, J. and J. Arbeiter, "RTP Payload Format for Society 2028 of Motion Picture and Television Engineers (SMPTE) ST 336 2029 Encoded Data", RFC 6597, April 2012. 2031 [RFC6682] Watson, M., Stockhammer, T., and M. Luby, "RTP Payload 2032 Format for Raptor Forward Error Correction (FEC)", RFC 2033 6682, August 2012. 2035 [RFC6722] Hoffman, P., "Publishing the "Tao of the IETF" as a Web 2036 Page", RFC 6722, August 2012. 2038 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2039 Specifications and Registration Procedures", BCP 13, RFC 2040 6838, January 2013. 2042 Appendix A. RTP Payload Format Template 2044 This section contains a template for writing an RTP payload format in 2045 form as a Internet draft. Text within [...] are instructions and 2046 must be removed. Some text proposals that are included are 2047 conditional. "..." is used to indicate where further text should be 2048 written. 2050 A.1. Title 2052 [The title shall be descriptive but as compact as possible. RTP is 2053 allowed and recommended abbreviation in the title] 2055 RTP Payload format for ... 2057 A.2. Front page boilerplate 2059 Status of this Memo 2061 [Insert the IPR notice and copyright boiler plate from BCP 78 and 79 2062 that applies to this draft.] 2064 [Insert the current Internet Draft document explanation. At the time 2065 of publishing it was:] 2067 Internet-Drafts are working documents of the Internet Engineering 2068 Task Force (IETF). Note that other groups may also distribute 2069 working documents as Internet-Drafts. The list of current Internet- 2070 Drafts is at http://datatracker.ietf.org/drafts/current/. 2072 Internet-Drafts are draft documents valid for a maximum of six months 2073 and may be updated, replaced, or obsoleted by other documents at any 2074 time. It is inappropriate to use Internet-Drafts as reference 2075 material or to cite them other than as "work in progress." 2077 A.3. Abstract 2079 [A payload format abstract should mention the capabilities of the 2080 format, for which media format is used, and a little about that codec 2081 formats capabilities. Any abbreviation used in the payload format 2082 must be spelled out here except the very well known like RTP. No 2083 references are allowed, no use of RFC 2119 language either.] 2085 A.4. Table of Content 2087 [All drafts over 15 pages in length must have an Table of Content.] 2089 A.5. Introduction 2091 [The introduction should provide a background and overview of the 2092 payload formats capabilities. No normative language in this section, 2093 i.e. no MUST, SHOULDs etc.] 2095 A.6. Conventions, Definitions and Acronyms 2097 [Define conventions, definitions and acronyms used in the document in 2098 this section. The most common definition used in RTP Payload formats 2099 are the RFC 2119 definitions of the upper case normative words, e.g. 2100 MUST and SHOULD.] 2102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 2103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 2104 document are to be interpreted as described in RFC 2119. 2106 A.7. Media Format Description 2108 [The intention of this section is to enable reviewers and persons to 2109 get an overview of the capabilities and major properties of the media 2110 format. It should be kept short and concise and is not a complete 2111 replacement for reading the media format specification.] 2113 A.8. Payload format 2115 [Overview of payload structure] 2117 A.8.1. RTP Header Usage 2119 [RTP header usage needs to be defined. The fields that absolutely 2120 need to be defined are timestamp and marker bit. Further field may 2121 be specified if used. All the rest should be left to their RTP 2122 specification definition] 2124 The remaining RTP header fields are used as specified in RTP [RFC 2125 3550]. 2127 A.8.2. Payload Header 2129 [Define how the payload header, if it exist, is structured and used.] 2131 A.8.3. Payload Data 2133 [The payload data, i.e. what the media codec has produced. Commonly 2134 done through reference to media codec specification which defines how 2135 the data is structured. Rules for padding may need to be defined to 2136 bring data to octet alignment.] 2138 A.9. Payload Examples 2140 [One or more examples are good to help ease the understanding of the 2141 RTP payload format.] 2143 A.10. Congestion Control Considerations 2145 [This section is to describe the possibility to vary the bit-rate as 2146 a response to congestion. Below is also a proposal for an initial 2147 text that reference RTP and profiles definition of congestion 2148 control.] 2149 Congestion control for RTP SHALL be used in accordance with RFC 3550 2150 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 2151 [RFC3551]. An additional requirement if best-effort service is being 2152 used is: users of this payload format MUST monitor packet loss to 2153 ensure that the packet loss rate is within acceptable parameters. 2155 A.11. Payload Format Parameters 2157 This RTP payload format is identified using the ... media type which 2158 is registered in accordance with RFC 4855 [RFC4855] and using the 2159 template of RFC 6838 [RFC6838]. 2161 A.11.1. Media Type Definition 2163 [Here the media type registration template from RFC 6838 is placed 2164 and filled out. This template is provided with some common RTP 2165 boilerplate.] 2167 Type name: 2169 Subtype name: 2171 Required parameters: 2173 Optional parameters: 2175 Encoding considerations: 2177 This media type is framed and binary, see section 4.8 in RFC6838 2178 [RFC6838]. 2180 Security considerations: 2182 Please see security consideration in RFCXXXX 2184 Interoperability considerations: 2186 Published specification: 2188 Applications that use this media type: 2190 Additional information: 2192 Deprecated alias names for this type: 2194 [Only applicable if there exists widely deployed alias for this 2195 media type; see Section 4.2.9 of [RFC6838]. Remove or use N/A 2196 otherwise.] 2198 Magic number(s): 2200 [Only applicable for media types that has file format 2201 specification. Remove or use N/A otherwise.] 2203 File extension(s): 2205 [Only applicable for media types that has file format 2206 specification. Remove or use N/A otherwise.] 2208 Macintosh file type code(s): 2210 [Only applicable for media types that has file format 2211 specification. Remove or use N/A otherwise.] 2213 Person & email address to contact for further information: 2215 Intended usage: 2217 [One of COMMON, LIMITED USE or OBSOLETE.] 2219 Restrictions on usage: 2221 [The below text is for media types that is only defined for RTP 2222 payload formats. There exist certain media types that are defined 2223 both as RTP payload formats and file transfer. The rules for such 2224 types are documented in RFC 4855 [RFC4855].] 2226 This media type depends on RTP framing, and hence is only defined 2227 for transfer via RTP [RFC3550]. Transport within other framing 2228 protocols is not defined at this time. 2230 Author: 2232 Change controller: 2234 IETF Payload working group delegated from the IESG. 2236 Provisional registration? (standards tree only): 2238 No 2240 (Any other information that the author deems interesting may be added 2241 below this line.) 2243 [From RFC 6838: 2245 Some discussion of Macintosh file type codes and their purpose can 2246 be found in [MACOSFILETYPES]. 2248 N/A", written exactly that way, can be used in any field if 2249 desired to emphasize the fact that it does not apply or that the 2250 question was not omitted by accident. Do not use 'none' or other 2251 words that could be mistaken for a response. 2253 Limited-use media types should also note in the applications list 2254 whether or not that list is exhaustive.] 2256 A.11.2. Mapping to SDP 2258 The mapping of the above defined payload format media type and its 2259 parameters SHALL be done according to Section 3 of RFC 4855 2260 [RFC4855]. 2262 [More specific rules only need to be included if some parameter does 2263 not match these rules.] 2265 A.11.2.1. Offer/Answer Considerations 2267 [Here write your offer/answer consideration section, please see 2268 Section 3.3.2.1 for help.] 2270 A.11.2.2. Declarative SDP Considerations 2272 [Here write your considerations for declarative SDP, please see 2273 Section 3.3.2.2 for help.] 2275 A.12. IANA Considerations 2277 This memo requests that IANA registers [insert media type name here] 2278 as specified in Appendix A.11.1. The media type is also requested to 2279 be added to the IANA registry for "RTP Payload Format MIME types" 2280 (http://www.iana.org/assignments/rtp-parameters). 2282 [See Section 7.4 and consider if any of the parameter needs a 2283 registered name space.] 2285 A.13. Security Considerations 2287 [See Section 7.2] 2289 RTP packets using the payload format defined in this specification 2290 are subject to the security considerations discussed in the RTP 2291 specification [RFC3550] , and in any applicable RTP profile such as 2292 RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ 2293 SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: 2294 Why RTP Does Not Mandate a Single Media Security Solution" 2295 [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload 2296 formats responsibility to discuss or mandate what solutions are used 2297 to meet the basic security goals like confiedenitality, integrity and 2298 source authenticity for RTP in general. This responsibility lays on 2299 anyone using RTP in an application. They can find guidance on 2300 available security mechanisms and important considerations in Options 2301 for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. 2302 The rest of the this security consideration discusses the security 2303 impacting properties of the payload format itself. 2305 This RTP payload format and its media decoder do not exhibit any 2306 significant non-uniformity in the receiver-side computational 2307 complexity for packet processing, and thus are unlikely to pose a 2308 denial-of-service threat due to the receipt of pathological data. 2309 Nor does the RTP payload format contain any active content. 2311 [The previous paragraph may need editing due to the format breaking 2312 either of the statements. Fill in here any further potential 2313 security threats created by the payload format itself.] 2315 A.14. RFC Editor Considerations 2317 Note to RFC Editor: This section may be removed after carrying out 2318 all the instructions of this section. 2320 RFCXXXX is to be replaced by the RFC number this specification 2321 receives when published. 2323 A.15. References 2325 [References must be classified as either normative or informative and 2326 added to the relevant section. References should use descriptive 2327 reference tags.] 2329 A.15.1. Normative References 2331 [Normative references are those that are required to be used to 2332 correctly implement the payload format.] 2334 A.15.2. Informative References 2336 [All other references.] 2338 A.16. Author Addresses 2340 [All Authors need to include their Name and email addresses as a 2341 minimal. Commonly also surface mail and possibly phone numbers are 2342 included.] 2344 [The Template Ends Here!] 2346 Author's Address 2348 Magnus Westerlund 2349 Ericsson 2350 Farogatan 6 2351 SE-164 80 Kista 2352 Sweden 2354 Phone: +46 10 714 82 87 2355 Email: magnus.westerlund@ericsson.com