idnits 2.17.1 draft-ietf-avt-rfc3555bis-part2-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1272. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1285. ** 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 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC3555, but the abstract doesn't seem to mention this, which it should. 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 (October 15, 2006) is 6403 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 4288 (ref. '2') (Obsoleted by RFC 6838) == Outdated reference: A later version (-05) exists of draft-ietf-avt-rfc3555bis-02 -- Duplicate reference: RFC3550, mentioned in '8', was also mentioned in '6'. Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Audio/Video Transport Working Group 3 INTERNET-DRAFT S. Casner 4 draft-ietf-avt-rfc3555bis-part2-02.txt Packet Design 5 Obsoletes: RFC 3555 (if approved) October 15, 2006 6 Expires: April 15, 2007 8 Media Type Registration of Payload Formats in the 9 RTP Profile for Audio and Video Conferences 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware have 15 been or will be disclosed, and any of which he or she becomes aware will 16 be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other groups 20 may also distribute working documents as Internet-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 material 25 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 April 15, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document specifies media type registrations for the RTP 42 payload formats defined in the RTP Profile for Audio and Video 43 Conferences. Some of these may also be used for transfer modes 44 other than RTP. 46 Table of Contents 48 1. Introduction .................................................. 3 49 1.1. IANA Considerations ...................................... 3 50 1.2. Terminology .............................................. 4 51 2. Registrations for "Audio/Video Profile" ....................... 4 52 2.1. Audio Type Registrations ................................. 4 53 2.2. Video Type Registrations ................................. 25 54 3. Changes from RFC 3555 ......................................... 26 55 4. Security Considerations ....................................... 26 56 5. References .................................................... 27 57 6. Author's Address .............................................. 28 58 7. Intellectual Property Statement ............................... 28 59 8. Disclaimer of Validity ........................................ 29 60 9. Copyright Statement ........................................... 29 62 1. Introduction 64 This document updates the media type registrations initially specified 65 in RFC 3555 for the Real-time Transport Protocol (RTP) payload formats 66 defined in the RTP Profile for Audio and Video Conferences, RFC 3551 67 [1], as subtypes under the "audio" and "video" media types. This 68 document does not include media type registrations for the RTP payload 69 formats that are referenced in RFC 3551 but defined in other RFCs. The 70 media type registrations for those payload formats are intended to be 71 updated by including them in revisions of the individual RFCs defining 72 the payload formats. 74 The media type registrations specified here conform to the updated 75 template format and procedures in RFC 4288 [2] and RFC XXXX [3]. This 76 update makes no technical changes in the registrations. Together with 77 RFC XXXX, this document obsoletes RFC 3555. 79 1.1. IANA Considerations 81 As a consequence of the generalized applicability of the media types 82 registry as specified in RFC 4288, some changes in nomenclature are 83 needed in the RTP Payload Format section of the registry. In the 84 registry title "RTP Payload Format MIME types" and the introductory 85 text, "MIME" should be changed to "media". "MIME" should be deleted from 86 the table headings, leaving just "media type" and "subtype". 88 This document updates the media type registrations listed below to 89 conform to the revised registration format specified in RFC 4288 and RFC 90 XXXX, so the reference for these media types should be changed from RFC 91 3555 to this document. Some media type registrations contained in RFC 92 3555 are omitted from this document; the existing registrations for 93 those types continue to be valid until updated by other RFCs. There are 94 no new registrations contained here. 96 audio/DVI4 97 audio/G722 98 audio/G723 99 audio/G726-16 100 audio/G726-24 101 audio/G726-32 102 audio/G726-40 103 audio/G728 104 audio/G729 105 audio/G729D 106 audio/G729E 107 audio/GSM 108 audio/GSM-EFR 109 audio/L8 110 audio/L16 111 audio/LPC 112 audio/PCMA 113 audio/PCMU 114 audio/VDVI 115 video/nv 117 Media type audio/L16 was initially registered via RFC 2586 for 118 transports other than RTP. That registration is incorporated here and 119 augmented with additional information for RTP transport. 121 1.2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [4] and indicate 126 requirement levels for implementations compliant with this 127 specification. 129 2. Registrations for "Audio/Video Profile" 131 In the following sections, the RTP payload formats defined in the RTP 132 Profile for Audio and Video Conferences, RFC 3551 [1], are registered as 133 media types. 135 2.1. Audio Type Registrations 137 For most audio payload formats, the RTP timestamp clock rate is equal to 138 the sampling rate. Some payload formats operate only at one fixed 139 sampling rate, while others are adjustable. 141 These audio formats also include the optional parameters "ptime", to 142 specify the recommended length of time in milliseconds represented by 143 the media in a packet, and "maxptime", to specify the maximum amount of 144 media that can be encapsulated in each packet, expressed as time in 145 milliseconds. The "ptime" and "maxptime" parameters are defined in the 146 Session Description Protocol (SDP), RFC ZZZZ [5]. 148 2.1.1. Registration of Media Type audio/DVI4 150 Type name: audio 152 Subtype name: DVI4 154 Required parameters: 155 rate: The RTP timestamp clock rate, which is equal to the 156 sampling rate. The typical rate is 8000, but other rates may 157 be specified. 159 Optional parameters: ptime, maxptime (see RFC ZZZZ) 161 Encoding considerations: 162 This media type is framed binary data (see Section 4.8 in RFC 163 4288). 165 Security considerations: 166 This media type does not carry active content. It does 167 transfer compressed data. See Section 4 of RFC YYYY. 169 Interoperability considerations: none 171 Published specification: RFC 3551 173 Applications which use this media type: 174 Audio and video streaming and conferencing tools. 176 Additional information: none 178 Person & email address to contact for further information: 179 Stephen Casner 181 Intended usage: COMMON 183 Restrictions on usage: 184 This media type depends on RTP framing, and hence is only 185 defined for transfer via RTP (RFC 3550 [6]). Transfer within 186 other framing protocols is not defined at this time. 188 Author: 189 Stephen Casner 191 Change controller: 192 IETF Audio/Video Transport working group delegated from the 193 IESG. 195 2.1.2. Registration of Media Type audio/G722 197 Type name: audio 199 Subtype name: G722 201 Required parameters: None 203 Optional parameters: ptime, maxptime (see RFC ZZZZ) 205 Encoding considerations: 206 This media type is framed binary data (see Section 4.8 in RFC 207 4288). 209 Security considerations: 210 This media type does not carry active content. It does 211 transfer compressed data. See Section 4 of RFC YYYY. 213 Interoperability considerations: none 215 Published specification: RFC 3551 217 Applications which use this media type: 218 Audio and video streaming and conferencing tools. 220 Additional information: none 222 Person & email address to contact for further information: 223 Stephen Casner 225 Intended usage: COMMON 227 Restrictions on usage: 228 This media type depends on RTP framing, and hence is only 229 defined for transfer via RTP (RFC 3550). Transfer within 230 other framing protocols is not defined at this time. 232 Author: 233 Stephen Casner 235 Change controller: 236 IETF Audio/Video Transport working group delegated from the 237 IESG. 239 2.1.3. Registration of Media Type audio/G723 241 Type name: audio 243 Subtype name: G723 245 Required parameters: None 247 Optional parameters: 248 ptime, maxptime: see RFC ZZZZ 250 bitrate: the data rate in kb/s used or preferred for the audio 251 bit stream, with permissible values 5.3 or 6.3. If 252 unspecified, the bitrate may change from frame to frame as 253 indicated inband. 255 annexa: indicates that Annex A, voice activity detection, is 256 used or preferred. Permissible values are "yes" and "no" 257 (without the quotes); "yes" is implied if this parameter is 258 omitted. 260 Encoding considerations: 261 This media type is framed binary data (see Section 4.8 in RFC 262 4288). 264 Security considerations: 265 This media type does not carry active content. It does 266 transfer compressed data. See Section 4 of RFC YYYY. 268 Interoperability considerations: none 270 Published specification: RFC 3551 272 Applications which use this media type: 273 Audio and video streaming and conferencing tools. 275 Additional information: none 277 Person & email address to contact for further information: 278 Stephen Casner 280 Intended usage: COMMON 282 Restrictions on usage: 283 This media type depends on RTP framing, and hence is only 284 defined for transfer via RTP (RFC 3550). Transfer within 285 other framing protocols is not defined at this time. 287 Author: 288 Stephen Casner 290 Change controller: 291 IETF Audio/Video Transport working group delegated from the 292 IESG. 294 2.1.4. Registration of Media Type audio/G726-16 296 Type name: audio 298 Subtype name: G726-16 300 Required parameters: None 302 Optional parameters: ptime, maxptime (see RFC ZZZZ) 304 Encoding considerations: 305 This media type is framed binary data (see Section 4.8 in RFC 306 4288). 308 Security considerations: 309 This media type does not carry active content. It does 310 transfer compressed data. See Section 4 of RFC YYYY. 312 Interoperability considerations: none 314 Published specification: RFC 3551 316 Applications which use this media type: 317 Audio and video streaming and conferencing tools. 319 Additional information: none 321 Person & email address to contact for further information: 322 Stephen Casner 324 Intended usage: COMMON 326 Restrictions on usage: 327 This media type depends on RTP framing, and hence is only 328 defined for transfer via RTP (RFC 3550). Transfer within 329 other framing protocols is not defined at this time. 331 Author: 332 Stephen Casner 334 Change controller: 335 IETF Audio/Video Transport working group delegated from the 336 IESG. 338 2.1.5. Registration of Media Type audio/G726-24 340 Type name: audio 342 Subtype name: G726-24 344 Required parameters: None 346 Optional parameters: ptime, maxptime (see RFC ZZZZ) 348 Encoding considerations: 349 This media type is framed binary data (see Section 4.8 in RFC 350 4288). 352 Security considerations: 353 This media type does not carry active content. It does 354 transfer compressed data. See Section 4 of RFC YYYY. 356 Interoperability considerations: none 358 Published specification: RFC 3551 360 Applications which use this media type: 361 Audio and video streaming and conferencing tools. 363 Additional information: none 365 Person & email address to contact for further information: 366 Stephen Casner 368 Intended usage: COMMON 370 Restrictions on usage: 371 This media type depends on RTP framing, and hence is only 372 defined for transfer via RTP (RFC 3550). Transfer within 373 other framing protocols is not defined at this time. 375 Author: 376 Stephen Casner 378 Change controller: 379 IETF Audio/Video Transport working group delegated from the 380 IESG. 382 2.1.6. Registration of Media Type audio/G726-32 384 Type name: audio 386 Subtype name: G726-32 388 Required parameters: None 390 Optional parameters: ptime, maxptime (see RFC ZZZZ) 392 Encoding considerations: 393 This media type is framed binary data (see Section 4.8 in RFC 394 4288). 396 Security considerations: 397 This media type does not carry active content. It does 398 transfer compressed data. See Section 4 of RFC YYYY. 400 Interoperability considerations: none 402 Published specification: RFC 3551 404 Applications which use this media type: 405 Audio and video streaming and conferencing tools. 407 Additional information: none 409 Person & email address to contact for further information: 410 Stephen Casner 412 Intended usage: COMMON 414 Restrictions on usage: 415 This media type depends on RTP framing, and hence is only 416 defined for transfer via RTP (RFC 3550). Transfer within 417 other framing protocols is not defined at this time. 419 Author: 420 Stephen Casner 422 Change controller: 423 IETF Audio/Video Transport working group delegated from the 424 IESG. 426 2.1.7. Registration of Media Type audio/G726-40 428 Type name: audio 429 Subtype name: G726-40 431 Required parameters: None 433 Optional parameters: ptime, maxptime (see RFC ZZZZ) 435 Encoding considerations: 436 This media type is framed binary data (see Section 4.8 in RFC 437 4288). 439 Security considerations: 440 This media type does not carry active content. It does 441 transfer compressed data. See Section 4 of RFC YYYY. 443 Interoperability considerations: none 445 Published specification: RFC 3551 447 Applications which use this media type: 448 Audio and video streaming and conferencing tools. 450 Additional information: none 452 Person & email address to contact for further information: 453 Stephen Casner 455 Intended usage: COMMON 457 Restrictions on usage: 458 This media type depends on RTP framing, and hence is only 459 defined for transfer via RTP (RFC 3550). Transfer within 460 other framing protocols is not defined at this time. 462 Author: 463 Stephen Casner 465 Change controller: 466 IETF Audio/Video Transport working group delegated from the 467 IESG. 469 2.1.8. Registration of Media Type audio/G728 471 Type name: audio 473 Subtype name: G728 475 Required parameters: None 476 Optional parameters: ptime, maxptime (see RFC ZZZZ) 478 Encoding considerations: 479 This media type is framed binary data (see Section 4.8 in RFC 480 4288). 482 Security considerations: 483 This media type does not carry active content. It does 484 transfer compressed data. See Section 4 of RFC YYYY. 486 Interoperability considerations: none 488 Published specification: RFC 3551 490 Applications which use this media type: 491 Audio and video streaming and conferencing tools. 493 Additional information: none 495 Person & email address to contact for further information: 496 Stephen Casner 498 Intended usage: COMMON 500 Restrictions on usage: 501 This media type depends on RTP framing, and hence is only 502 defined for transfer via RTP (RFC 3550). Transfer within 503 other framing protocols is not defined at this time. 505 Author: 506 Stephen Casner 508 Change controller: 509 IETF Audio/Video Transport working group delegated from the 510 IESG. 512 2.1.9. Registration of Media Type audio/G729 514 Type name: audio 516 Subtype name: G729 518 Required parameters: None 520 Optional parameters: 521 ptime, maxptime: see RFC ZZZZ 522 annexb: indicates that Annex B, voice activity detection, is 523 used or preferred. Permissible values are "yes" and "no" 524 (without the quotes); "yes" is implied if this parameter is 525 omitted. 527 Encoding considerations: 528 This media type is framed binary data (see Section 4.8 in RFC 529 4288). 531 Security considerations: 532 This media type does not carry active content. It does 533 transfer compressed data. See Section 4 of RFC YYYY. 535 Interoperability considerations: none 537 Published specification: RFC 3551 539 Applications which use this media type: 540 Audio and video streaming and conferencing tools. 542 Additional information: none 544 Person & email address to contact for further information: 545 Stephen Casner 547 Intended usage: COMMON 549 Restrictions on usage: 550 This media type depends on RTP framing, and hence is only 551 defined for transfer via RTP (RFC 3550). Transfer within 552 other framing protocols is not defined at this time. 554 Author: 555 Stephen Casner 557 Change controller: 558 IETF Audio/Video Transport working group delegated from the 559 IESG. 561 2.1.10. Registration of Media Type audio/G729D 563 Type name: audio 565 Subtype name: G729D 567 Required parameters: None 568 Optional parameters: 569 ptime, maxptime: see RFC ZZZZ 571 annexb: indicates that Annex B, voice activity detection, is 572 used or preferred. Permissible values are "yes" and "no" 573 (without the quotes); "yes" is implied if this parameter is 574 omitted. 576 Encoding considerations: 577 This media type is framed binary data (see Section 4.8 in RFC 578 4288). 580 Security considerations: 581 This media type does not carry active content. It does 582 transfer compressed data. See Section 4 of RFC YYYY. 584 Interoperability considerations: none 586 Published specification: RFC 3551 588 Applications which use this media type: 589 Audio and video streaming and conferencing tools. 591 Additional information: none 593 Person & email address to contact for further information: 594 Stephen Casner 596 Intended usage: COMMON 598 Restrictions on usage: 599 This media type depends on RTP framing, and hence is only 600 defined for transfer via RTP (RFC 3550). Transfer within 601 other framing protocols is not defined at this time. 603 Author: 604 Stephen Casner 606 Change controller: 607 IETF Audio/Video Transport working group delegated from the 608 IESG. 610 2.1.11. Registration of Media Type audio/G729E 612 Type name: audio 614 Subtype name: G729E 615 Required parameters: None 617 Optional parameters: 618 ptime, maxptime: see RFC ZZZZ 620 annexb: indicates that Annex B, voice activity detection, is 621 used or preferred. Permissible values are "yes" and "no" 622 (without the quotes); "yes" is implied if this parameter is 623 omitted. 625 Encoding considerations: 626 This media type is framed binary data (see Section 4.8 in RFC 627 4288). 629 Security considerations: 630 This media type does not carry active content. It does 631 transfer compressed data. See Section 4 of RFC YYYY. 633 Interoperability considerations: none 635 Published specification: RFC 3551 637 Applications which use this media type: 638 Audio and video streaming and conferencing tools. 640 Additional information: none 642 Person & email address to contact for further information: 643 Stephen Casner 645 Intended usage: COMMON 647 Restrictions on usage: 648 This media type depends on RTP framing, and hence is only 649 defined for transfer via RTP (RFC 3550). Transfer within 650 other framing protocols is not defined at this time. 652 Author: 653 Stephen Casner 655 Change controller: 656 IETF Audio/Video Transport working group delegated from the 657 IESG. 659 2.1.12. Registration of Media Type audio/GSM 661 Type name: audio 662 Subtype name: GSM 664 Required parameters: None 666 Optional parameters: ptime, maxptime (see RFC ZZZZ) 668 Encoding considerations: 669 This media type is framed binary data (see Section 4.8 in RFC 670 4288). 672 Security considerations: 673 This media type does not carry active content. It does 674 transfer compressed data. See Section 4 of RFC YYYY. 676 Interoperability considerations: none 678 Published specification: RFC 3551 680 Applications which use this media type: 681 Audio and video streaming and conferencing tools. 683 Additional information: none 685 Person & email address to contact for further information: 686 Stephen Casner 688 Intended usage: COMMON 690 Restrictions on usage: 691 This media type depends on RTP framing, and hence is only 692 defined for transfer via RTP (RFC 3550). Transfer within 693 other framing protocols is not defined at this time. 695 Author: 696 Stephen Casner 698 Change controller: 699 IETF Audio/Video Transport working group delegated from the 700 IESG. 702 2.1.13. Registration of Media Type audio/GSM-EFR 704 Type name: audio 706 Subtype name: GSM-EFR 708 Required parameters: None 709 Optional parameters: ptime, maxptime (see RFC ZZZZ) 711 Encoding considerations: 712 This media type is framed binary data (see Section 4.8 in RFC 713 4288). 715 Security considerations: 716 This media type does not carry active content. It does 717 transfer compressed data. See Section 4 of RFC YYYY. 719 Interoperability considerations: none 721 Published specification: RFC 3551 723 Applications which use this media type: 724 Audio and video streaming and conferencing tools. 726 Additional information: none 728 Person & email address to contact for further information: 729 Stephen Casner 731 Intended usage: COMMON 733 Restrictions on usage: 734 This media type depends on RTP framing, and hence is only 735 defined for transfer via RTP (RFC 3550). Transfer within 736 other framing protocols is not defined at this time. 738 Author: 739 Stephen Casner 741 Change controller: 742 IETF Audio/Video Transport working group delegated from the 743 IESG. 745 2.1.14. Registration of Media Type audio/L8 747 Type name: audio 749 Subtype name: L8 751 Required parameters: 752 rate: the RTP timestamp clock rate 754 Optional parameters: 755 channels: how many audio streams are interleaved -- defaults 756 to 1; stereo would be 2, etc. Interleaving takes place 757 between individual one-byte samples. The channel order is as 758 specified in RFC 3551. 760 ptime, maxptime: see RFC ZZZZ 762 Encoding considerations: 763 This media type is framed binary data (see Section 4.8 in RFC 764 4288). 766 Security considerations: 767 This media type does not carry active content. It does 768 transfer compressed data. See Section 4 of RFC YYYY. 770 Interoperability considerations: none 772 Published specification: RFC 3551 774 Applications which use this media type: 775 Audio and video streaming and conferencing tools. 777 Additional information: none 779 Person & email address to contact for further information: 780 Stephen Casner 782 Intended usage: COMMON 784 Restrictions on usage: 785 This media type depends on RTP framing, and hence is only 786 defined for transfer via RTP (RFC 3550). Transfer within 787 other framing protocols is not defined at this time. 789 Author: 790 Stephen Casner 792 Change controller: 793 IETF Audio/Video Transport working group delegated from the 794 IESG. 796 2.1.15. Registration of Media Type audio/L16 798 Media type audio/L16 was initially registered via RFC 2586 for 799 transports other than RTP. That registration is incorporated here and 800 augmented with additional information for RTP transport. 802 Type name: audio 803 Subtype name: L16 805 Required parameters 806 rate: number of samples per second -- For non-RTP transport, 807 the permissible values for rate are 8000, 11025, 16000, 22050, 808 24000, 32000, 44100, and 48000 samples per second. For RTP 809 transport, other values are permissible but the aforementioned 810 values are RECOMMENDED. For RTP, the rate parameter indicates 811 the RTP timestamp clock rate, which is equal to the sample 812 rate. 814 Optional parameters 815 channels: how many audio streams are interleaved -- defaults 816 to 1; stereo would be 2, etc. Interleaving takes place 817 between individual two-byte samples. The channel order is as 818 specified in RFC 3551 unless a channel-order parameter is also 819 present. 821 emphasis: analog preemphasis applied to the signal before 822 quantization. The only emphasis value defined here is 823 emphasis=50-15 to indicate the 50/15 microsecond preemphasis 824 used with Compact Disks. This parameter MUST be omitted if no 825 analog preemphasis was applied. Note that this is a stream 826 property parameter, not a receiver configuration parameter. 827 Thus, if parameters are negotiated, it may not be possible for 828 the sender to comply with a receiver request for a particular 829 setting. 831 channel-order: specifies the sample interleaving order for 832 multiple-channel audio streams (see RFC 3190 [7] Section 7). 833 Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, 834 DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, 835 DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc. 836 For interoperation with DV video systems, only a subset of 837 these channel combinations is specified for use with 20-bit 838 linear encoding in the DV video specification [9]; those are 839 DV.LRLsRs, DV.LRCS, DV.LmixRmixTWoQ1Q2. This parameter MUST 840 be omitted when the AIFF-C channel order convention (see RFC 841 3551) is in use. 843 For RTP, ptime: RECOMMENDED duration of each packet in 844 milliseconds. 846 For RTP, maxptime: maximum duration of each packet in 847 milliseconds. 849 Encoding considerations 850 Audio data is binary data, and must be encoded for non-binary 851 transport; the Base64 encoding is suitable for Email. Note 852 that audio data does not compress easily using lossless 853 compression. 855 Security considerations 856 Audio/L16 data is believed to offer no security risks. This 857 media type does not carry active content. The encoding is not 858 compressed. See Section 4 of RFC YYYY. 860 Interoperability considerations 861 This type is compatible with the encoding used in the WAV 862 (Microsoft Windows RIFF) and Apple AIFF union types, and with 863 the public domain "sox" and "rateconv" programs. 865 Published specification 866 RFC 2586 for non-RTP transports, RFC 3551 for RTP 868 Applications which use this media 869 The public domain "sox" and "rateconv" programs accept this 870 type. 872 Magic number(s) : None 873 File extension(s) : WAV L16 874 Macintosh file type code : AIFF 876 Person to contact for further information 877 Name : James Salsman 878 E-mail : jps-L16@bovik.org 880 Intended usage 881 Common 883 It is expected that many audio and speech applications will 884 use this type. Already the most popular platforms provide 885 this type with the rate=11025 parameter referred to as "radio 886 quality speech." 888 Restrictions on usage 889 In addition to file-based transfer methods, this type is also 890 defined for transfer via RTP (RFC 3550). 892 Author 893 James Salsman for non-RTP transports. 894 Stephen Casner for RTP transport. 896 Change controller 897 James Salsman for non-RTP transports. 898 For RTP transport, IETF Audio/Video Transport working group 899 delegated from the IESG. 901 2.1.16. Registration of Media Type audio/LPC 903 Type name: audio 905 Subtype name: LPC 907 Required parameters: None 909 Optional parameters: ptime, maxptime (see RFC ZZZZ) 911 Encoding considerations: 912 This media type is framed binary data (see Section 4.8 in RFC 913 4288). 915 Security considerations: 916 This media type does not carry active content. It does 917 transfer compressed data. See Section 4 of RFC YYYY. 919 Interoperability considerations: none 921 Published specification: RFC 3551 923 Applications which use this media type: 924 Audio and video streaming and conferencing tools. 926 Additional information: none 928 Person & email address to contact for further information: 929 Stephen Casner 931 Intended usage: COMMON 933 Restrictions on usage: 934 This media type depends on RTP framing, and hence is only 935 defined for transfer via RTP (RFC 3550). Transfer within 936 other framing protocols is not defined at this time. 938 Author: 939 Stephen Casner 941 Change controller: 942 IETF Audio/Video Transport working group delegated from the 943 IESG. 945 2.1.17. Registration of Media Type audio/PCMA 947 Type name: audio 949 Subtype name: PCMA 951 Required parameters: 952 rate: The RTP timestamp clock rate, which is equal to the 953 sampling rate. The typical rate is 8000, but other rates may 954 be specified. 956 Optional parameters: 957 channels: how many audio streams are interleaved -- defaults 958 to 1; stereo would be 2, etc. Interleaving takes place 959 between individual one-byte samples. The channel order is as 960 specified in RFC 3551. 962 ptime, maxptime: see RFC ZZZZ 964 Encoding considerations: 965 This media type is framed binary data (see Section 4.8 in RFC 966 4288). 968 Security considerations: 969 This media type does not carry active content. It does 970 transfer compressed data. See Section 4 of RFC YYYY. 972 Interoperability considerations: none 974 Published specification: RFC 3551 976 Applications which use this media type: 977 Audio and video streaming and conferencing tools. 979 Additional information: none 981 Person & email address to contact for further information: 982 Stephen Casner 984 Intended usage: COMMON 986 Restrictions on usage: 987 This media type depends on RTP framing, and hence is only 988 defined for transfer via RTP (RFC 3550). Transfer within 989 other framing protocols is not defined at this time. 991 Author: 992 Stephen Casner 994 Change controller: 995 IETF Audio/Video Transport working group delegated from the 996 IESG. 998 2.1.18. Registration of Media Type audio/PCMU 1000 Type name: audio 1002 Subtype name: PCMU 1004 Required parameters: 1005 rate: The RTP timestamp clock rate, which is equal to the 1006 sampling rate. The typical rate is 8000, but other rates may 1007 be specified. 1009 Optional parameters: 1010 channels: how many audio streams are interleaved -- defaults 1011 to 1; stereo would be 2, etc. Interleaving takes place 1012 between individual one-byte samples. The channel order is as 1013 specified in RFC 3551. 1015 ptime, maxptime: see RFC ZZZZ 1017 Encoding considerations: 1018 This media type is framed binary data (see Section 4.8 in RFC 1019 4288). 1021 Security considerations: 1022 This media type does not carry active content. It does 1023 transfer compressed data. See Section 4 of RFC YYYY. 1025 Interoperability considerations: none 1027 Published specification: RFC 3551 1029 Applications which use this media type: 1030 Audio and video streaming and conferencing tools. 1032 Additional information: none 1034 Person & email address to contact for further information: 1035 Stephen Casner 1037 Intended usage: COMMON 1039 Restrictions on usage: 1040 This media type depends on RTP framing, and hence is only 1041 defined for transfer via RTP (RFC 3550). Transfer within 1042 other framing protocols is not defined at this time. 1044 Author: 1045 Stephen Casner 1047 Change controller: 1048 IETF Audio/Video Transport working group delegated from the 1049 IESG. 1051 2.1.19. Registration of Media Type audio/VDVI 1053 Type name: audio 1055 Subtype name: VDVI 1057 Required parameters: None 1059 Optional parameters: ptime, maxptime (see RFC ZZZZ) 1061 Encoding considerations: 1062 This media type is framed binary data (see Section 4.8 in RFC 1063 4288). 1065 Security considerations: 1066 This media type does not carry active content. It does 1067 transfer compressed data. See Section 4 of RFC YYYY. 1069 Interoperability considerations: none 1071 Published specification: RFC 3551 1073 Applications which use this media type: 1074 Audio and video streaming and conferencing tools. 1076 Additional information: none 1078 Person & email address to contact for further information: 1079 Stephen Casner 1081 Intended usage: COMMON 1083 Restrictions on usage: 1084 This media type depends on RTP framing, and hence is only 1085 defined for transfer via RTP (RFC 3550). Transfer within 1086 other framing protocols is not defined at this time. 1088 Author: 1089 Stephen Casner 1091 Change controller: 1092 IETF Audio/Video Transport working group delegated from the 1093 IESG. 1095 2.2. Video Type Registrations 1097 For most video payload formats, including the one registered here, the 1098 RTP timestamp clock rate is always 90000 Hz, so the "rate" parameter is 1099 not applicable. Likewise, the "channel" parameter is not used with 1100 video, while "ptime" and "maxptime" could be but typically are not. 1102 2.2.1. Registration of Media Type video/nv 1104 Type name: video 1106 Subtype name: nv 1108 Required parameters: None 1110 Optional parameters: None 1112 Encoding considerations: 1113 This media type is framed binary data (see Section 4.8 in RFC 1114 4288). 1116 Security considerations: 1117 This media type does not carry active content. It does 1118 transfer compressed data. See Section 4 of RFC YYYY. 1120 Interoperability considerations: none 1122 Published specification: RFC 3551 1124 Applications which use this media type: 1125 Audio and video streaming and conferencing tools. 1127 Additional information: none 1129 Person & email address to contact for further information: 1130 Stephen Casner 1132 Intended usage: COMMON 1134 Restrictions on usage: 1135 This media type depends on RTP framing, and hence is only 1136 defined for transfer via RTP (RFC 3550). Transfer within 1137 other framing protocols is not defined at this time. 1139 Author: 1140 Stephen Casner 1142 Change controller: 1143 IETF Audio/Video Transport working group delegated from the 1144 IESG. 1146 3. Changes from RFC 3555 1148 RFC 3555 is obsoleted by the combination of RFC XXXX [3] and this 1149 document. RFC XXXX retains the specification of procedures and 1150 requirements from RFC 3555, while the media type registrations from RFC 1151 3555 were extracted into this document. The media type registrations 1152 for the RTP payload formats that are referenced in RFC 3551 [1] but 1153 defined in other RFCs have been elided from this document because those 1154 registrations are intended to be updated by including them in revisions 1155 of the individual RFCs defining the payload formats. 1157 The media type registrations in this document have been updated to 1158 conform to the revised media type registration procedures in RFC 4288 1159 [2] and RFC XXXX. Whereas RFC 3555 required the encoding considerations 1160 to specify transfer via RTP, that is now specified under restrictions on 1161 usage. The encoding considerations now warn that these types are framed 1162 binary data. The change controller is also now identified according to 1163 current conventions. The optional parameter "channels" was clarified 1164 for audio subtypes L8, PCMA, and PCMU. Finally, reference [9], which 1165 was missing from RFC 3555, has been corrected. 1167 4. Security Considerations 1169 This memo specifies media type registrations for the transfer of several 1170 compressed audio and video data encodings via RTP, so implementations 1171 using these media types are subject to the security considerations 1172 discussed in the RTP specification [8]. 1174 None of these media types carry "active content" that could impose 1175 malicious side-effects upon the receiver. The content consists solely 1176 of compressed audio or video data to be decoded and presented as sound 1177 or images. However, several audio and video encodings are perfect for 1178 hiding data using steganography. 1180 A potential denial-of-service threat exists for data encodings using 1181 compression techniques that have non-uniform receiver-end computational 1182 load. The attacker can inject pathological datagrams into the stream 1183 which are complex to decode and cause the receiver to be overloaded. 1184 However, none of the encodings registered here has an expansion factor 1185 greater than about 20, and all are considered relatively simple by 1186 modern standards (some are implemented on handheld devices and most were 1187 implemented on general-purpose computers ten years ago). 1189 As with any IP-based protocol, in some circumstances a receiver may be 1190 overloaded simply by the receipt of too many packets, either desired or 1191 undesired. Network-layer authentication MAY be used to discard packets 1192 from undesired sources, but the processing cost of the authentication 1193 itself may be too high. 1195 RTP may be sent via IP multicast, which provides no direct means for a 1196 sender to know all the receivers of the data sent and therefore no 1197 measure of privacy. Rightly or not, users may be more sensitive to 1198 privacy concerns with audio and video communication than they have been 1199 with more traditional forms of network communication. Therefore, the 1200 use of security mechanisms with RTP to provide confidentiality and 1201 integrity of the data is important. Because the data compression used 1202 with these media types is applied end-to-end, encryption may be 1203 performed after compression so there is no conflict between the two 1204 operations. 1206 5. References 1208 5.1. Normative References 1210 [1] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 1211 Conferences with Minimal Control", RFC 3551, July 2003. 1213 [2] Freed, N. and J. Klensin, "Media Type Specifications and 1214 Registration Procedures", BCP 13, RFC 4288, December, 2005. 1216 [3] Casner, S., "Media Type Registration of RTP Payload Types", 1217 draft-ietf-avt-rfc3555bis-02.txt, February 2006. 1218 (Companion to this document, referenced herein as RFC XXXX). 1220 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1221 Levels", BCP 14, RFC 2119, March 1997. 1223 [5] Handley, M., V. Jacobson and C. Perkins, "SDP: Session Description 1224 Protocol", draft-ietf-mmusic-sdp-new-26.txt, January 2006. 1225 (Approved for publication as Proposed Standard to obsolete 1226 RFC 2327, so this reference should be to the RFC when published 1227 and that number inserted where RFC ZZZZ appears in this document) 1229 [6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: 1230 A Transport Protocol for Real-Time Applications", RFC 3550, July 1231 2003. 1233 [7] Kobayashi, K., Ogawa, A., Casner, S. and C. Bormann, "RTP Payload 1234 Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled 1235 Audio", RFC 3190, January 2002. 1237 [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: 1238 A Transport Protocol for Real-Time Applications", RFC 3550, July 1239 2003. 1241 5.2. Informative References 1243 [9] IEC 61834, Helical-scan digital video cassette recording system 1244 using 6,35 mm magnetic tape for consumer use (525-60, 625-50, 1245 1125-60 and 1250-50 systems), August 1998. 1247 [Note to RFC Editor: References in the media type registrations to RFC 1248 YYYY are to be replaced with the RFC number of this document itself. 1249 The purpose of the self-references is to make the registrations complete 1250 when extracted.] 1252 6. Author's Address 1254 Stephen L. Casner 1255 Packet Design 1256 3400 Hillview Avenue, Building 3 1257 Palo Alto, CA 94304 1258 United States 1260 Phone: +1 650 739-1843 1261 EMail: casner@acm.org 1263 7. Intellectual Property Statement 1265 The IETF takes no position regarding the validity or scope of any 1266 Intellectual Property Rights or other rights that might be claimed to 1267 pertain to the implementation or use of the technology described in this 1268 document or the extent to which any license under such rights might or 1269 might not be available; nor does it represent that it has made any 1270 independent effort to identify any such rights. Information on the 1271 procedures with respect to rights in RFC documents can be found in BCP 1272 78 and BCP 79. 1274 Copies of IPR disclosures made to the IETF Secretariat and any 1275 assurances of licenses to be made available, or the result of an attempt 1276 made to obtain a general license or permission for the use of such 1277 proprietary rights by implementers or users of this specification can be 1278 obtained from the IETF on-line IPR repository at 1279 http://www.ietf.org/ipr. 1281 The IETF invites any interested party to bring to its attention any 1282 copyrights, patents or patent applications, or other proprietary rights 1283 that may cover technology that may be required to implement this 1284 standard. Please address the information to the IETF at ietf- 1285 ipr@ietf.org. 1287 8. Disclaimer of Validity 1289 This document and the information contained herein are provided on an 1290 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 1291 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1292 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1293 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1294 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1295 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1297 9. Copyright Statement 1299 Copyright (C) The Internet Society (2006). 1301 This document is subject to the rights, licenses and restrictions 1302 contained in BCP 78, and except as set forth therein, the authors retain 1303 all their rights.