idnits 2.17.1 draft-ietf-avt-rtp-howto-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2070. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2081. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2088. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2094. 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 : ---------------------------------------------------------------------------- -- 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 11, 2008) is 5706 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- 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 3285 (Obsoleted by RFC 5385) -- Obsolete informational reference (is this intentional?): RFC 3978 (Obsoleted by RFC 5378) -- 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 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4677 (Obsoleted by RFC 6722) -- Obsolete informational reference (is this intentional?): RFC 4695 (Obsoleted by RFC 6295) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio Video Transport Working M. Westerlund 3 Group Ericsson 4 Internet-Draft September 11, 2008 5 Intended status: Informational 6 Expires: March 15, 2009 8 How to Write an RTP Payload Format 9 draft-ietf-avt-rtp-howto-05 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 15, 2009. 36 Abstract 38 This document contains information on how to best write an RTP 39 payload format. Reading tips, design practices, and practical tips 40 on how to quickly and with good results produce an RTP payload format 41 specification. A template is also included with instructions that 42 can be used when writing an RTP payload format. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 47 1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 5 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 50 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 51 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 3. Preparations . . . . . . . . . . . . . . . . . . . . . . . . . 8 54 3.1. Recommend Reading . . . . . . . . . . . . . . . . . . . . 8 55 3.1.1. IETF Process and Publication . . . . . . . . . . . . . 8 56 3.1.2. RTP . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 3.2. Important RTP details . . . . . . . . . . . . . . . . . . 13 58 3.2.1. The RTP Session . . . . . . . . . . . . . . . . . . . 13 59 3.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . . 14 60 3.2.3. RTP Multiplexing . . . . . . . . . . . . . . . . . . . 15 61 3.2.4. RTP Synchronization . . . . . . . . . . . . . . . . . 16 62 3.3. Signalling Aspects . . . . . . . . . . . . . . . . . . . . 17 63 3.3.1. Media Types . . . . . . . . . . . . . . . . . . . . . 17 64 3.3.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 18 65 3.4. Transport Characteristics . . . . . . . . . . . . . . . . 21 66 3.4.1. Path MTU . . . . . . . . . . . . . . . . . . . . . . . 21 68 4. Specification Process . . . . . . . . . . . . . . . . . . . . 22 69 4.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 70 4.1.1. Steps from Idea to Publication . . . . . . . . . . . . 22 71 4.1.2. WG meetings . . . . . . . . . . . . . . . . . . . . . 24 72 4.1.3. Draft Naming . . . . . . . . . . . . . . . . . . . . . 24 73 4.1.4. How to speed up the process . . . . . . . . . . . . . 24 74 4.2. Other Standards bodies . . . . . . . . . . . . . . . . . . 25 75 4.3. Propreitary and Vendor Specific . . . . . . . . . . . . . 26 77 5. Designing Payload Formats . . . . . . . . . . . . . . . . . . 27 78 5.1. Features of RTP payload formats . . . . . . . . . . . . . 27 79 5.1.1. Aggregation . . . . . . . . . . . . . . . . . . . . . 27 80 5.1.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 28 81 5.1.3. Interleaving and Transmission Re-Scheduling . . . . . 28 82 5.1.4. Media Back Channels . . . . . . . . . . . . . . . . . 29 83 5.1.5. Scalability . . . . . . . . . . . . . . . . . . . . . 29 84 5.1.6. High Packet Rates . . . . . . . . . . . . . . . . . . 30 86 6. Current Trends in Payload Format Design . . . . . . . . . . . 31 87 6.1. Audio Payloads . . . . . . . . . . . . . . . . . . . . . . 31 88 6.2. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 31 89 6.3. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 91 7. Important Specification Sections . . . . . . . . . . . . . . . 33 92 7.1. Security Consideration . . . . . . . . . . . . . . . . . . 33 93 7.2. Congestion Control . . . . . . . . . . . . . . . . . . . . 34 94 7.3. IANA Consideration . . . . . . . . . . . . . . . . . . . . 34 96 8. Authoring Tools . . . . . . . . . . . . . . . . . . . . . . . 36 97 8.1. Editing Tools . . . . . . . . . . . . . . . . . . . . . . 36 98 8.2. Verification Tools . . . . . . . . . . . . . . . . . . . . 36 100 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 37 102 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 104 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 106 12. RFC Editor Consideration . . . . . . . . . . . . . . . . . . . 40 108 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 110 14. Informative References . . . . . . . . . . . . . . . . . . . . 42 112 Appendix A. RTP Payload Format Template . . . . . . . . . . . . . 47 113 A.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 47 114 A.2. Front page boilerplate . . . . . . . . . . . . . . . . . . 47 115 A.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 48 116 A.4. Table of Content . . . . . . . . . . . . . . . . . . . . . 48 117 A.5. Introduction . . . . . . . . . . . . . . . . . . . . . . . 48 118 A.6. Conventions, Definitions and Acronyms . . . . . . . . . . 48 119 A.7. Media Format Background . . . . . . . . . . . . . . . . . 48 120 A.8. Payload format . . . . . . . . . . . . . . . . . . . . . . 48 121 A.8.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . 49 122 A.8.2. Payload Header . . . . . . . . . . . . . . . . . . . . 49 123 A.8.3. Payload Data . . . . . . . . . . . . . . . . . . . . . 49 124 A.9. Payload Examples . . . . . . . . . . . . . . . . . . . . . 49 125 A.10. Congestion Control Considerations . . . . . . . . . . . . 49 126 A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 49 127 A.11.1. Media Type Definition . . . . . . . . . . . . . . . . 49 128 A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 51 129 A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 51 130 A.13. Securtiy Considerations . . . . . . . . . . . . . . . . . 51 131 A.14. References . . . . . . . . . . . . . . . . . . . . . . . . 52 132 A.14.1. Normative References . . . . . . . . . . . . . . . . . 52 133 A.14.2. Informative References . . . . . . . . . . . . . . . . 52 134 A.15. Author Addresses . . . . . . . . . . . . . . . . . . . . . 53 135 A.16. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . 53 136 A.17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 53 138 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 54 139 Intellectual Property and Copyright Statements . . . . . . . . . . 55 141 1. Introduction 143 RTP [RFC3550] payload formats define how a specific real-time data 144 format is structured in the payload of an RTP packet. A real-time 145 data format without a payload format specification can't be 146 transported using RTP. This creates an interest from many 147 individuals/organizations with media encoders or other types of real- 148 time data to define RTP payload formats. The specification of a well 149 designed RTP payload format is non-trivial and requires knowledge of 150 both RTP and the real-time data format. 152 This document intends to help any author of an RTP payload format to 153 make important design decisions, consider important features of RTP, 154 security, etc. The document is also intended to be a good starting 155 point for any person with little experience in IETF and/or RTP to 156 learn the necessary steps. 158 This document extends and updates the information that are available 159 in "Guidelines for Writers of RTP Payload Format Specifications" 160 [RFC2736]. Since this RFC was written further experience has been 161 gained on the design and specification of RTP payload format. 162 Several new RTP profiles, and robustness tools has also been defined, 163 which needs to be considered. 165 We also discuss the possible venues of defining an RTP payload 166 format, in IETF, by other standard bodies and proprietary ones. 167 Independent on the intended venue of specification, all will gain 168 from this document. 170 1.1. Structure 172 This document has several different parts discussing different 173 aspects of the creation of an RTP payload format specification. 174 After the introduction and definitions there are a section discussing 175 the preparations the author(s) should do before start writing. The 176 following section discusses the different processes used when 177 specifying and completing an payload format, with focus on working 178 inside the IETF. Section 5 discusses the design of payload formats 179 themselves in detail. Section 6 discusses the current design trends 180 and provides good examples of practices that should be followed when 181 applicable. Following that there is a discussion on important 182 sections in the RTP payload format specification itself, like 183 security and IANA considerations. This document ends with an 184 appendix containing an template that can be used when writing RTP 185 payload formats. 187 2. Terminology 189 2.1. Definitions 191 Media Stream: A sequence of RTP packets that together provides all 192 or parts of a media. It is scoped in RTP by the RTP session and a 193 single sender source. 195 RTP Session: An association among a set of participants 196 communicating with RTP. The distinguishing feature of an RTP 197 session is that each maintains a full, separate space of SSRC 198 identifiers. See also Section (Section 3.2.1). 200 RTP Payload Format: The RTP Payload format specifies how a specific 201 media format is put into the RTP Payloads. Thus enabling the 202 format to be used in RTP sessions. 204 2.2. Acronyms 206 ABNF: Augmented Backus-Naur Form 208 ADU: Application Data Unit 210 ALF: Application Level Framing 212 ASM: Any-Source Multicast 214 AVT: Audio Video Transport 216 BCP: Best Current Practice 218 ID: Internet Draft 220 MTU: Maximum Transmission Unit 222 WG: Working Group 224 QoS: Quality of Service 226 RFC: Request For Comment 228 RTP: Real-time Transport Protocol 230 RTCP: RTP Control Protocol 231 RTT: Round Trip Time 233 SSM: Source Specific Multicast 235 3. Preparations 237 RTP is a complex real-time media delivery framework and it has a lot 238 of details to consider when writing an RTP payload format. There is 239 also important to have a good understanding of the media codec/format 240 so that all its important features and properties are considered. 241 First when one has sufficient understanding of both parts can one 242 produce an RTP payload format of high quality. On top of this, one 243 needs to understand the process within IETF and especially the AVT WG 244 to quickly go from initial idea to a finished RFC. This and the next 245 section helps an author prepare himself in those regards. 247 3.1. Recommend Reading 249 In the below sub sections there are a number of documents listed. 250 Not all needs to be read in full detail. However, an author 251 basically needs to be aware of everything listed below. 253 3.1.1. IETF Process and Publication 255 For newcomers to IETF it is strongly recommended that one reads the 256 "Tao of the IETF" [RFC4677] that goes through most things that one 257 needs to know about the IETF. It contains information about history, 258 organisational structure, how the WG and meetings work and many more 259 details. 261 The main part of the IETF process is defined in RFC 2026 [RFC2026]. 262 In addition an author needs to understands the IETF rules and rights 263 associated with copyright and IPR documented in BCP 78 [RFC3978] and 264 BCP 79 [RFC3979]. RFC 2418 [RFC2418] describes the WG process, the 265 relation between the IESG and the WG, and the responsibilities of WG 266 chairs and participants. 268 It is important to note that the RFC series contains documents of 269 several different classifications; standards track, informational, 270 experimental, best current practice (BCP), and historic. The 271 standard tracks contains documents of three different maturity 272 classifications, proposed, draft and Internet Standard. A standards 273 track document must start as proposed, after proved interoperability 274 of all the features it can be moved to draft standard, and final when 275 further experience has been gathered it can be moved to Internet 276 standard. As the content of the RFCs are not allowed to be changed, 277 the only way of updating an RFC is to write and publish a new one 278 that either updates or replaces the old one. Therefore it is 279 important to both consider the Category field in the header and check 280 if the RFC one is reading or going to reference is the latest and 281 valid. One way of checking the current status of an RFC is to use 282 the RFC-editor's RFC search engine, which displays the current status 283 and which if any RFCs that updates or obsolete it. 285 Before starting to write an draft one should also read the Internet 286 Draft writing guidelines 287 (http://www.ietf.org/ietf/1id-guidelines.txt), the ID checklist 288 (http://www.ietf.org/ID-Checklist.html) and the RFC editorial 289 guidelines and procedures [RFC-ED]. Another document that can be 290 useful is the "Guide for Internet Standards Writers" [RFC2360]. 292 There are also a number of documents to consider in process of 293 writing of drafts intended to become RFCs. These are important when 294 writing certain type of text. 296 RFC 2606: When writing examples using DNS names in Internet drafts, 297 those name shall be using the example.com, example.net, and 298 example.org domains. 300 RFC 3849: Defines the range of IPv6 unicast addresses (2001: 301 DB8::/32) that should be used in any examples. 303 RFC 3330: Defines the range of IPv4 unicast addresses reserved for 304 documentation and examples: 192.0.2.0/24. 306 RFC 5234: Augmented Backus-Naur Form (ABNF) is often used when 307 writing text field specifications. Not that commonly used in RTP 308 payload formats but may be useful when defining Media Type 309 parameters of some complexity. 311 3.1.2. RTP 313 The recommended reading for RTP consist of several different parts; 314 design guidelines, the RTP protocol, profiles, robustness tools, and 315 media specific recommendations. 317 Any author of RTP payload formats should start with reading RFC 2736 318 [RFC2736] which contains an introduction to the application layer 319 framing (ALF) principle, the channel characteristics of IP channels, 320 and design guidelines for RTP payload formats. The goal of ALF is to 321 be able to transmit Application Data Units (ADUs) that are 322 independently usable by the receiver in individual RTP packets. Thus 323 minimizing dependencies between RTP packets and the effects of packet 324 loss. 326 Then it is suitable to learn more about the RTP protocol, by studying 327 the RTP specification RFC 3550 [RFC3550] and the existing profiles. 328 As a complement to the standards document there exist a book totally 329 dedicated to RTP [CSP-RTP]. There exist several profiles for RTP 330 today, but all are based on the "RTP Profile for Audio and Video 331 Conferences with Minimal Control" (RFC 3551) [RFC3551] (abbreviated 332 AVP). The other profiles that one should known about are Secure RTP 333 (SAVP) [RFC3711], "Extended RTP Profile for RTCP-based Feedback" 334 [RFC4585] and "Extended Secure RTP Profile for RTCP-based Feedback 335 (RTP/SAVPF)" [RFC5124]. It is important to understand RTP and the 336 AVP profile in detail. For the other profiles it is sufficient to 337 have an understanding on what functionality they provided and the 338 limitations they create. 340 There has been developed a number of robustness tools for RTP. The 341 tools are for different use cases and real-time requirements. 343 RFC 2198: The "RTP Payload for Redundant Audio Data" [RFC2198] 344 provides functionalities to provided redundant copies of audio or 345 text payloads. These redundant copies are sent together with an 346 primary format in the same RTP payload. This format relies on the 347 RTP timestamp to determine where data belongs in a sequence and 348 therefore is usually primarily suitable to be used with audio. 349 However also the RTP Payload format for T.140 [RFC4103] text 350 format uses this format. The formats major property is that it 351 only preserves the timestamp of the redundant payloads, not the 352 original sequence number. Thus making it unusable for most video 353 formats. This format is also only suitable for media formats that 354 produce relatively small RTP payloads. 356 RFC 5109: The "RTP Payload Format for Generic Forward Error 357 Correction" [RFC5109] provides an XOR based FEC of the whole or 358 parts of a the packets for a number of RTP packets. These FEC 359 packets are sent in a separate stream or as a redundant encoding 360 using RFC 2198. This FEC scheme has certain restrictions in the 361 number of packets it can protect. It is suitable for low to 362 medium delay tolerant applications with limited amount of RTP 363 packets. 365 RTP Retransmission: The RTP retransmission scheme [RFC4588] is used 366 for semi-reliability of the most important RTP packets in a media 367 stream. The scheme is not intended, nor suitable, to provide full 368 reliability. It requires the application to be quite delay 369 tolerant as a minimum of one round-trip time plus processing delay 370 is required to perform an retransmission. Thus it is mostly 371 suitable for streaming applications but may also be usable in 372 certain other cases when operating on networks with short round 373 trip times (RTT). 375 RTP over TCP: RFC 4571 [RFC4571] defines how one sends RTP and RTCP 376 packet over connection oriented transports like TCP. If one uses 377 TCP one gets reliability for all packets but loose some of the 378 real-time behavior that RTP was designed to provide. Issues with 379 TCP transport of real-time media include head of line blocking and 380 wasting resources on retransmission of already late data. TCP is 381 also limited to point-to-point connections which further restricts 382 its applicability. 384 There has also been discussion and also design of RTP payload 385 formats, e.g AMR and AMR-WB[RFC4867], supporting the unequal error 386 detection provided by UDP-Lite [RFC3828]. The idea is that by not 387 having a checksum over part of the RTP payload one can allow bit- 388 errors from the lower layers. By allowing bit-errors one can 389 increase the efficiency of some link layers, and also avoid 390 unnecessary discards of data when the payload and media codec could 391 get at least some utility from the data. The main issue is that one 392 has no idea on the level of bit-errors present in the unprotected 393 part of the payload. Which makes it hard or impossible to determine 394 if one can design something usable or not. Payload format designers 395 are recommended against considering features for unequal error 396 detection unless very clear requirements exist. 398 There also exist some management and monitoring extensions. 400 RFC 2959: The RTP protocol Management Information Database (MIB) 401 [RFC2959] that is used with SNMP [RFC3410] to configure and 402 retrieve information about RTP sessions. 404 RFC 3611: The RTCP Extended Reports (RTCP XR) [RFC3611] consist of a 405 framework for reports sent within RTCP. It can easily be extended 406 by defining new report formats in future. The report formats that 407 are defined are providing report information on; packet loss 408 vectors, packet duplication, packet reception times, RTCP 409 statistics summary and VoIP Quality. It also defines a mechanism 410 that allows receivers to calculate the RTT to other session 411 participants when used. 413 RMONMIB: The remote monitoring work group has defined a mechanism 414 [RFC3577] based on usage of the MIB that can be an alternative to 415 RTCP XR. 417 There has also been developed a number of transport optimizations 418 that are used in certain environments. They are all intended to be 419 transparent and not need special consideration by the RTP payload 420 format writer. Thus they are primarily listed here for informational 421 reasons and do not require deeper studies. 423 RFC 2508: Compressing IP/UDP/RTP headers for slow serial links 424 (CRTP) [RFC2508] is the first IETF developed RTP header 425 compression mechanism. It provides quite good compression however 426 it has clear performance problems when subject to packet loss or 427 reordering between compressor and decompressor. 429 RFC 3095: Is the base specification of the robust header compression 430 (ROHC) protocol [RFC3095]. This solution was created as a result 431 of CRTP's lack of performance when subject to losses. 433 RFC 3545: Enhanced compressed RTP (E-CRTP) [RFC3545] was developed 434 to provide extensions to CRTP that allows for better performance 435 over links with long RTTs, packet loss and/or reordering. 437 RFC 4170: Tunneling Multiplexed Compressed RTP (TCRTP) [RFC4170] is 438 a solution that allows header compression within a tunnel carrying 439 multiple multiplexed RTP flows. This is primarily used in voice 440 trunking. 442 There exist a couple of different security mechanisms that may be 443 used with RTP. All generic mechanisms need to be transparent for the 444 RTP payload format and nothing that needs special consideration. The 445 main reason that there exist different solutions is that different 446 applications have different requirements thus different solutions 447 have been developed. The main properties for a RTP security 448 mechanism are to provide confidentiality for the RTP payload, 449 integrity protection to detect manipulation of payload and headers, 450 and source authentication. Not all mechanism provides all of these 451 features which will need to be considered when used. 453 RTP Encryption: Section 9 of RFC 3550 describes a mechanism to 454 provide confidentiality of the RTP and RTCP packets, using per 455 default DES encryption. It may use other encryption algorithms if 456 both end-points agree on it. This mechanism is not recommend due 457 to its weak security properties of the used encryption algorithms. 458 It also lacks integrity and source authentication mechanisms. 460 SRTP: The profile for Secure RTP (SAVP) [RFC3711] and the derived 461 profile (SAVPF [RFC5124]) is a solution that provides 462 confidentiality, integrity protection and partial source 463 authentication. 465 IPsec: IPsec [RFC4301] may also be used to protect RTP and RTCP 466 packet. 468 TLS: TLS [RFC5246] may also be used to provide transport security 469 between two end-point of the TLS connection for a flow of RTP 470 packets that are framed over TCP. 472 DTLS: Datagram TLS [RFC4347] is an alternative to TLS that allow TLS 473 to be used over datagrams, like UDP. Thus it has the potential 474 for being used to protect RTP over UDP. However the necessary 475 signalling mechanism for using it that has not yet been developed 476 in any of the IETF real-time media application signalling 477 protocols. 479 3.2. Important RTP details 481 This section does not remove the necessity of reading up on RTP. 482 However it does point out a couple of important details to remember 483 when designing the payload format. 485 3.2.1. The RTP Session 487 The definition of the RTP session from RFC 3550 is: 489 "An association among a set of participants communicating with RTP. 490 A participant may be involved in multiple RTP sessions at the same 491 time. In a multimedia session, each medium is typically carried in a 492 separate RTP session with its own RTCP packets unless the encoding 493 itself multiplexes multiple media into a single data stream. A 494 participant distinguishes multiple RTP sessions by reception of 495 different sessions using different pairs of destination transport 496 addresses, where a pair of transport addresses comprises one network 497 address plus a pair of ports for RTP and RTCP. All participants in 498 an RTP session may share a common destination transport address pair, 499 as in the case of IP multicast, or the pairs may be different for 500 each participant, as in the case of individual unicast network 501 addresses and port pairs. In the unicast case, a participant may 502 receive from all other participants in the session using the same 503 pair of ports, or may use a distinct pair of ports for each. 505 The distinguishing feature of an RTP session is that each maintains a 506 full, separate space of SSRC identifiers (defined next). The set of 507 participants included in one RTP session consists of those that can 508 receive an SSRC identifier transmitted by any one of the participants 509 either in RTP as the SSRC or a CSRC (also defined below) or in RTCP. 510 For example, consider a three-party conference implemented using 511 unicast UDP with each participant receiving from the other two on 512 separate port pairs. If each participant sends RTCP feedback about 513 data received from one other participant only back to that 514 participant, then the conference is composed of three separate point- 515 to-point RTP sessions. If each participant provides RTCP feedback 516 about its reception of one other participant to both of the other 517 participants, then the conference is composed of one multi-party RTP 518 session. The latter case simulates the behavior that would occur 519 with IP multicast communication among the three participants. 521 The RTP framework allows the variations defined here, but a 522 particular control protocol or application design will usually impose 523 constraints on these variations." 525 3.2.2. RTP Header 527 The RTP header contains two fields that require additional 528 specification by the RTP payload format, namely the RTP Timestamp and 529 the marker bit. Certain RTP payload formats also uses the RTP 530 sequence number to realize certain functionalities. The payload type 531 is used to indicate the used payload format. 533 Marker bit: A single bit normally used to provide important 534 indications. In audio it is normally used to indicate the start 535 of an talk burst. This to enable jitter buffer adaptation prior 536 to this with minimal audio quality impact. In video the marker 537 bit is normally used to indicate the last packet part of an frame. 538 This enables an decoder to finish decoding the picture, where it 539 otherwise may need to wait for the next packet to explicitly know 540 that. 542 Timestamp: The RTP timestamp indicate the time instance the media 543 belongs to. For discrete media, like video it normally indicates 544 when the media (frame) was sampled. For continuous media it 545 normally indicates the first time instance the media present in 546 the payload represents. For audio this is the sampling time of 547 the first sample. All RTP payload formats must specify the 548 meaning of the timestamp value and which clock rates that are 549 allowed. Note that clock rates below 1000 Hz is not appropriate 550 due to RTCP measurements function that in that case lose 551 resolution. 553 Sequence number: The sequence number are monotonically increasing 554 and set as packets are sent. That property is used in many 555 payload formats to recover the order of everything from the whole 556 stream down to fragments of ADUs and the order they shall be 557 decoded. 559 Payload Type: Commonly the same payload type is used for a media 560 stream for the whole duration of a session. However in some cases 561 it may be required to change the payload format or its 562 configuration during the session. The payload type is used to 563 indicate on a per packet basis which format is used. Thus certain 564 major configuration information can be bound to a payload type 565 value by out-of-band signalling. Examples of this would be video 566 decoder configuration information. 568 SSRC: The Sender Source ID is normally not used by a payload format 569 other than identifying the RTP timestamp and sequence number space 570 a packet belongs to, allowing the simultaneously reception of 571 multiple senders. However there are certain of the mechanisms the 572 make RTP robuster that are RTP payloads that have used multiple 573 SSRCs and bound them together to correctly separate original data 574 and repair or redundant data. 576 The remaining fields are commonly not influencing the RTP payload 577 format. The padding bit is worth clarifying as it indicates that one 578 or more bytes are appended after the RTP payload. This padding must 579 be removed by a receiver before payload format processing can occur. 580 Thus it is completely separate from any padding that may occur within 581 the payload format itself. 583 3.2.3. RTP Multiplexing 585 RTP has three multiplexing points that are used for different 586 purposes. A proper understanding of this is important to correctly 587 utilized them. 589 The first one is separation of media streams of different types, 590 which is accomplished using different RTP sessions. So for example 591 in the common multi-media session with audio and video, RTP multiplex 592 audio and video on different RTP sessions. To achieve this 593 separation, transport level functionalities are use, normally UDP 594 port numbers. Different RTP sessions are also used to realize 595 layered scalability as it allows a receiver to select one or more 596 layers for multicasted RTP sessions simply by joining the multicast 597 groups the desired layers are transported over. This also allows 598 different Quality of Service (QoS) be applied to different media. 600 The next point is separation of different sources within a RTP 601 session. Here RTP uses the SSRC (Sender Source) which identifies 602 individual sources. An example of individual sources in audio RTP 603 session, would be different microphones, independent of if they are 604 from the same host or different hosts. For each SSRC a unique RTP 605 sequence number and timestamp space is used. 607 The third multiplexing point is the RTP headers payload type field. 608 The payload type identifies what format the content in the RTP 609 payload has. This includes different payload format configurations, 610 different codecs, and also usage of robustness mechanisms like the 611 one described in RFC 2198 [RFC2198]. 613 3.2.4. RTP Synchronization 615 There are several types of synchronization and we will here describe 616 how RTP handles the different types: 618 Intra media: The synchronization within a media stream from a source 619 is accomplished using the RTP timestamp field. Each RTP packet 620 carry the RTP timestamp that specifies the media contained in this 621 packets position in relation to other media on the time line. 622 This is especially useful in cases of discontinues transmissions. 623 Discontinues can also be caused by the network and with extensive 624 losses the RTP timestamp tells the receiver how much later than 625 previously received media the media shall be played out. 627 Inter media: As applications commonly has a desire to use several 628 media types at the same time there exist a need to synchronize 629 also the different medias from the same source. This puts two 630 requirements on RTP; possibility to determine which media is from 631 the same source and if they should be synchronized with each 632 other; and the functionality to facilitate the synchronization 633 itself. 635 The first part of Inter media synchronization is to determine which 636 SSRCs in each session that should be synchronized with each other. 637 This is accomplished by comparing the RTCP SDES CNAME field. SSRCs 638 with the same CNAME in different RTP session should be synchronized. 640 The actual RTCP mechanism for inter media synchronization is based on 641 that each media stream provide a position on the media specific time 642 line (measured in RTP timestamp ticks) and a common reference time 643 line. The common reference time line is in RTCP expressed as an wall 644 clock time in the Network Time Protocol (NTP) format. It is 645 important to notice that the wall clock time is not required to be 646 synchronized between hosts, for example by using NTP [RFC1305] . It 647 can even have nothing at all to do with the actual time, for example 648 the host system's uptime can be used for this purpose. The important 649 factor is that all media streams from a particular source that are 650 being synchronized uses the same reference clock to derive there 651 relative RTP timestamp time scales. 653 In the below Figure (Figure 1) it is depicted how if one receives 654 RTCP Sender Report (SR) packet P1 in one media stream and RTCP SR 655 packet P2 in the other session, then one can calculate the 656 corresponding RTP timestamp values for any arbitrary point in time T. 657 However to be able to do that it is also required to know the RTP 658 timestamp rates for each media currently used in the sessions 659 TS1 --+---------------+-------> 660 | | 661 P1 | 662 | | 663 NTP ---+-----+---------T------> 664 | | 665 P2 | 666 | | 667 TS2 ---------+---------+---X--> 669 Figure 1: RTCP Synchronization 671 Lets assume that media 1 uses a RTP Timestamp clock rate of 16 kHz, 672 and media 2 a rate of 90 kHz. Then the TS1 and TS2 for point T can 673 be calculated in the following way: TS1(T) = TS1(P1) + 16000 * 674 (NTP(T)-NTP(P1)) and TS2(T) = TS2(P2) + 90000 * (NTP(T)-NTP(P2)). 675 This calculation is useful as it allows to generate a common 676 synchronization point for which all time values are provided (TS1(T), 677 TS2(T) and T). So when one like to calculate at which NTP time the 678 TS present in packet X corresponds to one can do that in the 679 following way: NTP(X) = NTP(T) + (TS2(X) - TS2(T))/90000. 681 3.3. Signalling Aspects 683 RTP payload formats are used in the context of application signalling 684 protocols such as SIP [RFC3261] using SDP [RFC4566] with Offer/Answer 685 [RFC3264], RTSP [RFC2326] or SAP [RFC2326]. These examples all uses 686 SDP to indicate which and how many media streams that are desired to 687 be used in the session and their configuration. To be able to 688 declare or negotiate which media format and RTP payload packetization 689 the payload format must be given an identifier. In addition to the 690 identifier many payload formats also have the need to carry further 691 configuration information out-of-band in regards to the RTP payloads 692 prior to the media transport session. 694 The above examples of session establishing protocols all use SDP, 695 however also other session description formats may be used. For 696 example there have been discussion on a new Session Description 697 format within IETF (SDP-NG). To prevent locking the usage of RTP to 698 SDP based out-of-band signalling, the payload formats are identified 699 using an separate definition format for the identifier and 700 parameters. That format is the Media Type. 702 3.3.1. Media Types 704 Media types [RFC4288] was originally created for identifying media 705 formats included in email. Media types are today also used in HTTP 706 [RFC2616], MSRP [RFC4975] and many other protocols to identify 707 arbitrary content carried within the protocols. Media types also 708 provide a media hierarchy that fits RTP payload formats well. Media 709 type names are two-part and consist of content type and sub-type 710 separated with a slash, e.g. "audio/PCMA" or "video/h263-2000". It 711 is important to choose the correct content-type when creating the 712 media type identifying an RTP payload format. However in most cases 713 there is little doubt what content type the format belongs to. 714 Guidelines for choosing the correct media type and registration rules 715 are present in RFC 4288 [RFC4288]. The additional rules for media 716 types for RTP payload formats are present in RFC 4855 [RFC4855]. 718 Media types are allowed any number of parameters which are divided 719 into two groups, required and optional parameters. They are always 720 on the form name=value. There exist no restriction on how the value 721 is defined from media types perspective, except that parameters must 722 have value. However the carrying of media types in SDP etc. has 723 resulted in the following restrictions that needs to be followed to 724 make media types for RTP payload format usable: 726 1. Arbitrary binary content in the parameters are allowed but needs 727 to be encoded so that they can be placed within text based 728 protocols. Base64 [RFC4648] is recommended, but for shorter 729 content BASE16 may be more appropriate as it is simpler to 730 interpret by humans. This needs to be explicitly stated when 731 defining a media type parameter with binary value. 733 2. The end of the value needs to be easily found when parsing a 734 message. Thus parameter values that are continuous and non 735 interrupted by common text separators, such as space and semi- 736 colon are recommended. If that is not possible some type of 737 escaping should be used. Usage of " (double quote) is 738 recommended. 740 3. A common representation form of the media type and its parameters 741 is on a single line. In those cases the media type is followed 742 by a semi-colon separated list of the parameter value pair, e.g. 743 audio/amr octet-align=0; mode-set=0,2,5,7; mode-change-period=2. 745 3.3.2. Mapping to SDP 747 As SDP [RFC4566] is so commonly used as an out-of-band signalling 748 channel, a mapping of the media type exist. The details on how to 749 map the media type and its parameters into SDP are described in RFC 750 4855 [RFC4855]. However this is not sufficient to explain how 751 certain parameter shall be interpreted for example in the context of 752 Offer/Answer negotiation [RFC3264]. 754 3.3.2.1. The Offer/Answer Model 756 The Offer/Answer (O/A) model allows SIP to negotiate media formats 757 and which payload formats and their configuration is used in a 758 session. However O/A does not define a default behavior and instead 759 points out the need to define how parameters behave. To make things 760 even more complex the direction of media within a session do have 761 impact on these rules, thus some cases may require description 762 separately for peers that are send only, receiver only or both 763 senders and receivers as identified by the SDP attributes a=sendonly, 764 a=recvonly, and a=sendrecv. In addition any usage of multicast puts 765 a further limitations as the same media stream is delivered to all 766 participants. If those restrictions are to limiting also to be used 767 in unicast then separate rules for unicast and multicast will be 768 required. 770 The most common O/A interpretation and the simplest is for 771 declarative parameters, i.e. the sending entity can declare a value 772 and that has no direct impact on the other agents values. This 773 declared value applies to all media that are going to be sent to the 774 declaring entity. For example most video codecs has level parameter 775 which tells the other participants the highest complexity the video 776 decoder supports. The level parameter can be declared independently 777 by two participants in a unicast session as it will be the media 778 sender responsibility to transmit a video stream that fulfills the 779 limitation the other has declared. However in multicast it will be 780 necessary to send a stream that follows the limitation of the weakest 781 receiver, i.e. the one that has supports the lowest level. To 782 simplify the negotiation in these cases it is common to require any 783 answerer to a multicast session to take a yes or no approach to 784 parameters. 786 "Negotiated" parameters are another type of parameters, for which 787 both sides needs to agree on their values. Such parameter requires 788 that the answerer either accept as they are offered or remove the 789 payload type the parameter belonged to. The removal of the payload 790 type from the answer indicates to the offerer the lack of support. 791 An unfortunate implications of the need to use complete payload types 792 to indicate each configuration possible to achieve interoperability, 793 is that the number of payload types necessary can quickly grow big. 794 This is one reason to keep the total number of set of capabilities 795 that may be implemented limited. 797 The most problematic type of parameters are those that relates with 798 the transmission the entity performs. They do not really fit the O/A 799 model but can be shoe-horned in. Example of such parameters can be 800 found in the H.264 video code's payload format [RFC3984], where the 801 name of all parameters with this property starts sprop-. The issue 802 that exist is that they declare properties for a media stream one 803 don't yet know if the other party accept. The best one can make of 804 the situation is to explain the assumption that the other party will 805 accept the same reception parameter as the offerer of the session. 806 If the answerer needs to change any declarative parameter then the 807 offerer may be required to make an new offer to update the parameter 808 values for its outgoing media stream. 810 Another issue to consider is the sendonly media streams in offers. 811 For all parameters that relates to what one accepts to receive those 812 don't have any meaning other than provide a template for the 813 answering entity. It is worth pointing out in the specification that 814 these provides recommended set of parameter values by the sender. 815 Note that sendonly streams in answers will need to indicate the 816 offerers parameters to ensure that the offerer can match the answer 817 to the offer. 819 A further issue with offer/answer which complicates things is that it 820 is allowed to renumber the payload types between offer and answer. 821 This is not recommended but allowed for support of gateways to the 822 ITU conferencing suit. Which means that answers for payload types 823 needs to be possible to bind to the ones in the offer even when the 824 payload type number has been changed, and some of the proposed 825 payload types have been removed. This must normally be done based on 826 configurations offered, thus negotiated parameters becomes vital. 828 3.3.2.2. Declarative usage in RTSP and SAP 830 SAP (Session Announcement Protocol) [RFC2974] is used for announcing 831 multicast sessions. Independently of the usage of Source Specific 832 Multicast (SSM) [RFC3569] or Any-Source Multicast (ASM), the SDP 833 provided by SAP applies to all participants. All media that is sent 834 to the session must follow the media stream definition as specified 835 by the SDP. Thus enabling everyone to receive the session if they 836 support the configuration. Here SDP provides a one way channel with 837 no possibility to affect the configuration defined by SDP that the 838 session creator has decided upon. Any RTP Payload format that 839 requires parameters for the send direction and which needs individual 840 values per implementation or instance will fail in a SAP session for 841 a multicast session allowing anyone to send. 843 Real-Time Streaming Protocol (RTSP) [RFC2326] allows the negotiation 844 of transport parameters for media streams part of a streaming session 845 between a server and client. RTSP has divided the transport 846 parameters from the media configuration. SDP is commonly used for 847 media configuration in RTSP and is sent to the client prior to 848 session establishment, either through the usage of the DESCRIBE 849 method or an out-of-band channel like HTTP, email etc. The SDP is 850 used to determine which media streams and what formats are being used 851 before the session establishment. 853 Thus both SAP and RTSP uses SDP to configure receivers and senders 854 with a predetermined configuration including the payload format and 855 any of its parameters of a media stream. Thus all parameters are 856 used in a declarative fashion. This can result in different 857 treatment of parameters between offer/answer and declarative usage in 858 RTSP and SAP. This will then need to be pointed out by the payload 859 format specification. 861 3.4. Transport Characteristics 863 The general channel characteristics that RTP flows are experiencing 864 are documented in Section 3 of RFC2736 [RFC2736]. Below additional 865 information is discussed. 867 3.4.1. Path MTU 869 At the time of writing the most common IP Maximum Transmission Unit 870 (MTU) of used link layers is 1500 bytes (Ethernet data payload). 871 However there exist links with both smaller MTU and much larger MTUs. 872 Certain parts of Internet do already today support IP MTU of 9000 873 bytes or more. There is an slow ongoing evolution towards larger MTU 874 sizes. This should be considered in the design, especially in 875 regards to features such as aggregation of independently decodable 876 data units. 878 4. Specification Process 880 This section discusses the recommended process to produce an RTP 881 payload format in the described venues. This is to document the best 882 current practice on how to get a well designed and specified payload 883 format as quickly as possible. For specifications that are 884 proprietary or defined by other standards bodies than IETF the 885 primary milestone is registration of the RTP payload format name. 886 However there is also the issue of ensuring best possible quality of 887 any specification. 889 4.1. IETF 891 Specification in IETF is recommended for all standardized media 892 formats. The main reason is to provide an openly available RTP 893 payload format specification that also has been reviewed by people 894 experienced with RTP Payload formats. This also assumes that the AVT 895 WG exist. 897 4.1.1. Steps from Idea to Publication 899 There are a number of steps that an RTP payload format should go 900 through from the initial idea until it is published. This also 901 documents the process that the AVT working group applies when working 902 with RTP payload formats. 904 1. Idea: Determined the need for an RTP payload format as an IETF 905 specification. 907 2. Initial effort: Using this document as guideline one should be 908 able to get started on the work. If one's media codec doesn't 909 fit any of the common design patterns or one has problems 910 understanding what the most suitable way forward is, then one 911 should contact the AVT working group and/or the WG chairs. The 912 goal of this stage is to have an initial individual draft. This 913 draft needs to focus on the introduction parts that describe the 914 real-time media format and the basic idea on how to packetize it. 915 All the details are not required to be filled in. However 916 security chapter is not something that one should skip even 917 initially. It is important to consider already from the start 918 any serious security risks that needs to be solved. This step is 919 completed when one has a draft that is sufficient detailed for a 920 first review by the WG. The less confident one is of the 921 solution, the less work should be spent on details, instead 922 concentrate on the codec properties and what is required to make 923 it work. 925 3. Submission of first version. When one has performed the above 926 one submits the draft as an individual draft. This can be done 927 at any time except the 3 weeks (current deadline at the time of 928 writing, consult current announcements) prior to an IETF meeting. 929 When the IETF draft announcement has been sent out on the draft 930 announcement list, forward it to the AVT WG and request that it 931 is reviewed. In the email outline any issues the authors 932 currently have with the design. 934 4. Iterative improvements: Taking the feedback into account one 935 updates the draft and try resolve any issues. New revision of 936 the draft can be submitted at any time. It is recommended to do 937 it whenever one has made major updates or have new issues that 938 are easiest to discuss in the context of a new draft version. 940 5. Becoming WG document: Due to that the definition of RTP payload 941 formats are part of the AVT's charter, RTP payload formats that 942 are going to be published as standards track RFCs needs to become 943 WG documents. Becoming WG document means that the chairs are 944 responsible for administrative handling, like publication 945 requests. However be aware that making a document into a WG 946 document changes the formal ownership and responsibility from the 947 individual authors to the WG. The initial authors will continue 948 being document editor, unless unusual circumstances occur. The 949 AVT WG accepts new RTP payload formats based on their suitability 950 and document maturity. The document maturity is a requirement to 951 ensure that there are dedicated document editors and that there 952 exist a good solution. 954 6. Iterative improvements: The updates and review cycles continues 955 until the draft the has reached the maturity suitable for 956 publication. 958 7. WG last call: WG last call of at least 2 weeks are always 959 performed for payload formats in the AVT WG. The authors request 960 WG last call for a draft when they think it i mature enough for 961 publication. The chairs perform a review to check if they agree 962 with the authors assessment. If the chairs agree on the 963 maturity, the WG last call is announced on the WG mailing list. 964 If there are issues raised these needs to be addressed with an 965 updated draft version. For any more substantial updates of 966 draft, a new WG last call is announced for the updated version. 967 Minor changes, like editorial on can be progressed without an 968 additional WG last call. 970 8. Publication Requested: For WG documents the chairs request 971 publication of the draft. After this the approval and 972 publication process described in RFC 2026 [RFC2026] are 973 performed. The status after the publication has been requested 974 can be tracked using the IETF data tracker. Documents do not 975 expire as normal after publication has been requested. In 976 addition any submission of document updates requires the approval 977 of WG chair(s). The authors are commonly asked to address 978 comments or issues raised by the IESG. The authors also review 979 the document prior to publication as an RFC to ensure its 980 correctness. 982 4.1.2. WG meetings 984 WG meetings are for discussing issues, not presentations. This means 985 that most RTP payload format should never need to be discussed in a 986 WG meeting. RTP payload formats that would be discussed are either 987 controversial issues that failed to be resolved on the mailing list, 988 or includes new design concepts worth a general discussion. 990 There exist no requirement to present or discuss a draft at a WG 991 meeting before it becoming published as an RFC. Thus even authors 992 that lack the possibility to go to WG meetings should be able to 993 successfully specify an RTP payload format in IETF. WG meetings may 994 only become required if the draft get stuck in a serious debate that 995 isn't easily resolved. 997 4.1.3. Draft Naming 999 To simplify the work of the AVT WG chairs and its WG members a 1000 specific draft file naming convention shall be used for RTP payload 1001 formats. Individual submissions shall be named draft--avt-rtp--. The WG documents 1003 shall be named according to this template: 1004 draft-ietf-avt-rtp--. The inclusion of 1005 "avt" in the draft filename ensures that the search for "avt-" will 1006 find all AVT related drafts. Inclusion of "rtp" tells us that it is 1007 an RTP payload format draft. The descriptive name should be as short 1008 as possible while still describe what the payload format is for. It 1009 is recommended to use the media format or codec acronym. Please note 1010 that the version must start at 00 and is increased by one for each 1011 submission to the IETF secretary of the draft. No version numbers 1012 may be skipped. 1014 4.1.4. How to speed up the process 1016 There a number of ways of losing a lot of time in the above process. 1017 This section discuss what to do and what to avoid. 1019 o Do not only update the draft to the meeting deadline. An update 1020 to each meeting automatically limits the draft to 3 updates per 1021 year. Instead ignore the meeting schedule and publish new 1022 versions as soon as possible. 1024 o Try to avoid requesting review when people are busy, like the 1025 weeks before a meeting. Review should be asked at all possible 1026 times and it is actually more likely that people has more time for 1027 them directly after a meeting. 1029 o Perform draft updates quickly. A common mistake is that the 1030 authors lets the draft slip. By performing updates to the draft 1031 text directly after getting resolution on an issue, speeds things 1032 up. This as it minimizes the delay that the author has direct 1033 control over. Waiting for reviews, responses from area directors 1034 and chairs, etc can be much harder to speed up. 1036 o Failing to take the human nature into account. It happens that 1037 people forget or needs to be reminded about tasks. Send people 1038 you are waiting for a kindly reminder if things takes longer than 1039 expected. To avoid annoying people ask for a time estimate from 1040 people when they expect to fulfill the requested task. 1042 o Not enough review. It is common that documents take a long time 1043 and many iterations because not enough review is performed in each 1044 iteration. To improve the amount of review you get on your own 1045 document, trade review time with other document authors. Make a 1046 deal with some other document authors that you will review his 1047 draft(s) if he reviews yours. Even inexperience reviewers can 1048 help with language, editorial or clarity issues. Try also 1049 approaching the more experienced people in the WG and get them to 1050 commit to a review. The WG chairs cannot, even if desirable, be 1051 expected to review all versions. Due to workload the chairs may 1052 need to concentrate on key points in a draft evolution, like 1053 initial submissions, if ready to become WG document and WG last 1054 call. 1056 4.2. Other Standards bodies 1058 Other standard bodies may define RTP payload in their own 1059 specifications. When they do this they are strongly recommend to 1060 contact the AVT WG chairs and request review of the work. It is 1061 recommended that at least two review steps are performed. One early 1062 in the process when more fundamental issues easily can be resolved 1063 without abandoning a lot of effort. Then when nearing completion, 1064 but while still possible to update the specification as second review 1065 should be scheduled. In that pass the quality can be assessed and 1066 hopefully no updates are needed. Using this procedure can avoids 1067 both conflicting definitions and serious mistakes, like breaking 1068 certain aspects of the RTP model. 1070 RTP payload Media Types may be registered in the standards tree by 1071 other standard bodies. The requirements on the organization are 1072 outlined in the media types registration document (RFC 4855 [RFC4855] 1073 and RFC 4288 [RFC4288]). This registration requires a request to the 1074 IESG, which ensures that the registration template is acceptable. To 1075 avoid last minute problems with these registration the registration 1076 template must be sent for review both to the AVT WG and the media 1077 types list (ietf-types@iana.org) and is something that should be 1078 included in the IETF reviews of the payload format specification. 1080 Registration of the RTP payload name is something that is required to 1081 avoid name collision in the future. Do also note that "x-" names are 1082 not suitable for any documented format as they have the same problem 1083 with name collision and can't be registered. The list of already 1084 registered media types can be found at IANA (http://www.iana.org). 1086 4.3. Propreitary and Vendor Specific 1088 Proprietary RTP payload formats are commonly specified when the real- 1089 time media format is proprietary and not intended to be part of any 1090 standardized system. However there exist many reasons why also 1091 proprietary formats should be correctly documented and registered; 1093 o Usage in standardized signalling environment such as SIP/SDP. RTP 1094 needs to be configured regarding used RTP profiles, payload 1095 formats and their payload types. To accomplish this there is an 1096 need for registered names to ensure that the names do not collide 1097 with other formats. 1099 o Sharing with business partners. As RTP payload formats are used 1100 for communication, situations where business partners like to 1101 support one proprietary format often arises. Having a well 1102 written specification of the format will save time and money for 1103 both one selves and ones partner, as interoperability will much 1104 easier to accomplish. 1106 o To ensure interoperability between different implementations on 1107 different platforms. 1109 To avoid name collisions there is a central register keeping tracks 1110 of the registered Media Type names used by different RTP payload 1111 formats. When it comes to proprietary formats they should be 1112 registered in the vendors own tree. All vendor specific 1113 registrations uses sub-type names that start with "vnd.". All names that uses names in the vendors own trees are not 1115 required to be registered with IANA. However registration is 1116 recommended if used at all in public environments. 1118 5. Designing Payload Formats 1120 The best summary of payload format design is KISS (Keep It Simple, 1121 Stupid). A simple payload format makes it easy to review for 1122 correctness, implement, and have low complexity. Unfortunately 1123 contradicting requirements sometime makes it hard to do things 1124 simple. Complexity issues and problems that occur for RTP payload 1125 formats are: 1127 Too many configurations: Contradicting requirements results in that 1128 one configuration for each conceivable case is created. Such 1129 contradicting requirements are often between functionality and 1130 bandwidth. This has two big negatives. First all configurations 1131 needs to be implemented. Secondly the using application must 1132 select the most suitable configuration. Selecting the best 1133 configuration can be very difficult and in negotiating 1134 applications, this can create interoperability problems. The 1135 recommendation is to try to select a very limited (preferable one) 1136 configuration that preforms the most common case well and is 1137 capable of handling the other cases, but maybe less well. 1139 Hard to implement: Certain payload formats may become difficult to 1140 implement both correctly and efficient. This needs to be 1141 considered in the design. 1143 Interaction with general mechanisms: Special solutions may create 1144 issues with deployed tools for RTP, like tools for robuster 1145 transport of RTP. For example the requirement of non broken 1146 sequence space creates issues with using both payload type 1147 switching and interleaving any mechanism for media independent 1148 resilience within the stream. 1150 5.1. Features of RTP payload formats 1152 There are number of common features in RTP payload formats. There 1153 are no general requirement to support these features, instead their 1154 applicability must be considered for each payload format. It might 1155 in fact be that certain features are not even applicable. 1157 5.1.1. Aggregation 1159 Aggregation allows for the inclusion of multiple ADUs within the same 1160 RTP payload. This is commonly supported for codec that produce ADUs 1161 of sizes smaller than the IP MTU. Do remember that the MTU may be 1162 significantly larger than 1500 bytes, 9000 bytes is available today 1163 and a MTU of 64k may be available in the future. Many speech codecs 1164 have the property of ADUs of a few fixed sizes. Video encoders 1165 generally may produce ADUs of quite flexible size. Thus the need for 1166 aggregation may be less. However in certain use cases the 1167 possibility to aggregate multiple ADUs especially for different 1168 playback times are useful. 1170 The main disadvantage of aggregation is the extra delay introduced, 1171 due to buffering until sufficient amount of ADUs have been collected 1172 and reduced robustness against packet loss. It also introduces 1173 buffering requirements on the receiver. 1175 5.1.2. Fragmentation 1177 If the real-time media format has the property that it may produce 1178 ADUs that are larger than common MTUs sizes then fragmentation 1179 support should be considered. An RTP Payload format may always fall 1180 back on IP fragmentation, however as discussed in RFC 2736 this have 1181 some drawbacks. The usage of RTP payload format level fragmentation, 1182 does primarily allow for more efficient usage of RTP packet loss 1183 recovery mechanisms. However it may in some cases also allow usage 1184 of the partial ADU by doing media specific fragmentation at media 1185 specific boundaries. 1187 5.1.3. Interleaving and Transmission Re-Scheduling 1189 Interleaving has been implemented in a number of payload formats to 1190 allow for less quality reduction when packet loss occurs. When 1191 losses are bursty and several consecutive packets are lost, the 1192 impact on quality can be quite severe. Interleaving is used to 1193 convert that burst loss to several spread out individual losses. It 1194 can also be used when several ADUs are aggregated in the same 1195 packets. A loss of an RTP packet with several ADUs in the payload 1196 has the same affect as a burst loss if the ADUs would have been 1197 transmitted in individual packets. To reduce the burstiness of the 1198 loss, the data present in an aggregated payload may be interleaved, 1199 thus spread the loss over a longer time period. 1201 A requirement for doing interleaving within an RTP payload format is 1202 the aggregation of multiple ADUs. For formats that don't use 1203 aggregation there is still the possibility to implement an 1204 transmission order re-scheduling mechanism. That have the effect 1205 that packets transmitted next to each other originates from different 1206 points in the media stream. This can be used to mitigate burst 1207 losses, which may be useful if one transmit packets with small 1208 intervals. However it may also be used to transmit more significant 1209 data earlier in combination with RTP retransmission to allow for more 1210 graceful degradation and increased possibilities to receive the most 1211 important data, e.g. Intra frames of video. 1213 The drawbacks of interleaving is the significantly increased 1214 transmission buffering delay, making it mostly useless for low delay 1215 applications. It also creates significant buffering requirements on 1216 the receiver. That buffering also is problematic as it is usually 1217 difficult to indicate when a receiver may start consume data and 1218 still avoid buffer underrun caused by the interleaving mechanism 1219 itself. The transmission re-scheduling is only useful in a few 1220 specific cases, like in streaming with retransmissions. This must be 1221 weighted against the complexity of these schemes. 1223 5.1.4. Media Back Channels 1225 A few RTP payload format have implemented back channels within the 1226 media format. Those have been for specific features, like the AMR 1227 [RFC4867] codec mode request (CMR) field. The CMR field is used in 1228 gateway operations to circuit switched voice to allow an IP terminal 1229 to react to the CS networks need for a specific encoder mode. A 1230 common property for the media back channels is the need to have this 1231 signalling in direct relation to the media or the media path. 1233 If back channels are considered for an RTP payload format they should 1234 be for specific mechanism and which can't be easily satisfied by more 1235 generic mechanisms within RTP or RTCP. 1237 5.1.5. Scalability 1239 There exist some codecs that supports some type of scalability, i.e. 1240 where additional data can be used to improve media stream properties, 1241 but the additional data isn't required for decoding. This quality 1242 improvements has been so far been in a number of different types: 1244 Temporal: For video codecs increased frame rate is one way to 1245 improve the quality. Audio codecs could provide increase sampling 1246 rate. 1248 Spatial: Video codecs with scalability may increase the resolution 1249 or image size. 1251 Quality: The perceived quality of the media stream can be improved 1252 without affecting the temporal or spatial properties of the media. 1253 This is usually done by improving the signal to noise ration 1254 within the content. 1256 Codecs that support scalability are at the time of writing this 1257 having a bit of revival. It has been realized that getting the need 1258 functionality for the media stream in the RTP framework is quite 1259 challenging. The author hopes to be able to provide some lessons 1260 from this work in this document in the future. 1262 5.1.6. High Packet Rates 1264 Some media codecs requires high packet rates, and in these cases the 1265 RTP sequence number wraps to quickly. As rule of thumb, the sequence 1266 number space must not be possible to wrap in less than 2 minutes (TCP 1267 maximum segment lifetime). If that may occur then the payload format 1268 should specify a extended sequence number field to allow the receiver 1269 to determine where a specific payload belongs in the sequence also in 1270 the face of extensive reordering. The RTP payload format for 1271 uncompressed video [RFC4175] can be used as an example for such a 1272 field. 1274 6. Current Trends in Payload Format Design 1276 This section provides a few examples of payload formats that is worth 1277 noting for good design in general or specific details. 1279 6.1. Audio Payloads 1281 The AMR [RFC4867], AMR-WB [RFC4867], EVRC [RFC3558], SMV [RFC3558] 1282 payload format are all quite similar. They are all for frame based 1283 audio codecs and use a table of content structure. Each frame has a 1284 table of contents entry that indicate the type of the frame and if 1285 additional frames are present. This is quite flexible but produces 1286 unnecessary overhead if the ADU is fixed size and when aggregating 1287 multiple ones they are commonly of the same type. In that case a 1288 solution like that in AMR-WB+ [RFC4352] maybe more suitable. 1290 AMR-WB+ does contain one less good feature which is depending on the 1291 media codec itself. The media codec produces a large range of 1292 different frame lengths in time perspective. The RTP timestamp rate 1293 is selected to the very unusual value of 72 kHz despite that output 1294 normally is at sample rate 48kHz. This timestamp rate is the 1295 smallest found value that would make all of the frames the codec 1296 could produce results in integer frame length in RTP timestamp ticks. 1297 That way a receiver can always correctly place the frames in relation 1298 to any other frame, also at frame length changes. The down side is 1299 that the decoder output for certain frame lengths are in fact partial 1300 samples. Resulting in that the output in samples from the codec will 1301 vary from frame to frame, potentially making implementation more 1302 difficult. 1304 The RTP payload format for MIDI [RFC4695] contains some interesting 1305 features. MIDI is an audio format sensitive to packet losses, as the 1306 loss of a note off command will result in that a note will be stuck 1307 in an on state. To counter this a recovery journal is defined that 1308 provides a summarized state that allows the receiver to recover from 1309 packet losses quickly. It also uses RTCP and the reported highest 1310 sequence number to be able to prune the state the recovery journal 1311 needs to contain. These features appears limited in applicability 1312 for media formats that are highly stateful and primarily uses 1313 symbolic media representations. 1315 6.2. Video 1317 The definition of RTP payload formats for video has seen an evolution 1318 from the early ones such as H.261 towards the latest for VC-1 and 1319 H.264. 1321 The H.264 RTP payload format [RFC3984] can be seen as a smorgasbord 1322 of functionality, some pretty advanced as the interleaving. The 1323 reason for this was to ensure that the majority of applications 1324 considered by the ITU-T and MPEG that can be supported by RTP was 1325 supported. This has created a payload format that rarely is 1326 implemented in its completeness. Despite that no major issues with 1327 interoperability has been reported. However, there are common 1328 complaints about its complexity. 1330 The RTP payload format for uncompressed video [RFC4175] is basically 1331 required to be mentioned in this context as it contains a special 1332 feature not commonly seen in RTP payload formats. Due to the high 1333 bit-rate and thus packet rate of uncompressed video (gigabits rather 1334 than megabits) the payload format include a field to extend the RTP 1335 sequence number as the normal 16-bit one can wrap in below a second. 1336 It also specifies a registry of different color sub-sampling that can 1337 be re-used in other video RTP payload formats. 1339 6.3. Text 1341 There would be overstating that there exist a trend in text payload 1342 formats as only a single format actually carrying a text format has 1343 been standardized in IETF, namely T.140 [RFC4103]. The 3GPP Timed 1344 Text format [RFC4396] could be considered to be text, despite it in 1345 the end was registered as a video format. This is decorated text, 1346 usable for subtitles and other embellishments of video which is why 1347 it ended up being registered as video format. However, it has many 1348 of the properties that text formats in generally have. 1350 The RTP payload format for T.140 was designed with high reliability 1351 in mind as real-time text commonly are a extremely low-bit rate 1352 application. Thus, it recommends the use of RFC 2190 with many 1353 redundancy generations. However, the format failed to provide a text 1354 block specific sequence number and relies instead of the RTP one to 1355 detection loss. This makes detection of missing text blocks 1356 unnecessarily difficult and hinders the deployment with other 1357 robustness mechanisms that would switch the payload type as that may 1358 result in erroneous error marking in the T.140 text stream. 1360 7. Important Specification Sections 1362 There a number of sections in the payload format draft that needs 1363 some special considerations. These include security and IANA 1364 considerations. 1366 7.1. Security Consideration 1368 All Internet drafts requires a Security Consideration section. The 1369 security consideration section in an RTP payload format needs to 1370 concentrate on the security properties this particular format has. 1371 Some payload format has very little specific issues or properties and 1372 can fully fall back on the general RTP and used profile's security 1373 considerations. Due to that these are always applicable a reference 1374 to these are normally placed first in the security consideration 1375 section. 1377 The security issues of confidentiality, integrity protection and 1378 source authentication are common issues for all payload formats. 1379 These should be solved by payload external mechanism and does not 1380 need any special consideration in the payload format except for an 1381 reminder on these issues. A suitable stock text to inform people 1382 about this is included in the template. 1384 Potential security issues with an RTP payload format and the media 1385 encoding that needs to be considered are: 1387 1. That the decoding of the payload format or its media shows 1388 substantial non-uniformity, either in output or in complexity to 1389 perform the decoding operation. For example a generic non- 1390 destructive compression algorithm may provide an output of almost 1391 infinite size for a very limited input. Thus consuming memory or 1392 storage space out of proportion with what the receiving 1393 application expected causing some sort of disruption, i.e. a 1394 denial of service attack on the receiver by preventing that host 1395 to produce any good put. Certain decoding operations may also 1396 have variable consumption of amount of processing needed to 1397 perform such operations dependent on the input. This may also be 1398 a security risk if that processing load is possible to raise 1399 significantly from nominal simply by designing a malicious input 1400 sequence. If such potential exist this must be expressed in the 1401 security consideration section to make implementers aware of the 1402 need to take precautions against such behavior. 1404 2. The inclusion of active content in the media format or its 1405 transport. With active content means scripts etc that allows an 1406 attacker to perform potentially arbitrary operations on the 1407 receiver. Most active content have limited possibility to access 1408 the system or perform operations outside a protected sandbox. 1409 RFC 4855 [RFC4855] has a requirement that this is noted in the 1410 media types registration if the payload format contains active 1411 content or not. If the payload format has active content it is 1412 strongly recommend that references to any security model 1413 applicable for such content is referenced. A boiler plate text 1414 for no is included in the template which must be changed if the 1415 format actual carries active content. 1417 3. Some media formats allows for the carrying of "user data", or 1418 types of data which is not known at the time of the specification 1419 of the payload format. Such data may be a security risk and 1420 should be mentioned. 1422 Suitable stock text for the security consideration is provided in the 1423 template. However the authors do need to actively consider any 1424 security issues from the start. Failure to address these issues is 1425 blocking approval and publication. 1427 7.2. Congestion Control 1429 RTP and its profiles do discuss congestion control. Congestion 1430 control is an important issue in any usage in non-dedicated networks. 1431 For that reason all RTP payload formats are recommended to discuss 1432 the possibilities that exist to regulate the bit-rate of the 1433 transmissions using the described RTP payload format. Some formats 1434 may have limited or step wise regulation of bit-rate. Such limiting 1435 factor should be discussed. 1437 7.3. IANA Consideration 1439 Due to that all RTP Payload format contains a Media Type 1440 specification they also need an IANA consideration section. The 1441 media type name must be registered and this is done by requesting 1442 that IANA register that media name. When that registration request 1443 is written it shall also be requested that the media type is included 1444 under the "RTP Payload Format MIME types" list part of the RTP 1445 registry. 1447 In addition to the above request for media type registration some 1448 payload formats may have parameters where in the future new parameter 1449 values needs to be added. In these cases a registry for that 1450 parameter must be created. This is done by defining the registry in 1451 the IANA consideration section. BCP 26 (RFC 5226) [RFC5226] provides 1452 guidelines to writing such registries. Care should be taken when 1453 defining the policy for new registrations. 1455 Before writing a new registry it is worth checking the existing ones 1456 in the IANA "MIME Media Type Sub-Parameter Registries". For example 1457 video formats needing a media parameter expressing color sub-sampling 1458 may be able to reuse those defined for video/raw [RFC4175]. 1460 8. Authoring Tools 1462 This section informs and recommends some tools that may be used. 1463 Don't be pressured to follow these recommendation. There exist a 1464 number of alternatives. But these suggestion is worth checking out 1465 before deciding that the field is greener somewhere else. 1467 8.1. Editing Tools 1469 There is many choices when it comes to tools to choose for authoring 1470 Internet drafts. However in the end they needs to be able to produce 1471 a draft that conforms to the Internet drafts requirements. If you 1472 don't have any previous experience with authoring Internet drafts 1473 XML2RFC do have some advantages. It helps creating a lot of the 1474 necessary boiler plate in accordance with the latest rules. Thus 1475 reducing the effort. It also speeds up the publication after 1476 approval as the RFC-editor can use the source XML document to quicker 1477 produce the RFC. 1479 Another common choice is to use Microsoft Word and a suitable 1480 template, see [RFC3285] to produce the draft and print that using the 1481 generic text printer. It has some advantage when it comes to spell 1482 checking and change bars. However Word may also produce some 1483 problems, like changing formating, inconsistent result between what 1484 one sees in the editor and in the generated text document, at least 1485 according to the authors personal experience. 1487 8.2. Verification Tools 1489 There are few tools that are very good to know about when writing an 1490 draft. These help check and verify parts of ones work. These tools 1491 can be found at http://tools.ietf.org. 1493 o ID Nits checker. It checks that the boiler plate and some other 1494 things that are easily verifiable by machine is okay in your 1495 draft. Always use it before submitting a draft to avoid direct 1496 refusal in the submission step. 1498 o ABNF Parser and verification. Used to check that your ABNF parses 1499 correctly and warns about loose ends, like undefined symbols. 1500 However the actual content can only be verified by humans knowing 1501 what it intends to describe. 1503 o RFC diff. A diff tool that is optimized for drafts and RFC. For 1504 example it doesn't point out that the foot and header has moved in 1505 relation to the text on every page. 1507 9. Open Issues 1509 This document currently has a few open issues that needs resolving 1510 before publication: 1512 o Should any procedure for the future when the AVT WG is closed be 1513 described? 1515 o The section of current examples of good work needs to be filled 1516 in. 1518 o Consider mention RFC-errata 1520 10. IANA Considerations 1522 This document makes no request of IANA. 1524 Note to RFC Editor: this section may be removed on publication as an 1525 RFC. 1527 11. Security Considerations 1529 As this is an informational document on the writing of drafts 1530 intended to be RFCs there is no direct security considerations. 1531 However the document does discuss the writing of security 1532 consideration sections and what should be particular considered when 1533 specifying RTP payload formats. 1535 12. RFC Editor Consideration 1537 Note to RFC Editor: This section may be removed after carrying out 1538 all the instructions of this section. 1540 13. Acknowledgements 1542 The author would like to thank the individuals that has provided 1543 input to this document. These individuals include: John Lazzaro. 1545 14. Informative References 1547 [CSP-RTP] Colin , "RTP: Audio and Video for the Internet", 1548 June 2003. 1550 [MACOSFILETYPES] 1551 Apple Knowledge Base Article 1552 55381, "Mac OS: 1553 File Type and Creator Codes, and File Formats", 1993. 1555 [RFC-ED] http://www.rfc-editor.org/policy.html, "RFC Editorial 1556 Guidelines and Procedures", July 2008. 1558 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1559 Specification, Implementation", RFC 1305, March 1992. 1561 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1562 3", BCP 9, RFC 2026, October 1996. 1564 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 1565 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 1566 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 1567 September 1997. 1569 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1570 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1572 [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, 1573 RFC 2360, June 1998. 1575 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 1576 Procedures", BCP 25, RFC 2418, September 1998. 1578 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 1579 Headers for Low-Speed Serial Links", RFC 2508, 1580 February 1999. 1582 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1583 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1584 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1586 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 1587 Payload Format Specifications", BCP 36, RFC 2736, 1588 December 1999. 1590 [RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time 1591 Transport Protocol Management Information Base", RFC 2959, 1592 October 2000. 1594 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1595 Announcement Protocol", RFC 2974, October 2000. 1597 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1598 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 1599 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 1600 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 1601 Compression (ROHC): Framework and four profiles: RTP, UDP, 1602 ESP, and uncompressed", RFC 3095, July 2001. 1604 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1605 A., Peterson, J., Sparks, R., Handley, M., and E. 1606 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1607 June 2002. 1609 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1610 with Session Description Protocol (SDP)", RFC 3264, 1611 June 2002. 1613 [RFC3285] Gahrns, M. and T. Hain, "Using Microsoft Word to create 1614 Internet Drafts and RFCs", RFC 3285, May 2002. 1616 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1617 "Introduction and Applicability Statements for Internet- 1618 Standard Management Framework", RFC 3410, December 2002. 1620 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 1621 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 1622 High Delay, Packet Loss and Reordering", RFC 3545, 1623 July 2003. 1625 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1626 Jacobson, "RTP: A Transport Protocol for Real-Time 1627 Applications", STD 64, RFC 3550, July 2003. 1629 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1630 Video Conferences with Minimal Control", STD 65, RFC 3551, 1631 July 2003. 1633 [RFC3558] Li, A., "RTP Payload Format for Enhanced Variable Rate 1634 Codecs (EVRC) and Selectable Mode Vocoders (SMV)", 1635 RFC 3558, July 2003. 1637 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1638 Multicast (SSM)", RFC 3569, July 2003. 1640 [RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. 1641 Romascanu, "Introduction to the Remote Monitoring (RMON) 1642 Family of MIB Modules", RFC 3577, August 2003. 1644 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 1645 Protocol Extended Reports (RTCP XR)", RFC 3611, 1646 November 2003. 1648 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1649 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1650 RFC 3711, March 2004. 1652 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1653 G. Fairhurst, "The Lightweight User Datagram Protocol 1654 (UDP-Lite)", RFC 3828, July 2004. 1656 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 1657 RFC 3978, March 2005. 1659 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 1660 Technology", BCP 79, RFC 3979, March 2005. 1662 [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, 1663 M., and D. Singer, "RTP Payload Format for H.264 Video", 1664 RFC 3984, February 2005. 1666 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1667 Conversation", RFC 4103, June 2005. 1669 [RFC4170] Thompson, B., Koren, T., and D. Wing, "Tunneling 1670 Multiplexed Compressed RTP (TCRTP)", BCP 110, RFC 4170, 1671 November 2005. 1673 [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for 1674 Uncompressed Video", RFC 4175, September 2005. 1676 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1677 Registration Procedures", BCP 13, RFC 4288, December 2005. 1679 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1680 Internet Protocol", RFC 4301, December 2005. 1682 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1683 Security", RFC 4347, April 2006. 1685 [RFC4352] Sjoberg, J., Westerlund, M., Lakaniemi, A., and S. Wenger, 1686 "RTP Payload Format for the Extended Adaptive Multi-Rate 1687 Wideband (AMR-WB+) Audio Codec", RFC 4352, January 2006. 1689 [RFC4396] Rey, J. and Y. Matsui, "RTP Payload Format for 3rd 1690 Generation Partnership Project (3GPP) Timed Text", 1691 RFC 4396, February 2006. 1693 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1694 Description Protocol", RFC 4566, July 2006. 1696 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1697 and RTP Control Protocol (RTCP) Packets over Connection- 1698 Oriented Transport", RFC 4571, July 2006. 1700 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1701 "Extended RTP Profile for Real-time Transport Control 1702 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1703 July 2006. 1705 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1706 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1707 July 2006. 1709 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1710 Encodings", RFC 4648, October 2006. 1712 [RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's 1713 Guide to the Internet Engineering Task Force", RFC 4677, 1714 September 2006. 1716 [RFC4695] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for 1717 MIDI", RFC 4695, November 2006. 1719 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1720 Formats", RFC 4855, February 2007. 1722 [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, 1723 "RTP Payload Format and File Storage Format for the 1724 Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband 1725 (AMR-WB) Audio Codecs", RFC 4867, April 2007. 1727 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1728 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1730 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 1731 Correction", RFC 5109, December 2007. 1733 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1734 Real-time Transport Control Protocol (RTCP)-Based Feedback 1735 (RTP/SAVPF)", RFC 5124, February 2008. 1737 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1738 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1739 May 2008. 1741 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1742 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1744 Appendix A. RTP Payload Format Template 1746 This section contains a template for writing an RTP payload format in 1747 form as a Internet draft. Text within [...] are instructions and 1748 must be removed. Some text proposals that are included are 1749 conditional. "..." is used to indicate where further text should be 1750 written. 1752 A.1. Title 1754 [The title shall be descriptive but as compact as possible. RTP is 1755 allowed and recommended abbreviation in the title] 1757 RTP Payload format for ... 1759 A.2. Front page boilerplate 1761 Status of this Memo 1763 [Insert the IPR notice boiler plate from BCP 79 that applies to this 1764 draft.] 1766 [Insert the current Internet Draft document explanation. At the time 1767 of publishing it was:] 1769 Internet-Drafts are working documents of the Internet Engineering 1770 Task Force (IETF), its areas, and its working groups. Note that 1771 other groups may also distribute working documents as Internet- 1772 Drafts. 1774 Internet-Drafts are draft documents valid for a maximum of six months 1775 and may be updated, replaced, or obsoleted by other documents at any 1776 time. It is inappropriate to use Internet-Drafts as reference 1777 material or to cite them other than as "work in progress." 1779 [Insert the ID list and shadow list reference. At the time of 1780 publishing it was:] 1782 The list of current Internet-Drafts can be accessed at 1783 http://www.ietf.org/ietf/1id-abstracts.txt. 1785 The list of Internet-Draft Shadow Directories can be accessed at 1786 http://www.ietf.org/shadow.html. 1788 [Optionally: Select either of these paragraphs depending on draft 1789 status] 1791 This document is an individual submission to the IETF. Comments 1792 should be directed to the authors. 1794 This document is a submission of the IETF AVT WG. Comments should be 1795 directed to the AVT WG mailing list, avt@ietf.org. 1797 A.3. Abstract 1799 [An payload format abstract should mention the capabilities of the 1800 format, for which media format is used, and a little about that codec 1801 formats capabilities. Any abbreviation used in the payload format 1802 must be spelled out here except the very well known like RTP. No 1803 references are allowed, no use of RFC 2119 language either.] 1805 A.4. Table of Content 1807 [All drafts over 15 pages in length must have an Table of Content.] 1809 A.5. Introduction 1811 [The introduction should provide a background and overview of the 1812 payload formats capabilities. No normative language in this section, 1813 i.e. no MUST, SHOULDs etc.] 1815 A.6. Conventions, Definitions and Acronyms 1817 [Define conventions, definitions and acronyms used in the document in 1818 this section. The most common definition used in RTP Payload formats 1819 are the RFC 2119 definitions of the upper case normative words, e.g. 1820 MUST and SHOULD.] 1822 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1823 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1824 document are to be interpreted as described in RFC 2119. 1826 RFC-editor note: RFCXXXX is to be replaced by the RFC number this 1827 specification recieves when published. 1829 A.7. Media Format Background 1831 [The intention of this section is to enable reviewers and persons to 1832 get an overview of the capabilities and major properties of the media 1833 format. It should be kept short and concise and is not a complete 1834 replacement for reading the media format specification.] 1836 A.8. Payload format 1838 [Overview of payload structure] 1840 A.8.1. RTP Header Usage 1842 [RTP header usage needs to be defined. The fields that absolutely 1843 need to be defined are timestamp and marker bit. Further field may 1844 be specified if used. All the rest should be left to their RTP 1845 specification definition] 1847 The remaining RTP header fields are used as specified in RFC 3550. 1849 A.8.2. Payload Header 1851 [Define how the payload header, if it exist, is structured and used.] 1853 A.8.3. Payload Data 1855 [The payload data, i.e. what the media codec has produced. Commonly 1856 done through reference to media codec specification which defines how 1857 the data is structured. Rules for padding may need to be defined to 1858 bring data to octet alignment.] 1860 A.9. Payload Examples 1862 [One or more examples are good to help ease the understanding of the 1863 RTP payload format.] 1865 A.10. Congestion Control Considerations 1867 [This section is to describe the possibility to vary the bit-rate as 1868 a response to congestion. Below is also a proposal for an initial 1869 text that reference RTP and profiles definition of congestion 1870 control.] 1872 Congestion control for RTP SHALL be used in accordance with RFC 3550 1873 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 1874 [RFC3551]. An additional requirement if best-effort service is being 1875 used is: users of this payload format MUST monitor packet loss to 1876 ensure that the packet loss rate is within acceptable parameters. 1878 A.11. Payload Format Parameters 1880 This RTP payload format is identified using the ... media type which 1881 is registered in accordance with RFC 4855 [RFC4855] and using the 1882 template of RFC 4288 [RFC4288]. 1884 A.11.1. Media Type Definition 1886 [Here the media type registration template from RFC 4288 is placed 1887 and filled out. This template is provided with some common RTP 1888 boilerplate.] 1890 Type name: 1892 Subtype name: 1894 Required parameters: 1896 Optional parameters: 1898 Encoding considerations: 1900 This media type is framed and binary, see section 4.8 in RFC4288 1901 [RFC4288]. 1903 Security considerations: 1905 Please see security consideration in RFCXXXX 1907 Interoperability considerations: 1909 Published specification: 1911 Applications that use this media type: 1913 Additional information: 1915 Magic number(s): 1917 File extension(s): 1919 Macintosh file type code(s): 1921 Person & email address to contact for further information: 1923 Intended usage: (One of COMMON, LIMITED USE or OBSOLETE.) 1925 Restrictions on usage: 1927 [The below text is for media types that is only defined for RTP 1928 payload formats. There exist certain media types that are defined 1929 both as RTP payload formats and file transfer. The rules for such 1930 types are documented in RFC 4855 [RFC4855].] 1932 This media type depends on RTP framing, and hence is only defined for 1933 transfer via RTP [RFC3550]. Transport within other framing protocols 1934 is not defined at this time. 1936 Author: 1938 Change controller: 1940 IETF Audio/Video Transport working group delegated from the IESG. 1942 (Any other information that the author deems interesting may be added 1943 below this line.) 1945 [From RFC 4288: Some discussion of Macintosh file type codes and 1946 their purpose can be found in [MACOSFILETYPES]. Additionally, please 1947 refrain from writing "none" or anything similar when no file 1948 extension or Macintosh file type is specified, lest "none" be 1949 confused with an actual code value.] 1951 A.11.2. Mapping to SDP 1953 The mapping of the above defined payload format media type and its 1954 parameters SHALL be done according to Section 3 of RFC 4855 1955 [RFC4855]. 1957 [More specific rules only need to be included if some parameter does 1958 not match these rules.] 1960 A.11.2.1. Offer/Answer Considerations 1962 [Here write your offer/answer consideration section, please see 1963 Section Section 3.3.2.1 for help.] 1965 A.11.2.2. Declarative SDP Considerations 1967 [Here write your considerations for declarative SDP, please see 1968 Section Section 3.3.2.2 for help.] 1970 A.12. IANA Considerations 1972 This memo requests that IANA registers [insert media type name here] 1973 as specified in Appendix A.11.1. The media type is also requested to 1974 be added to the IANA registry for "RTP Payload Format MIME types" 1975 (http://www.iana.org/assignments/rtp-parameters). 1977 [See Section Section 7.3 and consider if any of the parameter needs a 1978 registered name space.] 1980 A.13. Securtiy Considerations 1982 [See Section Section 7.1] 1983 RTP packets using the payload format defined in this specification 1984 are subject to the security considerations discussed in the RTP 1985 specification [RFC3550] , and in any applicable RTP profile. The 1986 main security considerations for the RTP packet carrying the RTP 1987 payload format defined within this memo are confidentiality, 1988 integrity and source authenticity. Confidentiality is achieved by 1989 encryption of the RTP payload. Integrity of the RTP packets through 1990 suitable cryptographic integrity protection mechanism. Cryptographic 1991 system may also allow the authentication of the source of the 1992 payload. A suitable security mechanism for this RTP payload format 1993 should provide confidentiality, integrity protection and at least 1994 source authentication capable of determining if an RTP packet is from 1995 a member of the RTP session or not. 1997 Note that the appropriate mechanism to provide security to RTP and 1998 payloads following this memo may vary. It is dependent on the 1999 application, the transport, and the signalling protocol employed. 2000 Therefore a single mechanism is not sufficient, although if suitable 2001 the usage of SRTP [RFC3711] is recommended. Other mechanism that may 2002 be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but 2003 also other alternatives may exist. 2005 This RTP payload format and its media decoder do not exhibit any 2006 significant non-uniformity in the receiver-side computational 2007 complexity for packet processing, and thus are unlikely to pose a 2008 denial-of-service threat due to the receipt of pathological data. 2009 Nor does the RTP payload format contain any active content. 2011 [The previous paragraph may need editing due to the format breaking 2012 either of the statements. Fill in here any further potential 2013 security threats] 2015 A.14. References 2017 [References must be classified as either normative or informative and 2018 added to the relevant section. References should use descriptive 2019 reference tags.] 2021 A.14.1. Normative References 2023 [Normative references are those that are required to be used to 2024 correctly implement the payload format.] 2026 A.14.2. Informative References 2028 [All other references.] 2030 A.15. Author Addresses 2032 [All Authors need to include their Name and email addresses as a 2033 minimal. Commonly also surface mail and possibly phone numbers are 2034 included.] 2036 A.16. IPR Notice 2038 [Use the appropriate boilerplate from Section 5 of BCP 79 [RFC3979].] 2040 A.17. Copyright Notice 2042 [Use the boilerplate from Section 5.4 and 5.5 of BCP 78 [RFC3978].] 2044 Author's Address 2046 Magnus Westerlund 2047 Ericsson 2048 Torshamgatan 23 2049 Stockholm, SE-164 80 2050 SWEDEN 2052 Phone: +46 8 7190000 2053 Fax: +46 8 757 55 50 2054 Email: magnus.westerlund@ericsson.com 2056 Full Copyright Statement 2058 Copyright (C) The IETF Trust (2008). 2060 This document is subject to the rights, licenses and restrictions 2061 contained in BCP 78, and except as set forth therein, the authors 2062 retain all their rights. 2064 This document and the information contained herein are provided on an 2065 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2066 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2067 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2068 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2069 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2070 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2072 Intellectual Property 2074 The IETF takes no position regarding the validity or scope of any 2075 Intellectual Property Rights or other rights that might be claimed to 2076 pertain to the implementation or use of the technology described in 2077 this document or the extent to which any license under such rights 2078 might or might not be available; nor does it represent that it has 2079 made any independent effort to identify any such rights. Information 2080 on the procedures with respect to rights in RFC documents can be 2081 found in BCP 78 and BCP 79. 2083 Copies of IPR disclosures made to the IETF Secretariat and any 2084 assurances of licenses to be made available, or the result of an 2085 attempt made to obtain a general license or permission for the use of 2086 such proprietary rights by implementers or users of this 2087 specification can be obtained from the IETF on-line IPR repository at 2088 http://www.ietf.org/ipr. 2090 The IETF invites any interested party to bring to its attention any 2091 copyrights, patents or patent applications, or other proprietary 2092 rights that may cover technology that may be required to implement 2093 this standard. Please address the information to the IETF at 2094 ietf-ipr@ietf.org.