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