idnits 2.17.1 draft-periyannan-generic-rtp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 839 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 48 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 53 has weird spacing: '... each audio...' -- 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 (March 13, 1998) is 9541 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) ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '2') (Obsoleted by RFC 3551) ** Obsolete normative reference: RFC 2035 (ref. '3') (Obsoleted by RFC 2435) ** Obsolete normative reference: RFC 2038 (ref. '4') (Obsoleted by RFC 2250) ** Obsolete normative reference: RFC 2032 (ref. '5') (Obsoleted by RFC 4587) -- Unexpected draft version: The latest known version of draft-ietf-mmusic-rtsp is -08, but you're referring to -09. -- Possible downref: Normative reference to a draft: ref. '7' -- No information found for draft-klemets-asf-rtp - is the name correct? -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-06) exists of draft-ietf-mmusic-sdp-05 Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Audio-Video Transport WG 3 INTERNET-DRAFT A. Periyannan, D. Singer, M. Speer 4 draft-periyannan-generic-rtp-00 Apple Computer / Sun Microsystems 5 March 13, 1998 6 Expires: September 13, 1998 8 Delivering Media Generically over RTP 10 Status of This Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 Abstract 32 This document specifies a method for delivering generic media streams 33 over the Realtime Transport Protocol (RTP). This proposal is intended 34 for media or codec types that are not already handled by other RTP 35 payload specifications. Three packetization schemes are defined for 36 carrying the media data. The Session Description Protocol (SDP) is 37 used to convey to receivers the packetization scheme used, the media 38 data encoding format and parameters for the media encoding format. 40 1 Introduction 42 This document defines a method for delivering generic media streams 43 over the Realtime Transport Protocol (RTP) [1]. RTP is a protocol 44 designed to carry realtime media data along with synchronization 45 information over a datagram protocol (usually UDP over IP). The 46 protocol itself does not address the encapsulation of specific media 47 types, but instead leaves it to various profile and payload format 49 A. Periyannan, D. Singer, M. Speer [Page 1]^L 50 specifications. An accompanying RTP profile document [2] contains 51 various payload specifications to carry audio and video over RTP for 52 conferencing applications and specifies the static payload types for 53 each audio/video compression scheme. 55 The RTP payload specifications available today are limited to a few 56 audio compression schemes such as PCM, GSM and DVI [2] and a few 57 video compression schemes such as JPEG, MPEG and H.261 [3,4,5]. In 58 the current model every new compression scheme requires a new RTP 59 payload specification. As we move forward this model is impractical 60 since there are many new audio and video codecs that will become 61 available. There are also many compression schemes that are already 62 available within media file formats and playback architectures such 63 as QuickTime, WAV, RealAudio and ASF that do not have RTP payload 64 specifications. There are media types such as text and MIDI that are 65 not addressed by any RTP payload specification. There needs to be a 66 way of carrying all of this media over RTP without having to 67 individually come up with payload specifications for each of them. 69 Two proposals were made for delivering QuickTime [7] and ASF [8] 70 media over RTP that solve the above mentioned problems. These 71 proposals solved the primary problem but raised a major concern - 72 they were incompatible with each other. They introduced two ways of 73 delivering the same media content over RTP. In contrast, this 74 proposal illustrates a method for carrying generic media and codec 75 types over RTP that is independent of the file format and media 76 playback architecture. 78 The goals of this proposal can be divided into two categories, 80 - define a set of packetization schemes that cover the needs of 81 various media types. 83 - define a mechanism within SDP to convey the packetization scheme, 84 the media encoding format and other parameters for the media encoding 85 format. 87 Proposals to achieve the above goals are covered in sections 2 and 3 88 of this document. Open issues are listed in section 4. 90 2 RTP Packetization Schemes 92 This proposal defines three packetization schemes. They are designed 93 to meet the needs of different types of media samples in media 94 streams. The scheme used in a given RTP session is agreed upon by the 95 senders and receivers through non-RTP means. (Section 3 defines a 96 mechanism to convey this information through SDP.) 98 A. Periyannan, D. Singer, M. Speer [Page 2]^L 99 For the purposes of this proposal, a media sample is defined as a 100 unit of compressed or uncompressed media data with an associated 101 duration and timestamp. Audio samples are typically constant size, 102 constant duration units of audio data. Video samples are usually 103 variable size units of video data refered to as video frames. MIDI 104 samples are typically variable size, variable duration units of MIDI 105 instructions. Text samples are variable size, variable duration units 106 containing text strings usually in Unicode format. 108 The choice of which scheme to use on a given RTP session is based on 109 the type of stream. More specifically it depends on characteristics 110 such as, 112 - the duration of each media sample 114 - the size of each media sample compared to the Maximum Transmission 115 Unit (MTU) size of the underlying network 117 - the need for receivers to detect key samples with a mechanism that 118 is independent of the encoding format. (Key samples are defined as 119 intracoded samples in a media stream that also contains intercoded 120 samples.) 122 - the need to specify sample durations 124 The definition of each packetization scheme in this section is 125 preceded by a recommendation on its usage based on the above 126 considerations. The three schemes proposed here may not satisfy the 127 needs of all the current and future types of media streams. More 128 packetization schemes may be added to this list to satisfy changing 129 requirements. 131 2.1 Generic Scheme A 133 This packetization scheme is recommended for use with media streams 134 with the following characteristics, 136 - the duration and size of each media sample is constant 138 - the size of each media sample is less than the MTU size of the 139 underlying network (after taking into account the RTP header) 141 Media streams that typically fall into this category are frame-based 142 as well as sample-based compressed or uncompressed audio streams. 144 The RTP packet used in Scheme A is formatted as follows: 146 A. Periyannan, D. Singer, M. Speer [Page 3]^L 147 0 1 2 3 148 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 . RTP Header . 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 . Sample Data... . 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 The format and general usage of the RTP header fields are described 156 in [1]. The following fields of the RTP header will be used as 157 specified below: 159 - The payload type should specify one of the dynamic payload types 160 that should be agreed upon through some non-RTP means. 162 - The RTP timestamp is based on a timescale that should be agreed 163 upon through some non-RTP means. The timestamp encodes the sampling 164 instant of the first media sample contained in the RTP data packet. 165 Multiple samples may be contained in one RTP packet. The initial 166 value of the timestamp is random (unpredictable) to make known- 167 plaintext attacks on encryption more difficult, see RTP [1]. 169 - The marker bit (M-bit) is unused. Transmitters must set this bit to 170 zero. Receivers must ignore this bit. 172 The sample data immediately follows the RTP header and contains one 173 or more complete media samples. 175 2.2 Generic Scheme B 177 This packetization scheme is recommended for use with media streams 178 with the following characteristics, 180 - the size of each media sample is variable and typically greater 181 than the MTU size of the underlying network (after taking into 182 account the RTP header) 184 - the duration of each media sample is the difference between its 185 timestamp and the timestamp of the next sample or the duration is 186 either implicitly or explicitly contained within the sample data. 188 - the receivers do not have a need to be able to detect key samples 189 using a mechanism that is independent of the encoding format. 191 Media streams that typically fall into this category are compressed 192 video streams with large frame sizes. 194 A. Periyannan, D. Singer, M. Speer [Page 4]^L 195 The RTP packet used in Scheme B is formatted as follows: 197 0 1 2 3 198 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 . RTP Header . 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 . Sample Data... . 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 The format and general usage of the RTP header fields are described 206 in [1]. The following fields of the RTP header will be used as 207 specified below: 209 - The payload type should specify one of the dynamic payload types 210 that should be agreed upon through some non-RTP means. 212 - The RTP timestamp is based on a timescale that should be agreed 213 upon through some non-RTP means. The timestamp encodes the sampling 214 instant of the media sample contained in the RTP data packet. An RTP 215 packet contains a single complete sample or a single sample is 216 fragmented over multiple RTP packets. If a media sample occupies more 217 than one packet, the timestamp must be the same on all of those 218 packets. Packets containing different samples must have different 219 timestamps so that samples may be distinguished by the timestamp. The 220 initial value of the timestamp is random (unpredictable) to make 221 known-plaintext attacks on encryption more difficult, see RTP [1]. 223 - The marker bit (M-bit) is set to one in the last packet of a sample 224 and otherwise, must be zero. If one sample is fully contained within 225 an RTP packet the M-bit must be set to one. Thus, it is possible to 226 easily detect that a complete sample has been received and can be 227 decoded and presented. 229 The sample data immediately follows the RTP header and contains one 230 complete media sample or a fragment of a media sample. 232 2.3 Generic Scheme C 234 This packetization scheme is recommended for use with media streams 235 with the following characteristics, 237 - the size of each media sample is variable - some packets are larger 238 than the MTU size, but most are much smaller. 240 - sometimes the samples require a mechanism outside their encoding 242 A. Periyannan, D. Singer, M. Speer [Page 5]^L 243 format to specify the duration. 245 - the receivers have a need to be able to detect key samples using a 246 mechanism that is independent of the encoding format. 248 Media streams that typically fall into this category are compressed 249 video streams with some large frames and many small frames, 250 proprietary video streams that have a need for receivers to be able 251 to detect key samples and MIDI streams that require duration of a 252 sample to be specified. 254 The RTP packet used in Scheme C is formatted as follows: 256 0 1 2 3 257 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 . RTP Header . 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 . Scheme C Header... . 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 . Sample Data... . 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 . Scheme C Header... . 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 . Sample Data... . 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 . ...... . 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 The format and general usage of the RTP header fields are described 273 in [1]. The following fields of the RTP header will be used as 274 specified below: 276 - The payload type should specify one of the dynamic payload types 277 that should be agreed upon through some non-RTP means. 279 - The RTP timestamp is based on a timescale that should be agreed 280 upon through some non-RTP means. The timestamp encodes the sampling 281 instant of the first media sample contained in the RTP data packet. 282 Multiple samples may be contained in one RTP packet or a single 283 sample may be fragmented over multiple RTP packets. If a media sample 284 occupies more than one packet, the timestamp must be the same on all 285 of those packets. Packets containing different samples must have 286 different timestamps so that samples may be distinguished by the 287 timestamp. The initial value of the timestamp is random 289 A. Periyannan, D. Singer, M. Speer [Page 6]^L 290 (unpredictable) to make known-plaintext attacks on encryption more 291 difficult, see RTP [1]. 293 - The marker bit (M-bit) is set to one in the last packet of a sample 294 and otherwise, must be zero. If one or more samples are fully 295 contained within an RTP packet the M-bit must be set to one. Thus, it 296 is possible to easily detect that a complete sample has been received 297 and can be decoded and presented. 299 The RTP payload contains one of the following, 301 - One media sample fragment, i.e. when the sample size is larger than 302 the MTU size and hence the sample has to be fragmented over multiple 303 packets. 305 - One or more complete media samples, i.e. when the sample size is 306 smaller than the MTU size and hence one or more media samples can be 307 placed in a single RTP packet. 309 In both cases each media sample or fragment is preceded by a Scheme C 310 header. 312 The Scheme C header is defined as follows: 314 0 1 2 3 315 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 |S|L|R|D| RES | Length/Offset | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Relative Timestamp | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Duration | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 The fields in the Scheme C header have the following meanings: 326 S bit: 1 bit 327 The S-bit is set to one if the sample is a key sample, i.e. 328 intracoded sample. Otherwise it is set to zero. The S-bit in all 329 headers preceding fragments of the same sample must be set to the 330 same value. 332 L bit: 1 bit 333 The L-bit is set to one if the Length/Offset field contains a length. 335 A. Periyannan, D. Singer, M. Speer [Page 7]^L 336 Otherwise it is set to zero and the Length/Offset field contains an 337 offset. The L-bit must be set to one in all headers preceding 338 complete samples and must be set to zero in all headers preceding 339 sample fragments. 341 R bit: 1 bit 342 The R-bit is set to one if the header contains a relative timestamp. 343 Otherwise it is set to zero. The R-bit in all headers preceding 344 fragments of the same sample must be set to the same value. 346 D bit: 1 bit 347 The D-bit is set to one if the header contains a sample duration. 348 Otherwise it is set to zero. The D-bit in all headers preceding 349 fragments of the same sample must be set to the same value. 351 RES: 8 bits 352 Reserved for future use. Transmitters must set these bits to zero. 353 Receivers must ignore these bits. 355 Length/Offset: 24 bits 356 If a single sample is fragmented over multiple packets, the L-bit is 357 set to zero and the Length/Offset field contains the byte offset of 358 the first byte of this fragment from the beginning of the sample. If 359 one or more complete samples are contained in this packet, the L-bit 360 is set to one in each Scheme C header, and the Sample Length/Offset 361 field contains the length of this sample (including the Scheme C 362 header.) The sum of the lengths of all samples in a packet must be 363 equal to the RTP payload length. Receivers make use of this 364 relationship to ascertain whether there are more samples to extract 365 from a packet. 367 Relative Timestamp: signed 32 bits 368 This field is present only if the R-bit is set to one. It contains 369 the relative timestamp for this sample with respect to the timestamp 370 in the RTP header. The timescale used is the same as that used for 371 the timestamp in the RTP header. This field is specified as a signed 372 32-bit number to allow for negative offsets from the RTP header 373 timestamp. When this field is absent a default relative timestamp of 374 zero is used. 376 Duration: 32 bits 377 This field is present only if the D-bit is set to one. It contains 378 the duration of the sample. The timescale used is the same as that 379 used for the timestamp in the RTP header. The Duration in all headers 380 preceding fragments of the same sample must be set to the same value. 381 When this field is absent the default duration is implicitly or 382 explicitly obtained from the sample data. If this is not possible the 383 default is the difference between this sample's timestamp and the 385 A. Periyannan, D. Singer, M. Speer [Page 8]^L 386 next sample's timestamp. 388 The length of the Scheme C header varies between 4 bytes and 12 bytes 389 depending on whether the R and D bits are set. When neither of the 390 bits are set the header length is 4 bytes. When only one of them is 391 set the header length is 8 bytes. When both bits are set the header 392 length is 12 bytes. 394 3 SDP Usage 396 SDP is used as a mechanism to convey to RTP receivers the information 397 required to decode and present a set of RTP sessions. SDP can be used 398 as an announcement mechanism as described in [9] or can be used as a 399 description format with the Real Time Streaming Protocol [6]. In both 400 cases, SDP is used to specify the set of RTP sessions being 401 transmitted, the media type in each session, the payload format and 402 encoding format of each session and other parameters associated with 403 each session. 405 This proposal defines a set of extensions to the mechanisms already 406 defined by SDP. These extensions are used to convey the following 407 information: 409 - RTP packetization scheme 411 - Media sample encoding format 413 - Parameters for the media encoding format 415 The SDP rtpmap and fmtp attributes are used to convey the above 416 information. 418 3.1 rtpmap Attribute 420 The SDP specification [9] currently defines the following format for 421 the rtpmap attribute, 423 a=rtpmap: /[/] 426 The is either a registered IANA name or an 427 unregistered name preceded by "X-". Currently, this name specifies 428 the encoding format of the media samples and also implicitly 429 specifies the packetization scheme used. 431 This proposal defines a new usage for the that 432 separates the packetization scheme and the media encoding format. 433 When the packetization scheme is implicit in the encoding format the 435 A. Periyannan, D. Singer, M. Speer [Page 9]^L 436 optional fields are dropped and the usage becomes identical to the 437 old usage of . The is enclosed in 438 quotes when it contains the optional fields. All other fields of the 439 rtpmap attribute line are used as defined in [9]. 441 The is defined as follows: 443 "[/][,]" 445 The specifies the encodings used in the media 446 samples, i.e. it specifies the compression scheme used for audio or 447 video streams or the media type used for other types of streams. The 448 optional specifies the headers used within the 449 RTP payload and the mechanisms used to fragment samples over RTP 450 packets. 452 The as well as the are 453 either registered IANA names or unregistered names preceded by "X-". 454 The optional that precedes the encoding format is used to 455 qualify the when the format falls within the scope 456 of an encompassing format. The is either a registered 457 IANA name or an unregistered name preceded by "X-". When a 458 is present then the falls under the 459 scope of the and hence is not registered with the IANA. 461 The packetization schemes defined in section 2 are named as follows, 463 Generic Scheme A genpak-a 464 Generic Scheme B genpak-b 465 Generic Scheme C genpak-c 467 Some examples of the new usage of the rtpmap attribute are presented: 469 An RTP session with Intel Indeo video over generic packetization 470 scheme B with a timescale (clockrate) of 600: 472 a=rtpmap:99 "indeo,genpak-b"/600 474 An RTP session with QuickTime MIDI over generic packetization scheme 475 C with a timescale of 30: 477 a=rtpmap:99 "x-qt/midi,genpak-c"/30 479 An RTP session with Microsoft ADPCM audio over generic packetization 480 scheme A with a timescale of 8 KHz: 482 A. Periyannan, D. Singer, M. Speer [Page 10]^L 483 a=rtpmap:99 "x-asf/00000002-0000-0010-8000-00AA00389B71,genpak- 484 a"/8000 486 An RTP session with QuickTime AppleVideo over generic packetization 487 scheme B with a timescale of 90000: 489 a=rtpmap:99 "x-qt/viderpza,genpak-b"/90000 491 An RTP session with QuickTime Sprites over a proprietary 492 packetization scheme with a timescale of 600: 494 a=rtpmap:99 "x-qt/twen,x-qtsprite"/600 496 This method of using the rtpmap attribute allows for widely available 497 proprietary video codecs such as Intel's Indeo to be sent over RTP 498 regardless of the file format used to store the content or the 499 multimedia architecture used to present it. In addition, the method 500 is flexible enough to allow a way to specify proprietary codecs that 501 only exist within a proprietary file format or multimedia playback 502 architecture. The method also allows new packetization schemes to be 503 added independent of new encoding formats. 505 3.2 fmtp Attribute 507 The SDP specification [9] currently defines the following format for 508 the fmtp attribute, 510 a=fmtp: 512 is one of the payload types specified for the media, i.e. 513 one of the payload types for which there is an rtpmap attribute line. 514 The usage of is currently undefined in 515 the specification. 517 This proposal defines that the usage of is scoped by the specified in the 519 corresponding rtpmap attribute for the payload type specified in the 520 fmtp line. Thus, if we are sending Intel's Indeo (indeo) over RTP the 521 format specific parameters are those defined for Indeo and if we're 522 sending QuickTime MIDI (x-qt/midi) over RTP the format specific 523 parameters are those defined for QuickTime MIDI. 525 The definitions for format specific parameters for a given encoding 526 format are beyond the scope of this document. 528 4 Open Issues 530 The following open issues need to be resolved: 532 A. Periyannan, D. Singer, M. Speer [Page 11]^L 533 - M-bit usage in scheme A 534 The M-bit is currently unused in scheme A. It can be used to indicate 535 the first packet after a gap in the RTP timeline. 537 - A new rtpmap2 538 An attempt was made to keep the rtpmap line as close as possible to 539 the current specification. This may not be the best choice. A new 540 rtpmap2 will eliminate confusion and parsing problems. (Also, the "," 541 delimiter is not widely used in SDP. Should a space be used instead?) 543 - Multiple fmtp attribute lines per format 544 We may need multiple fmtp lines per format (payload type) for better 545 readability. In the current SDP specification it is unclear whether 546 this is legally allowed. 548 - Binary data in fmtp attribute lines 549 When sending proprietary encoding formats over RTP, the format 550 specific parameters may need to be transparently conveyed to the 551 receiver in binary form. There is currently no mechanism defined in 552 SDP to convey binary data. 554 - Large SDP files 555 The format specific parameters may require more space than the 1 556 Kbyte limit in SDP. This limit needs to relaxed. 558 Acknowledgments 560 The authors would like to thank all the members of the QuickTime 561 Streaming team - Anne Jones, Jay Geagan, Andy Grignon, Sylvain Rouze 562 and Kevin Gong for their valuable input in writing this proposal. 564 A. Periyannan, D. Singer, M. Speer [Page 12]^L 565 References 567 [1] H. Schulzrinne, et. al., "RTP : A Transport Protocol for Real- 568 Time Applications", IETF RFC 1889, January 1996. 570 [2] H. Schulzrinne, et. al., "RTP Profile for Audio and Video 571 Conference with Minimal Control", IETF RFC 1890, January 1996. 573 [3] L. Berc, et. al., "RTP Payload Format for JPEG-compressed Video", 574 IETF RFC 2035, October 1996. 576 [4] D. Hoffman, et. al., "RTP Payload Format for MPEG1/MPEG2 Video", 577 IETF RFC 2038, October 1996. 579 [5] T. Turletti, C. Huitema, "RTP Payload Format for H.261 Video 580 Streams", IETF RFC 2032, October 1996. 582 [6] H. Schulzrinne, et. al., "Real Time Streaming Protocol", IETF 583 Draft, draft-ietf-mmusic-rtsp-09.txt, February 2 1998, Expires: 584 August 2 1998. 586 [7] A. Jones, et. al., "RTP Payload Format for QuickTime Media 587 Streams", IETF Draft, draft-ietf-avt-qt-rtp-00.txt, July 22 1997, 588 Expires: January 22 1998. 590 [8] A. Klemets, "RTP Payload Format for ASF Streams", IETF Draft, 591 draft-klemets-asf-rtp-00.txt, October 8 1997, Expires: April 8 1998. 593 [9] M. Handley, "SDP: Session Description Protocol", IETF Draft, 594 draft-ietf-mmusic-sdp-05.txt, November 21 1997, Expires: November 21 595 1998. 597 Authors' Contact Information 598 Alagu Periyannan 599 Email: alagu@apple.com 600 Tel: +1 408 862 5387 602 David Singer 603 Email: singer@apple.com 604 Tel: +1 408 974 3162 606 Apple Computer, Inc. 607 One Infinite Loop, MS:302-3MT 608 Cupertino CA 95014 609 USA 611 Michael Speer 613 A. Periyannan, D. Singer, M. Speer [Page 13]^L 614 Email: michael.speer@sun.com 615 Tel: +1 650 786 6368 617 Sun Microsystems, Inc. 618 901 San Antonio Road, MS UMPK15-214 619 Palo Alto CA 94303 620 USA 622 A. Periyannan, D. Singer, M. Speer [Page 14]^L