idnits 2.17.1 draft-ietf-avt-profile-new-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 an Authors' Addresses Section. ** There are 36 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 358 has weird spacing: '...hannels descr...' == Line 366 has weird spacing: '... lc c r...' == Line 476 has weird spacing: '...ncoding sampl...' == Line 498 has weird spacing: '...A: not appli...' == Line 629 has weird spacing: '... bits conte...' == (3 more instances...) -- 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 (June 25, 1999) is 9071 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 1427 looks like a reference -- Missing reference section? '2' on line 1432 looks like a reference -- Missing reference section? '5' on line 1443 looks like a reference -- Missing reference section? '3' on line 1435 looks like a reference -- Missing reference section? '4' on line 1439 looks like a reference -- Missing reference section? '6' on line 1447 looks like a reference -- Missing reference section? '7' on line 1450 looks like a reference -- Missing reference section? '8' on line 1455 looks like a reference -- Missing reference section? '9' on line 1459 looks like a reference -- Missing reference section? '10' on line 1463 looks like a reference -- Missing reference section? '11' on line 1628 looks like a reference -- Missing reference section? '12' on line 1473 looks like a reference -- Missing reference section? '13' on line 1479 looks like a reference -- Missing reference section? '14' on line 1483 looks like a reference -- Missing reference section? '15' on line 1486 looks like a reference -- Missing reference section? '0' on line 853 looks like a reference -- Missing reference section? '22' on line 1513 looks like a reference -- Missing reference section? '23' on line 1517 looks like a reference -- Missing reference section? '24' on line 1521 looks like a reference -- Missing reference section? '25' on line 1525 looks like a reference -- Missing reference section? '26' on line 1531 looks like a reference -- Missing reference section? '27' on line 1535 looks like a reference -- Missing reference section? '28' on line 1539 looks like a reference -- Missing reference section? '29' on line 852 looks like a reference -- Missing reference section? '30' on line 853 looks like a reference -- Missing reference section? '31' on line 854 looks like a reference -- Missing reference section? '32' on line 855 looks like a reference -- Missing reference section? '33' on line 856 looks like a reference -- Missing reference section? '34' on line 857 looks like a reference -- Missing reference section? '35' on line 858 looks like a reference -- Missing reference section? '36' on line 859 looks like a reference -- Missing reference section? '37' on line 860 looks like a reference -- Missing reference section? '38' on line 861 looks like a reference -- Missing reference section? '39' on line 866 looks like a reference -- Missing reference section? '40' on line 867 looks like a reference -- Missing reference section? '41' on line 868 looks like a reference -- Missing reference section? '42' on line 869 looks like a reference -- Missing reference section? '43' on line 870 looks like a reference -- Missing reference section? '44' on line 871 looks like a reference -- Missing reference section? '45' on line 872 looks like a reference -- Missing reference section? '16' on line 1489 looks like a reference -- Missing reference section? '46' on line 873 looks like a reference -- Missing reference section? '17' on line 1493 looks like a reference -- Missing reference section? '47' on line 874 looks like a reference -- Missing reference section? '18' on line 1497 looks like a reference -- Missing reference section? '48' on line 875 looks like a reference -- Missing reference section? '19' on line 1500 looks like a reference -- Missing reference section? '49' on line 876 looks like a reference -- Missing reference section? '20' on line 1505 looks like a reference -- Missing reference section? '50' on line 877 looks like a reference -- Missing reference section? '21' on line 1509 looks like a reference -- Missing reference section? '51' on line 878 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 55 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force AVT WG 2 Internet Draft Schulzrinne/Casner 3 draft-ietf-avt-profile-new-06.txt Columbia U./Cisco Systems 4 June 25, 1999 5 Expires: December 25, 1999 7 RTP Profile for Audio and Video Conferences with Minimal Control 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This memorandum is a revision of RFC 1890 in preparation for 34 advancement from Proposed Standard to Draft Standard status. Readers 35 are encouraged to use the PostScript form of this draft to see where 36 changes from RFC 1890 are marked by change bars. 38 This document describes a profile called "RTP/AVP" for the use of the 39 real-time transport protocol (RTP), version 2, and the associated 40 control protocol, RTCP, within audio and video multiparticipant 41 conferences with minimal control. It provides interpretations of 42 generic fields within the RTP specification suitable for audio and 43 video conferences. In particular, this document defines a set of 44 default mappings from payload type numbers to encodings. 46 This document also describes how audio and video data may be carried 47 within RTP. It defines a set of standard encodings and their names 48 when used within RTP. The descriptions provide pointers to reference 49 implementations and the detailed standards. This document is meant as 50 an aid for implementors of audio, video and other real-time 51 multimedia applications. 53 Resolution of Open Issues 55 [Note to the RFC Editor: This section is to be deleted when this 56 draft is published as an RFC but is shown here for reference during 57 the Last Call. The first paragraph of the Abstract is also to be 58 deleted. All RFC XXXX should be filled in with the number of the RTP 59 specification RFC submitted for Draft Standard status, and all RFC 60 YYYY should be filled in with the number of the draft specifying MIME 61 registration of RTP payload types as it is submitted for Proposed 62 Standard status. These latter references are intended to be non- 63 normative.] 65 Readers are directed to Appendix 9, Changes from RFC 1890, for a 66 listing of the changes that have been made in this draft. The 67 changes from RFC 1890 are marked with change bars in the PostScript 68 form of this draft. 70 The revisions in this draft are intended to be complete for Last 71 Call. The following open issues from previous drafts have been 72 addressed: 74 o The procedure for registering RTP encoding names as MIME 75 subtypes was moved to a separate RFC-to-be that may also serve 76 to specify how (some of) the encodings here may be used with 77 mail and other not-RTP transports. That procedure is not 78 required to implement this profile, but may be used in those 79 contexts where it is needed. 81 o This profile follows the suggestion in the RTP spec that RTCP 82 bandwidth may be specified separately from the session 83 bandwidth and separately for active senders and passive 84 receivers. 86 o No specific action is taken in this document to address 87 generic payload formats; it is assumed that if any generic 88 payload formats are developed, they can be specified in 89 separate RFCs and that the session parameters they require for 90 operation can be specified in the MIME registration of those 91 formats. 93 1 Introduction 94 This profile defines aspects of RTP left unspecified in the RTP 95 Version 2 protocol definition (RFC XXXX) [1]. This profile is 96 intended for the use within audio and video conferences with minimal 97 session control. In particular, no support for the negotiation of 98 parameters or membership control is provided. The profile is expected 99 to be useful in sessions where no negotiation or membership control 100 are used (e.g., using the static payload types and the membership 101 indications provided by RTCP), but this profile may also be useful in 102 conjunction with a higher-level control protocol. 104 Use of this profile may be implicit in the use of the appropriate 105 applications; there may be no explicit indication by port number, 106 protocol identifier or the like. Applications such as session 107 directories should refer to this profile as "RTP/AVP". 109 Other profiles may make different choices for the items specified 110 here. 112 This document also defines a set of encodings and payload formats for 113 audio and video. 115 1.1 Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [2] and 120 indicate requirement levels for implementations compliant with this 121 RTP profile. 123 This draft defines the term media type as dividing encodings of audio 124 and video content into three classes: audio, video and audio/video 125 (interleaved). 127 2 RTP and RTCP Packet Forms and Protocol Behavior 129 The section "RTP Profiles and Payload Format Specification" of RFC 130 XXXX enumerates a number of items that can be specified or modified 131 in a profile. This section addresses these items. Generally, this 132 profile follows the default and/or recommended aspects of the RTP 133 specification. 135 RTP data header: The standard format of the fixed RTP data 136 header is used (one marker bit). 138 Payload types: Static payload types are defined in Section 6. 140 RTP data header additions: No additional fixed fields are 141 appended to the RTP data header. 143 RTP data header extensions: No RTP header extensions are 144 defined, but applications operating under this profile MAY 145 use such extensions. Thus, applications SHOULD NOT assume 146 that the RTP header X bit is always zero and SHOULD be 147 prepared to ignore the header extension. If a header 148 extension is defined in the future, that definition MUST 149 specify the contents of the first 16 bits in such a way 150 that multiple different extensions can be identified. 152 RTCP packet types: No additional RTCP packet types are defined 153 by this profile specification. 155 RTCP report interval: The suggested constants are to be used for 156 the RTCP report interval calculation. Sessions operating 157 under this profile MAY specify a separate parameter for the 158 RTCP traffic bandwidth rather than using the default 159 fraction of the session bandwidth. The RTCP traffic 160 bandwidth MAY be divided into two separate session 161 parameters for those participants which are active data 162 senders and those which are not. Following the 163 recommendation in the RTP specification [1] that 1/4 of the 164 RTCP bandwidth be dedicated to data senders, the 165 RECOMMENDED default values for these two parameters would 166 be 1.25% and 3.75%, respectively. For a particular session, 167 the RTCP bandwidth for non-data-senders MAY be set to zero 168 when operating on unidirectional links or for sessions that 169 don't require feedback on the quality of reception. The 170 RTCP bandwidth for data senders SHOULD be kept non-zero so 171 that sender reports can still be sent for inter-media 172 synchronization and to identify the source by CNAME. The 173 means by which the one or two session parameters for RTCP 174 bandwidth are specified is beyond the scope of this memo. 176 SR/RR extension: No extension section is defined for the RTCP SR 177 or RR packet. 179 SDES use: Applications MAY use any of the SDES items described 180 in the RTP specification. While CNAME information MUST be 181 sent every reporting interval, other items SHOULD only be 182 sent every third reporting interval, with NAME sent seven 183 out of eight times within that slot and the remaining SDES 184 items cyclically taking up the eighth slot, as defined in 185 Section 6.2.2 of the RTP specification. In other words, 186 NAME is sent in RTCP packets 1, 4, 7, 10, 13, 16, 19, 187 while, say, EMAIL is used in RTCP packet 22. 189 Security: The RTP default security services are also the default 190 under this profile. 192 String-to-key mapping: A user-provided string ("pass phrase") is 193 hashed with the MD5 algorithm to a 16-octet digest. An n- 194 bit key is extracted from the digest by taking the first n 195 bits from the digest. If several keys are needed with a 196 total length of 128 bits or less (as for triple DES), they 197 are extracted in order from that digest. The octet ordering 198 is specified in RFC 1423, Section 2.2. (Note that some DES 199 implementations require that the 56-bit key be expanded 200 into 8 octets by inserting an odd parity bit in the most 201 significant bit of the octet to go with each 7 bits of the 202 key.) 204 It is RECOMMENDED that pass phrases be restricted to ASCII 205 letters, digits, the hyphen, and white space to reduce the 206 the chance of transcription errors when conveying keys by 207 phone, fax, telex or email. 209 The pass phrase MAY be preceded by a specification of the 210 encryption algorithm. Any characters up to the first slash 211 (ASCII 0x2f) are taken as the name of the encryption 212 algorithm. The encryption format specifiers SHOULD be drawn 213 from RFC 1423 or any additional identifiers registered with 214 IANA. If no slash is present, DES-CBC is assumed as 215 default. The encryption algorithm specifier is case 216 sensitive. 218 The pass phrase typed by the user is transformed to a 219 canonical form before applying the hash algorithm. For that 220 purpose, we define `white space' to be the ASCII space, 221 formfeed, newline, carriage return, tab, or vertical tab as 222 well as all characters contained in the Unicode space 223 characters table. The transformation consists of the 224 following steps: (1) convert the input string to the ISO 225 10646 character set, using the UTF-8 encoding as specified 226 in Annex P to ISO/IEC 10646-1:1993 (ASCII characters 227 require no mapping, but ISO 8859-1 characters do); (2) 228 remove leading and trailing white space characters; (3) 229 replace one or more contiguous white space characters by a 230 single space (ASCII or UTF-8 0x20); (4) convert all letters 231 to lower case and replace sequences of characters and non- 232 spacing accents with a single character, where possible. A 233 minimum length of 16 key characters (after applying the 234 transformation) SHOULD be enforced by the application, 235 while applications MUST allow up to 256 characters of 236 input. 238 Underlying protocol: The profile specifies the use of RTP over 239 unicast and multicast UDP as well as TCP. (This does not 240 preclude the use of these definitions when RTP is carried 241 by other lower-layer protocols.) 243 Transport mapping: The standard mapping of RTP and RTCP to 244 transport-level addresses is used. 246 Encapsulation: A minimal TCP encapsulation is defined. 248 3 Registering Additional Encodings with IANA 250 This profile lists a set of encodings, each of which is comprised of 251 a particular media data compression or representation plus a payload 252 format for encapsulation within RTP. Some of those payload formats 253 are specified here, while others are specified in separate RFCs. It 254 is expected that additional encodings beyond the set listed here will 255 be created in the future and specified in additional payload format 256 RFCs. 258 This profile also assigns to each encoding a short name which MAY be 259 used by higher-level control protocols, such as the Session 260 Description Protocol (SDP), RFC 2327 [5], to identify encodings 261 selected for a particular RTP session. 263 In some contexts it may be useful to refer to these encodings in the 264 form of a MIME content-type. To facilitate this, RFC YYYY [3] 265 provides registrations for all of the encodings names listed here as 266 MIME subtype names under the "audio" and "video" MIME types through 267 the MIME registration procedure as specified in RFC 2048 [4]. 269 Any additional encodings specified for use under this profile (or 270 others) may also be assigned names registered as MIME subtypes with 271 the Internet Assigned Numbers Authority (IANA). This registry 272 provides a means to insure that the names assigned to the additional 273 encodings are kept unique. RFC YYYY specifies the information that is 274 required for the registration of RTP encodings. 276 In addition to assigning names to encodings, this profile also also 277 assigns static RTP payload type numbers to some of them. However, the 278 payload type number space is relatively small and cannot accommodate 279 assignments for all existing and future encodings. During the early 280 stages of RTP development, it was necessary to use statically 281 assigned payload types because no other mechanism had been specified 282 to bind encodings to payload types. It was anticipated that non-RTP 283 means beyond the scope of this memo (such as directory services or 284 invitation protocols) would be specified to establish a dynamic 285 mapping between a payload type and an encoding. Now, mechanisms for 286 defining dynamic payload type bindings have been specified in the 287 Session Description Protocol (SDP) and in other protocols such as 288 ITU-T recommendation H.323/H.245. These mechanisms associate the 289 registered name of the encoding/payload format, along with any 290 additional required parameters such as the RTP timestamp clock rate 291 and number of channels, to a payload type number. This association 292 is effective only for the duration of the RTP session in which the 293 dynamic payload type binding is made. This association applies only 294 to the RTP session for which it is made, thus the numbers can be re- 295 used for different encodings in different sessions so the number 296 space limitation is avoided. 298 This profile reserves payload type numbers in the range 96-127 299 exclusively for dynamic assignment. Applications should first use 300 values in this range for dynamic payload types. Only applications 301 which need to define more than 32 dynamic payload types MAY bind 302 codes below 96, in which case it is RECOMMENDED that unassigned 303 payload type numbers be used first. However, the statically assigned 304 payload types are default bindings and MAY be dynamically bound to 305 new encodings if needed. Redefining payload types below 96 may cause 306 incorrect operation if an attempt is made to join a session without 307 obtaining session description information that defines the dynamic 308 payload types. 310 Dynamic payload types SHOULD NOT be used without a well-defined 311 mechanism to indicate the mapping. Systems that expect to 312 interoperate with others operating under this profile SHOULD NOT make 313 their own assignments of proprietary encodings to particular, fixed 314 payload types. 316 This specification establishes the policy that no additional static 317 payload types will be assigned beyond the ones defined in this 318 document. Establishing this policy avoids the problem of trying to 319 create a set of criteria for accepting static assignments and 320 encourages the implementation and deployment of the dynamic payload 321 type mechanisms. 323 4 Audio 325 4.1 Encoding-Independent Rules 327 For applications which send either no packets or comfort-noise 328 packets during silence, the first packet of a talkspurt, that is, the 329 first packet after a silence period, SHOULD be distinguished by 330 setting the marker bit in the RTP data header to one. The marker bits 331 in all other packets is zero. The beginning of a talkspurt MAY be 332 used to adjust the playout delay to reflect changing network delays. 333 Applications without silence suppression MUST set the marker bit to 334 zero. 336 The RTP clock rate used for generating the RTP timestamp is 337 independent of the number of channels and the encoding; it equals the 338 number of sampling periods per second. For N-channel encodings, each 339 sampling period (say, 1/8000 of a second) generates N samples. (This 340 terminology is standard, but somewhat confusing, as the total number 341 of samples generated per second is then the sampling rate times the 342 channel count.) 344 If multiple audio channels are used, channels are numbered left-to- 345 right, starting at one. In RTP audio packets, information from 346 lower-numbered channels precedes that from higher-numbered channels. 347 For more than two channels, the convention followed by the AIFF-C 348 audio interchange format SHOULD be followed [6], using the following 349 notation: 351 l left 352 r right 353 c center 354 S surround 355 F front 356 R rear 358 channels description channel 359 1 2 3 4 5 6 360 __________________________________________________ 361 2 stereo l r 362 3 l r c 363 4 quadrophonic Fl Fr Rl Rr 364 4 l c r S 365 5 Fl Fr Fc Sl Sr 366 6 l lc c r rc S 368 Samples for all channels belonging to a single sampling instant MUST 369 be within the same packet. The interleaving of samples from different 370 channels depends on the encoding. General guidelines are given in 371 Section 4.3 and 4.4. 373 The sampling frequency SHOULD be drawn from the set: 8000, 11025, 374 16000, 22050, 24000, 32000, 44100 and 48000 Hz. (Older Apple 375 Macintosh computers had a native sample rate of 22254.54 Hz, which 376 can be converted to 22050 with acceptable quality by dropping 4 377 samples in a 20 ms frame.) However, most audio encodings are defined 378 for a more restricted set of sampling frequencies. Receivers SHOULD 379 be prepared to accept multi-channel audio, but MAY choose to only 380 play a single channel. 382 4.2 Operating Recommendations 384 The following recommendations are default operating parameters. 385 Applications SHOULD be prepared to handle other values. The ranges 386 given are meant to give guidance to application writers, allowing a 387 set of applications conforming to these guidelines to interoperate 388 without additional negotiation. These guidelines are not intended to 389 restrict operating parameters for applications that can negotiate a 390 set of interoperable parameters, e.g., through a conference control 391 protocol. 393 For packetized audio, the default packetization interval SHOULD have 394 a duration of 20 ms or one frame, whichever is longer, unless 395 otherwise noted in Table 1 (column "ms/packet"). The packetization 396 interval determines the minimum end-to-end delay; longer packets 397 introduce less header overhead but higher delay and make packet loss 398 more noticeable. For non-interactive applications such as lectures or 399 for links with severe bandwidth constraints, a higher packetization 400 delay MAY be used. A receiver SHOULD accept packets representing 401 between 0 and 200 ms of audio data. (For framed audio encodings, a 402 receiver SHOULD accept packets with a number of frames equal to 200 403 ms divided by the frame duration, rounded up.) This restriction 404 allows reasonable buffer sizing for the receiver. 406 4.3 Guidelines for Sample-Based Audio Encodings 408 In sample-based encodings, each audio sample is represented by a 409 fixed number of bits. Within the compressed audio data, codes for 410 individual samples may span octet boundaries. An RTP audio packet may 411 contain any number of audio samples, subject to the constraint that 412 the number of bits per sample times the number of samples per packet 413 yields an integral octet count. Fractional encodings produce less 414 than one octet per sample. 416 The duration of an audio packet is determined by the number of 417 samples in the packet. 419 For sample-based encodings producing one or more octets per sample, 420 samples from different channels sampled at the same sampling instant 421 SHOULD be packed in consecutive octets. For example, for a two- 422 channel encoding, the octet sequence is (left channel, first sample), 423 (right channel, first sample), (left channel, second sample), (right 424 channel, second sample), .... For multi-octet encodings, octets 425 SHOULD be transmitted in network byte order (i.e., most significant 426 octet first). 428 The packing of sample-based encodings producing less than one octet 429 per sample is encoding-specific. 431 The RTP timestamp reflects the instant at which the first sample in 432 the packet was sampled, that is, the oldest information in the 433 packet. 435 4.4 Guidelines for Frame-Based Audio Encodings 437 Frame-based encodings encode a fixed-length block of audio into 438 another block of compressed data, typically also of fixed length. For 439 frame-based encodings, the sender MAY choose to combine several such 440 frames into a single RTP packet. The receiver can tell the number of 441 frames contained in an RTP packet, if all the frames have the same 442 length, by dividing the RTP payload length by the audio frame size 443 which is defined as part of the encoding. This does not work when 444 carrying frames of different sizes unless the frame sizes are 445 relatively prime. If not, the frames MUST indicate their size. 447 For frame-based codecs, the channel order is defined for the whole 448 block. That is, for two-channel audio, right and left samples SHOULD 449 be coded independently, with the encoded frame for the left channel 450 preceding that for the right channel. 452 All frame-oriented audio codecs SHOULD be able to encode and decode 453 several consecutive frames within a single packet. Since the frame 454 size for the frame-oriented codecs is given, there is no need to use 455 a separate designation for the same encoding, but with different 456 number of frames per packet. 458 RTP packets SHALL contain a whole number of frames, with frames 459 inserted according to age within a packet, so that the oldest frame 460 (to be played first) occurs immediately after the RTP packet header. 461 The RTP timestamp reflects the instant at which the first sample in 462 the first frame was sampled, that is, the oldest information in the 463 packet. 465 4.5 Audio Encodings 467 The characteristics of the audio encodings described in this document 468 are shown in Table 1; they are listed in order of their payload type 469 in Table 4. While most audio codecs are only specified for a fixed 470 sampling rate, some sample-based algorithms (indicated by an entry of 471 "var." in the sampling rate column of Table 1) may be used with 472 different sampling rates, resulting in different coded bit rates. 473 When used with a sampling rate other than that for which a static 474 payload type is defined, non-RTP means beyond the scope of this memo 475 name of sampling default 476 encoding sample/frame bits/sample rate ms/frame ms/packet 477 __________________________________________________________________ 478 1016 frame N/A 8,000 30 30 479 CN frame N/A var. 480 DVI4 sample 4 var. 20 481 G722 sample 8 16,000 20 482 G723 frame N/A 8,000 30 30 483 G726-32 sample 4 8,000 20 484 G728 frame N/A 8,000 2.5 20 485 G729 frame N/A 8,000 10 20 486 GSM frame N/A 8,000 20 20 487 GSM-HR frame N/A 8,000 20 20 488 GSM-EFR frame N/A 8,000 20 20 489 L8 sample 8 var. 20 490 L16 sample 16 var. 20 491 LPC frame N/A 8,000 20 20 492 MPA frame N/A var. var. 493 PCMA sample 8 var. 20 494 PCMU sample 8 var. 20 495 QCELP frame N/A 8,000 20 20 496 VDVI sample var. var. 20 498 Table 1: Properties of Audio Encodings (N/A: not applicable; var.: 499 variable) 501 MUST be used to define a dynamic payload type and MUST indicate the 502 selected sampling rate. 504 4.5.1 1016 506 Encoding 1016 is a frame based encoding using code-excited linear 507 prediction (CELP) and is specified in Federal Standard FED-STD 1016 508 [7,8,9,10]. 510 4.5.2 CN 512 The CN (comfort noise) packet contains a single-octet message to the 513 receiver to play comfort noise at the absolute level specified. This 514 message would normally be sent once at the beginning of a silence 515 period (which also indicates the transition from speech to silence), 516 but the rate of noise level updates is implementation specific. The 517 magnitude of the noise level is packed into the least significant 518 bits of the noise-level payload, as shown below. 520 The noise level is expressed in -dBov, with values from 0 to 127 521 representing 0 to -127 dBov. dBov is the level relative to the 522 overload of the system. (Note: Representation relative to the 523 overload point of a system is particularly useful for digital 524 implementations, since one does not need to know the relative 525 calibration of the analog circuitry.) For example, in a 16-bit linear 526 PCM system (L16), a signal with 0 dBov represents a square wave with 527 the maximum possible amplitude (+/-32767), and -63 dBov corresponds 528 to -58 dBm0 in a standard telephone system. (dBm is the power level 529 in decibels relative to 1 mW, with an impedance of 600 Ohms.) 531 0 1 2 3 4 5 6 7 532 +-+-+-+-+-+-+-+-+ 533 |0| level | 534 +-+-+-+-+-+-+-+-+ 536 The RTP header for the comfort noise packet SHOULD be constructed as 537 if the comfort noise were an independent codec. Thus, the RTP 538 timestamp designates the beginning of the silence period. A static 539 payload type is assigned for a sampling rate of 8,000 Hz; if other 540 sampling rates are needed, they MUST be defined through dynamic 541 payload types. The RTP packet SHOULD NOT have the marker bit set. 543 The CN payload type is primarily for use with L16, DVI4, PCMA, PCMU 544 and other audio codecs that do not support comfort noise as part of 545 the codec itself. G.723.1 and G.729 have their own comfort noise 546 systems as part of Annexes A (G.723.1) and B (G.729), respectively. 548 4.5.3 DVI4 550 DVI4 is specified, with pseudo-code, in [11] as the IMA ADPCM wave 551 type. 553 However, the encoding defined here as DVI4 differs in three respects 554 from this recommendation: 556 o The RTP DVI4 header contains the predicted value rather than 557 the first sample value contained the IMA ADPCM block header. 559 o IMA ADPCM blocks contain an odd number of samples, since the 560 first sample of a block is contained just in the header 561 (uncompressed), followed by an even number of compressed 562 samples. DVI4 has an even number of compressed samples only, 563 using the `predict' word from the header to decode the first 564 sample. 566 o For DVI4, the 4-bit samples are packed with the first sample 567 in the four most significant bits and the second sample in the 568 four least significant bits. In the IMA ADPCM codec, the 569 samples are packed in the opposite order. 571 Each packet contains a single DVI block. This profile only defines 572 the 4-bit-per-sample version, while IMA also specifies a 3-bit-per- 573 sample encoding. 575 The "header" word for each channel has the following structure: 577 int16 predict; /* predicted value of first sample 578 from the previous block (L16 format) */ 579 u_int8 index; /* current index into stepsize table */ 580 u_int8 reserved; /* set to zero by sender, ignored by receiver */ 582 Each octet following the header contains two 4-bit samples, thus the 583 number of samples per packet MUST be even because there is no means 584 to indicate a partially filled last octet. 586 Packing of samples for multiple channels is for further study. 588 The document IMA Recommended Practices for Enhancing Digital Audio 589 Compatibility in Multimedia Systems (version 3.0) contains the 590 algorithm description. It is available from 592 Interactive Multimedia Association 593 48 Maryland Avenue, Suite 202 594 Annapolis, MD 21401-8011 595 USA 596 phone: +1 410 626-1380 598 4.5.4 G722 600 G722 is specified in ITU-T Recommendation G.722, "7 kHz audio-coding 601 within 64 kbit/s". The G.722 encoder produces a stream of octets, 602 each of which SHALL be octet-aligned in an RTP packet. The first bit 603 transmitted in the G.722 octet, which is the most significant bit of 604 the higher sub-band sample, SHALL correspond to the most significant 605 bit of the octet in the RTP packet. 607 4.5.5 G723 609 G723 is specified in ITU Recommendation G.723.1, "Dual-rate speech 610 coder for multimedia communications transmitting at 5.3 and 6.3 611 kbit/s". The G.723.1 5.3/6.3 kbit/s codec was defined by the ITU-T as 612 a mandatory codec for ITU-T H.324 GSTN videophone terminal 613 applications. The algorithm has a floating point specification in 614 Annex B to G.723.1, a silence compression algorithm in Annex A to 615 G.723.1 and an encoded signal bit-error sensitivity specification in 616 G.723.1 Annex C. 618 This Recommendation specifies a coded representation that can be used 619 for compressing the speech signal component of multi-media services 620 at a very low bit rate. Audio is encoded in 30 ms frames, with an 621 additional delay of 7.5 ms due to look-ahead. A G.723.1 frame can be 622 one of three sizes: 24 octets (6.3 kb/s frame), 20 octets (5.3 kb/s 623 frame), or 4 octets. These 4-octet frames are called SID frames 624 (Silence Insertion Descriptor) and are used to specify comfort noise 625 parameters. There is no restriction on how 4, 20, and 24 octet frames 626 are intermixed. The least significant two bits of the first octet in 627 the frame determine the frame size and codec type: 629 bits content octets/frame 630 00 high-rate speech (6.3 kb/s) 24 631 01 low-rate speech (5.3 kb/s) 20 632 10 SID frame 4 633 11 reserved 635 It is possible to switch between the two rates at any 30 ms frame 636 boundary. Both (5.3 kb/s and 6.3 kb/s) rates are a mandatory part of 637 the encoder and decoder. This coder was optimized to represent speech 638 with near-toll quality at the above rates using a limited amount of 639 complexity. 641 The packing of the encoded bit stream into octets and the 642 transmission order of the octets is specified in G.723.1. 644 4.5.6 G726-32 646 ITU-T Recommendation G.726 describes, among others, the algorithm 647 recommended for conversion of a single 64 kbit/s A-law or mu-law PCM 648 channel encoded at 8000 samples/sec to and from a 32 kbit/s channel. 649 The conversion is applied to the PCM stream using an Adaptive 650 Differential Pulse Code Modulation (ADPCM) transcoding technique. 651 G.726 describes codecs operating at 16 kb/s (2 bits/sample), 24 kb/s 652 (3 bits/sample), 32 kb/s (4 bits/sample), 40 kb/s (5 bits/sample). 653 Packetization is specified here only for the 32 kb/s encoding which 654 is labeled G726-32. 656 Note: In 1990, ITU-T Recommendation G.721 was merged with 657 Recommendation G.723 into ITU-T Recommendation G.726. Thus, G726-32 658 designates the same algorithm as G721 in RFC 1890. 660 No payload-specific header information SHALL be included as part of 661 the audio data. The 4-bit code words of the G726-32 encoding MUST be 662 packed into octets as follows: the first code word is placed in the 663 four least significant bits of the first octet, with the least 664 significant bit of the code word in the least significant bit of the 665 octet; the second code word is placed in the four most significant 666 bits of the first octet, with the most significant bit of the code 667 word in the most significant bit of the octet. Subsequent pairs of 668 the code words SHALL be packed in the same way into successive 669 octets, with the first code word of each pair placed in the least 670 significant four bits of the octet. The number of samples per packet 671 MUST be even because there is no means to indicate a partially filled 672 last octet. 674 4.5.7 G728 676 G728 is specified in ITU-T Recommendation G.728, "Coding of speech at 677 16 kbit/s using low-delay code excited linear prediction". 679 A G.278 encoder translates 5 consecutive audio samples into a 10-bit 680 codebook index, resulting in a bit rate of 16 kb/s for audio sampled 681 at 8,000 samples per second. The group of five consecutive samples is 682 called a vector. Four consecutive vectors, labeled V1 to V4 (where V1 683 is to be played first by the receiver), build one G.728 frame. The 684 four vectors of 40 bits are packed into 5 octets, labeled B1 through 685 B5. B1 SHALL be placed first in the RTP packet. 687 Referring to the figure below, the principle for bit order is 688 "maintenance of bit significance". Bits from an older vector are more 689 significant than bits from newer vectors. The MSB of the frame goes 690 to the MSB of B1 and the LSB of the frame goes to LSB of B5. 692 1 2 3 3 693 0 0 0 0 9 694 ++++++++++++++++++++++++++++++++++++++++ 695 <---V1---><---V2---><---V3---><---V4---> vectors 696 <--B1--><--B2--><--B3--><--B4--><--B5--> octets 697 <------------- frame 1 ----------------> 699 In particular, B1 contains the eight most significant bits of V1, 700 with the MSB of V1 being the MSB of B1. B2 contains the two least 701 significant bits of V1, the more significant of the two in its MSB, 702 and the six most significant bits of V2. B1 SHALL be placed first in 703 the RTP packet and B5 last. 705 4.5.8 G729 707 G729 is specified in ITU-T Recommendation G.729, "Coding of speech at 708 8 kbit/s using conjugate structure-algebraic code excited linear 709 prediction (CS-ACELP)". A reduced-complexity version of the G.729 710 algorithm is specified in Annex A to Rec. G.729. The speech coding 711 algorithms in the main body of G.729 and in G.729 Annex A are fully 712 interoperable with each other, so there is no need to further 713 distinguish between them. The G.729 and G.729 Annex A codecs were 714 optimized to represent speech with high quality, where G.729 Annex A 715 trades some speech quality for an approximate 50% complexity 716 reduction [12]. 718 A voice activity detector (VAD) and comfort noise generator (CNG) 719 algorithm in Annex B of G.729 is RECOMMENDED for digital simultaneous 720 voice and data applications and can be used in conjunction with G.729 721 or G.729 Annex A. A G.729 or G.729 Annex A frame contains 10 octets, 722 while the G.729 Annex B comfort noise frame occupies 2 octets: 724 0 1 725 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 |L| LSF1 | LSF2 | GAIN |R| 728 |S| | | |E| 729 |F|0 1 2 3 4|0 1 2 3|0 1 2 3 4|S| 730 |0| | | |V| RESV = Reserved (zero) 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 An RTP packet may consist of zero or more G.729 or G.729 Annex A 734 frames, followed by zero or one G.729 Annex B payloads. The presence 735 of a comfort noise frame can be deduced from the length of the RTP 736 payload. 738 The transmitted parameters of a G.729/G.729A 10-ms frame, consisting 739 of 80 bits, are defined in Recommendation G.729, Table 8/G.729. 741 The mapping of the these parameters is given below. Bits are numbered 742 as Internet order, that is, the most significant bit is bit 0. 744 0 1 2 3 745 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 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 |L| L1 | L2 | L3 | P1 |P| C1 | 748 |0| | | | |0| | 749 | |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7| |0 1 2 3 4| 750 | | | | | | | | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 4 5 6 754 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 2 3 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | C1 | S1 | GA1 | GB1 | P2 | C2 | 757 | | | | | | | 758 |5 6 7 8 9 1 1 1|0 1 2 3|0 1 2|0 1 2 3|0 1 2 3 4|0 1 2 3 4 5 6 7| 759 | 0 1 2| | | | | | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 7 763 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | C2 | S2 | GA2 | GB2 | 766 | | | | | 767 |8 9 1 1 1|0 1 2 3|0 1 2|0 1 2 3| 768 | 0 1 2| | | | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 4.5.9 GSM 773 GSM (group speciale mobile) denotes the European GSM 06.10 standard 774 for full-rate speech transcoding, ETS 300 961, which is based on 775 RPE/LTP (residual pulse excitation/long term prediction) coding at a 776 rate of 13 kb/s [13,14,15]. The text of the standard can be obtained 777 from 779 ETSI (European Telecommunications Standards Institute) 780 ETSI Secretariat: B.P.152 781 F-06561 Valbonne Cedex 782 France 783 Phone: +33 92 94 42 00 784 Fax: +33 93 65 47 16 786 Blocks of 160 audio samples are compressed into 33 octets, for an 787 effective data rate of 13,200 b/s. 789 4.5.9.1 General Packaging Issues 791 The GSM standard (ETS 300 961) specifies the bit stream produced by 792 the codec, but does not specify how these bits should be packed for 793 transmission. The packetization specified here has subsequently been 794 adopted in ETSI Technical Specification TS 101 318. Some software 795 implementations of the GSM codec use a different packing than that 796 specified here. 798 In the GSM packing used by RTP, the bits SHALL be packed beginning 799 from the most significant bit. Every 160 sample GSM frame is coded 800 into one 33 octet (264 bit) buffer. Every such buffer begins with a 4 801 bit signature (0xD), followed by the MSB encoding of the fields of 802 the frame. The first octet thus contains 1101 in the 4 most 803 significant bits (0-3) and the 4 most significant bits of F1 (0-3) in 804 the 4 least significant bits (4-7). The second octet contains the 2 805 least significant bits of F1 in bits 0-1, and F2 in bits 2-7, and so 806 on. The order of the fields in the frame is described in Table 2. 808 4.5.9.2 GSM variable names and numbers 810 In the RTP encoding we have the bit pattern described in Table 3, 811 where F.i signifies the ith bit of the field F, bit 0 is the most 812 significant bit, and the bits of every octet are numbered from 0 to 7 813 from most to least significant. 815 4.5.10 GSM-HR 817 GSM-HR denotes GSM 06.20 half rate speech transcoding, specified in 818 ETS 300 969 which is available from ETSI at the address given in 819 Section 4.5.9. This codec has a frame length of 112 bits (14 octets). 820 Packing of the fields in the codec bit stream into octets for 821 transmission in RTP is done in a manner similar to that specified 822 here for the original GSM 06.10 codec and is specified in ETSI 823 Technical Specification TS 101 318. 825 4.5.11 GSM-EFR 827 GSM-EFR denotes GSM 06.60 enhanced full rate speech transcoding, 828 specified in ETS 300 969 which is available from ETSI at the address 829 given in Section 4.5.9. This codec has a frame length of 244 bits. 830 For transmission in RTP, each codec frame is packed into a 31 octet 831 (248 bit) buffer beginning with a 4-bit signature 0xC in a manner 832 similar to that specified here for the original GSM 06.10 codec. The 833 packing is specified in ETSI Technical Specification TS 101 318. 835 4.5.12 L8 837 L8 denotes linear audio data samples, using 8-bits of precision with 838 an offset of 128, that is, the most negative signal is encoded as 839 field field name bits field field name bits 840 ________________________________________________ 841 1 LARc[0] 6 39 xmc[22] 3 842 2 LARc[1] 6 40 xmc[23] 3 843 3 LARc[2] 5 41 xmc[24] 3 844 4 LARc[3] 5 42 xmc[25] 3 845 5 LARc[4] 4 43 Nc[2] 7 846 6 LARc[5] 4 44 bc[2] 2 847 7 LARc[6] 3 45 Mc[2] 2 848 8 LARc[7] 3 46 xmaxc[2] 6 849 9 Nc[0] 7 47 xmc[26] 3 850 10 bc[0] 2 48 xmc[27] 3 851 11 Mc[0] 2 49 xmc[28] 3 852 12 xmaxc[0] 6 50 xmc[29] 3 853 13 xmc[0] 3 51 xmc[30] 3 854 14 xmc[1] 3 52 xmc[31] 3 855 15 xmc[2] 3 53 xmc[32] 3 856 16 xmc[3] 3 54 xmc[33] 3 857 17 xmc[4] 3 55 xmc[34] 3 858 18 xmc[5] 3 56 xmc[35] 3 859 19 xmc[6] 3 57 xmc[36] 3 860 20 xmc[7] 3 58 xmc[37] 3 861 21 xmc[8] 3 59 xmc[38] 3 862 22 xmc[9] 3 60 Nc[3] 7 863 23 xmc[10] 3 61 bc[3] 2 864 24 xmc[11] 3 62 Mc[3] 2 865 25 xmc[12] 3 63 xmaxc[3] 6 866 26 Nc[1] 7 64 xmc[39] 3 867 27 bc[1] 2 65 xmc[40] 3 868 28 Mc[1] 2 66 xmc[41] 3 869 29 xmaxc[1] 6 67 xmc[42] 3 870 30 xmc[13] 3 68 xmc[43] 3 871 31 xmc[14] 3 69 xmc[44] 3 872 32 xmc[15] 3 70 xmc[45] 3 873 33 xmc[16] 3 71 xmc[46] 3 874 34 xmc[17] 3 72 xmc[47] 3 875 35 xmc[18] 3 73 xmc[48] 3 876 36 xmc[19] 3 74 xmc[49] 3 877 37 xmc[20] 3 75 xmc[50] 3 878 38 xmc[21] 3 76 xmc[51] 3 880 Table 2: Ordering of GSM variables 882 zero. 884 4.5.13 L16 885 Octet Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 886 _____________________________________________________________________________ 887 0 1 1 0 1 LARc0.0 LARc0.1 LARc0.2 LARc0.3 888 1 LARc0.4 LARc0.5 LARc1.0 LARc1.1 LARc1.2 LARc1.3 LARc1.4 LARc1.5 889 2 LARc2.0 LARc2.1 LARc2.2 LARc2.3 LARc2.4 LARc3.0 LARc3.1 LARc3.2 890 3 LARc3.3 LARc3.4 LARc4.0 LARc4.1 LARc4.2 LARc4.3 LARc5.0 LARc5.1 891 4 LARc5.2 LARc5.3 LARc6.0 LARc6.1 LARc6.2 LARc7.0 LARc7.1 LARc7.2 892 5 Nc0.0 Nc0.1 Nc0.2 Nc0.3 Nc0.4 Nc0.5 Nc0.6 bc0.0 893 6 bc0.1 Mc0.0 Mc0.1 xmaxc00 xmaxc01 xmaxc02 xmaxc03 xmaxc04 894 7 xmaxc05 xmc0.0 xmc0.1 xmc0.2 xmc1.0 xmc1.1 xmc1.2 xmc2.0 895 8 xmc2.1 xmc2.2 xmc3.0 xmc3.1 xmc3.2 xmc4.0 xmc4.1 xmc4.2 896 9 xmc5.0 xmc5.1 xmc5.2 xmc6.0 xmc6.1 xmc6.2 xmc7.0 xmc7.1 897 10 xmc7.2 xmc8.0 xmc8.1 xmc8.2 xmc9.0 xmc9.1 xmc9.2 xmc10.0 898 11 xmc10.1 xmc10.2 xmc11.0 xmc11.1 xmc11.2 xmc12.0 xmc12.1 xcm12.2 899 12 Nc1.0 Nc1.1 Nc1.2 Nc1.3 Nc1.4 Nc1.5 Nc1.6 bc1.0 900 13 bc1.1 Mc1.0 Mc1.1 xmaxc10 xmaxc11 xmaxc12 xmaxc13 xmaxc14 901 14 xmax15 xmc13.0 xmc13.1 xmc13.2 xmc14.0 xmc14.1 xmc14.2 xmc15.0 902 15 xmc15.1 xmc15.2 xmc16.0 xmc16.1 xmc16.2 xmc17.0 xmc17.1 xmc17.2 903 16 xmc18.0 xmc18.1 xmc18.2 xmc19.0 xmc19.1 xmc19.2 xmc20.0 xmc20.1 904 17 xmc20.2 xmc21.0 xmc21.1 xmc21.2 xmc22.0 xmc22.1 xmc22.2 xmc23.0 905 18 xmc23.1 xmc23.2 xmc24.0 xmc24.1 xmc24.2 xmc25.0 xmc25.1 xmc25.2 906 19 Nc2.0 Nc2.1 Nc2.2 Nc2.3 Nc2.4 Nc2.5 Nc2.6 bc2.0 907 20 bc2.1 Mc2.0 Mc2.1 xmaxc20 xmaxc21 xmaxc22 xmaxc23 xmaxc24 908 21 xmaxc25 xmc26.0 xmc26.1 xmc26.2 xmc27.0 xmc27.1 xmc27.2 xmc28.0 909 22 xmc28.1 xmc28.2 xmc29.0 xmc29.1 xmc29.2 xmc30.0 xmc30.1 xmc30.2 910 23 xmc31.0 xmc31.1 xmc31.2 xmc32.0 xmc32.1 xmc32.2 xmc33.0 xmc33.1 911 24 xmc33.2 xmc34.0 xmc34.1 xmc34.2 xmc35.0 xmc35.1 xmc35.2 xmc36.0 912 25 Xmc36.1 xmc36.2 xmc37.0 xmc37.1 xmc37.2 xmc38.0 xmc38.1 xmc38.2 913 26 Nc3.0 Nc3.1 Nc3.2 Nc3.3 Nc3.4 Nc3.5 Nc3.6 bc3.0 914 27 bc3.1 Mc3.0 Mc3.1 xmaxc30 xmaxc31 xmaxc32 xmaxc33 xmaxc34 915 28 xmaxc35 xmc39.0 xmc39.1 xmc39.2 xmc40.0 xmc40.1 xmc40.2 xmc41.0 916 29 xmc41.1 xmc41.2 xmc42.0 xmc42.1 xmc42.2 xmc43.0 xmc43.1 xmc43.2 917 30 xmc44.0 xmc44.1 xmc44.2 xmc45.0 xmc45.1 xmc45.2 xmc46.0 xmc46.1 918 31 xmc46.2 xmc47.0 xmc47.1 xmc47.2 xmc48.0 xmc48.1 xmc48.2 xmc49.0 919 32 xmc49.1 xmc49.2 xmc50.0 xmc50.1 xmc50.2 xmc51.0 xmc51.1 xmc51.2 921 Table 3: GSM payload format 923 L16 denotes uncompressed audio data samples, using 16-bit signed 924 representation with 65535 equally divided steps between minimum and 925 maximum signal level, ranging from -32768 to 32767. The value is 926 represented in two's complement notation and transmitted in network 927 byte order (most significant byte first). 929 4.5.14 LPC 930 LPC designates an experimental linear predictive encoding contributed 931 by Ron Frederick, Xerox PARC, which is based on an implementation 932 written by Ron Zuckerman, Motorola, posted to the Usenet group 933 comp.dsp on June 26, 1992. The codec generates 14 octets for every 934 frame. The framesize is set to 20 ms, resulting in a bit rate of 935 5,600 b/s. 937 4.5.15 MPA 939 MPA denotes MPEG-1 or MPEG-2 audio encapsulated as elementary 940 streams. The encoding is defined in ISO standards ISO/IEC 11172-3 941 and 13818-3. The encapsulation is specified in RFC 2250 [16]. 943 The encoding may be at any of three levels of complexity, called 944 Layer I, II and III. The selected layer as well as the sampling rate 945 and channel count are indicated in the payload. MPEG-1 audio supports 946 sampling rates of 32, 44.1, and 48 kHz (ISO/IEC 11172-3, section 1.1; 947 "Scope"). MPEG-2 supports sampling rates of 16, 22.05 and 24 kHz. 948 The number of samples per frame is fixed, but the frame size will 949 vary with the sampling rate and bit rate. 951 4.5.16 PCMA and PCMU 953 PCMA and PCMU are specified in ITU-T Recommendation G.711. Audio data 954 is encoded as eight bits per sample, after logarithmic scaling. PCMU 955 denotes mu-law scaling, PCMA A-law scaling. A detailed description is 956 given by Jayant and Noll [17]. Each G.711 octet SHALL be octet- 957 aligned in an RTP packet. The sign bit of each G.711 octet SHALL 958 correspond to the most significant bit of the octet in the RTP packet 959 (i.e., assuming the G.711 samples are handled as octets on the host 960 machine, the sign bit SHALL be the most signficant bit of the octet 961 as defined by the host machine format). The 56 kb/s and 48 kb/s modes 962 of G.711 are not applicable to RTP, since PCMA and PCMU SHALL always 963 be transmitted as 8-bit samples. 965 4.5.17 QCELP 967 The Electronic Industries Association (EIA) & Telecommunications 968 Industry Association (TIA) standard IS-733, "TR45: High Rate Speech 969 Service Option for Wideband Spread Spectrum Communications Systems," 970 defines the QCELP audio compression algorithm for use in wireless 971 CDMA applications. The QCELP CODEC compresses each 20 milliseconds of 972 8000 Hz, 16- bit sampled input speech into one of four different size 973 output frames: Rate 1 (266 bits), Rate 1/2 (124 bits), Rate 1/4 (54 974 bits) or Rate 1/8 (20 bits). For typical speech patterns, this 975 results in an average output of 6.8 k bits/sec for normal mode and 976 4.7 k bits/sec for reduced rate mode. The packetization of the QCELP 977 audio codec is described in [18]. 979 4.5.18 RED 981 The redundant audio payload format "RED" is specified by RFC 2198 982 [19]. It defines a means by which multiple redundant copies of an 983 audio packet may be transmitted in a single RTP stream. Each packet 984 in such a stream contains, in addition to the audio data for that 985 packetization interval, a (more heavily compressed) copy of the data 986 from a previous packetization interval. This allows an approximation 987 of the data from lost packets to be recovered upon decoding of a 988 subsequent packet, giving much improved sound quality when compared 989 with silence substitution for lost packets. 991 4.5.19 VDVI 993 VDVI is a variable-rate version of DVI4, yielding speech bit rates of 994 between 10 and 25 kb/s. It is specified for single-channel operation 995 only. Samples are packed into octets starting at the most- 996 significant bit. The last octet is padded with 1 bits if the last 997 sample does not fill the last octet. This padding is distinct from 998 the valid codewords. The receiver needs to detect the padding 999 because there is no explicit count of samples in the packet. 1001 It uses the following encoding: 1003 DVI4 codeword VDVI bit pattern 1004 _______________________________ 1005 0 00 1006 1 010 1007 2 1100 1008 3 11100 1009 4 111100 1010 5 1111100 1011 6 11111100 1012 7 11111110 1013 8 10 1014 9 011 1015 10 1101 1016 11 11101 1017 12 111101 1018 13 1111101 1019 14 11111101 1020 15 11111111 1022 5 Video 1024 The following sections describe the video encodings that are defined 1025 in this memo and give their abbreviated names used for 1026 identification. These video encodings and their payload types are 1027 listed in Table 5. 1029 All of these video encodings use an RTP timestamp frequency of 90,000 1030 Hz, the same as the MPEG presentation time stamp frequency. This 1031 frequency yields exact integer timestamp increments for the typical 1032 24 (HDTV), 25 (PAL), and 29.97 (NTSC) and 30 Hz (HDTV) frame rates 1033 and 50, 59.94 and 60 Hz field rates. While 90 kHz is the RECOMMENDED 1034 rate for future video encodings used within this profile, other rates 1035 MAY be used. However, it is not sufficient to use the video frame 1036 rate (typically between 15 and 30 Hz) because that does not provide 1037 adequate resolution for typical synchronization requirements when 1038 calculating the RTP timestamp corresponding to the NTP timestamp in 1039 an RTCP SR packet. The timestamp resolution MUST also be sufficient 1040 for the jitter estimate contained in the receiver reports. 1042 For most of these video encodings, the RTP timestamp encodes the 1043 sampling instant of the video image contained in the RTP data packet. 1044 If a video image occupies more than one packet, the timestamp is the 1045 same on all of those packets. Packets from different video images are 1046 distinguished by their different timestamps. 1048 Most of these video encodings also specify that the marker bit of the 1049 RTP header SHOULD be set to one in the last packet of a video frame 1050 and otherwise set to zero. Thus, it is not necessary to wait for a 1051 following packet with a different timestamp to detect that a new 1052 frame should be displayed. 1054 5.1 BT656 1056 The encoding is specified in ITU-R Recommendation BT.656-3, 1057 "Interfaces for Digital Component Video Signals in 525-Line and 625- 1058 Line Television Systems operating at the 4:2:2 Level of 1059 Recommendation ITU-R BT.601 (Part A)". The packetization and RTP- 1060 specific properties are described in RFC 2431 [20]. 1062 5.2 CelB 1064 The CELL-B encoding is a proprietary encoding proposed by Sun 1065 Microsystems. The byte stream format is described in RFC 2029 [21]. 1067 5.3 JPEG 1069 The encoding is specified in ISO Standards 10918-1 and 10918-2. The 1070 RTP payload format is as specified in RFC 2435 [22]. 1072 5.4 H261 1073 The encoding is specified in ITU-T Recommendation H.261, "Video codec 1074 for audiovisual services at p x 64 kbit/s". The packetization and 1075 RTP-specific properties are described in RFC 2032 [23]. 1077 5.5 H263 1079 The encoding is specified in the 1996 version of ITU-T Recommendation 1080 H.263, "Video coding for low bit rate communication". The 1081 packetization and RTP-specific properties are described in RFC 2190 1082 [24]. 1084 5.6 H263-1998 1086 The encoding is specified in the 1998 version of ITU-T Recommendation 1087 H.263, "Video coding for low bit rate communication". The 1088 packetization and RTP-specific properties are described in RFC 2429 1089 [25]. Because the 1998 version of H.263 is a superset of the 1996 1090 syntax, this payload format can also be used with the 1996 version of 1091 H.263, and is RECOMMENDED for this use by new implementations. This 1092 payload format does not replace RFC 2190, which continues to be used 1093 by existing implementations, and may be required for backward 1094 compatibility in new implementations. Implementations using the new 1095 features of the 1998 version of H.263 MUST use the payload format 1096 described in RFC 2429. 1098 5.7 MPV 1100 MPV designates the use of MPEG-1 and MPEG-2 video encoding elementary 1101 streams as specified in ISO Standards ISO/IEC 11172 and 13818-2, 1102 respectively. The RTP payload format is as specified in RFC 2250 1103 [16], Section 3. 1105 5.8 MP2T 1107 MP2T designates the use of MPEG-2 transport streams, for either audio 1108 or video. The RTP payoad format is described in RFC 2250 [16], 1109 Section 2. 1111 5.9 MP1S 1113 MP1S designates an MPEG-1 systems stream, encapsulated according to 1114 RFC 2250 [16]. 1116 5.10 MP2P 1118 MP2P designates an MPEG-2 program stream, encapsulated according to 1119 RFC 2250 [16]. 1121 5.11 BMPEG 1123 BMPEG designates an experimental payload format for MPEG-1 and MPEG-2 1124 which specifies bundled (multiplexed) transport of audio and video 1125 elementary streams in one RTP stream as an alternative to the MP1S 1126 and MP2P formats. The packetization is described in RFC 2343 [26]. 1128 5.12 nv 1130 The encoding is implemented in the program `nv', version 4, developed 1131 at Xerox PARC by Ron Frederick. Further information is available from 1132 the author: 1134 Ron Frederick 1135 Xerox Palo Alto Research Center 1136 3333 Coyote Hill Road 1137 Palo Alto, CA 94304 1138 United States 1139 electronic mail: frederic@parc.xerox.com 1141 6 Payload Type Definitions 1143 Tables 4 and 5 define this profile's static payload type values for 1144 the PT field of the RTP data header. In addition, payload type 1145 values in the range 96-127 MAY be defined dynamically through a 1146 conference control protocol, which is beyond the scope of this 1147 document. For example, a session directory could specify that for a 1148 given session, payload type 96 indicates PCMU encoding, 8,000 Hz 1149 sampling rate, 2 channels. Entries in Tables 4 and 5 with payload 1150 type "dyn" have no static payload type assigned and are only used 1151 with a dynamic payload type. The payload type range marked `reserved' 1152 has been set aside so that RTCP and RTP packets can be reliably 1153 distinguished (see Section "Summary of Protocol Constants" of the RTP 1154 protocol specification). 1156 The payload types currently defined in this profile are assigned to 1157 exactly one of three categories or media types : audio only, video 1158 only and those combining audio and video. The media types are marked 1159 in Tables 4 and 5 as "A", "V" and "AV", respectively. Payload types 1160 of different media types SHALL NOT be interleaved or multiplexed 1161 within a single RTP session, but multiple RTP sessions MAY be used in 1162 parallel to send multiple media types. An RTP source MAY change 1163 payload types within the same media type during a session. See the 1164 section "Multiplexing RTP Sessions" of RFC XXXX for additional 1165 explanation. 1167 Session participants agree through mechanisms beyond the scope of 1168 this specification on the set of payload types allowed in a given 1169 session. This set MAY, for example, be defined by the capabilities 1170 of the applications used, negotiated by a conference control protocol 1171 or established by agreement between the human participants. 1173 Audio applications operating under this profile SHOULD, at a minimum, 1174 be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4). 1175 This allows interoperability without format negotiation and ensures 1176 successful negotation with a conference control protocol. 1178 PT encoding media type clock rate channels 1179 name (Hz) 1180 ___________________________________________________ 1181 0 PCMU A 8000 1 1182 1 1016 A 8000 1 1183 2 G726-32 A 8000 1 1184 3 GSM A 8000 1 1185 4 G723 A 8000 1 1186 5 DVI4 A 8000 1 1187 6 DVI4 A 16000 1 1188 7 LPC A 8000 1 1189 8 PCMA A 8000 1 1190 9 G722 A 16000 1 1191 10 L16 A 44100 2 1192 11 L16 A 44100 1 1193 12 QCELP A 8000 1 1194 13 unassigned A 1195 14 MPA A 90000 (see text) 1196 15 G728 A 8000 1 1197 16 DVI4 A 11025 1 1198 17 DVI4 A 22050 1 1199 18 G729 A 8000 1 1200 19 CN A 8000 1 1201 20 unassigned A 1202 21 unassigned A 1203 22 unassigned A 1204 23 unassigned A 1205 dyn GSM-HR A 8000 1 1206 dyn GSM-EFR A 8000 1 1207 dyn RED A 1209 Table 4: Payload types (PT) for audio encodings 1211 7 RTP over TCP and Similar Byte Stream Protocols 1212 PT encoding media type clock rate 1213 name (Hz) 1214 ____________________________________________ 1215 24 unassigned V 1216 25 CelB V 90000 1217 26 JPEG V 90000 1218 27 unassigned V 1219 28 nv V 90000 1220 29 unassigned V 1221 30 unassigned V 1222 31 H261 V 90000 1223 32 MPV V 90000 1224 33 MP2T AV 90000 1225 34 H263 V 90000 1226 35-71 unassigned ? 1227 72-76 reserved N/A N/A 1228 77-95 unassigned ? 1229 96-127 dynamic ? 1230 dyn BT656 V 90000 1231 dyn H263-1998 V 90000 1232 dyn MP1S V 90000 1233 dyn MP2P V 90000 1234 dyn BMPEG V 90000 1236 Table 5: Payload types (PT) for video and combined encodings 1238 Under special circumstances, it may be necessary to carry RTP in 1239 protocols offering a byte stream abstraction, such as TCP, possibly 1240 multiplexed with other data. If the application does not define its 1241 own method of delineating RTP and RTCP packets, it SHOULD prefix each 1242 packet with a two-octet length field. 1244 (Note: RTSP [27] provides its own encapsulation and does not need an 1245 extra length indication.) 1247 8 Port Assignment 1249 As specified in the RTP protocol definition, RTP data SHOULD be 1250 carried on an even UDP or TCP port number and the corresponding RTCP 1251 packets SHOULD be carried on the next higher (odd) port number. 1253 Applications operating under this profile MAY use any such UDP or TCP 1254 port pair. For example, the port pair MAY be allocated randomly by a 1255 session management program. A single fixed port number pair cannot be 1256 required because multiple applications using this profile are likely 1257 to run on the same host, and there are some operating systems that do 1258 not allow multiple processes to use the same UDP port with different 1259 multicast addresses. 1261 However, port numbers 5004 and 5005 have been registered for use with 1262 this profile for those applications that choose to use them as the 1263 default pair. Applications that operate under multiple profiles MAY 1264 use this port pair as an indication to select this profile if they 1265 are not subject to the constraint of the previous paragraph. 1266 Applications need not have a default and MAY require that the port 1267 pair be explicitly specified. The particular port numbers were chosen 1268 to lie in the range above 5000 to accommodate port number allocation 1269 practice within some versions of the Unix operating system, where 1270 port numbers below 1024 can only be used by privileged processes and 1271 port numbers between 1024 and 5000 are automatically assigned by the 1272 operating system. 1274 9 Changes from RFC 1890 1276 This RFC revises RFC 1890. It is fully backwards-compatible with RFC 1277 1890 and codifies existing practice. The changes are listed below. 1279 o Additional payload formats and/or expanded descriptions were 1280 included for CN, G722, G723, G726, G728, G729, GSM, GSM-HR, 1281 GSM-EFR, QCELP, RED, VDVI, BT656, H263-1998, MP1S, MP2P and 1282 BMPEG. 1284 o Static payload types 4, 12, 16, 17, 18, 19 and 34 were added. 1286 o The policy is established that no additional registration of 1287 static payload types for this Profile will be made beyond 1288 those included in Tables 4 and 5, but additional encoding 1289 names may be registered as MIME subtypes. 1291 o In Section 4.1, the requirement level for setting of the 1292 marker bit on the first packet after silence for audio was 1293 changed from "is" to "SHOULD be". 1295 o Similarly, text was added to specify that the marker bit 1296 SHOULD be set to one on the last packet of a video frame, and 1297 that video frames are distinguished by their timestamps. 1299 o This profile follows the suggestion in the RTP spec that RTCP 1300 bandwidth may be specified separately from the session 1301 bandwidth and separately for active senders and passive 1302 receivers. 1304 o RFC references are added for payload formats published after 1305 RFC 1890. 1307 o A minimal TCP encapsulation is defined. 1309 o The security considerations and full copyright sections were 1310 added. 1312 o According to Peter Hoddie of Apple, only pre-1994 Macintosh 1313 used the 22254.54 rate and none the 11127.27 rate, so the 1314 latter was dropped from the discussion of suggested sampling 1315 frequencies. 1317 o Table 1 was corrected to move some values from the 1318 "ms/packet" column to the "default ms/packet" column where 1319 they belonged. 1321 o Small clarifications of the text have been made in several 1322 places, some in response to questions from readers. In 1323 particular: 1325 - A definition for "media type" is given in Section 1.1 to 1326 allow the explanation of multiplexing RTP sessions in 1327 Section 6 to be more clear regarding the multiplexing of 1328 multiple media. 1330 - The explanation of how to determine the number of audio 1331 frames in a packet from the length was expanded. 1333 - More description of the allocation of bandwidth to SDES 1334 items is given. 1336 - The terms MUST, SHOULD, MAY, etc. are used as defined in RFC 1337 2119. 1339 o A second author for this document was added. 1341 10 Security Considerations 1343 Implementations using the profile defined in this specification are 1344 subject to the security considerations discussed in the RTP 1345 specification [1]. This profile does not specify any different 1346 security services other than giving rules for mapping characters in a 1347 user-provided pass phrase to canonical form. The primary function of 1348 this profile is to list a set of data compression encodings for audio 1349 and video media. 1351 Confidentiality of the media streams is achieved by encryption. 1352 Because the data compression used with the payload formats described 1353 in this profile is applied end-to-end, encryption may be performed 1354 after compression so there is no conflict between the two operations. 1356 A potential denial-of-service threat exists for data encodings using 1357 compression techniques that have non-uniform receiver-end 1358 computational load. The attacker can inject pathological datagrams 1359 into the stream which are complex to decode and cause the receiver to 1360 be overloaded. However, the encodings described in this profile do 1361 not exhibit any significant non-uniformity. 1363 As with any IP-based protocol, in some circumstances a receiver may 1364 be overloaded simply by the receipt of too many packets, either 1365 desired or undesired. Network-layer authentication MAY be used to 1366 discard packets from undesired sources, but the processing cost of 1367 the authentication itself may be too high. In a multicast 1368 environment, pruning of specific sources may be implemented in future 1369 versions of IGMP [28] and in multicast routing protocols to allow a 1370 receiver to select which sources are allowed to reach it. 1372 11 Full Copyright Statement 1374 Copyright (C) The Internet Society (1999). All Rights Reserved. 1376 This document and translations of it may be copied and furnished to 1377 others, and derivative works that comment on or otherwise explain it 1378 or assist in its implmentation may be prepared, copied, published and 1379 distributed, in whole or in part, without restriction of any kind, 1380 provided that the above copyright notice and this paragraph are 1381 included on all such copies and derivative works. However, this 1382 document itself may not be modified in any way, such as by removing 1383 the copyright notice or references to the Internet Society or other 1384 Internet organizations, except as needed for the purpose of 1385 developing Internet standards in which case the procedures for 1386 copyrights defined in the Internet Standards process must be 1387 followed, or as required to translate it into languages other than 1388 English. 1390 The limited permissions granted above are perpetual and will not be 1391 revoked by the Internet Society or its successors or assigns. 1393 This document and the information contained herein is provided on an 1394 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1395 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1396 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1397 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1398 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1400 12 Acknowledgements 1402 The comments and careful review of Simao Campos, Richard Cox and AVT 1403 Working Group participants are gratefully acknowledged. The GSM 1404 description was adopted from the IMTC Voice over IP Forum Service 1405 Interoperability Implementation Agreement (January 1997). Fred Burg 1406 and Terry Lyons helped with the G.729 description. 1408 13 Addresses of Authors 1410 Henning Schulzrinne 1411 Dept. of Computer Science 1412 Columbia University 1413 1214 Amsterdam Avenue 1414 New York, NY 10027 1415 USA 1416 electronic mail: schulzrinne@cs.columbia.edu 1418 Stephen L. Casner 1419 Cisco Systems, Inc. 1420 170 West Tasman Drive 1421 San Jose, CA 95134 1422 United States 1423 electronic mail: casner@cisco.com 1425 A Bibliography 1427 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A 1428 transport protocol for real-time applications," Internet Draft, 1429 Internet Engineering Task Force, Feb. 1999 Work in progress, revision 1430 to RFC 1889. 1432 [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1433 Levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 1435 [3] P. Hoschka, "MIME Type Registration of RTP Payload Types," 1436 Internet Draft, Internet Engineering Task Force, Feb. 1999 Work in 1437 progress. 1439 [4] N. Freed, J. Klensin, and J. Postel, "Multipurpose Internet Mail 1440 Extensions (MIME) Part Four: Registration Procedures," RFC 2048, 1441 Internet Engineering Task Force, Nov. 1996. 1443 [5] M. Handley and V. Jacobson, "SDP: Session Description Protocol," 1444 Request for Comments (Proposed Standard) RFC 2327, Internet 1445 Engineering Task Force, Apr. 1998. 1447 [6] Apple Computer, "Audio interchange file format AIFF-C," Aug. 1448 1991. (also ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z). 1450 [7] Office of Technology and Standards, "Telecommunications: Analog 1451 to digital conversion of radio voice by 4,800 bit/second code excited 1452 linear prediction (celp)," Federal Standard FS-1016, GSA, Room 6654; 1453 7th & D Street SW; Washington, DC 20407 (+1-202-708-9205), 1990. 1455 [8] J. P. Campbell, Jr., T. E. Tremain, and V. C. Welch, "The 1456 proposed Federal Standard 1016 4800 bps voice coder: CELP," Speech 1457 Technology , vol. 5, pp. 58--64, April/May 1990. 1459 [9] J. P. Campbell, Jr., T. E. Tremain, and V. C. Welch, "The federal 1460 standard 1016 4800 bps CELP voice coder," Digital Signal Processing , 1461 vol. 1, no. 3, pp. 145--155, 1991. 1463 [10] J. P. Campbell, Jr., T. E. Tremain, and V. C. Welch, "The DoD 1464 4.8 kbps standard (proposed federal standard 1016)," in Advances in 1465 Speech Coding (B. Atal, V. Cuperman, and A. Gersho, eds.), ch. 12, 1466 pp. 121--133, Kluwer Academic Publishers, 1991. 1468 [11] IMA Digital Audio Focus and Technical Working Groups, 1469 "Recommended practices for enhancing digital audio compatibility in 1470 multimedia systems (version 3.00)," tech. rep., Interactive 1471 Multimedia Association, Annapolis, Maryland, Oct. 1992. 1473 [12] D. Deleam and J.-P. Petit, "Real-time implementations of the 1474 recent ITU-T low bit rate speech coders on the TI TMS320C54X DSP: 1475 results, methodology, and applications," in Proc. of International 1476 Conference on Signal Processing, Technology, and Applications 1477 (ICSPAT) , (Boston, Massachusetts), pp. 1656--1660, Oct. 1996. 1479 [13] M. Mouly and M.-B. Pautet, The GSM system for mobile 1480 communications Lassay-les-Chateaux, France: Europe Media Duplication, 1481 1993. 1483 [14] J. Degener, "Digital speech compression," Dr. Dobb's Journal , 1484 Dec. 1994. 1486 [15] S. M. Redl, M. K. Weber, and M. W. Oliphant, An Introduction to 1487 GSM Boston: Artech House, 1995. 1489 [16] D. Hoffman, G. Fernando, V. Goyal, and M. Civanlar, "RTP payload 1490 format for MPEG1/MPEG2 video," Request for Comments (Proposed 1491 Standard) RFC 2250, Internet Engineering Task Force, Jan. 1998. 1493 [17] N. S. Jayant and P. Noll, Digital Coding of Waveforms-- 1494 Principles and Applications to Speech and Video Englewood Cliffs, New 1495 Jersey: Prentice-Hall, 1984. 1497 [18] K. McKay, "RTP Payload Format for PureVoice(tm) Audio", Internet 1498 Draft, Internet Engineering Task Force, Oct. 1998. Work in progress. 1500 [19] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. 1501 Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload for 1502 Redundant Audio Data," Request for Comments (Proposed Standard) RFC 1503 2198, Internet Engineering Task Force, Sep. 1997. 1505 [20] D. Tynan, "RTP payload format for BT.656 Video Encoding," 1506 Request for Comments (Proposed Standard) RFC 2431, Internet 1507 Engineering Task Force, Oct. 1998. 1509 [21] M. Speer and D. Hoffman, "RTP payload format of sun's CellB 1510 video encoding," Request for Comments (Proposed Standard) RFC 2029, 1511 Internet Engineering Task Force, Oct. 1996. 1513 [22] L. Berc, W. Fenner, R. Frederick, and S. McCanne, "RTP payload 1514 format for JPEG-compressed video," Request for Comments (Proposed 1515 Standard) RFC 2435, Internet Engineering Task Force, Oct. 1996. 1517 [23] T. Turletti and C. Huitema, "RTP payload format for H.261 video 1518 streams," Request for Comments (Proposed Standard) RFC 2032, Internet 1519 Engineering Task Force, Oct. 1996. 1521 [24] C. Zhu, "RTP payload format for H.263 video streams," Request 1522 for Comments (Proposed Standard) RFC 2190, Internet Engineering Task 1523 Force, Sep. 1997. 1525 [25] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. 1526 Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu, "RTP Payload Format 1527 for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)," Request for 1528 Comments (Proposed Standard) RFC 2429, Internet Engineering Task 1529 Force, Oct. 1998. 1531 [26] M. Civanlar, G. Cash, B. Haskell, "RTP Payload Format for 1532 Bundled MPEG," Request for Comments (Experimental) RFC 2343, Internet 1533 Engineering Task Force, May 1998. 1535 [27] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming 1536 protocol (RTSP)," Request for Comments (Proposed Standard) RFC 2326, 1537 Internet Engineering Task Force, Apr. 1998. 1539 [28] S. Deering, "Host Extensions for IP Multicasting," Request for 1540 Comments RFC 1112, STD 5, Internet Engineering Task Force, Aug. 1989. 1542 Current Locations of Related Resources 1544 Note: Several sections below refer to the ITU-T Software Tool Library 1545 (STL). It is available from the ITU Sales Service, Place des Nations, 1546 CH-1211 Geneve 20, Switzerland (also check http://www.itu.int. The 1547 ITU-T STL is covered by a license defined in ITU-T Recommendation 1548 G.191, "Software tools for speech and audio coding standardization". 1550 UTF-8 1552 Information on the UCS Transformation Format 8 (UTF-8) is available 1553 at 1555 http://www.stonehand.com/unicode/standard/utf8.html 1557 1016 1559 The U.S. DoD's Federal-Standard-1016 based 4800 bps code excited 1560 linear prediction voice coder version 3.2 (CELP 3.2) Fortran and C 1561 simulation source codes are available for worldwide distribution at 1562 no charge (on DOS diskettes, but configured to compile on Sun SPARC 1563 stations) from: Bob Fenichel, National Communications System, 1564 Washington, D.C. 20305, phone +1-703-692-2124, fax +1-703-746-4960. 1566 An implementation is also available at 1568 ftp://ftp.super.org/pub/speech/celp_3.2a.tar.Z 1570 DVI4 1572 An implementation is available from Jack Jansen at 1574 ftp://ftp.cwi.nl/local/pub/audio/adpcm.shar 1576 G722 1578 An implementation of the G.722 algorithm is available as part of the 1579 ITU-T STL, described above. 1581 G723 1583 The reference C code implementation defining the G.723.1 algorithm 1584 and its Annexes A, B, and C are available as an integral part of 1585 Recommendation G.723.1 from the ITU Sales Service, address listed 1586 above. Both the algorithm and C code are covered by a specific 1587 license. The ITU-T Secretariat should be contacted to obtain such 1588 licensing information. 1590 G726-32 1592 G726-32 is specified in the ITU-T Recommendation G.726, "40, 32, 24, 1593 and 16 kb/s Adaptive Differential Pulse Code Modulation (ADPCM)". An 1594 implementation of the G.726 algorithm is available as part of the 1595 ITU-T STL, described above. 1597 G729 1599 The reference C code implementation defining the G.729 algorithm and 1600 its Annexes A and B are available as an integral part of 1601 Recommendation G.729 from the ITU Sales Service, listed above. Both 1602 the algorithm and the C code are covered by a specific license. The 1603 contact information for obtaining the license is listed in the C 1604 code. 1606 GSM 1608 A reference implementation was written by Carsten Borman and Jutta 1609 Degener (TU Berlin, Germany). It is available at 1611 ftp://ftp.cs.tu-berlin.de/pub/local/kbs/tubmik/gsm/ 1613 Although the RPE-LTP algorithm is not an ITU-T standard, there is a C 1614 code implementation of the RPE-LTP algorithm available as part of the 1615 ITU-T STL. The STL implementation is an adaptation of the TU Berlin 1616 version. 1618 LPC 1620 An implementation is available at 1622 ftp://parcftp.xerox.com/pub/net-research/lpc.tar.Z 1624 PCMU, PCMA 1626 An implementation of these algorithm is available as part of the 1627 ITU-T STL, described above. Code to convert between linear and mu-law 1628 companded data is also available in [11]. 1630 Table of Contents 1632 1 Introduction ........................................ 2 1633 1.1 Terminology ......................................... 3 1634 2 RTP and RTCP Packet Forms and Protocol Behavior ..... 3 1635 3 Registering Additional Encodings with IANA .......... 6 1636 4 Audio ............................................... 7 1637 4.1 Encoding-Independent Rules .......................... 7 1638 4.2 Operating Recommendations ........................... 9 1639 4.3 Guidelines for Sample-Based Audio Encodings ......... 9 1640 4.4 Guidelines for Frame-Based Audio Encodings .......... 10 1641 4.5 Audio Encodings ..................................... 10 1642 4.5.1 1016 ................................................ 11 1643 4.5.2 CN .................................................. 11 1644 4.5.3 DVI4 ................................................ 12 1645 4.5.4 G722 ................................................ 13 1646 4.5.5 G723 ................................................ 13 1647 4.5.6 G726-32 ............................................. 14 1648 4.5.7 G728 ................................................ 15 1649 4.5.8 G729 ................................................ 16 1650 4.5.9 GSM ................................................. 17 1651 4.5.9.1 General Packaging Issues ............................ 17 1652 4.5.9.2 GSM variable names and numbers ...................... 18 1653 4.5.10 GSM-HR .............................................. 18 1654 4.5.11 GSM-EFR ............................................. 18 1655 4.5.12 L8 .................................................. 18 1656 4.5.13 L16 ................................................. 19 1657 4.5.14 LPC ................................................. 20 1658 4.5.15 MPA ................................................. 21 1659 4.5.16 PCMA and PCMU ....................................... 21 1660 4.5.17 QCELP ............................................... 21 1661 4.5.18 RED ................................................. 22 1662 4.5.19 VDVI ................................................ 22 1663 5 Video ............................................... 22 1664 5.1 BT656 ............................................... 23 1665 5.2 CelB ................................................ 23 1666 5.3 JPEG ................................................ 23 1667 5.4 H261 ................................................ 23 1668 5.5 H263 ................................................ 24 1669 5.6 H263-1998 ........................................... 24 1670 5.7 MPV ................................................. 24 1671 5.8 MP2T ................................................ 24 1672 5.9 MP1S ................................................ 24 1673 5.10 MP2P ................................................ 24 1674 5.11 BMPEG ............................................... 25 1675 5.12 nv .................................................. 25 1676 6 Payload Type Definitions ............................ 25 1677 7 RTP over TCP and Similar Byte Stream Protocols ...... 26 1678 8 Port Assignment ..................................... 27 1679 9 Changes from RFC 1890 ............................... 28 1680 10 Security Considerations ............................. 29 1681 11 Full Copyright Statement ............................ 30 1682 12 Acknowledgements .................................... 30 1683 13 Addresses of Authors ................................ 31 1684 A Bibliography ........................................ 31