idnits 2.17.1 draft-ietf-avt-profile-new-07.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: ---------------------------------------------------------------------------- ** 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 636 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 (October 21, 1999) is 8954 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 1439 looks like a reference -- Missing reference section? '2' on line 1444 looks like a reference -- Missing reference section? '5' on line 1455 looks like a reference -- Missing reference section? '3' on line 1447 looks like a reference -- Missing reference section? '4' on line 1451 looks like a reference -- Missing reference section? '6' on line 1459 looks like a reference -- Missing reference section? '7' on line 1462 looks like a reference -- Missing reference section? '8' on line 1467 looks like a reference -- Missing reference section? '9' on line 1471 looks like a reference -- Missing reference section? '10' on line 1475 looks like a reference -- Missing reference section? '11' on line 1640 looks like a reference -- Missing reference section? '12' on line 1485 looks like a reference -- Missing reference section? '13' on line 1491 looks like a reference -- Missing reference section? '14' on line 1495 looks like a reference -- Missing reference section? '15' on line 1498 looks like a reference -- Missing reference section? '0' on line 852 looks like a reference -- Missing reference section? '22' on line 1525 looks like a reference -- Missing reference section? '23' on line 1529 looks like a reference -- Missing reference section? '24' on line 1533 looks like a reference -- Missing reference section? '25' on line 1537 looks like a reference -- Missing reference section? '26' on line 1543 looks like a reference -- Missing reference section? '27' on line 1547 looks like a reference -- Missing reference section? '28' on line 1551 looks like a reference -- Missing reference section? '29' on line 851 looks like a reference -- Missing reference section? '30' on line 852 looks like a reference -- Missing reference section? '31' on line 853 looks like a reference -- Missing reference section? '32' on line 854 looks like a reference -- Missing reference section? '33' on line 855 looks like a reference -- Missing reference section? '34' on line 856 looks like a reference -- Missing reference section? '35' on line 857 looks like a reference -- Missing reference section? '36' on line 858 looks like a reference -- Missing reference section? '37' on line 859 looks like a reference -- Missing reference section? '38' on line 860 looks like a reference -- Missing reference section? '39' on line 865 looks like a reference -- Missing reference section? '40' on line 866 looks like a reference -- Missing reference section? '41' on line 867 looks like a reference -- Missing reference section? '42' on line 868 looks like a reference -- Missing reference section? '43' on line 869 looks like a reference -- Missing reference section? '44' on line 870 looks like a reference -- Missing reference section? '45' on line 871 looks like a reference -- Missing reference section? '16' on line 1501 looks like a reference -- Missing reference section? '46' on line 872 looks like a reference -- Missing reference section? '17' on line 1505 looks like a reference -- Missing reference section? '47' on line 873 looks like a reference -- Missing reference section? '18' on line 1509 looks like a reference -- Missing reference section? '48' on line 874 looks like a reference -- Missing reference section? '19' on line 1512 looks like a reference -- Missing reference section? '49' on line 875 looks like a reference -- Missing reference section? '20' on line 1517 looks like a reference -- Missing reference section? '50' on line 876 looks like a reference -- Missing reference section? '21' on line 1521 looks like a reference -- Missing reference section? '51' on line 877 looks like a reference Summary: 6 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-07.txt Columbia U./Cisco Systems 4 October 21, 1999 5 Expires: April 21, 2000 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 RTP timestamp clock rate, which is usually the same as the 503 sampling rate for audio. 505 4.5.1 1016 507 Encoding 1016 is a frame based encoding using code-excited linear 508 prediction (CELP) and is specified in Federal Standard FED-STD 1016 509 [7,8,9,10]. 511 4.5.2 CN 513 The CN (comfort noise) packet contains a single-octet message to the 514 receiver to play comfort noise at the absolute level specified. This 515 message would normally be sent once at the beginning of a silence 516 period (which also indicates the transition from speech to silence), 517 but the rate of noise level updates is implementation specific. The 518 magnitude of the noise level is packed into the least significant 519 bits of the noise-level payload, as shown below. 521 The noise level is expressed in -dBov, with values from 0 to 127 522 representing 0 to -127 dBov. dBov is the level relative to the 523 overload of the system. (Note: Representation relative to the 524 overload point of a system is particularly useful for digital 525 implementations, since one does not need to know the relative 526 calibration of the analog circuitry.) For example, in a 16-bit linear 527 PCM system (L16), a signal with 0 dBov represents a square wave with 528 the maximum possible amplitude (+/-32767), and -63 dBov corresponds 529 to -58 dBm0 in a standard telephone system. (dBm is the power level 530 in decibels relative to 1 mW, with an impedance of 600 Ohms.) 532 0 1 2 3 4 5 6 7 533 +-+-+-+-+-+-+-+-+ 534 |0| level | 535 +-+-+-+-+-+-+-+-+ 537 The RTP header for the comfort noise packet SHOULD be constructed as 538 if the comfort noise were an independent codec. Thus, the RTP 539 timestamp designates the beginning of the silence period. A static 540 payload type is assigned for a sampling rate of 8,000 Hz; if other 541 sampling rates are needed, they MUST be defined through dynamic 542 payload types. The RTP packet SHOULD NOT have the marker bit set. 544 The CN payload type is primarily for use with L16, DVI4, PCMA, PCMU 545 and other audio codecs that do not support comfort noise as part of 546 the codec itself. G.723.1 and G.729 have their own comfort noise 547 systems as part of Annexes A (G.723.1) and B (G.729), respectively. 549 4.5.3 DVI4 551 DVI4 is specified, with pseudo-code, in [11] as the IMA ADPCM wave 552 type. 554 However, the encoding defined here as DVI4 differs in three respects 555 from this recommendation: 557 o The RTP DVI4 header contains the predicted value rather than 558 the first sample value contained the IMA ADPCM block header. 560 o IMA ADPCM blocks contain an odd number of samples, since the 561 first sample of a block is contained just in the header 562 (uncompressed), followed by an even number of compressed 563 samples. DVI4 has an even number of compressed samples only, 564 using the `predict' word from the header to decode the first 565 sample. 567 o For DVI4, the 4-bit samples are packed with the first sample 568 in the four most significant bits and the second sample in the 569 four least significant bits. In the IMA ADPCM codec, the 570 samples are packed in the opposite order. 572 Each packet contains a single DVI block. This profile only defines 573 the 4-bit-per-sample version, while IMA also specifies a 3-bit-per- 574 sample encoding. 576 The "header" word for each channel has the following structure: 578 int16 predict; /* predicted value of first sample 579 from the previous block (L16 format) */ 580 u_int8 index; /* current index into stepsize table */ 581 u_int8 reserved; /* set to zero by sender, ignored by receiver */ 583 Each octet following the header contains two 4-bit samples, thus the 584 number of samples per packet MUST be even because there is no means 585 to indicate a partially filled last octet. 587 Packing of samples for multiple channels is for further study. 589 The document IMA Recommended Practices for Enhancing Digital Audio 590 Compatibility in Multimedia Systems (version 3.0) contains the 591 algorithm description. It is available from 593 Interactive Multimedia Association 594 48 Maryland Avenue, Suite 202 595 Annapolis, MD 21401-8011 596 USA 597 phone: +1 410 626-1380 599 4.5.4 G722 601 G722 is specified in ITU-T Recommendation G.722, "7 kHz audio-coding 602 within 64 kbit/s". The G.722 encoder produces a stream of octets, 603 each of which SHALL be octet-aligned in an RTP packet. The first bit 604 transmitted in the G.722 octet, which is the most significant bit of 605 the higher sub-band sample, SHALL correspond to the most significant 606 bit of the octet in the RTP packet. 608 Even though the actual sampling rate for G.722 audio is 16000 Hz, the 609 RTP clock rate for the G722 payload format is 8000 Hz because that 610 value was erroneously assigned in RFC 1890 and must remain unchanged 611 for backward compatibility. The octet rate or sample-pair rate is 612 8000 Hz. 614 4.5.5 G723 616 G723 is specified in ITU Recommendation G.723.1, "Dual-rate speech 617 coder for multimedia communications transmitting at 5.3 and 6.3 618 kbit/s". The G.723.1 5.3/6.3 kbit/s codec was defined by the ITU-T as 619 a mandatory codec for ITU-T H.324 GSTN videophone terminal 620 applications. The algorithm has a floating point specification in 621 Annex B to G.723.1, a silence compression algorithm in Annex A to 622 G.723.1 and an encoded signal bit-error sensitivity specification in 623 G.723.1 Annex C. 625 This Recommendation specifies a coded representation that can be used 626 for compressing the speech signal component of multi-media services 627 at a very low bit rate. Audio is encoded in 30 ms frames, with an 628 additional delay of 7.5 ms due to look-ahead. A G.723.1 frame can be 629 one of three sizes: 24 octets (6.3 kb/s frame), 20 octets (5.3 kb/s 630 frame), or 4 octets. These 4-octet frames are called SID frames 631 (Silence Insertion Descriptor) and are used to specify comfort noise 632 parameters. There is no restriction on how 4, 20, and 24 octet frames 633 are intermixed. The least significant two bits of the first octet in 634 the frame determine the frame size and codec type: 636 bits content octets/frame 637 00 high-rate speech (6.3 kb/s) 24 638 01 low-rate speech (5.3 kb/s) 20 639 10 SID frame 4 640 11 reserved 642 It is possible to switch between the two rates at any 30 ms frame 643 boundary. Both (5.3 kb/s and 6.3 kb/s) rates are a mandatory part of 644 the encoder and decoder. This coder was optimized to represent speech 645 with near-toll quality at the above rates using a limited amount of 646 complexity. 648 The packing of the encoded bit stream into octets and the 649 transmission order of the octets is specified in G.723.1. 651 4.5.6 G726-32 653 ITU-T Recommendation G.726 describes, among others, the algorithm 654 recommended for conversion of a single 64 kbit/s A-law or mu-law PCM 655 channel encoded at 8000 samples/sec to and from a 32 kbit/s channel. 656 The conversion is applied to the PCM stream using an Adaptive 657 Differential Pulse Code Modulation (ADPCM) transcoding technique. 658 G.726 describes codecs operating at 16 kb/s (2 bits/sample), 24 kb/s 659 (3 bits/sample), 32 kb/s (4 bits/sample), 40 kb/s (5 bits/sample). 660 Packetization is specified here only for the 32 kb/s encoding which 661 is labeled G726-32. 663 Note: In 1990, ITU-T Recommendation G.721 was merged with 664 Recommendation G.723 into ITU-T Recommendation G.726. Thus, G726-32 665 designates the same algorithm as G721 in RFC 1890. 667 No payload-specific header information SHALL be included as part of 668 the audio data. The 4-bit code words of the G726-32 encoding MUST be 669 packed into octets as follows: the first code word is placed in the 670 four least significant bits of the first octet, with the least 671 significant bit of the code word in the least significant bit of the 672 octet; the second code word is placed in the four most significant 673 bits of the first octet, with the most significant bit of the code 674 word in the most significant bit of the octet. Subsequent pairs of 675 the code words SHALL be packed in the same way into successive 676 octets, with the first code word of each pair placed in the least 677 significant four bits of the octet. The number of samples per packet 678 MUST be even because there is no means to indicate a partially filled 679 last octet. 681 4.5.7 G728 683 G728 is specified in ITU-T Recommendation G.728, "Coding of speech at 684 16 kbit/s using low-delay code excited linear prediction". 686 A G.278 encoder translates 5 consecutive audio samples into a 10-bit 687 codebook index, resulting in a bit rate of 16 kb/s for audio sampled 688 at 8,000 samples per second. The group of five consecutive samples is 689 called a vector. Four consecutive vectors, labeled V1 to V4 (where V1 690 is to be played first by the receiver), build one G.728 frame. The 691 four vectors of 40 bits are packed into 5 octets, labeled B1 through 692 B5. B1 SHALL be placed first in the RTP packet. 694 Referring to the figure below, the principle for bit order is 695 "maintenance of bit significance". Bits from an older vector are more 696 significant than bits from newer vectors. The MSB of the frame goes 697 to the MSB of B1 and the LSB of the frame goes to LSB of B5. 699 1 2 3 3 700 0 0 0 0 9 701 ++++++++++++++++++++++++++++++++++++++++ 702 <---V1---><---V2---><---V3---><---V4---> vectors 703 <--B1--><--B2--><--B3--><--B4--><--B5--> octets 704 <------------- frame 1 ----------------> 706 In particular, B1 contains the eight most significant bits of V1, 707 with the MSB of V1 being the MSB of B1. B2 contains the two least 708 significant bits of V1, the more significant of the two in its MSB, 709 and the six most significant bits of V2. B1 SHALL be placed first in 710 the RTP packet and B5 last. 712 4.5.8 G729 714 G729 is specified in ITU-T Recommendation G.729, "Coding of speech at 715 8 kbit/s using conjugate structure-algebraic code excited linear 716 prediction (CS-ACELP)". A reduced-complexity version of the G.729 717 algorithm is specified in Annex A to Rec. G.729. The speech coding 718 algorithms in the main body of G.729 and in G.729 Annex A are fully 719 interoperable with each other, so there is no need to further 720 distinguish between them. The G.729 and G.729 Annex A codecs were 721 optimized to represent speech with high quality, where G.729 Annex A 722 trades some speech quality for an approximate 50% complexity 723 reduction [12]. 725 A voice activity detector (VAD) and comfort noise generator (CNG) 726 algorithm in Annex B of G.729 is RECOMMENDED for digital simultaneous 727 voice and data applications and can be used in conjunction with G.729 728 or G.729 Annex A. A G.729 or G.729 Annex A frame contains 10 octets, 729 while the G.729 Annex B comfort noise frame occupies 2 octets: 731 0 1 732 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 |L| LSF1 | LSF2 | GAIN |R| 735 |S| | | |E| 736 |F|0 1 2 3 4|0 1 2 3|0 1 2 3 4|S| 737 |0| | | |V| RESV = Reserved (zero) 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 An RTP packet may consist of zero or more G.729 or G.729 Annex A 741 frames, followed by zero or one G.729 Annex B payloads. The presence 742 of a comfort noise frame can be deduced from the length of the RTP 743 payload. 745 The transmitted parameters of a G.729/G.729A 10-ms frame, consisting 746 of 80 bits, are defined in Recommendation G.729, Table 8/G.729. 748 The mapping of the these parameters is given below. Bits are numbered 749 as Internet order, that is, the most significant bit is bit 0. 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 |L| L1 | L2 | L3 | P1 |P| C1 | 755 |0| | | | |0| | 756 | |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| 757 | | | | | | | | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 4 5 6 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | C1 | S1 | GA1 | GB1 | P2 | C2 | 764 | | | | | | | 765 |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| 766 | 0 1 2| | | | | | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 7 770 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | C2 | S2 | GA2 | GB2 | 773 | | | | | 774 |8 9 1 1 1|0 1 2 3|0 1 2|0 1 2 3| 775 | 0 1 2| | | | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 4.5.9 GSM 780 GSM (group speciale mobile) denotes the European GSM 06.10 standard 781 for full-rate speech transcoding, ETS 300 961, which is based on 782 RPE/LTP (residual pulse excitation/long term prediction) coding at a 783 rate of 13 kb/s [13,14,15]. The text of the standard can be obtained 784 from 786 ETSI (European Telecommunications Standards Institute) 787 ETSI Secretariat: B.P.152 788 F-06561 Valbonne Cedex 789 France 790 Phone: +33 92 94 42 00 791 Fax: +33 93 65 47 16 792 Blocks of 160 audio samples are compressed into 33 octets, for an 793 effective data rate of 13,200 b/s. 795 4.5.9.1 General Packaging Issues 797 The GSM standard (ETS 300 961) specifies the bit stream produced by 798 the codec, but does not specify how these bits should be packed for 799 transmission. The packetization specified here has subsequently been 800 adopted in ETSI Technical Specification TS 101 318. Some software 801 implementations of the GSM codec use a different packing than that 802 specified here. 804 In the GSM packing used by RTP, the bits SHALL be packed beginning 805 from the most significant bit. Every 160 sample GSM frame is coded 806 into one 33 octet (264 bit) buffer. Every such buffer begins with a 4 807 bit signature (0xD), followed by the MSB encoding of the fields of 808 the frame. The first octet thus contains 1101 in the 4 most 809 significant bits (0-3) and the 4 most significant bits of F1 (0-3) in 810 the 4 least significant bits (4-7). The second octet contains the 2 811 least significant bits of F1 in bits 0-1, and F2 in bits 2-7, and so 812 on. The order of the fields in the frame is described in Table 2. 814 4.5.9.2 GSM variable names and numbers 816 In the RTP encoding we have the bit pattern described in Table 3, 817 where F.i signifies the ith bit of the field F, bit 0 is the most 818 significant bit, and the bits of every octet are numbered from 0 to 7 819 from most to least significant. 821 4.5.10 GSM-HR 823 GSM-HR denotes GSM 06.20 half rate speech transcoding, specified in 824 ETS 300 969 which is available from ETSI at the address given in 825 Section 4.5.9. This codec has a frame length of 112 bits (14 octets). 826 Packing of the fields in the codec bit stream into octets for 827 transmission in RTP is done in a manner similar to that specified 828 here for the original GSM 06.10 codec and is specified in ETSI 829 Technical Specification TS 101 318. 831 4.5.11 GSM-EFR 833 GSM-EFR denotes GSM 06.60 enhanced full rate speech transcoding, 834 specified in ETS 300 969 which is available from ETSI at the address 835 given in Section 4.5.9. This codec has a frame length of 244 bits. 836 For transmission in RTP, each codec frame is packed into a 31 octet 837 (248 bit) buffer beginning with a 4-bit signature 0xC in a manner 838 field field name bits field field name bits 839 ________________________________________________ 840 1 LARc[0] 6 39 xmc[22] 3 841 2 LARc[1] 6 40 xmc[23] 3 842 3 LARc[2] 5 41 xmc[24] 3 843 4 LARc[3] 5 42 xmc[25] 3 844 5 LARc[4] 4 43 Nc[2] 7 845 6 LARc[5] 4 44 bc[2] 2 846 7 LARc[6] 3 45 Mc[2] 2 847 8 LARc[7] 3 46 xmaxc[2] 6 848 9 Nc[0] 7 47 xmc[26] 3 849 10 bc[0] 2 48 xmc[27] 3 850 11 Mc[0] 2 49 xmc[28] 3 851 12 xmaxc[0] 6 50 xmc[29] 3 852 13 xmc[0] 3 51 xmc[30] 3 853 14 xmc[1] 3 52 xmc[31] 3 854 15 xmc[2] 3 53 xmc[32] 3 855 16 xmc[3] 3 54 xmc[33] 3 856 17 xmc[4] 3 55 xmc[34] 3 857 18 xmc[5] 3 56 xmc[35] 3 858 19 xmc[6] 3 57 xmc[36] 3 859 20 xmc[7] 3 58 xmc[37] 3 860 21 xmc[8] 3 59 xmc[38] 3 861 22 xmc[9] 3 60 Nc[3] 7 862 23 xmc[10] 3 61 bc[3] 2 863 24 xmc[11] 3 62 Mc[3] 2 864 25 xmc[12] 3 63 xmaxc[3] 6 865 26 Nc[1] 7 64 xmc[39] 3 866 27 bc[1] 2 65 xmc[40] 3 867 28 Mc[1] 2 66 xmc[41] 3 868 29 xmaxc[1] 6 67 xmc[42] 3 869 30 xmc[13] 3 68 xmc[43] 3 870 31 xmc[14] 3 69 xmc[44] 3 871 32 xmc[15] 3 70 xmc[45] 3 872 33 xmc[16] 3 71 xmc[46] 3 873 34 xmc[17] 3 72 xmc[47] 3 874 35 xmc[18] 3 73 xmc[48] 3 875 36 xmc[19] 3 74 xmc[49] 3 876 37 xmc[20] 3 75 xmc[50] 3 877 38 xmc[21] 3 76 xmc[51] 3 879 Table 2: Ordering of GSM variables 881 similar to that specified here for the original GSM 06.10 codec. The 882 packing is specified in ETSI Technical Specification TS 101 318. 884 Octet Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 885 _____________________________________________________________________________ 886 0 1 1 0 1 LARc0.0 LARc0.1 LARc0.2 LARc0.3 887 1 LARc0.4 LARc0.5 LARc1.0 LARc1.1 LARc1.2 LARc1.3 LARc1.4 LARc1.5 888 2 LARc2.0 LARc2.1 LARc2.2 LARc2.3 LARc2.4 LARc3.0 LARc3.1 LARc3.2 889 3 LARc3.3 LARc3.4 LARc4.0 LARc4.1 LARc4.2 LARc4.3 LARc5.0 LARc5.1 890 4 LARc5.2 LARc5.3 LARc6.0 LARc6.1 LARc6.2 LARc7.0 LARc7.1 LARc7.2 891 5 Nc0.0 Nc0.1 Nc0.2 Nc0.3 Nc0.4 Nc0.5 Nc0.6 bc0.0 892 6 bc0.1 Mc0.0 Mc0.1 xmaxc00 xmaxc01 xmaxc02 xmaxc03 xmaxc04 893 7 xmaxc05 xmc0.0 xmc0.1 xmc0.2 xmc1.0 xmc1.1 xmc1.2 xmc2.0 894 8 xmc2.1 xmc2.2 xmc3.0 xmc3.1 xmc3.2 xmc4.0 xmc4.1 xmc4.2 895 9 xmc5.0 xmc5.1 xmc5.2 xmc6.0 xmc6.1 xmc6.2 xmc7.0 xmc7.1 896 10 xmc7.2 xmc8.0 xmc8.1 xmc8.2 xmc9.0 xmc9.1 xmc9.2 xmc10.0 897 11 xmc10.1 xmc10.2 xmc11.0 xmc11.1 xmc11.2 xmc12.0 xmc12.1 xcm12.2 898 12 Nc1.0 Nc1.1 Nc1.2 Nc1.3 Nc1.4 Nc1.5 Nc1.6 bc1.0 899 13 bc1.1 Mc1.0 Mc1.1 xmaxc10 xmaxc11 xmaxc12 xmaxc13 xmaxc14 900 14 xmax15 xmc13.0 xmc13.1 xmc13.2 xmc14.0 xmc14.1 xmc14.2 xmc15.0 901 15 xmc15.1 xmc15.2 xmc16.0 xmc16.1 xmc16.2 xmc17.0 xmc17.1 xmc17.2 902 16 xmc18.0 xmc18.1 xmc18.2 xmc19.0 xmc19.1 xmc19.2 xmc20.0 xmc20.1 903 17 xmc20.2 xmc21.0 xmc21.1 xmc21.2 xmc22.0 xmc22.1 xmc22.2 xmc23.0 904 18 xmc23.1 xmc23.2 xmc24.0 xmc24.1 xmc24.2 xmc25.0 xmc25.1 xmc25.2 905 19 Nc2.0 Nc2.1 Nc2.2 Nc2.3 Nc2.4 Nc2.5 Nc2.6 bc2.0 906 20 bc2.1 Mc2.0 Mc2.1 xmaxc20 xmaxc21 xmaxc22 xmaxc23 xmaxc24 907 21 xmaxc25 xmc26.0 xmc26.1 xmc26.2 xmc27.0 xmc27.1 xmc27.2 xmc28.0 908 22 xmc28.1 xmc28.2 xmc29.0 xmc29.1 xmc29.2 xmc30.0 xmc30.1 xmc30.2 909 23 xmc31.0 xmc31.1 xmc31.2 xmc32.0 xmc32.1 xmc32.2 xmc33.0 xmc33.1 910 24 xmc33.2 xmc34.0 xmc34.1 xmc34.2 xmc35.0 xmc35.1 xmc35.2 xmc36.0 911 25 Xmc36.1 xmc36.2 xmc37.0 xmc37.1 xmc37.2 xmc38.0 xmc38.1 xmc38.2 912 26 Nc3.0 Nc3.1 Nc3.2 Nc3.3 Nc3.4 Nc3.5 Nc3.6 bc3.0 913 27 bc3.1 Mc3.0 Mc3.1 xmaxc30 xmaxc31 xmaxc32 xmaxc33 xmaxc34 914 28 xmaxc35 xmc39.0 xmc39.1 xmc39.2 xmc40.0 xmc40.1 xmc40.2 xmc41.0 915 29 xmc41.1 xmc41.2 xmc42.0 xmc42.1 xmc42.2 xmc43.0 xmc43.1 xmc43.2 916 30 xmc44.0 xmc44.1 xmc44.2 xmc45.0 xmc45.1 xmc45.2 xmc46.0 xmc46.1 917 31 xmc46.2 xmc47.0 xmc47.1 xmc47.2 xmc48.0 xmc48.1 xmc48.2 xmc49.0 918 32 xmc49.1 xmc49.2 xmc50.0 xmc50.1 xmc50.2 xmc51.0 xmc51.1 xmc51.2 920 Table 3: GSM payload format 922 4.5.12 L8 924 L8 denotes linear audio data samples, using 8-bits of precision with 925 an offset of 128, that is, the most negative signal is encoded as 926 zero. 928 4.5.13 L16 929 L16 denotes uncompressed audio data samples, using 16-bit signed 930 representation with 65535 equally divided steps between minimum and 931 maximum signal level, ranging from -32768 to 32767. The value is 932 represented in two's complement notation and transmitted in network 933 byte order (most significant byte first). 935 4.5.14 LPC 937 LPC designates an experimental linear predictive encoding contributed 938 by Ron Frederick, Xerox PARC, which is based on an implementation 939 written by Ron Zuckerman, Motorola, posted to the Usenet group 940 comp.dsp on June 26, 1992. The codec generates 14 octets for every 941 frame. The framesize is set to 20 ms, resulting in a bit rate of 942 5,600 b/s. 944 4.5.15 MPA 946 MPA denotes MPEG-1 or MPEG-2 audio encapsulated as elementary 947 streams. The encoding is defined in ISO standards ISO/IEC 11172-3 948 and 13818-3. The encapsulation is specified in RFC 2250 [16]. 950 The encoding may be at any of three levels of complexity, called 951 Layer I, II and III. The selected layer as well as the sampling rate 952 and channel count are indicated in the payload. The RTP timestamp 953 clock rate is always 90000, independent of the sampling rate. MPEG-1 954 audio supports sampling rates of 32, 44.1, and 48 kHz (ISO/IEC 955 11172-3, section 1.1; "Scope"). MPEG-2 supports sampling rates of 16, 956 22.05 and 24 kHz. The number of samples per frame is fixed, but the 957 frame size will vary with the sampling rate and bit rate. 959 4.5.16 PCMA and PCMU 961 PCMA and PCMU are specified in ITU-T Recommendation G.711. Audio data 962 is encoded as eight bits per sample, after logarithmic scaling. PCMU 963 denotes mu-law scaling, PCMA A-law scaling. A detailed description is 964 given by Jayant and Noll [17]. Each G.711 octet SHALL be octet- 965 aligned in an RTP packet. The sign bit of each G.711 octet SHALL 966 correspond to the most significant bit of the octet in the RTP packet 967 (i.e., assuming the G.711 samples are handled as octets on the host 968 machine, the sign bit SHALL be the most signficant bit of the octet 969 as defined by the host machine format). The 56 kb/s and 48 kb/s modes 970 of G.711 are not applicable to RTP, since PCMA and PCMU SHALL always 971 be transmitted as 8-bit samples. 973 4.5.17 QCELP 975 The Electronic Industries Association (EIA) & Telecommunications 976 Industry Association (TIA) standard IS-733, "TR45: High Rate Speech 977 Service Option for Wideband Spread Spectrum Communications Systems," 978 defines the QCELP audio compression algorithm for use in wireless 979 CDMA applications. The QCELP CODEC compresses each 20 milliseconds of 980 8000 Hz, 16- bit sampled input speech into one of four different size 981 output frames: Rate 1 (266 bits), Rate 1/2 (124 bits), Rate 1/4 (54 982 bits) or Rate 1/8 (20 bits). For typical speech patterns, this 983 results in an average output of 6.8 k bits/sec for normal mode and 984 4.7 k bits/sec for reduced rate mode. The packetization of the QCELP 985 audio codec is described in [18]. 987 4.5.18 RED 989 The redundant audio payload format "RED" is specified by RFC 2198 990 [19]. It defines a means by which multiple redundant copies of an 991 audio packet may be transmitted in a single RTP stream. Each packet 992 in such a stream contains, in addition to the audio data for that 993 packetization interval, a (more heavily compressed) copy of the data 994 from a previous packetization interval. This allows an approximation 995 of the data from lost packets to be recovered upon decoding of a 996 subsequent packet, giving much improved sound quality when compared 997 with silence substitution for lost packets. 999 4.5.19 VDVI 1001 VDVI is a variable-rate version of DVI4, yielding speech bit rates of 1002 between 10 and 25 kb/s. It is specified for single-channel operation 1003 only. Samples are packed into octets starting at the most- 1004 significant bit. The last octet is padded with 1 bits if the last 1005 sample does not fill the last octet. This padding is distinct from 1006 the valid codewords. The receiver needs to detect the padding 1007 because there is no explicit count of samples in the packet. 1009 It uses the following encoding: 1011 DVI4 codeword VDVI bit pattern 1012 _______________________________ 1013 0 00 1014 1 010 1015 2 1100 1016 3 11100 1017 4 111100 1018 5 1111100 1019 6 11111100 1020 7 11111110 1021 8 10 1022 9 011 1023 10 1101 1024 11 11101 1025 12 111101 1026 13 1111101 1027 14 11111101 1028 15 11111111 1030 5 Video 1032 The following sections describe the video encodings that are defined 1033 in this memo and give their abbreviated names used for 1034 identification. These video encodings and their payload types are 1035 listed in Table 5. 1037 All of these video encodings use an RTP timestamp frequency of 90,000 1038 Hz, the same as the MPEG presentation time stamp frequency. This 1039 frequency yields exact integer timestamp increments for the typical 1040 24 (HDTV), 25 (PAL), and 29.97 (NTSC) and 30 Hz (HDTV) frame rates 1041 and 50, 59.94 and 60 Hz field rates. While 90 kHz is the RECOMMENDED 1042 rate for future video encodings used within this profile, other rates 1043 MAY be used. However, it is not sufficient to use the video frame 1044 rate (typically between 15 and 30 Hz) because that does not provide 1045 adequate resolution for typical synchronization requirements when 1046 calculating the RTP timestamp corresponding to the NTP timestamp in 1047 an RTCP SR packet. The timestamp resolution MUST also be sufficient 1048 for the jitter estimate contained in the receiver reports. 1050 For most of these video encodings, the RTP timestamp encodes the 1051 sampling instant of the video image contained in the RTP data packet. 1052 If a video image occupies more than one packet, the timestamp is the 1053 same on all of those packets. Packets from different video images are 1054 distinguished by their different timestamps. 1056 Most of these video encodings also specify that the marker bit of the 1057 RTP header SHOULD be set to one in the last packet of a video frame 1058 and otherwise set to zero. Thus, it is not necessary to wait for a 1059 following packet with a different timestamp to detect that a new 1060 frame should be displayed. 1062 5.1 BT656 1064 The encoding is specified in ITU-R Recommendation BT.656-3, 1065 "Interfaces for Digital Component Video Signals in 525-Line and 625- 1066 Line Television Systems operating at the 4:2:2 Level of 1067 Recommendation ITU-R BT.601 (Part A)". The packetization and RTP- 1068 specific properties are described in RFC 2431 [20]. 1070 5.2 CelB 1071 The CELL-B encoding is a proprietary encoding proposed by Sun 1072 Microsystems. The byte stream format is described in RFC 2029 [21]. 1074 5.3 JPEG 1076 The encoding is specified in ISO Standards 10918-1 and 10918-2. The 1077 RTP payload format is as specified in RFC 2435 [22]. 1079 5.4 H261 1081 The encoding is specified in ITU-T Recommendation H.261, "Video codec 1082 for audiovisual services at p x 64 kbit/s". The packetization and 1083 RTP-specific properties are described in RFC 2032 [23]. 1085 5.5 H263 1087 The encoding is specified in the 1996 version of ITU-T Recommendation 1088 H.263, "Video coding for low bit rate communication". The 1089 packetization and RTP-specific properties are described in RFC 2190 1090 [24]. 1092 5.6 H263-1998 1094 The encoding is specified in the 1998 version of ITU-T Recommendation 1095 H.263, "Video coding for low bit rate communication". The 1096 packetization and RTP-specific properties are described in RFC 2429 1097 [25]. Because the 1998 version of H.263 is a superset of the 1996 1098 syntax, this payload format can also be used with the 1996 version of 1099 H.263, and is RECOMMENDED for this use by new implementations. This 1100 payload format does not replace RFC 2190, which continues to be used 1101 by existing implementations, and may be required for backward 1102 compatibility in new implementations. Implementations using the new 1103 features of the 1998 version of H.263 MUST use the payload format 1104 described in RFC 2429. 1106 5.7 MPV 1108 MPV designates the use of MPEG-1 and MPEG-2 video encoding elementary 1109 streams as specified in ISO Standards ISO/IEC 11172 and 13818-2, 1110 respectively. The RTP payload format is as specified in RFC 2250 1111 [16], Section 3. 1113 5.8 MP2T 1115 MP2T designates the use of MPEG-2 transport streams, for either audio 1116 or video. The RTP payoad format is described in RFC 2250 [16], 1117 Section 2. 1119 5.9 MP1S 1121 MP1S designates an MPEG-1 systems stream, encapsulated according to 1122 RFC 2250 [16]. 1124 5.10 MP2P 1126 MP2P designates an MPEG-2 program stream, encapsulated according to 1127 RFC 2250 [16]. 1129 5.11 BMPEG 1131 BMPEG designates an experimental payload format for MPEG-1 and MPEG-2 1132 which specifies bundled (multiplexed) transport of audio and video 1133 elementary streams in one RTP stream as an alternative to the MP1S 1134 and MP2P formats. The packetization is described in RFC 2343 [26]. 1136 5.12 nv 1138 The encoding is implemented in the program `nv', version 4, developed 1139 at Xerox PARC by Ron Frederick. Further information is available from 1140 the author: 1142 Ron Frederick 1143 Xerox Palo Alto Research Center 1144 3333 Coyote Hill Road 1145 Palo Alto, CA 94304 1146 United States 1147 electronic mail: frederic@parc.xerox.com 1149 6 Payload Type Definitions 1151 Tables 4 and 5 define this profile's static payload type values for 1152 the PT field of the RTP data header. In addition, payload type 1153 values in the range 96-127 MAY be defined dynamically through a 1154 conference control protocol, which is beyond the scope of this 1155 document. For example, a session directory could specify that for a 1156 given session, payload type 96 indicates PCMU encoding, 8,000 Hz 1157 sampling rate, 2 channels. Entries in Tables 4 and 5 with payload 1158 type "dyn" have no static payload type assigned and are only used 1159 with a dynamic payload type. The payload type range marked `reserved' 1160 has been set aside so that RTCP and RTP packets can be reliably 1161 distinguished (see Section "Summary of Protocol Constants" of the RTP 1162 protocol specification). 1164 The payload types currently defined in this profile are assigned to 1165 exactly one of three categories or media types : audio only, video 1166 only and those combining audio and video. The media types are marked 1167 in Tables 4 and 5 as "A", "V" and "AV", respectively. Payload types 1168 of different media types SHALL NOT be interleaved or multiplexed 1169 within a single RTP session, but multiple RTP sessions MAY be used in 1170 parallel to send multiple media types. An RTP source MAY change 1171 payload types within the same media type during a session. See the 1172 section "Multiplexing RTP Sessions" of RFC XXXX for additional 1173 explanation. 1175 Session participants agree through mechanisms beyond the scope of 1176 this specification on the set of payload types allowed in a given 1177 session. This set MAY, for example, be defined by the capabilities 1178 of the applications used, negotiated by a conference control protocol 1179 or established by agreement between the human participants. 1181 Audio applications operating under this profile SHOULD, at a minimum, 1182 be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4). 1183 This allows interoperability without format negotiation and ensures 1184 successful negotation with a conference control protocol. 1186 7 RTP over TCP and Similar Byte Stream Protocols 1188 Under special circumstances, it may be necessary to carry RTP in 1189 protocols offering a byte stream abstraction, such as TCP, possibly 1190 multiplexed with other data. If the application does not define its 1191 own method of delineating RTP and RTCP packets, it SHOULD prefix each 1192 packet with a two-octet length field. 1194 (Note: RTSP [27] provides its own encapsulation and does not need an 1195 extra length indication.) 1197 8 Port Assignment 1199 As specified in the RTP protocol definition, RTP data SHOULD be 1200 carried on an even UDP or TCP port number and the corresponding RTCP 1201 packets SHOULD be carried on the next higher (odd) port number. 1203 Applications operating under this profile MAY use any such UDP or TCP 1204 port pair. For example, the port pair MAY be allocated randomly by a 1205 session management program. A single fixed port number pair cannot be 1206 required because multiple applications using this profile are likely 1207 to run on the same host, and there are some operating systems that do 1208 not allow multiple processes to use the same UDP port with different 1209 multicast addresses. 1211 However, port numbers 5004 and 5005 have been registered for use with 1212 this profile for those applications that choose to use them as the 1213 PT encoding media type clock rate channels 1214 name (Hz) 1215 ___________________________________________________ 1216 0 PCMU A 8000 1 1217 1 1016 A 8000 1 1218 2 G726-32 A 8000 1 1219 3 GSM A 8000 1 1220 4 G723 A 8000 1 1221 5 DVI4 A 8000 1 1222 6 DVI4 A 16000 1 1223 7 LPC A 8000 1 1224 8 PCMA A 8000 1 1225 9 G722 A 8000 1 1226 10 L16 A 44100 2 1227 11 L16 A 44100 1 1228 12 QCELP A 8000 1 1229 13 CN A 1230 14 MPA A 90000 (see text) 1231 15 G728 A 8000 1 1232 16 DVI4 A 11025 1 1233 17 DVI4 A 22050 1 1234 18 G729 A 8000 1 1235 19 unassigned A 8000 1 1236 20 unassigned A 1237 21 unassigned A 1238 22 unassigned A 1239 23 unassigned A 1240 dyn GSM-HR A 8000 1 1241 dyn GSM-EFR A 8000 1 1242 dyn RED A 1244 Table 4: Payload types (PT) for audio encodings 1246 default pair. Applications that operate under multiple profiles MAY 1247 use this port pair as an indication to select this profile if they 1248 are not subject to the constraint of the previous paragraph. 1249 Applications need not have a default and MAY require that the port 1250 pair be explicitly specified. The particular port numbers were chosen 1251 to lie in the range above 5000 to accommodate port number allocation 1252 practice within some versions of the Unix operating system, where 1253 port numbers below 1024 can only be used by privileged processes and 1254 port numbers between 1024 and 5000 are automatically assigned by the 1255 operating system. 1257 9 Changes from RFC 1890 1258 PT encoding media type clock rate 1259 name (Hz) 1260 ____________________________________________ 1261 24 unassigned V 1262 25 CelB V 90000 1263 26 JPEG V 90000 1264 27 unassigned V 1265 28 nv V 90000 1266 29 unassigned V 1267 30 unassigned V 1268 31 H261 V 90000 1269 32 MPV V 90000 1270 33 MP2T AV 90000 1271 34 H263 V 90000 1272 35-71 unassigned ? 1273 72-76 reserved N/A N/A 1274 77-95 unassigned ? 1275 96-127 dynamic ? 1276 dyn BT656 V 90000 1277 dyn H263-1998 V 90000 1278 dyn MP1S V 90000 1279 dyn MP2P V 90000 1280 dyn BMPEG V 90000 1282 Table 5: Payload types (PT) for video and combined encodings 1284 This RFC revises RFC 1890. It is fully backwards-compatible with RFC 1285 1890 and codifies existing practice. The changes are listed below. 1287 o Additional payload formats and/or expanded descriptions were 1288 included for CN, G722, G723, G726, G728, G729, GSM, GSM-HR, 1289 GSM-EFR, QCELP, RED, VDVI, BT656, H263-1998, MP1S, MP2P and 1290 BMPEG. 1292 o Static payload types 4, 12, 13, 16, 17, 18 and 34 were added. 1294 o The policy is established that no additional registration of 1295 static payload types for this Profile will be made beyond 1296 those included in Tables 4 and 5, but additional encoding 1297 names may be registered as MIME subtypes. 1299 o In Section 4.1, the requirement level for setting of the 1300 marker bit on the first packet after silence for audio was 1301 changed from "is" to "SHOULD be". 1303 o Similarly, text was added to specify that the marker bit 1304 SHOULD be set to one on the last packet of a video frame, and 1305 that video frames are distinguished by their timestamps. 1307 o This profile follows the suggestion in the RTP spec that RTCP 1308 bandwidth may be specified separately from the session 1309 bandwidth and separately for active senders and passive 1310 receivers. 1312 o RFC references are added for payload formats published after 1313 RFC 1890. 1315 o A minimal TCP encapsulation is defined. 1317 o The security considerations and full copyright sections were 1318 added. 1320 o According to Peter Hoddie of Apple, only pre-1994 Macintosh 1321 used the 22254.54 rate and none the 11127.27 rate, so the 1322 latter was dropped from the discussion of suggested sampling 1323 frequencies. 1325 o Table 1 was corrected to move some values from the 1326 "ms/packet" column to the "default ms/packet" column where 1327 they belonged. 1329 o A note has been added for G722 to clarify a discrepancy 1330 between the actual sampling rate and the RTP timestamp clock 1331 rate. 1333 o Small clarifications of the text have been made in several 1334 places, some in response to questions from readers. In 1335 particular: 1337 - A definition for "media type" is given in Section 1.1 to 1338 allow the explanation of multiplexing RTP sessions in 1339 Section 6 to be more clear regarding the multiplexing of 1340 multiple media. 1342 - The explanation of how to determine the number of audio 1343 frames in a packet from the length was expanded. 1345 - More description of the allocation of bandwidth to SDES 1346 items is given. 1348 - The terms MUST, SHOULD, MAY, etc. are used as defined in RFC 1349 2119. 1351 o A second author for this document was added. 1353 10 Security Considerations 1355 Implementations using the profile defined in this specification are 1356 subject to the security considerations discussed in the RTP 1357 specification [1]. This profile does not specify any different 1358 security services other than giving rules for mapping characters in a 1359 user-provided pass phrase to canonical form. The primary function of 1360 this profile is to list a set of data compression encodings for audio 1361 and video media. 1363 Confidentiality of the media streams is achieved by encryption. 1364 Because the data compression used with the payload formats described 1365 in this profile is applied end-to-end, encryption may be performed 1366 after compression so there is no conflict between the two operations. 1368 A potential denial-of-service threat exists for data encodings using 1369 compression techniques that have non-uniform receiver-end 1370 computational load. The attacker can inject pathological datagrams 1371 into the stream which are complex to decode and cause the receiver to 1372 be overloaded. However, the encodings described in this profile do 1373 not exhibit any significant non-uniformity. 1375 As with any IP-based protocol, in some circumstances a receiver may 1376 be overloaded simply by the receipt of too many packets, either 1377 desired or undesired. Network-layer authentication MAY be used to 1378 discard packets from undesired sources, but the processing cost of 1379 the authentication itself may be too high. In a multicast 1380 environment, pruning of specific sources may be implemented in future 1381 versions of IGMP [28] and in multicast routing protocols to allow a 1382 receiver to select which sources are allowed to reach it. 1384 11 Full Copyright Statement 1386 Copyright (C) The Internet Society (1999). All Rights Reserved. 1388 This document and translations of it may be copied and furnished to 1389 others, and derivative works that comment on or otherwise explain it 1390 or assist in its implmentation may be prepared, copied, published and 1391 distributed, in whole or in part, without restriction of any kind, 1392 provided that the above copyright notice and this paragraph are 1393 included on all such copies and derivative works. However, this 1394 document itself may not be modified in any way, such as by removing 1395 the copyright notice or references to the Internet Society or other 1396 Internet organizations, except as needed for the purpose of 1397 developing Internet standards in which case the procedures for 1398 copyrights defined in the Internet Standards process must be 1399 followed, or as required to translate it into languages other than 1400 English. 1402 The limited permissions granted above are perpetual and will not be 1403 revoked by the Internet Society or its successors or assigns. 1405 This document and the information contained herein is provided on an 1406 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1407 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1408 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1409 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1410 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1412 12 Acknowledgements 1414 The comments and careful review of Simao Campos, Richard Cox and AVT 1415 Working Group participants are gratefully acknowledged. The GSM 1416 description was adopted from the IMTC Voice over IP Forum Service 1417 Interoperability Implementation Agreement (January 1997). Fred Burg 1418 and Terry Lyons helped with the G.729 description. 1420 13 Addresses of Authors 1422 Henning Schulzrinne 1423 Dept. of Computer Science 1424 Columbia University 1425 1214 Amsterdam Avenue 1426 New York, NY 10027 1427 USA 1428 electronic mail: schulzrinne@cs.columbia.edu 1430 Stephen L. Casner 1431 Cisco Systems, Inc. 1432 170 West Tasman Drive 1433 San Jose, CA 95134 1434 United States 1435 electronic mail: casner@cisco.com 1437 A Bibliography 1439 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A 1440 transport protocol for real-time applications," Internet Draft, 1441 Internet Engineering Task Force, Feb. 1999 Work in progress, revision 1442 to RFC 1889. 1444 [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1445 Levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 1447 [3] P. Hoschka, "MIME Type Registration of RTP Payload Types," 1448 Internet Draft, Internet Engineering Task Force, Feb. 1999 Work in 1449 progress. 1451 [4] N. Freed, J. Klensin, and J. Postel, "Multipurpose Internet Mail 1452 Extensions (MIME) Part Four: Registration Procedures," RFC 2048, 1453 Internet Engineering Task Force, Nov. 1996. 1455 [5] M. Handley and V. Jacobson, "SDP: Session Description Protocol," 1456 Request for Comments (Proposed Standard) RFC 2327, Internet 1457 Engineering Task Force, Apr. 1998. 1459 [6] Apple Computer, "Audio interchange file format AIFF-C," Aug. 1460 1991. (also ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z). 1462 [7] Office of Technology and Standards, "Telecommunications: Analog 1463 to digital conversion of radio voice by 4,800 bit/second code excited 1464 linear prediction (celp)," Federal Standard FS-1016, GSA, Room 6654; 1465 7th & D Street SW; Washington, DC 20407 (+1-202-708-9205), 1990. 1467 [8] J. P. Campbell, Jr., T. E. Tremain, and V. C. Welch, "The 1468 proposed Federal Standard 1016 4800 bps voice coder: CELP," Speech 1469 Technology , vol. 5, pp. 58--64, April/May 1990. 1471 [9] J. P. Campbell, Jr., T. E. Tremain, and V. C. Welch, "The federal 1472 standard 1016 4800 bps CELP voice coder," Digital Signal Processing , 1473 vol. 1, no. 3, pp. 145--155, 1991. 1475 [10] J. P. Campbell, Jr., T. E. Tremain, and V. C. Welch, "The DoD 1476 4.8 kbps standard (proposed federal standard 1016)," in Advances in 1477 Speech Coding (B. Atal, V. Cuperman, and A. Gersho, eds.), ch. 12, 1478 pp. 121--133, Kluwer Academic Publishers, 1991. 1480 [11] IMA Digital Audio Focus and Technical Working Groups, 1481 "Recommended practices for enhancing digital audio compatibility in 1482 multimedia systems (version 3.00)," tech. rep., Interactive 1483 Multimedia Association, Annapolis, Maryland, Oct. 1992. 1485 [12] D. Deleam and J.-P. Petit, "Real-time implementations of the 1486 recent ITU-T low bit rate speech coders on the TI TMS320C54X DSP: 1487 results, methodology, and applications," in Proc. of International 1488 Conference on Signal Processing, Technology, and Applications 1489 (ICSPAT) , (Boston, Massachusetts), pp. 1656--1660, Oct. 1996. 1491 [13] M. Mouly and M.-B. Pautet, The GSM system for mobile 1492 communications Lassay-les-Chateaux, France: Europe Media Duplication, 1493 1993. 1495 [14] J. Degener, "Digital speech compression," Dr. Dobb's Journal , 1496 Dec. 1994. 1498 [15] S. M. Redl, M. K. Weber, and M. W. Oliphant, An Introduction to 1499 GSM Boston: Artech House, 1995. 1501 [16] D. Hoffman, G. Fernando, V. Goyal, and M. Civanlar, "RTP payload 1502 format for MPEG1/MPEG2 video," Request for Comments (Proposed 1503 Standard) RFC 2250, Internet Engineering Task Force, Jan. 1998. 1505 [17] N. S. Jayant and P. Noll, Digital Coding of Waveforms-- 1506 Principles and Applications to Speech and Video Englewood Cliffs, New 1507 Jersey: Prentice-Hall, 1984. 1509 [18] K. McKay, "RTP Payload Format for PureVoice(tm) Audio", Internet 1510 Draft, Internet Engineering Task Force, Oct. 1998. Work in progress. 1512 [19] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. 1513 Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload for 1514 Redundant Audio Data," Request for Comments (Proposed Standard) RFC 1515 2198, Internet Engineering Task Force, Sep. 1997. 1517 [20] D. Tynan, "RTP payload format for BT.656 Video Encoding," 1518 Request for Comments (Proposed Standard) RFC 2431, Internet 1519 Engineering Task Force, Oct. 1998. 1521 [21] M. Speer and D. Hoffman, "RTP payload format of sun's CellB 1522 video encoding," Request for Comments (Proposed Standard) RFC 2029, 1523 Internet Engineering Task Force, Oct. 1996. 1525 [22] L. Berc, W. Fenner, R. Frederick, and S. McCanne, "RTP payload 1526 format for JPEG-compressed video," Request for Comments (Proposed 1527 Standard) RFC 2435, Internet Engineering Task Force, Oct. 1996. 1529 [23] T. Turletti and C. Huitema, "RTP payload format for H.261 video 1530 streams," Request for Comments (Proposed Standard) RFC 2032, Internet 1531 Engineering Task Force, Oct. 1996. 1533 [24] C. Zhu, "RTP payload format for H.263 video streams," Request 1534 for Comments (Proposed Standard) RFC 2190, Internet Engineering Task 1535 Force, Sep. 1997. 1537 [25] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. 1538 Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu, "RTP Payload Format 1539 for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)," Request for 1540 Comments (Proposed Standard) RFC 2429, Internet Engineering Task 1541 Force, Oct. 1998. 1543 [26] M. Civanlar, G. Cash, B. Haskell, "RTP Payload Format for 1544 Bundled MPEG," Request for Comments (Experimental) RFC 2343, Internet 1545 Engineering Task Force, May 1998. 1547 [27] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming 1548 protocol (RTSP)," Request for Comments (Proposed Standard) RFC 2326, 1549 Internet Engineering Task Force, Apr. 1998. 1551 [28] S. Deering, "Host Extensions for IP Multicasting," Request for 1552 Comments RFC 1112, STD 5, Internet Engineering Task Force, Aug. 1989. 1554 Current Locations of Related Resources 1556 Note: Several sections below refer to the ITU-T Software Tool Library 1557 (STL). It is available from the ITU Sales Service, Place des Nations, 1558 CH-1211 Geneve 20, Switzerland (also check http://www.itu.int. The 1559 ITU-T STL is covered by a license defined in ITU-T Recommendation 1560 G.191, "Software tools for speech and audio coding standardization". 1562 UTF-8 1564 Information on the UCS Transformation Format 8 (UTF-8) is available 1565 at 1567 http://www.stonehand.com/unicode/standard/utf8.html 1569 1016 1571 The U.S. DoD's Federal-Standard-1016 based 4800 bps code excited 1572 linear prediction voice coder version 3.2 (CELP 3.2) Fortran and C 1573 simulation source codes are available for worldwide distribution at 1574 no charge (on DOS diskettes, but configured to compile on Sun SPARC 1575 stations) from: Bob Fenichel, National Communications System, 1576 Washington, D.C. 20305, phone +1-703-692-2124, fax +1-703-746-4960. 1578 An implementation is also available at 1580 ftp://ftp.super.org/pub/speech/celp_3.2a.tar.Z 1582 DVI4 1584 An implementation is available from Jack Jansen at 1586 ftp://ftp.cwi.nl/local/pub/audio/adpcm.shar 1588 G722 1590 An implementation of the G.722 algorithm is available as part of the 1591 ITU-T STL, described above. 1593 G723 1595 The reference C code implementation defining the G.723.1 algorithm 1596 and its Annexes A, B, and C are available as an integral part of 1597 Recommendation G.723.1 from the ITU Sales Service, address listed 1598 above. Both the algorithm and C code are covered by a specific 1599 license. The ITU-T Secretariat should be contacted to obtain such 1600 licensing information. 1602 G726-32 1604 G726-32 is specified in the ITU-T Recommendation G.726, "40, 32, 24, 1605 and 16 kb/s Adaptive Differential Pulse Code Modulation (ADPCM)". An 1606 implementation of the G.726 algorithm is available as part of the 1607 ITU-T STL, described above. 1609 G729 1611 The reference C code implementation defining the G.729 algorithm and 1612 its Annexes A and B are available as an integral part of 1613 Recommendation G.729 from the ITU Sales Service, listed above. Both 1614 the algorithm and the C code are covered by a specific license. The 1615 contact information for obtaining the license is listed in the C 1616 code. 1618 GSM 1620 A reference implementation was written by Carsten Borman and Jutta 1621 Degener (TU Berlin, Germany). It is available at 1623 ftp://ftp.cs.tu-berlin.de/pub/local/kbs/tubmik/gsm/ 1625 Although the RPE-LTP algorithm is not an ITU-T standard, there is a C 1626 code implementation of the RPE-LTP algorithm available as part of the 1627 ITU-T STL. The STL implementation is an adaptation of the TU Berlin 1628 version. 1630 LPC 1632 An implementation is available at 1634 ftp://parcftp.xerox.com/pub/net-research/lpc.tar.Z 1636 PCMU, PCMA 1638 An implementation of these algorithm is available as part of the 1639 ITU-T STL, described above. Code to convert between linear and mu-law 1640 companded data is also available in [11]. 1642 Table of Contents 1644 1 Introduction ........................................ 2 1645 1.1 Terminology ......................................... 3 1646 2 RTP and RTCP Packet Forms and Protocol Behavior ..... 3 1647 3 Registering Additional Encodings with IANA .......... 6 1648 4 Audio ............................................... 7 1649 4.1 Encoding-Independent Rules .......................... 7 1650 4.2 Operating Recommendations ........................... 9 1651 4.3 Guidelines for Sample-Based Audio Encodings ......... 9 1652 4.4 Guidelines for Frame-Based Audio Encodings .......... 10 1653 4.5 Audio Encodings ..................................... 10 1654 4.5.1 1016 ................................................ 11 1655 4.5.2 CN .................................................. 11 1656 4.5.3 DVI4 ................................................ 12 1657 4.5.4 G722 ................................................ 13 1658 4.5.5 G723 ................................................ 14 1659 4.5.6 G726-32 ............................................. 14 1660 4.5.7 G728 ................................................ 15 1661 4.5.8 G729 ................................................ 16 1662 4.5.9 GSM ................................................. 17 1663 4.5.9.1 General Packaging Issues ............................ 18 1664 4.5.9.2 GSM variable names and numbers ...................... 18 1665 4.5.10 GSM-HR .............................................. 18 1666 4.5.11 GSM-EFR ............................................. 18 1667 4.5.12 L8 .................................................. 20 1668 4.5.13 L16 ................................................. 20 1669 4.5.14 LPC ................................................. 21 1670 4.5.15 MPA ................................................. 21 1671 4.5.16 PCMA and PCMU ....................................... 21 1672 4.5.17 QCELP ............................................... 21 1673 4.5.18 RED ................................................. 22 1674 4.5.19 VDVI ................................................ 22 1675 5 Video ............................................... 23 1676 5.1 BT656 ............................................... 23 1677 5.2 CelB ................................................ 23 1678 5.3 JPEG ................................................ 24 1679 5.4 H261 ................................................ 24 1680 5.5 H263 ................................................ 24 1681 5.6 H263-1998 ........................................... 24 1682 5.7 MPV ................................................. 24 1683 5.8 MP2T ................................................ 24 1684 5.9 MP1S ................................................ 25 1685 5.10 MP2P ................................................ 25 1686 5.11 BMPEG ............................................... 25 1687 5.12 nv .................................................. 25 1688 6 Payload Type Definitions ............................ 25 1689 7 RTP over TCP and Similar Byte Stream Protocols ...... 26 1690 8 Port Assignment ..................................... 26 1691 9 Changes from RFC 1890 ............................... 27 1692 10 Security Considerations ............................. 30 1693 11 Full Copyright Statement ............................ 30 1694 12 Acknowledgements .................................... 31 1695 13 Addresses of Authors ................................ 31 1696 A Bibliography ........................................ 31