idnits 2.17.1 draft-ietf-avt-rtp-howto-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1877. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1861. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1867. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 RFC 3978 Section 5.4 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 (May 3, 2006) is 6560 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 1782 -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- 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 3267 (Obsoleted by RFC 4867) -- Obsolete informational reference (is this intentional?): RFC 3285 (Obsoleted by RFC 5385) -- Obsolete informational reference (is this intentional?): RFC 3548 (Obsoleted by RFC 4648) -- Obsolete informational reference (is this intentional?): RFC 3555 (Obsoleted by RFC 4855, RFC 4856) -- 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) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 21 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 May 3, 2006 5 Expires: November 4, 2006 7 How to Write an RTP Payload Format 8 draft-ietf-avt-rtp-howto-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 4, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document contains information on how to best write an RTP 42 payload format. Reading tips, design practices, and practical tips 43 on how to quickly and with good results produce an RTP payload format 44 specification. A template is also included with instructions that 45 can be used when writing an RTP payload format. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Preparations . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1. Recommend Reading . . . . . . . . . . . . . . . . . . . . 7 58 3.1.1. IETF Process and Publication . . . . . . . . . . . . . 7 59 3.1.2. RTP . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.2. Important RTP details . . . . . . . . . . . . . . . . . . 11 61 3.2.1. The RTP Session . . . . . . . . . . . . . . . . . . . 11 62 3.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . . 12 63 3.2.3. RTP Multiplexing . . . . . . . . . . . . . . . . . . . 13 64 3.2.4. RTP Synchronization . . . . . . . . . . . . . . . . . 14 65 3.3. Signalling Aspects . . . . . . . . . . . . . . . . . . . . 15 66 3.3.1. Media Types . . . . . . . . . . . . . . . . . . . . . 16 67 3.3.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 16 68 3.4. Transport Characteristics . . . . . . . . . . . . . . . . 19 69 3.4.1. Path MTU . . . . . . . . . . . . . . . . . . . . . . . 19 71 4. Specification Process . . . . . . . . . . . . . . . . . . . . 20 72 4.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 73 4.1.1. Steps from Idea to Publication . . . . . . . . . . . . 20 74 4.1.2. WG meetings . . . . . . . . . . . . . . . . . . . . . 22 75 4.1.3. Draft Naming . . . . . . . . . . . . . . . . . . . . . 22 76 4.1.4. How to speed up the process . . . . . . . . . . . . . 22 77 4.2. Other Standards bodies . . . . . . . . . . . . . . . . . . 23 78 4.3. Propreitary and Vendor Specific . . . . . . . . . . . . . 24 80 5. Designing Payload Formats . . . . . . . . . . . . . . . . . . 25 81 5.1. Features of RTP payload formats . . . . . . . . . . . . . 25 82 5.1.1. Aggreagation . . . . . . . . . . . . . . . . . . . . . 25 83 5.1.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 26 84 5.1.3. Interleaving and Transmission Re-Scheduling . . . . . 26 85 5.1.4. Media Back Channels . . . . . . . . . . . . . . . . . 27 87 6. Current Trends in Payload Format Design . . . . . . . . . . . 28 88 6.1. Audio Payloads . . . . . . . . . . . . . . . . . . . . . . 28 89 6.2. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 28 90 6.3. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 7. Important Specification Sections . . . . . . . . . . . . . . . 29 93 7.1. Security Consideration . . . . . . . . . . . . . . . . . . 29 94 7.2. Congestion Control . . . . . . . . . . . . . . . . . . . . 30 95 7.3. IANA Consideration . . . . . . . . . . . . . . . . . . . . 30 97 8. Authoring Tools . . . . . . . . . . . . . . . . . . . . . . . 31 98 8.1. Editing Tools . . . . . . . . . . . . . . . . . . . . . . 31 99 8.2. Verification Tools . . . . . . . . . . . . . . . . . . . . 31 101 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32 103 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 105 11. Security Considerations . . . . . . . . . . . . . . . . . . . 34 107 12. RFC Editor Consideration . . . . . . . . . . . . . . . . . . . 35 109 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 111 14. Informative References . . . . . . . . . . . . . . . . . . . . 36 113 Appendix A. RTP Payload Format Template . . . . . . . . . . . . . 40 114 A.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 40 115 A.2. Front page boilerplate . . . . . . . . . . . . . . . . . . 40 116 A.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 41 117 A.4. Table of Content . . . . . . . . . . . . . . . . . . . . . 41 118 A.5. Introduction . . . . . . . . . . . . . . . . . . . . . . . 41 119 A.6. Conventions, Definitions and Acronyms . . . . . . . . . . 41 120 A.7. Media Format Background . . . . . . . . . . . . . . . . . 41 121 A.8. Payload format . . . . . . . . . . . . . . . . . . . . . . 41 122 A.8.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . 41 123 A.8.2. Payload Header . . . . . . . . . . . . . . . . . . . . 42 124 A.8.3. Payload Data . . . . . . . . . . . . . . . . . . . . . 42 125 A.9. Payload Examples . . . . . . . . . . . . . . . . . . . . . 42 126 A.10. Congestion Control Considerations . . . . . . . . . . . . 42 127 A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 42 128 A.11.1. Media Type Definition . . . . . . . . . . . . . . . . 42 129 A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 44 130 A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 44 131 A.13. Securtiy Considerations . . . . . . . . . . . . . . . . . 44 132 A.14. References . . . . . . . . . . . . . . . . . . . . . . . . 45 133 A.14.1. Normative References . . . . . . . . . . . . . . . . . 45 134 A.14.2. Informative References . . . . . . . . . . . . . . . . 45 135 A.15. Author Addresses . . . . . . . . . . . . . . . . . . . . . 45 136 A.16. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . 45 137 A.17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 45 139 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 140 Intellectual Property and Copyright Statements . . . . . . . . . . 47 142 1. Introduction 144 RTP [RFC3550] payload formats define how a specific real-time data 145 format is structured in the payload of an RTP packet. A real-time 146 data format without a payload format specification can't be 147 transported using RTP. This creates an interest from many 148 individuals/organizations with media encoders or other types of real- 149 time data to define RTP payload formats. The specification of a well 150 designed RTP payload format is non-trivial and requires knowledge of 151 both RTP and the real-time data format. 153 This document intends to help any author of an RTP payload format to 154 make important design decisions, consider important features of RTP, 155 security, etc. The document is also intended to be a good starting 156 point for any person with little experience in IETF and/or RTP to 157 learn the necessary steps. 159 This document extends and updates the information that are available 160 in "Guidelines for Writers of RTP Payload Format Specifications" 161 [RFC2736]. Since this RFC was written further experience has been 162 gained on the design and specification of RTP payload format. 163 Several new RTP profiles, and robustness tools has also been defined, 164 which needs to be considered. 166 We also discuss the possible venues of defining an RTP payload 167 format, in IETF, by other standard bodies and proprietary ones. 168 Independent on the intended venue of specification, all will gain 169 from this document. 171 1.1. Structure 173 This document has several different parts discussing different 174 aspects of the creation of an RTP payload format specification. 175 After the introduction and definitions there are a section discussing 176 the preparations the author(s) should do before start writing. The 177 following section discusses the different processes used when 178 specifying and completing an payload format, with focus on working 179 inside the IETF. Section 5 discusses the design of payload formats 180 themselves in detail. Section 6 discusses the current design trends 181 and provides good examples of practices that should be followed when 182 applicable. Following that there is a discussion on important 183 sections in the RTP payload format specification itself, like 184 security and IANA considerations. This document ends with an 185 appendix containing an template that can be used when writing RTP 186 payload formats. 188 2. Terminology 190 2.1. Definitions 192 Media Stream A sequence of RTP packets that together provides all or 193 parts of a media. It is scoped in RTP by the RTP session and a 194 single sender source. 196 RTP Session: An association among a set of participants communicating 197 with RTP. The distinguishing feature of an RTP session is that 198 each maintains a full, separate space of SSRC identifiers. See 199 also Section3.2.1. 201 RTP Payload Format: The RTP Payload format specifies how a specific 202 media format is put into the RTP Payloads. Thus enabling the 203 format to be used in RTP sessions. 205 2.2. Acronyms 207 ABNF Augmented Backus-Naur Form 209 ADU Application Data Unit 211 ALF Application Level Framing 213 ASM Any-Source Multicast 215 AVT: Audio Video Transport 217 BCP Best Current Practice 219 ID: Internet Draft 221 MTU Maximum Transmission Unit 223 WG: Working Group 225 QoS: Quality of Service 227 RFC: Request For Comment 229 RTP: Real-time Transport Protocol 231 RTCP: RTP Control Protocol 232 RTT: Round Trip Time 234 SSM Source Specific Multicast 236 3. Preparations 238 RTP is a complex real-time media delivery framework and it has a lot 239 of details to consider when writing an RTP payload format. There is 240 also important to have a good understanding of the media codec/format 241 so that all its important features and properties are considered. 242 First when one has sufficient understanding of both part can one 243 produce an RTP payload format of high quality. On top of this, one 244 needs to understand the process within IETF and especially the AVT WG 245 to quickly go from initial idea to a finished RFC. This and the next 246 section helps an author prepare himself in those regards. 248 3.1. Recommend Reading 250 In the below sub sections there are a number of documents listed. 251 Not all needs to be read in full detail. However basically 252 everything listed below does an author need to be aware of. 254 3.1.1. IETF Process and Publication 256 To understand the IETF process an draft author should start by 257 reading RFC 2026 [RFC2026] that describes the standards process of 258 IETF. In addition an author needs to understands the IETF rules and 259 rights associated with copyright and IPR documented in BCP 78 260 [RFC3978] and BCP 79 [RFC3979]. In RFC 2418 [RFC2418] is the WG 261 process, the relation between the IESG and the WG, and the 262 responsibilities of WG chairs and participants described. 264 It is important to note that the RFC series contains documents of 265 several different classifications; standards track, informational, 266 experimental, best current practice (BCP), and historic. The 267 standard tracks contains documents of three different maturity 268 classifications, proposed, draft and Internet Standard. A standards 269 track document must start as proposed, after proved interoperability 270 of all the features it can be moved to draft standard, and final when 271 further experience has been gathered it can be moved to Internet 272 standard. As the content of the RFCs are not allowed to be changed, 273 the only way of updating an RFC is to write and publish a new one 274 that either updates or replaces the old one. Therefore it is 275 important to both consider the Category field in the header and check 276 if the RFC one is reading or going to reference is the latest and 277 valid. One way of checking the current status of an RFC is to use 278 the RFC-editor's RFC search engine, which displays the current status 279 and which if any RFCs that updates or obsolete it. 281 Before starting to write an draft one should also read the Internet 282 Draft writing guidelines 283 (http://www.ietf.org/ietf/1id-guidelines.txt), the ID checklist 284 (http://www.ietf.org/ID-Checklist.html) and "Instructions to Request 285 for Comments (RFC) Authors" [rfc2223bis]. 287 There are also a number of documents to consider in process of 288 writing of drafts intended to become RFCs. These are important when 289 writing certain type of text. 291 RFC 2606: When writing examples using DNS names in Internet drafts, 292 those name shall be using the example.com, example.net, and 293 example.org domains. 295 RFC 3849: Defines the range of IPv6 unicast addresses (2001:DB8::/32) 296 that should be used in any examples. 298 RFC 3330: Defines the range of IPv4 unicast addresses reserved for 299 documentation and examples: 192.0.2.0/24. 301 RFC 4234: Augmented Backus-Naur Form (ABNF) is often used when 302 writing text field specifications. Not that commonly used in RTP 303 payload formats but may be useful when defining Media Type 304 parameters of some complexity. 306 3.1.2. RTP 308 The recommended reading for RTP consist of several different parts; 309 design guidelines, the RTP protocol, profiles, robustness tools, and 310 media specific recommendations. 312 Any author of RTP payload formats should start with reading RFC 2736 313 [RFC2736] which contains an introduction to the application layer 314 framing (ALF) principle, the channel characteristics of IP channels, 315 and design guidelines for RTP payload formats. The goal of ALF is to 316 be able to transmit Application Data Units (ADUs) that are 317 independently usable by the receiver in individual RTP packets. Thus 318 minimizing dependencies between RTP packets and the effects of packet 319 loss. 321 Then it is suitable to learn more about the RTP protocol, by studying 322 the RTP specification RFC 3550 [RFC3550] and the existing profiles. 323 As a complement to the standards document there exist a book totally 324 dedicated to RTP [CSP-RTP]. There exist several profiles for RTP 325 today, but all are based on the "RTP Profile for Audio and Video 326 Conferences with Minimal Control" (RFC 3551) [RFC3551] (abbreviated 327 AVP). The other profiles that one should known about are Secure RTP 328 (SAVP) [RFC3711], "Extended RTP Profile for RTCP-based Feedback" 329 [rfc-avpf] and "Extended Secure RTP Profile for RTCP-based Feedback 330 (RTP/SAVPF)" [rfc-savpf]. It is important to understand RTP and the 331 AVP profile in detail. For the other profiles it is sufficient to 332 have an understanding on what functionality they provided and the 333 limitations they create. 335 There has been developed a number of robustness tools for RTP. The 336 tools are for different use cases and real-time requirements. 338 RFC 2198: The "RTP Payload for Redundant Audio Data" [RFC2198] 339 provides functionalities to provided redundant copies of audio or 340 text payloads. These redundant copies are sent together with an 341 primary format in the same RTP payload. This format relies on the 342 RTP timestamp to determine where data belongs in a sequence and 343 therefore is usually primarily suitable to be used with audio. 344 However also the RTP Payload format for T.140 [RFC4103] text 345 format uses this format. The formats major property is that it 346 only preserves the timestamp of the redundant payloads, not the 347 original sequence number. Thus making it unusable for most video 348 formats. This format is also only suitable for media formats that 349 produce relatively small RTP payloads. 351 RFC 2733: The "An RTP Payload Format for Generic Forward Error 352 Correction" provides an XOR based FEC over a number of RTP 353 packets. These FEC packets are sent in a separate stream or as a 354 redundant encoding using RFC 2198. This FEC scheme has certain 355 restrictions in the number of packets it can protect. It is 356 suitable for low to medium delay tolerable applications with 357 limited amount of RTP packets. 359 RTP Retransmission: The RTP retransmission scheme [rtp-rtx] is used 360 for semi-reliability of the most important RTP packets in a media 361 stream. The scheme is not intended, nor suitable, to provide full 362 reliability. It requires the application to be quite delay 363 tolerable as a minimum of a round-trip time plus processing delay 364 is required to perform an retransmission. Thus it is mostly 365 suitable for streaming applications but may also be usable in 366 certain cases when operating on networks with short RTT. 368 There also exist some management and monitoring extensions. 370 RFC 2959: The RTP protocol Management Information Database (MIB) 371 [RFC2959] that is used with SNMP to configure and retrieve 372 information about RTP sessions. 374 RFC 3611: The RTCP Extended Reports (RTCP XR) [RFC3611] consist of a 375 framework for reports sent within RTCP. It can easily be extended 376 by defining new report formats in future. The report formats that 377 are defined are providing report information on; packet loss 378 vectors, packet duplication, packet reception times, RTCP 379 statistics summary and VoIP Quality. It also defines a mechanism 380 that allows receivers to calculate the RTT to other session 381 participants when used. 383 RMONMIB: The remote monitoring work group has defined a mechanism 384 [RFC3577] based on usage of the MIB that can be an alternative to 385 RTCP XR. 387 There has also been developed a number of transport optimizations 388 that are used in certain environments. They are all intended to be 389 transparent and not need special consideration by the RTP payload 390 format writer. Thus they are primarily listed here for informational 391 reasons and do not require deeper studies. 393 RFC 2508: Compressing IP/UDP/RTP headers for slow serial links (CRTP) 394 [RFC2508] is the first IETF developed RTP header compression 395 mechanism. It provides quite good compression however it has 396 clear performance problems when subject to packet loss between 397 compressor and decompressor. 399 RFC 3095: Is the base specification of the robust header compression 400 (ROHC) protocol [RFC3095]. This solution was created as a result 401 of CRTP's lack of performance when subject to losses. 403 RFC 3545: Enhanced compressed RTP (E-CRTP) [RFC3545] was also 404 developed to provide extensions to CRTP that allows for better 405 performance over links with long RTTs, packet loss and/or 406 reordering. 408 RFC 4170: Tunneling Multiplexed Compressed RTP (TCRTP) [RFC4170] is a 409 solution that allows header compression within a tunnel carrying 410 multiple multiplexed RTP flows. This is primarily used in voice 411 trunking. 413 There exist a couple of different security mechanisms that may be 414 used with RTP. All generic mechanisms need to be transparent for the 415 RTP payload format and nothing that needs special consideration. The 416 main reason that there exist different solutions is that different 417 applications have different requirements thus different solutions 418 have been developed. The main properties for a RTP security 419 mechanism are to provide confidentiality for the RTP payload, 420 integrity protection to detect manipulation of payload and headers, 421 and source authentication. Not all mechanism provides all of these 422 features which will need to be considered when used. 424 RTP Encryption: Section 9 of RFC 3550 describes a mechanism to 425 provide confidentiality of the RTP and RTCP packets, using per 426 default DES encryption. It may use other encryption algorithms if 427 both end-points agree on it. This mechanism is not recommend due 428 to its weak security properties of the used encryption algorithms. 429 It also lacks integrity and source authentication mechanisms. 431 SRTP: The profile for Secure RTP (SAVP) [RFC3711] and the derived 432 profile (SAVPF [rfc-savpf]) is a solution that provides 433 confidentiality, integrity protection and partial source 434 authentication. 436 IPsec: IPsec may also be used to protect RTP and RTCP packet. 438 TLS: TLS may also be used to provide transport security between two 439 end-point of the TLS connection for a flow of RTP packets that are 440 framed over TCP. 442 3.2. Important RTP details 444 This section does not remove the necessity of reading up on RTP. 445 However it does point out a couple of important details to remember 446 when designing the payload format. 448 3.2.1. The RTP Session 450 The definition of the RTP session from RFC 3550 is: 452 "An association among a set of participants communicating with RTP. 453 A participant may be involved in multiple RTP sessions at the same 454 time. In a multimedia session, each medium is typically carried in a 455 separate RTP session with its own RTCP packets unless the encoding 456 itself multiplexes multiple media into a single data stream. A 457 participant distinguishes multiple RTP sessions by reception of 458 different sessions using different pairs of destination transport 459 addresses, where a pair of transport addresses comprises one network 460 address plus a pair of ports for RTP and RTCP. All participants in 461 an RTP session may share a common destination transport address pair, 462 as in the case of IP multicast, or the pairs may be different for 463 each participant, as in the case of individual unicast network 464 addresses and port pairs. In the unicast case, a participant may 465 receive from all other participants in the session using the same 466 pair of ports, or may use a distinct pair of ports for each. 468 The distinguishing feature of an RTP session is that each maintains a 469 full, separate space of SSRC identifiers (defined next). The set of 470 participants included in one RTP session consists of those that can 471 receive an SSRC identifier transmitted by any one of the participants 472 either in RTP as the SSRC or a CSRC (also defined below) or in RTCP. 473 For example, consider a three-party conference implemented using 474 unicast UDP with each participant receiving from the other two on 475 separate port pairs. If each participant sends RTCP feedback about 476 data received from one other participant only back to that 477 participant, then the conference is composed of three separate point- 478 to-point RTP sessions. If each participant provides RTCP feedback 479 about its reception of one other participant to both of the other 480 participants, then the conference is composed of one multi-party RTP 481 session. The latter case simulates the behavior that would occur 482 with IP multicast communication among the three participants. 484 The RTP framework allows the variations defined here, but a 485 particular control protocol or application design will usually impose 486 constraints on these variations." 488 3.2.2. RTP Header 490 The RTP header contains two fields that require additional 491 specification by the RTP payload format, namely the RTP Timestamp and 492 the marker bit. Certain RTP payload formats also uses the RTP 493 sequence number to realize certain functionalities. The payload type 494 is used to indicate the used payload format. 496 Marker bit: A single bit normally used to provide important 497 indications. In audio it is normally used to indicate the start 498 of an talk burst. This to enable jitter buffer adaptation prior 499 to this with minimal audio quality impact. In video the marker 500 bit is normally used to indicate the last packet part of an frame. 501 This enables an decoder to finish decoding the picture, where it 502 otherwise may need to wait for the next packet to explicitly know 503 that. 505 Timestamp: The RTP timestamp indicate the time instance the media 506 belongs to. For discrete media, like video it normally indicates 507 when the media (frame) was sampled. For continuous media it 508 normally indicates the first time instance the media present in 509 the payload represents. For audio this is the sampling time of 510 the first sample. All RTP payload formats must specify the 511 meaning of the timestamp value and which clock rates that are 512 allowed. Note that clock rates below 1000 Hz is not appropriate 513 due to RTCP measurements function that in that case loose 514 resolution. 516 Sequence number: The sequence number are monotonically increasing and 517 set as packets are sent. That property is used in many payload 518 formats to recover the order of everything from the whole stream 519 down to fragments of ADUs and the order they shall be decoded. 521 Payload Type: Commonly the same payload type is used for a media 522 stream for the whole duration of a session. However in some cases 523 it may be required to change the payload format or its 524 configuration during the session. The payload type is used to 525 indicate on a per packet basis which format is used. Thus certain 526 major configuration information can be bound to a payload type 527 value by out-of-band signalling. Examples of this would be video 528 decoder configuration information. 530 SSRC: The Sender Source ID is normally not used by a payload format 531 other than identifying the RTP timestamp and sequence number space 532 a packet belongs to, allowing the simultaneously reception of 533 multiple senders. However there are certain of the RTP 534 robustification mechanisms that are RTP payloads that have used 535 multiple SSRCs and bound them together to correctly separate 536 original data and repair or robustification data. 538 The remaining fields are commonly not influencing the RTP payload 539 format. The padding bit is worth clarifying as it indicates that one 540 or more bytes are appended after the RTP payload. This padding must 541 be removed by a receiver before payload format processing can occur. 542 Thus it is completely separate from any padding that may occur within 543 the payload format itself. 545 3.2.3. RTP Multiplexing 547 RTP has three multiplexing points that are used for different 548 purposes. A proper understanding of this is important to correctly 549 utilized them. 551 The first one is separation of media streams of different types, 552 which is accomplished using different RTP sessions. So for example 553 in the common multi-media session with audio and video, RTP multiplex 554 audio and video on different RTP sessions. To achieve this 555 separation, transport level functionalities are use, normally UDP 556 port numbers. Different RTP sessions are also used to realize 557 layered scalability as it allows a receiver to select one or more 558 layers for multicasted RTP sessions simply by joining the multicast 559 groups the desired layers are transported over. This also allows 560 different Quality of Service (QoS) be applied to different media. 562 The next point is separation of different sources within a RTP 563 session. Here RTP uses the SSRC (Sender Source) which identifies 564 individual sources. An example of individual sources in audio RTP 565 session, would be different microphones, independent of if they are 566 from the same host or different hosts. For each SSRC a unique RTP 567 sequence number and timestamp space is used. 569 The third multiplexing point is the RTP headers payload type field. 570 The payload type identifies what format the content in the RTP 571 payload has. This includes different payload format configurations, 572 different codecs, and also usage of robustness mechanisms like the 573 one described in RFC 2198 [RFC2198]. 575 3.2.4. RTP Synchronization 577 There are several types of synchronization and we will here describe 578 how RTP handles the different types: 580 Intra media: The synchronization within a media stream from a source 581 is accomplished using the RTP timestamp field. Each RTP packet 582 carry the RTP timestamp that specifies the media contained in this 583 packets position in relation to other media on the time line. 584 This is especially useful in cases of discontinues transmissions. 585 Discontinues can also be caused by the network and with extensive 586 losses the RTP timestamp tells the receiver how much later than 587 previously received media the media shall be played out. 589 Inter media: As applications commonly has a desire to use several 590 media types at the same time there exist a need to synchronize 591 also the different medias from the same source. This puts two 592 requirements on RTP; possibility to determine which media is from 593 the same source and if they should be synchronized with each 594 other; and the functionality to facilitate the synchronization 595 itself. 597 The first part of Inter media synchronization is to determine which 598 SSRCs in each session that should be synchronized with each other. 599 This is accomplished by comparing the RTCP SDES CNAME field. SSRCs 600 with the same CNAME in different RTP session should be synchronized. 602 The actual RTCP mechanism for inter media synchronization is based on 603 that each media stream provide a position on the media specific time 604 line (measured in RTP timestamp ticks) and a common reference time 605 line. The common reference time line is in RTCP expressed as an wall 606 clock time in the Network Time Protocol (NTP) format. It is 607 important to notice that the wall clock time is not required to be 608 synchronized between hosts, for example by using NTP [RFC1305] . It 609 can even have nothing at all to do with the actual time, for example 610 the host system's uptime can be used for this purpose. The important 611 factor is that all media streams from a particular source that are 612 being synchronized uses the same reference clock to derive there 613 relative RTP timestamp time scales. 615 In the below Figure (Figure 1) it is depicted how if one receives 616 RTCP Sender Report (SR) packet P1 in one media stream and RTCP SR 617 packet P2 in the other session, then one can calculate the 618 corresponding RTP timestamp values for any arbitrary point in time T. 619 However to be able to do that it is also required to know the RTP 620 timestamp rates for each media currently used in the sessions. 622 (preamble) 623 TS1 --+---------------+-------> 624 | | 625 P1 | 626 | | 627 NTP ---+-----+---------T------> 628 | | 629 P2 | 630 | | 631 TS2 ---------+---------+---X--> 632 (postamble) 634 Figure 1: RTCP Synchronization 636 Lets assume that media one uses a RTP Timestamp clock rate of 16000 637 Hz, and media 2 a rate of 90 kHz. Then the TS1 and TS2 for point T 638 can be calculated in the following way: TS1(T) = TS1(P1) + 16000 * 639 (NTP(T)-NTP(P1)) and TS2(T) = TS2(P2) + 90000 * (NTP(T)-NTP(P2)). 640 This calculation is useful as it allows to generate a common 641 synchronization point for which all time values are provided (TS1(T), 642 TS2(T) and T). So when one like to calculate at which NTP time the 643 TS present in packet X corresponds to one can do that in the 644 following way: NTP(X) = NTP(T) + (TS2(X) - TS2(T))/90000. 646 3.3. Signalling Aspects 648 RTP payload formats are used in the context of application signalling 649 protocols such as SIP [RFC3261] using SDP [sdp-new] with Offer/Answer 650 [RFC3264], RTSP [RFC2326] or SAP [RFC2326]. These examples all uses 651 SDP to indicate which and how many media streams that are desired to 652 be used in the session and their configuration. To be able to 653 declare or negotiate which media format and RTP payload packetization 654 the payload format must be given an identifier. In addition to the 655 identifier many payload formats also have the need to carry further 656 configuration information out-of-band in regards to the RTP payloads 657 prior to the media transport session. 659 The above examples of session establishing protocols all use SDP, 660 however also other session description formats may be used. For 661 example there have been discussion on a new Session Description 662 format within IETF (SDP-NG). To prevent locking the usage of RTP to 663 SDP based out-of-band signalling, the payload formats are identified 664 using an separate definition format for the identifier and 665 parameters. That format is the Media Type. 667 3.3.1. Media Types 669 Media types [RFC4288] was originally created for identifying media 670 formats included in email. Media types are today also used in HTTP, 671 MSRP and many other protocols to identify arbitrary content carried 672 within the protocols. Media types also provide a media hierarchy 673 that fits RTP payload formats well. Media type names are two-part 674 and consist of content type and sub-type separated with a slash, e.g. 675 "audio/PCMA" or "video/h263-2000". It is important to choose the 676 correct content-type when creating the media type identifying an RTP 677 payload format. However in most cases there is little doubt what 678 content type the format belongs to. Guidelines for choosing the 679 correct media type and registration rules are present in RFC 4288 680 [RFC4288]. The additional rules for media types for RTP payload 681 formats are present in RFC XXXX. [rfc3555bis] 683 Media types are allowed any number of parameters which are divided 684 into two groups, required and optional parameters. They are always 685 on the form name=value. There exist no restriction on how the value 686 is defined from media types perspective, except that parameters must 687 have value. However the carrying of media types in SDP etc. has 688 resulted in the following restrictions that needs to be followed to 689 make media types for RTP payload format usable: 691 1. Arbitrary binary content in the parameters are allowed but needs 692 to be encoded so that they can be placed within text based 693 protocols. Base64 [RFC3548] is recommended, but for shorter 694 content BASE16 may be more appropriate as it is simpler to 695 interpret by humans. This needs to be explicitly stated when 696 defining a media type parameter with binary content. 698 2. The end of the value needs to be easily found when parsing a 699 message. Thus parameter values that are continuous and non 700 interrupted by common text separators, such as space and semi- 701 colon are recommended. If that is not possible some type of 702 escaping should be used. Usage of <"> is recommended. 704 3. A common representation form of the media type and its parameters 705 is on a single line. In those cases the media type is followed 706 by a semi-colon separated list of the parameter value pair, e.g. 707 audio/amr octet-align=0; mode-set=0,2,5,7; mode-change-period=2. 709 3.3.2. Mapping to SDP 711 As SDP [sdp-new] is so commonly used as an out-of-band signalling 712 channel, a mapping of the media type exist. The details on how to 713 map the media type and its parameters into SDP are described in RFC 714 YYYY [rfc3555bis]. However this is not sufficient to explain how 715 certain parameter shall be interpreted for example in the context of 716 Offer/Answer negotiation [RFC3264]. 718 3.3.2.1. The Offer/Answer Model 720 The Offer/Answer (O/A) model allows SIP to negotiate media formats 721 and which payload formats and their configuration is used in a 722 session. However O/A does not define a default behavior and instead 723 points out the need to define how parameters behave. To make things 724 even more complex the direction of media within a session do have 725 impact on these rules, thus some cases may require description 726 separately for peers that are send only, receiver only or both 727 senders and receivers as identified by the SDP attributes a=sendonly, 728 a=recvonly, and a=sendrecv. In addition any usage of multicast puts 729 a further limitations as the same media stream is delivered to all 730 participants. If those restrictions are to limiting also to be used 731 in unicast then separate rules for unicast and multicast will be 732 required. 734 The most common O/A interpretation and the simplest is for 735 declarative parameters, i.e. the sending entity can declare a value 736 and that has no direct impact on the other agents values. This 737 declared value applies to all media that are going to be sent to the 738 declaring entity. For example most video codecs has level parameter 739 which tells the other participants the highest complexity the video 740 decoder supports. The level parameter can be declared independently 741 by two participants in a unicast session as it will be the media 742 sender responsibility to transmit a video stream that fulfills the 743 limitation the other has declared. However in multicast it will be 744 necessary to send a stream that follows the limitation of the weakest 745 receiver, i.e. the one that has supports the lowest level. To 746 simplify the negotiation in these cases it is common to require any 747 answerer to a multicast session to take a yes or no approach to 748 parameters. 750 "Negotiated" parameters are another type of parameters, for which 751 both sides needs to agree on their values. Such parameter requires 752 that the answerer either accept as they are offered or remove the 753 payload type the parameter belonged to. The removal of the payload 754 type from the answer indicates to the offerer the lack of support. 755 An unfortunate implications of the need to use complete payload types 756 to indicate each configuration possible to achieve interoperability, 757 is that the number of payload types necessary can quickly grow big. 758 This is one reason to keep the total number of set of capabilities 759 that may be implemented limited. 761 The most problematic type of parameters are those that relates with 762 the transmission the entity performs. They do not really fit the O/A 763 model but can be shoe-horned in. Example of such parameters can be 764 found in the H.264 video code's payload format [RFC3984], where the 765 name of all parameters with this property starts sprop-. The issue 766 that exist is that they declare properties for a media stream one 767 don't yet know if the other party accept. The best one can make of 768 the situation is to explain the assumption that the other party will 769 accept the same reception parameter as the offerer of the session. 770 If the answerer needs to change any declarative parameter then the 771 offerer may be required to make an new offer to update the parameter 772 values for its outgoing media stream. 774 Another issue to consider is the sendonly media streams in offers. 775 For all parameters that relates to what one accepts to receive those 776 don't have any meaning other than provide a template for the 777 answering entity. It is worth pointing out in the specification that 778 these provides recommended set of parameter values by the sender. 779 Note that sendonly streams in answers will need to indicate the 780 offerers parameters to ensure that the offerer can match the answer 781 to the offer. 783 A further issue with offer/answer which complicates things is that it 784 is allowed to renumber the payload types between offer and answer. 785 This is not recommended but allowed for support of gateways to the 786 ITU conferencing suit. Which means that answers for payload types 787 needs to be possible to bind to the ones in the offer even when the 788 payload type number has been changed, and some of the proposed 789 payload types have been removed. This must normally be done based on 790 configurations offered, thus negotiated parameters becomes vital. 792 3.3.2.2. Declarative usage in RTSP and SAP 794 SAP (Session Announcement Protocol) [RFC2974] is used for announcing 795 multicast sessions. Independently of the usage of Source Specific 796 Multicast (SSM) [RFC3569] or Any-Source Multicast (ASM), the SDP 797 provided by SAP applies to all participants. All media that is sent 798 to the session must follow the media stream definition as specified 799 by the SDP. Thus enabling everyone to receive the session if they 800 support the configuration. Here SDP provides a one way channel with 801 no possibility to affect the configuration defined by SDP that the 802 session creator has decided upon. Any RTP Payload format that 803 requires parameters for the send direction and which needs individual 804 values per implementation or instance will fail in a SAP session for 805 a multicast session allowing anyone to send. 807 Real-Time Streaming Protocol (RTSP) [RFC2326] allows the negotiation 808 of transport parameters for media streams part of a streaming session 809 between a server and client. RTSP has divided the transport 810 parameters from the media configuration. SDP is commonly used for 811 media configuration in RTSP and is sent to the client prior to 812 session establishment, either through the usage of the DESCRIBE 813 method or an out-of-band channel like HTTP, email etc. The SDP is 814 used to determine which media streams and what formats are being used 815 before the session establishment. 817 Thus both SAP and RTSP uses SDP to configure receivers and senders 818 with a predetermined configuration including the payload format and 819 any of its parameters of a media stream. Thus all parameters are 820 used in a declarative fashion. This can result in different 821 treatment of parameters between offer/answer and declarative usage in 822 RTSP and SAP. This will then need to be pointed out by the payload 823 format specification. 825 3.4. Transport Characteristics 827 The general channel characteristics that RTP flows are experiencing 828 are documented in Section 3 of RFC2736 [RFC2736]. Below additional 829 information is discussed. 831 3.4.1. Path MTU 833 At the time of writing the most common IP Maximum Transmission Unit 834 (MTU) of used link layers is 1500 bytes (Ethernet data payload). 835 However there exist links with both smaller MTU and much larger MTUs. 836 Certain parts of Internet do already today support IP MTU of 9000 837 bytes or more. There is an slow ongoing evolution towards larger MTU 838 sizes. This should be considered in the design, especially in 839 regards to features such as aggregation of independently decodable 840 data units. 842 4. Specification Process 844 This section discusses the recommended process to produce an RTP 845 payload format in the described venues. This is to document the best 846 current practice on how to get a well designed and specified payload 847 format as quickly as possible. For specifications that are 848 proprietary or defined by other standards bodies than IETF the 849 primary milestone is registration of the RTP payload format name. 850 However there is also the issue of ensuring best possible quality of 851 any specification. 853 4.1. IETF 855 Specification in IETF is recommended for all standardized media 856 formats. The main reason is to provide an openly available RTP 857 payload format specification that also has been reviewed by people 858 experienced with RTP Payload formats. This also assumes that the AVT 859 WG exist. 861 4.1.1. Steps from Idea to Publication 863 There are a number of steps that an RTP payload format should go 864 through from the initial idea until it is published. This also 865 documents the process that the AVT working group applies when working 866 with RTP payload formats. 868 1. Idea: Determined the need for an RTP payload format as an IETF 869 specification. 871 2. Initial effort: Using this document as guideline one should be 872 able to get started on the work. If one's media codec doesn't 873 fit any of the common design patterns or one has problems 874 understanding what the most suitable way forward is, then one 875 should contact the AVT working group and/or the WG chairs. The 876 goal of this stage is to have an initial individual draft. This 877 draft needs to focus on the introduction parts that describe the 878 real-time media format and the basic idea on how to packetize it. 879 All the details are not required to be filled in. However 880 security chapter is not something that one should skip even 881 initially. It is important to consider already from the start 882 any serious security risks that needs to be solved. This step is 883 completed when one has a draft that is sufficient detailed for a 884 first review by the WG. The less confident one is of the 885 solution, the less work should be spent on details, instead 886 concentrate on the codec properties and what is required to make 887 it work. 889 3. Submission of first version. When one has performed the above 890 one submits the draft as an individual draft. This can be done 891 at any time except the 3 weeks (current deadline at the time of 892 writing, consult current announcements) just before an IETF 893 meeting. When the IETF draft announcement has been sent out on 894 the draft announcement list, forward it to the AVT WG and request 895 that it is reviewed. In the email outline any issues the authors 896 currently have with the design. 898 4. Iterative improvements: Taking the feedback into account one 899 updates the draft and try resolve any issues. New revision of 900 the draft can be submitted at any time. It is recommended to do 901 it whenever one has made major updates or have new issues that 902 are easiest to discuss in the context of a new draft version. 904 5. Becoming WG document: Due to that the definition of RTP payload 905 formats are part of the AVT's charter, RTP payload formats that 906 are going to be published as standards track RFCs needs to become 907 WG documents. Becoming WG document means that the chairs are 908 responsible for administrative handling, like publication 909 requests. However be aware that making a document into a WG 910 document changes the formal ownership and responsibility from the 911 individual authors to the WG. The initial authors will continue 912 being document editor, unless unusual circumstances occur. The 913 AVT WG accepts new RTP payload formats based on their suitability 914 and document maturity. The document maturity is a requirement to 915 ensure that there are dedicated document editors and that there 916 exist a good solution. 918 6. Iterative improvements: The updates and review cycles continues 919 until the draft the has reached the maturity suitable for 920 publication. 922 7. WG last call: WG last call of at least 2 weeks are always 923 performed for AVT WG documents. The authors request WG last call 924 for a draft when they think it i mature enough for publication. 925 The chairs perform a review to check if they agree with the 926 authors assessment. If the chairs agree on the maturity, the WG 927 last call is announced on the WG mailing list. If there are 928 issues raised these needs to be addressed with an updated draft 929 version. For any more substantial updates of draft, a new WG 930 last call is announced for the updated version. Minor changes, 931 like editorial on can be progressed without an additional WG last 932 call. 934 8. Publication Requested: For WG documents the chairs request 935 publication of the draft. After this the approval and 936 publication process described in RFC 2026 [RFC2026] are 937 performed. The status after the publication has been requested 938 can be tracked using the IETF data tracker. Documents do not 939 expire as normal after publication has been requested. In 940 addition any submission of document updates requires the approval 941 of WG chair(s). The authors are commonly asked to address 942 comments or issues raised by the IESG. The authors also review 943 the document prior to publication as an RFC to ensure its 944 correctness. 946 4.1.2. WG meetings 948 WG meetings are for discussing issues, not presentations. This means 949 that most RTP payload format should never need to be discussed in a 950 WG meeting. RTP payload formats that would be discussed are either 951 controversial issues that failed to be resolved on the mailing list, 952 or includes new design concepts worth a general discussion. 954 There exist no requirement to present or discuss a draft at a WG 955 meeting before it becoming published as an RFC. Thus even authors 956 that lack the possibility to go to WG meetings should be able to 957 successfully specify an RTP payload format in IETF. WG meetings may 958 only become required if the draft get stuck in a serious debate that 959 isn't easily resolved. 961 4.1.3. Draft Naming 963 To simplify the work of the AVT WG chairs and its WG members a 964 specific draft file naming convention shall be used for RTP payload 965 formats. Individual submissions shall be named draft--avt-rtp--. The WG documents 967 shall be named according to this template: 968 draft-ietf-avt-rtp--. The inclusion of 969 "avt" in the draft filename ensures that the search for "avt-" will 970 find all AVT related drafts. Inclusion of "rtp" tells us that it is 971 an RTP payload format draft. The descriptive name should be as short 972 as possible while still describe what the payload format is for. It 973 is recommended to use the media format or codec acronym. Please note 974 that the version must start at 00 and is increased by one for each 975 submission to the IETF secretary of the draft. No version numbers 976 may be skipped. 978 4.1.4. How to speed up the process 980 There a number of ways of losing a lot of time in the above process. 981 This section discuss what to do and what to avoid. 983 o Do not only update the draft to the meeting deadline. An update 984 to each meeting automatically limits the draft to 3 updates per 985 year. Instead ignore the meeting schedule and publish new 986 versions as soon as possible. 988 o Try to avoid requesting review when people are busy, like the 989 weeks before a meeting. Review should be asked at all possible 990 times and it is actually more likely that people has more time for 991 them directly after a meeting. 993 o Perform draft updates quickly. A common mistake is that the 994 authors lets the draft slip. By performing updates to the draft 995 text directly after getting resolution on an issue, speeds things 996 up. This as it minimizes the delay that the author has direct 997 control over. Waiting for reviews, responses from area directors 998 and chairs, etc can be much harder to speed up. 1000 o Failing to take the human nature into account. It happens that 1001 people forget or needs to be reminded about tasks. Send people 1002 you are waiting for a kindly reminder if things takes longer than 1003 expected. To avoid annoying people ask for a time estimate from 1004 people when they expect to full fill the requested task. 1006 o Not enough review. It is common that documents take a long time 1007 and many iterations because not enough review is performed in each 1008 iteration. To improve the amount of review you get on your own 1009 document, trade review time with other document authors. Make a 1010 deal with some other document authors that you will review his 1011 draft(s) if he reviews yours. Even inexperience reviewers can 1012 help with language, editorial or clarity issues. Try also 1013 approaching the more experienced people in the WG and get them to 1014 commit to a review. The WG chairs cannot, even if desirable, be 1015 expected to review all versions. Due to workload the chairs may 1016 need to concentrate on key points in a draft evolution, like 1017 initial submissions, if ready to become WG document and WG last 1018 call. 1020 4.2. Other Standards bodies 1022 Other standard bodies may define RTP payload in their own 1023 specifications. When they do this they are strongly recommend to 1024 contact the AVT WG chairs and request review of the work. It is 1025 recommended that at least two review steps are performed. One early 1026 in the process when more fundamental issues easily can be resolved 1027 without abandoning a lot of effort. Then when nearing completion, 1028 but while still possible to update the specification as second review 1029 should be scheduled. In that pass the quality can be assessed and 1030 hopefully no updates are needed. Using this procedure can avoids 1031 both conflicting definitions and serious mistakes, like breaking 1032 certain aspects of the RTP model. 1034 RTP payload Media Types may be registered in the standards tree by 1035 other standard bodies. The requirements on the organization are 1036 outlined in the media types registration document (RFC 3555 [RFC3555] 1037 and RFC 4288 [RFC4288]). This registration requires a request to the 1038 IESG, which ensures that the registration template is acceptable. To 1039 avoid last minute problems with these registration the registration 1040 template should be sent for review both to the AVT WG and the media 1041 types list (ietf-types@iana.org) and is something that should be 1042 included in the IETF reviews of the payload format specification. 1044 Registration of the RTP payload name is something that is required to 1045 avoid name collision in the future. Do also note that "x-" names are 1046 not suitable for any documented format as they have the same problem 1047 with name collision and can't be registered. The list of already 1048 registered media types can be found at IANA (http://www.iana.org). 1050 4.3. Propreitary and Vendor Specific 1052 Proprietary RTP payload formats are commonly specified when the real- 1053 time media format is proprietary and not intended to be part of any 1054 standardized system. However there exist many reasons why also 1055 proprietary formats should be correctly documented and registered; 1057 o Usage in standardized signalling environment such as SIP/SDP. RTP 1058 needs to be configured regarding used RTP profiles, payload 1059 formats and their payload types. To accomplish this there is an 1060 need for registered names to ensure that the names do not collide 1061 with other formats. 1063 o Sharing with business partners. As RTP payload formats are used 1064 for communication, situations where business partners like to 1065 support one proprietary format often arises. Having a well 1066 written specification of the format will save time and money for 1067 both one selves and ones partner, as interoperability will much 1068 easier to accomplish. 1070 o To ensure interoperability between different implementations on 1071 different platforms. 1073 To avoid name collisions there is a central register keeping tracks 1074 of the registered Media Type names used by different RTP payload 1075 formats. When it comes to proprietary formats they should be 1076 registered in the vendors own tree. All vendor specific 1077 registrations uses names that start with "vnd.vendor-name". All 1078 names that uses names in the vendors own trees are not required to be 1079 registered with IANA. However registration is recommended if used at 1080 all in public environments. 1082 5. Designing Payload Formats 1084 The best summary of payload format design is KISS (Keep It Simple, 1085 Stupid). A simple payload format makes it easy to review for 1086 correctness, implement, and have low complexity. Unfortunately 1087 contradicting requirements sometime makes it hard to do things 1088 simple. Complexity issues and problems that occur for RTP payload 1089 formats are: 1091 To many configurations: Contradicting requirements results in that 1092 one configuration for each conceivable case is created. Such 1093 contradicting requirements are often between functionality and 1094 bandwidth. This has two big negatives. First all configurations 1095 needs to be implemented. Secondly the using application must 1096 select the most suitable configuration. Selecting the best 1097 configuration can be very difficult and in negotiating 1098 applications, this can create interoperability problems. The 1099 recommendation is to try to select a very limited (preferable one) 1100 configuration that preforms the most common case well and is 1101 capable of handling the other cases, but maybe less well. 1103 Hard to implement: Certain payload formats may become difficult to 1104 implement both correctly and efficient. This needs to be 1105 considered in the design. 1107 Interaction with general mechanisms: Special solutions may create 1108 issues with deployed tools for RTP, like robustification tools. 1109 For example the requirement of non broken sequence space creates 1110 issues with using both payload type switching and interleaving any 1111 robustification mechanism within the stream. 1113 5.1. Features of RTP payload formats 1115 There are number of common features in RTP payload formats. There 1116 are no general requirement to support these features, instead their 1117 applicability must be considered for each payload format. It might 1118 in fact be that certain features are not even applicable. 1120 5.1.1. Aggreagation 1122 Aggregation allows for the inclusion of multiple ADUs within the same 1123 RTP payload. This is commonly supported for codec that produce ADUs 1124 of sizes smaller than the IP MTU. Do remember that the MTU may be 1125 significantly larger than 1500 bytes, 9000 bytes is available today 1126 and a MTU of 64k may be available in the future. Many speech codecs 1127 have the property of ADUs of a few fixed sizes. Video encoders 1128 generally may produce ADUs of quite flexible size. Thus the need for 1129 aggregation may be less. However in certain use cases the 1130 possibility to aggregate multiple ADUs especially for different 1131 playback times are useful. 1133 The main disadvantage of aggregation is the extra delay introduced, 1134 due to buffering until sufficient amount of ADUs have been collected. 1135 It also introduces buffering requirements on the receiver. 1137 5.1.2. Fragmentation 1139 If the real-time media format has the property that it may produce 1140 ADUs that are larger than common MTUs sizes then fragmentation 1141 support should be considered. An RTP Payload format may always 1142 fallback on IP fragmentation, however as discussed in RFC 2736 this 1143 have some drawbacks. The usage of RTP payload format level 1144 fragmentation, does primarily allow for more efficient usage of RTP 1145 packet loss recovery mechanisms. 1147 5.1.3. Interleaving and Transmission Re-Scheduling 1149 Interleaving has been implemented in a number of payload formats to 1150 allow for less quality reduction when packet loss occurs and data is 1151 aggregated. A loss of an RTP packet with several ADUs in the payload 1152 has the same affect as a burst loss if the ADUs would have been 1153 transmitted in individual packets. To reduce the burstiness of the 1154 loss, the data present in an aggregated payload may be interleaved, 1155 thus spread the loss over a longer time period. 1157 A requirement for doing interleaving within an RTP payload format is 1158 the aggregation of multiple ADUs. For formats that don't use 1159 aggregation there is still the possibility to implement an 1160 transmission order re-scheduling mechanism. That have the effect 1161 that packets transmitted next to each other originates from different 1162 points in the media stream. This can be used to mitigate burst 1163 losses, which may be useful if one transmit packets with small 1164 intervals. However it may also be used to transmit more significant 1165 data earlier in combination with RTP retransmission to allow for more 1166 graceful degradation and increased possibilities to receive the most 1167 important data, e.g. Intra frames of video. 1169 The drawbacks of interleaving is the significantly increased 1170 transmission buffering delay, making it mostly useless for low delay 1171 applications. It also creates significant buffering requirements on 1172 the receiver. That buffering also is problematic as it is usually 1173 difficult to indicate when a receiver may start consume data and 1174 still avoid buffer underrun caused by the interleaving mechanism 1175 itself. The transmission re-scheduling is only useful in a few 1176 specific cases, like in streaming with retransmissions. This must be 1177 weighted against the complexity of these schemes. 1179 5.1.4. Media Back Channels 1181 A few RTP payload format have implemented back channels within the 1182 media format. Those have been for specific features, like the AMR 1183 [RFC3267] codec mode request (CMR) field. The CMR field is used in 1184 gateway operations to circuit switched voice to allow an IP terminal 1185 to react to the CS networks need for a specific encoder mode. A 1186 common property for the media back channels is the need to have this 1187 signalling in direct relation to the media or the media path. 1189 If back channels are considered for an RTP payload format they should 1190 be for specific mechanism and which can't be easily satisfied by more 1191 generic mechanisms within RTP or RTCP. 1193 6. Current Trends in Payload Format Design 1195 This section provides a few examples of payload formats that is worth 1196 noting for good design in general or specific details. 1198 6.1. Audio Payloads 1200 To be written 1202 6.2. Video 1204 To be written 1206 6.3. Text 1208 To be written 1210 7. Important Specification Sections 1212 There a number of sections in the payload format draft that needs 1213 some special considerations. These include security and IANA 1214 considerations. 1216 7.1. Security Consideration 1218 All Internet drafts requires a Security Consideration section. The 1219 security consideration section in an RTP payload format needs to 1220 concentrate on the security properties this particular format has. 1221 Some payload format has very little specific issues or properties and 1222 can fully fall back on the general RTP and used profile's security 1223 considerations. Due to that these are always applicable a reference 1224 to these are normally placed first in the security consideration 1225 section. 1227 The security issues of confidentiality, integrity protection and 1228 source authentication are common issues for all payload formats. 1229 These should be solved by payload external mechanism and does not 1230 need any special consideration in the payload format except for an 1231 reminder on these issues. A suitable stock text to inform people 1232 about this is included in the template. 1234 Potential security issues with an RTP payload format and the media 1235 encoding that needs to be considered are: 1237 1. That the decoding of the payload format or its media shows 1238 substantial non-uniformity, either in output or in complexity to 1239 perform the decoding operation. For example a generic non- 1240 destructive compression algorithm may provide an output of almost 1241 infinite size for a very limited input. Thus consuming memory or 1242 storage space out of proportion with what the receiving 1243 application expected causing some sort of disruption, i.e. a 1244 denial of service attack on the receiver by preventing that host 1245 to produce any good put. Certain decoding operations may also 1246 have variable consumption of amount of processing needed to 1247 perform such operations dependent on the input. This may also be 1248 a security risk if that processing load is possible to raise 1249 significantly from nominal simply by designing a malicious input 1250 sequence. If such potential exist this must be expressed in the 1251 security consideration section to make implementers aware of the 1252 need to take precautions against such behavior. 1254 2. The inclusion of active content in the media format or its 1255 transport. With active content means scripts etc that allows an 1256 attacker to perform potentially arbitrary operations on the 1257 receiver. Most active content have limited possibility to access 1258 the system or perform operations outside a protected sandbox. 1259 However if active content may be included the potential must be 1260 noted. It is also strongly recommend that references to any 1261 security model applicable for such content is referenced. 1263 3. Some media formats allows for the carrying of "user data", or 1264 types of data which is not known at the time of the specification 1265 of the payload format. Such data may be a security risk and 1266 should be mentioned. 1268 Suitable stock text for the security consideration is provided in the 1269 template. However the authors do need to actively consider any 1270 security issues from the start. Failure to address these issues is 1271 blocking approval and publication. 1273 7.2. Congestion Control 1275 RTP and its profiles do discuss congestion control. Congestion 1276 control is an important issue in any usage in non-dedicated networks. 1277 For that reason all RTP payload formats are recommended to discuss 1278 the possibilities that exist to regulate the bit-rate of the 1279 transmissions using the described RTP payload format. Some formats 1280 may have limited or step wise regulation of bit-rate. Such limiting 1281 factor should be discussed. 1283 7.3. IANA Consideration 1285 Due to that all RTP Payload format contains a Media Type 1286 specification they also need an IANA consideration section. The 1287 media type name must be registered and this is done by requesting 1288 that IANA register that media name. When that registration request 1289 is written it shall also be requested that the media type is included 1290 under the "RTP Payload Format MIME types" list part of the RTP 1291 registry. 1293 In addition to the above request for media type registration some 1294 payload formats may have parameters where in the future new parameter 1295 values needs to be added. In these cases a registry for that 1296 parameter must be created. This is done by defining the registry in 1297 the IANA consideration section. BCP 26 (RFC 2434) [RFC2434] provides 1298 guidelines to writing such registries. Care should be taken when 1299 defining the policy for new registrations. 1301 Before writing a new registry it is worth checking the existing ones 1302 in the IANA "MIME Media Type Sub-Parameter Registries". For example 1303 video formats needing a media parameter expressing color sub-sampling 1304 may be able to reuse those defined for video/raw [RFC4175]. 1306 8. Authoring Tools 1308 This section informs and recommends some tools that may be used. 1309 Don't be pressured to follow these recommendation. There exist a 1310 number of alternatives. But these suggestion is worth checking out 1311 before deciding that the field is greener somewhere else. 1313 8.1. Editing Tools 1315 There is many choices when it comes to tools to choose for authoring 1316 Internet drafts. However in the end they needs to be able to produce 1317 a draft that conforms to the Internet drafts requirements. If you 1318 don't have any previous experience with authoring Internet drafts 1319 XML2RFC do have some advantages. It helps creating a lot of the 1320 necessary boiler plate in accordance with the latest rules. Thus 1321 reducing the effort. It also speeds up the publication after 1322 approval as the RFC-editor can use the source XML document to quicker 1323 produce the RFC. 1325 Another common choice is to use Microsoft Word and a suitable 1326 template, see [RFC3285] to produce the draft and print that using the 1327 generic text printer. It has some advantage when it comes to spell 1328 checking and change bars. However Word may also produce some 1329 problems, like changing formating, inconsistent result between what 1330 one sees in the editor and in the generated text document, at least 1331 according to the authors personal experience. 1333 8.2. Verification Tools 1335 There are few tools that are very good to know about when writing an 1336 draft. These help check and verify parts of ones work. These tools 1337 can be found at http://tools.ietf.org. 1339 o ID Nits checker. It checks that the boiler plate and some other 1340 things that are easily verifiable by machine is okay in your 1341 draft. Always use it before submitting a draft to avoid direct 1342 refusal in the submission step. 1344 o ABNF Parser and verification. Used to check that your ABNF parses 1345 correctly and warns about loose ends, like undefined symbols. 1346 However the actual content can only be verified by humans knowing 1347 what it intends to describe. 1349 o RFC diff. A diff tool that is optimized for drafts and RFC. For 1350 example it doesn't point out that the foot and header has moved in 1351 relation to the text on every page. 1353 9. Open Issues 1355 This document currently has a few open issues that needs resolving 1356 before publication: 1358 o Should any procedure for the future when the AVT WG is closed be 1359 described? 1361 o The section of current examples of good work needs to be filled 1362 in. 1364 o 1366 10. IANA Considerations 1368 This document makes no request of IANA. 1370 Note to RFC Editor: this section may be removed on publication as an 1371 RFC. 1373 11. Security Considerations 1375 As this is an informational document on the writing of drafts 1376 intended to be RFCs there is no direct security considerations. 1377 However the document does discuss the writing of security 1378 consideration sections and what should be particular considered for 1379 RTP payload formats. 1381 12. RFC Editor Consideration 1383 Note to RFC Editor: This section may be removed after carrying out 1384 all the instructions of this section. 1386 Please replace all References to RFC XXXX with the RFC number that 1387 the update of RFC 3555 [rfc3555bis] receives. 1389 13. Acknowledgements 1391 14. Informative References 1393 [CSP-RTP] Colin , "RTP: Audio and Video for the Internet", 1394 June 2003. 1396 [MACOSFILETYPES] 1397 Apple Knowledge Base Article 1398 55381, "Mac OS: 1399 File Type and Creator Codes, and File Formats", 1993. 1401 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1402 Specification, Implementation", RFC 1305, March 1992. 1404 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1405 3", BCP 9, RFC 2026, October 1996. 1407 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 1408 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 1409 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 1410 September 1997. 1412 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1413 RFC 2246, January 1999. 1415 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1416 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1418 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 1419 Procedures", BCP 25, RFC 2418, September 1998. 1421 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1422 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1423 October 1998. 1425 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 1426 Headers for Low-Speed Serial Links", RFC 2508, 1427 February 1999. 1429 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 1430 Payload Format Specifications", BCP 36, RFC 2736, 1431 December 1999. 1433 [RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time 1434 Transport Protocol Management Information Base", RFC 2959, 1435 October 2000. 1437 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1438 Announcement Protocol", RFC 2974, October 2000. 1440 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1441 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 1442 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 1443 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 1444 Compression (ROHC): Framework and four profiles: RTP, UDP, 1445 ESP, and uncompressed", RFC 3095, July 2001. 1447 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1448 A., Peterson, J., Sparks, R., Handley, M., and E. 1449 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1450 June 2002. 1452 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1453 with Session Description Protocol (SDP)", RFC 3264, 1454 June 2002. 1456 [RFC3267] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, 1457 "Real-Time Transport Protocol (RTP) Payload Format and 1458 File Storage Format for the Adaptive Multi-Rate (AMR) and 1459 Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", 1460 RFC 3267, June 2002. 1462 [RFC3285] Gahrns, M. and T. Hain, "Using Microsoft Word to create 1463 Internet Drafts and RFCs", RFC 3285, May 2002. 1465 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 1466 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 1467 High Delay, Packet Loss and Reordering", RFC 3545, 1468 July 2003. 1470 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1471 Encodings", RFC 3548, July 2003. 1473 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1474 Jacobson, "RTP: A Transport Protocol for Real-Time 1475 Applications", STD 64, RFC 3550, July 2003. 1477 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1478 Video Conferences with Minimal Control", STD 65, RFC 3551, 1479 July 2003. 1481 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1482 Payload Formats", RFC 3555, July 2003. 1484 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1485 Multicast (SSM)", RFC 3569, July 2003. 1487 [RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. 1488 Romascanu, "Introduction to the Remote Monitoring (RMON) 1489 Family of MIB Modules", RFC 3577, August 2003. 1491 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 1492 Protocol Extended Reports (RTCP XR)", RFC 3611, 1493 November 2003. 1495 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1496 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1497 RFC 3711, March 2004. 1499 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 1500 RFC 3978, March 2005. 1502 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 1503 Technology", BCP 79, RFC 3979, March 2005. 1505 [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, 1506 M., and D. Singer, "RTP Payload Format for H.264 Video", 1507 RFC 3984, February 2005. 1509 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1510 Conversation", RFC 4103, June 2005. 1512 [RFC4170] Thompson, B., Koren, T., and D. Wing, "Tunneling 1513 Multiplexed Compressed RTP (TCRTP)", BCP 110, RFC 4170, 1514 November 2005. 1516 [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for 1517 Uncompressed Video", RFC 4175, September 2005. 1519 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1520 Registration Procedures", BCP 13, RFC 4288, December 2005. 1522 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1523 Internet Protocol", RFC 4301, December 2005. 1525 [rfc-avpf] 1526 Joerg, "Extended RTP Profile for RTCP-based Feedback (RTP/ 1527 AVPF)", August 2004. 1529 [rfc-savpf] 1530 Joerg, "Extended Secure RTP Profile for RTCP-based 1531 Feedback (RTP/SAVPF)", July 2004. 1533 [rfc2223bis] 1534 Reynolds, K., "Instructions to Request for Comments (RFC) 1535 Authors", August 2004. 1537 [rfc3555bis] 1538 Casner, L., "MIME Type Registration of RTP Payload 1539 Formats", October 2005. 1541 [rtp-rtx] Jose, "RTP Retransmission Payload Format", March 2005. 1543 [sdp-new] Perkins, "SDP: Session Description Protocol", July 2005. 1545 Appendix A. RTP Payload Format Template 1547 This section contains a template for writing an RTP payload format in 1548 form as a Internet draft. Text within [...] are instructions and 1549 must be removed. Some text proposals that are included are 1550 conditional. "..." is used to indicate where further text should be 1551 written. 1553 A.1. Title 1555 [The title shall be descriptive but as compact as possible. RTP is 1556 allowed and recommended abbreviation in the title] 1558 RTP Payload format for ... 1560 A.2. Front page boilerplate 1562 Status of this Memo 1564 [Insert the IPR notice boiler plate from BCP 79 that applies to this 1565 draft.] 1567 [Insert the current Internet Draft document explanation. At the time 1568 of publishing it was:] 1570 Internet-Drafts are working documents of the Internet Engineering 1571 Task Force (IETF), its areas, and its working groups. Note that 1572 other groups may also distribute working documents as Internet- 1573 Drafts. 1575 Internet-Drafts are draft documents valid for a maximum of six months 1576 and may be updated, replaced, or obsoleted by other documents at any 1577 time. It is inappropriate to use Internet-Drafts as reference 1578 material or to cite them other than as "work in progress." 1580 [Insert the ID list and shadow list reference. At the time of 1581 publishing it was:] 1583 The list of current Internet-Drafts can be accessed at 1584 http://www.ietf.org/ietf/1id-abstracts.txt. 1586 The list of Internet-Draft Shadow Directories can be accessed at 1587 http://www.ietf.org/shadow.html. 1589 [Optionally: Select either of these paragraphs depending on draft 1590 status] 1592 This document is an individual submission to the IETF. Comments 1593 should be directed to the authors. 1595 This document is a submission of the IETF AVT WG. Comments should be 1596 directed to the AVT WG mailing list, avt@ietf.org. 1598 A.3. Abstract 1600 [An payload format abstract should mention the capabilities of the 1601 format, for which media format is used, and a little about that codec 1602 formats capabilities. Any abbreviation used in the payload format 1603 must be spelled out here except the very well known like RTP. No 1604 references are allowed, no use of RFC 2119 language either.] 1606 A.4. Table of Content 1608 [All drafts over 15 pages in length must have an Table of Content.] 1610 A.5. Introduction 1612 [The introduction should provide a background and overview of the 1613 payload formats capabilities. No normative language in this section, 1614 i.e. no MUST, SHOULDS etc.] 1616 A.6. Conventions, Definitions and Acronyms 1618 [Define conventions, definitions and acronyms used in the document in 1619 this section. The most common definition used in RTP Payload formats 1620 are the RFC 2119 definitions of the upper case normative words, e.g. 1621 MUST and SHOULD.] 1623 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1624 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1625 document are to be interpreted as described in RFC 2119. 1627 A.7. Media Format Background 1629 [The intention of this section is to enable reviewers and persons to 1630 get an overview of the capabilities and major properties of the media 1631 format. It should be kept short and concise and is not a complete 1632 replacement for reading the media format specification.] 1634 A.8. Payload format 1636 [Overview of payload structure] 1638 A.8.1. RTP Header Usage 1640 [RTP header usage needs to be defined. The fields that absolutely 1641 need to be defined are timestamp and marker bit. Further field may 1642 be specified if used. All the rest should be left to their RTP 1643 specification definition] 1645 The remaining RTP header fields are used as specified in RFC 3550. 1647 A.8.2. Payload Header 1649 [Define how the payload header if it exist are structured and used.] 1651 A.8.3. Payload Data 1653 [The payload data, i.e. what the media codec has produced. Commonly 1654 done through reference to media codec specification which defines how 1655 the data is structured. Rules for padding may need to be defined to 1656 bring data to octet alignment.] 1658 A.9. Payload Examples 1660 [One or more examples are good to help ease the understanding of the 1661 RTP payload format.] 1663 A.10. Congestion Control Considerations 1665 [This section is to describe the possibility to vary the bit-rate as 1666 a response to congestion. Below is also a proposal for an initial 1667 text that reference RTP and profiles definition of congestion 1668 control.] 1670 Congestion control for RTP SHALL be used in accordance with RFC 3550 1671 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 1672 [RFC3551]. An additional requirement if best-effort service is being 1673 used is: users of this payload format MUST monitor packet loss to 1674 ensure that the packet loss rate is within acceptable parameters. 1676 A.11. Payload Format Parameters 1678 This RTP payload format is identified using the ... media type which 1679 is registered in accordance with RFC XXXX [rfc3555bis] and using the 1680 template of RFC 4288 [RFC4288]. 1682 A.11.1. Media Type Definition 1684 [Here the media type registration template from RFC 4288 is placed 1685 and filled out. This template is provided with some common RTP 1686 boilerplate.] 1688 Type name: 1690 Subtype name: 1692 Required parameters: 1694 Optional parameters: 1696 Encoding considerations: 1698 This media type is framed and binary, see section 4.8 in RFC4288 1699 [RFC4288]. 1701 Security considerations: 1703 Interoperability considerations: 1705 Published specification: 1707 Applications that use this media type: 1709 Additional information: 1711 Magic number(s): 1713 File extension(s): 1715 Macintosh file type code(s): 1717 Person & email address to contact for further information: 1719 Intended usage: (One of COMMON, LIMITED USE or OBSOLETE.) 1721 Restrictions on usage: 1723 [The below text is for media types that is only defined for RTP 1724 payload formats. There exist certain media types that are defined 1725 both as RTP payload formats and file transfer. The rules for such 1726 types are documented in RFC 3555bis [rfc3555bis].] 1728 This media type depends on RTP framing, and hence is only defined for 1729 transfer via RTP [RFC3550]. Transport within other framing protocols 1730 is not defined at this time. 1732 Author: 1734 Change controller: 1736 IETF Audio/Video Transport working group delegated from the IESG. 1738 (Any other information that the author deems interesting may be added 1739 below this line.) 1741 [From RFC 4288: Some discussion of Macintosh file type codes and 1742 their purpose can be found in [MACOSFILETYPES]. Additionally, please 1743 refrain from writing "none" or anything similar when no file 1744 extension or Macintosh file type is specified, lest "none" be 1745 confused with an actual code value.] 1747 A.11.2. Mapping to SDP 1749 The mapping of the above defined payload format media type and its 1750 parameters SHALL be done according to Section 3 of RFC XXXX 1751 [rfc3555bis]. 1753 [More specific rules only need to be included if some parameter does 1754 not match these rules.] 1756 A.11.2.1. Offer/Answer Considerations 1758 [Here write your offer/answer consideration section, please see 1759 Section Section 3.3.2.1 for help.] 1761 A.11.2.2. Declarative SDP Considerations 1763 [Here write your considerations for declarative SDP, please see 1764 Section Section 3.3.2.2 for help.] 1766 A.12. IANA Considerations 1768 This memo requests that IANA registers [insert media type name here] 1769 as specified in Appendix A.11.1. The media type is also requested to 1770 be added to the IANA registry for "RTP Payload Format MIME types" 1771 (http://www.iana.org/assignments/rtp-parameters). 1773 [See Section Section 7.3 and consider if any of the parameter needs a 1774 registered name space.] 1776 A.13. Securtiy Considerations 1778 [See Section Section 7.1] 1780 RTP packets using the payload format defined in this specification 1781 are subject to the security considerations discussed in the RTP 1782 specification [4], and in any applicable RTP profile. The main 1783 security considerations for the RTP packet carrying the RTP payload 1784 format defined within this memo are confidentiality, integrity and 1785 source authenticity. Confidentiality is achieved by encryption of 1786 the RTP payload. Integrity of the RTP packets through suitable 1787 cryptographic integrity protection mechanism. Cryptographic system 1788 may also allow the authentication of the source of the payload. A 1789 suitable security mechanism for this RTP payload format should 1790 provide confidentiality, integrity protection and at least source 1791 authentication capable of determining if an RTP packet is from a 1792 member of the RTP session or not. 1794 Note that the appropriate mechanism to provide security to RTP and 1795 payloads following this memo may vary. It is dependent on the 1796 application, the transport, and the signalling protocol employed. 1797 Therefore a single mechanism is not sufficient, although if suitable 1798 the usage of SRTP [RFC3711] is recommended. Other mechanism that may 1799 be used are IPsec [RFC4301] and TLS [RFC2246] (RTP over TCP), but 1800 also other alternatives may exist. 1802 [Fill in here any further potential security threats] 1804 A.14. References 1806 [References must be classified as either normative or informative and 1807 added to the relevant section. References should use descriptive 1808 reference tags.] 1810 A.14.1. Normative References 1812 [Normative references are those that are required to be used to 1813 correctly implement the payload format.] 1815 A.14.2. Informative References 1817 [All other references.] 1819 A.15. Author Addresses 1821 [All Authors need to include their Name and email addresses as a 1822 minimal. Commonly also surface mail and possibly phone numbers are 1823 included.] 1825 A.16. IPR Notice 1827 [Use the appropriate boilerplate from Section 5 of BCP 79 [RFC3979].] 1829 A.17. Copyright Notice 1831 [Use the boilerplate from Section 5.4 and 5.5 of BCP 78 [RFC3978].] 1833 Author's Address 1835 Magnus Westerlund 1836 Ericsson 1837 Torshamgatan 23 1838 Stockholm, SE-164 80 1839 SWEDEN 1841 Phone: +46 8 4048287 1842 Fax: +46 8 757 55 50 1843 Email: magnus.westerlund@ericsson.com 1845 Intellectual Property Statement 1847 The IETF takes no position regarding the validity or scope of any 1848 Intellectual Property Rights or other rights that might be claimed to 1849 pertain to the implementation or use of the technology described in 1850 this document or the extent to which any license under such rights 1851 might or might not be available; nor does it represent that it has 1852 made any independent effort to identify any such rights. Information 1853 on the procedures with respect to rights in RFC documents can be 1854 found in BCP 78 and BCP 79. 1856 Copies of IPR disclosures made to the IETF Secretariat and any 1857 assurances of licenses to be made available, or the result of an 1858 attempt made to obtain a general license or permission for the use of 1859 such proprietary rights by implementers or users of this 1860 specification can be obtained from the IETF on-line IPR repository at 1861 http://www.ietf.org/ipr. 1863 The IETF invites any interested party to bring to its attention any 1864 copyrights, patents or patent applications, or other proprietary 1865 rights that may cover technology that may be required to implement 1866 this standard. Please address the information to the IETF at 1867 ietf-ipr@ietf.org. 1869 Disclaimer of Validity 1871 This document and the information contained herein are provided on an 1872 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1873 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1874 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1875 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1876 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1877 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1879 Copyright Statement 1881 Copyright (C) The Internet Society (2006). This document is subject 1882 to the rights, licenses and restrictions contained in BCP 78, and 1883 except as set forth therein, the authors retain all their rights. 1885 Acknowledgment 1887 Funding for the RFC Editor function is currently provided by the 1888 Internet Society.