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