idnits 2.17.1 draft-ietf-avt-compact-bundled-evrc-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 960. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 937. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 944. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 950. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3558, but the abstract doesn't seem to directly say this. It does mention RFC3558 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC3558, updated by this document, for RFC5378 checks: 2002-02-05) -- 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 17, 2006) is 6394 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 4566 (ref. '7') (Obsoleted by RFC 8866) -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-05) exists of draft-ietf-avt-rfc3555bis-03 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Xie 3 Internet-Draft Motorola 4 Updates: RFC 3558 (if approved) R. Kapoor 5 Expires: April 20, 2007 Qualcomm 6 October 17, 2006 8 Enhancements to RTP Payload Formats for EVRC Family Codecs 9 draft-ietf-avt-compact-bundled-evrc-11.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 20, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document updates the Enhanced Variable Rate Codec (EVRC) RTP 43 payload formats defined in RFC 3558 with several enhancements and 44 extensions. In particular, it defines support for the header-free 45 and interleaved/bundled packet formats for the EVRC-B codec, a new 46 compact bundled format for the EVRC and EVRC-B codecs, as well as 47 discontinuous transmission (DTX) support for EVRC and EVRC-B encoded 48 speech transported via RTP. VoIP applications operating over low 49 bandwidth dial-up and wireless networks require such enhancements for 50 efficient use of the bandwidth. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Support of EVRC-B Codec . . . . . . . . . . . . . . . . . 3 56 1.2 Compact (Header-free) Bundled Format . . . . . . . . . . . 3 57 1.3 Discontinuous Transmission (DTX) . . . . . . . . . . . . . 4 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. EVRC-B Codec . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Compact Bundled Format . . . . . . . . . . . . . . . . . . . 5 61 4.1 Single Rate Operation . . . . . . . . . . . . . . . . . . 5 62 5. Storage Format For EVRC-B Codec . . . . . . . . . . . . . . 6 63 6. Media Type Definitions . . . . . . . . . . . . . . . . . . . 6 64 6.1 Registration of Media Type EVRC1 . . . . . . . . . . . . . 6 65 6.2 Registration of Media Type EVRCB . . . . . . . . . . . . . 9 66 6.3 Registration of Media Type EVRCB0 . . . . . . . . . . . . 11 67 6.4 Registration of Media Type EVRCB1 . . . . . . . . . . . . 12 68 6.5 Updated Registration of Media Type EVRC . . . . . . . . . 13 69 6.6 Updated Registration of Media Type EVRC0 . . . . . . . . . 15 70 6.7 Mapping MIME Parameters into SDP . . . . . . . . . . . . . 17 71 6.8 Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 18 72 7. Backward Compatibility with RFC 3558 . . . . . . . . . . . . 19 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 74 9. Security Considerations . . . . . . . . . . . . . . . . . . 19 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 11.1 Normative References . . . . . . . . . . . . . . . . . . 20 78 11.2 Informative References . . . . . . . . . . . . . . . . . 20 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 80 Intellectual Property and Copyright Statements . . . . . . . 22 82 1. Introduction 84 This document defines support for the header-free and interleaved/ 85 bundled packet formats for the EVRC-B codec, a new compact bundled 86 format for the EVRC and EVRC-B codecs, as well as discontinuous 87 transmission (DTX) support for EVRC and EVRC-B encoded speech 88 transported via RTP. VoIP applications operating over low bandwidth 89 dial-up and wireless networks require such EVRC RTP payload 90 capabilities for efficient use of the bandwidth. 92 1.1 Support of EVRC-B Codec 94 EVRC-B [3] is an extension to [2] developed in 3GPP2. EVRC-B [3] 95 compresses each 20 milliseconds of 8000Hz, 16-bit sampled speech 96 input into output frames of one of the four different sizes: Rate 1 97 (171 bits), Rate 1/2 (80 bits), Rate 1/4 (40 bits), or Rate 1/8 (16 98 bits). In addition, there are two zero bit codec frame types: null 99 frames and erasure frames, similar to EVRC [2]. One significant 100 enhancement in EVRC-B is the use of 1/4 rate frames that were not 101 used in EVRC. This provides lower average data rates (ADRs) compared 102 to EVRC, for a given voice quality. 104 Since speech frames encoded by EVRC-B are different from those 105 encoded by EVRC, EVRC-B and EVRC codecs do not interoperate with each 106 other. At the initiation of a RTP session, the RTP sender and 107 receiver need to indicate (e.g., using MIME subtypes that are 108 separate from those of EVRC) that EVRC-B is to be used for the 109 ensuing session. 111 1.2 Compact (Header-free) Bundled Format 113 The current interleaved/bundled packet format defined in RFC 3558 114 allows bundling of multiple speech frames of different rate in a 115 single RTP packet, sending mode change requests, and interleaving. 116 To support these functions, a Table of Contents (ToC) is used in each 117 RTP packet in addition to the standard RTP header. The size of the 118 ToC is variable, depending on the number of EVRC frames carried in 119 the packet [4]. 121 The current header-free packet format defined in RFC 3558 is more 122 compact and optimized for use over wireless links. It eliminates the 123 need for a ToC by requiring that each RTP packet contain only one 124 speech frame (of any allowable rate), i.e., bundling is not allowed. 125 Moreover, interleaving and mode change request are not supported in 126 the header-free format [4]. 128 The compact bundled format described in this document presents the 129 user an alternative to the header-free format defined in RFC 3558. 131 This format allows bundling of multiple EVRC or EVRC-B frames without 132 the addition of extra headers, as would be in case of the 133 interleaved/bundled format. However, in order to use this compact 134 bundled format, only one EVRC/EVRC-B rate (full rate or 1/2 rate) can 135 be used in the session. Similar to the header-free format defined in 136 RFC 3558, interleaving and mode change request are not supported in 137 the compact bundled format. 139 1.3 Discontinuous Transmission (DTX) 141 Information carried in frames of EVRC and EVRC-B codecs varies little 142 during periods of silence. The transmission of these frames across 143 the radio interface in a wireless system is expensive in terms of 144 capacity, and therefore, suppression of these frames is desirable. 145 Such an operation is called DTX, also known as silence suppression. 147 In general, when DTX/silence suppression is applied, the first few 148 frames of silence may be transmitted at the beginning of the period 149 of silence to establish background noise. Then a portion of the 150 stream of subsequent silence frames is not transmitted and is 151 discarded at the sender. At the receiver, background or comfort 152 noise may be generated by using the previously received silence 153 frames. 155 The full detail of DTX/silence suppression operation can be found in 156 [8] as well as RFC 3551 [9] and RFC 3558 [4]. This document only 157 defines the additional optional MIME parameters (silencesupp, dtxmax, 158 dtxmin, and hangover) for setting up a DTX/silence suppression 159 session, where "silencesupp" is for indicating the capability and 160 willingness of using DTX/silence suppression, "dtxmax" and "dtxmin" 161 for indicating the desired range of DTX update interval, and 162 "hangover" for indicating the desired number of silence frames at the 163 beginning of each silence period to establish background noise at the 164 receiver (see Section 6.1 for detailed definition). 166 The EVRC and EVRC-B codecs in variable rate operation mode send 1/8 167 rate frames during periods of silence, while in single rate operation 168 mode (see Section 4), silence is encoded and sent in frames of the 169 same rate as that of speech frames. The DTX parameters defined in 170 this document apply to 1/8th rate frames in the variable rate mode 171 and to silence frames in the single rate operation mode. 173 For simplicity, in the rest of this document the term "silence frame" 174 refers either to an 1/8th rate frame in variable rate operation or a 175 frame that contains only silence in the signal rate operation. 177 2. Conventions 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC 2119 [1]. 183 3. EVRC-B Codec 185 Three RTP packet formats are supported for the EVRC-B codec - the 186 interleaved/bundled packet format, the header-free packet format and 187 the compact bundled packet format. For the interleaved/bundled and 188 header-free packet formats, the operational details and capabilities, 189 such as ToC, interleaving, and bundling, of EVRC-B are exactly the 190 same as those of EVRC, as defined in RFC 3558 [4], except that the 191 mode change request field in the ToC MUST be interpreted according to 192 the definition of the RATE_REDUC parameter in EVRC-B [3]. The 193 compact bundled packet format for EVRC-B is defined in Section 4 of 194 this document. 196 4. Compact Bundled Format 198 A packet in the compact bundled format consists of an RTP header 199 followed by a sequence of one or more consecutive EVRC/EVRC-B codec 200 data frames of the same rate, as shown below: 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | RTP Header [4] | 206 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 207 | | 208 | One or more EVRC/EVRC-B data frames of same rate | 209 | .... | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 The codec data frames MUST be generated from the output of the codec 213 following the procedure described in 5.2 in RFC 3558 [4] and all MUST 214 be of the same rate and size. 216 4.1 Single Rate Operation 218 As mentioned earlier, in order to use the compact bundled format, all 219 the EVRC/EVRC-B data frames in the session MUST be of the same rate. 220 This packet format may carry only full or half-rate frames. 222 For a session that uses the compact bundled format, the rate for the 223 session can be determined during the session setup signaling, for 224 example, via SDP exchanges. See Section 6 below for more details. 226 5. Storage Format For EVRC-B Codec 228 The storage format is used for storing EVRC-B encoded speech frames, 229 e.g., as a file or e-mail attachment. 231 The file begins with a magic number to identify the vocoder that is 232 used. The magic number for EVRC-B corresponds to the ASCII character 233 string: 235 "#!EVRC-B\n" 236 (or 0x2321 0x4556 0x5243 0x2d42 0x0a in hexadecimal). 238 Note, the "\n" is an important part of both this magic number and the 239 "#!EVRC\n" magic number defined in Section 11 of RFC 3558 and the 240 "\n" MUST be included in any comparison of either magic number, 241 since, otherwise, a prefix of the EVRC-B magic number could be 242 mistaken for the EVRC magic number. 244 The codec data frames are stored in consecutive order, with a single 245 TOC entry field, extended to one octet, prefixing each codec data 246 frame. The ToC field as defined in Section 5.1 of [4] is extended to 247 one octet by setting the four most significant bits of the octet to 248 zero. For example, a ToC value of 4 (a full-rate frame) is stored as 249 0x04. 251 Speech frames lost in transmission and non-received frames MUST be 252 stored as erasure frames to maintain synchronization with the 253 original media. 255 6. Media Type Definitions 257 [-- RFC Editor: Please replace all instances of "RFC XXXX" in this 258 and subsequent sections with the RFC number of this document prior to 259 IANA registration and RFC publication, and remove this note.] 261 6.1 Registration of Media Type EVRC1 263 Type name: audio 265 Subtype names: EVRC1 267 Required parameters: none 269 Optional parameters: 271 ptime: see RFC 4566 [7]. 273 maxptime: The maximum amount of media which can be encapsulated in 274 each packet, expressed as time in milliseconds. The time MUST 275 be calculated as the sum of the time the media present in the 276 packet represents. The time SHOULD be a multiple of the 277 duration of a single codec data frame (20 msec). If not 278 signaled, the default maxptime value MUST be 200 milliseconds. 280 fixedrate: Indicates the EVRC rate of the session while in single 281 rate operation. Valid values include: 0.5 and 1, where a value 282 of 0.5 indicates the 1/2 rate while a value of 1 indicates the 283 full rate. If this parameter is not present, 1/2 rate is 284 assumed. 286 silencesupp: Permissible values are 0 and 1. A value of 1 287 indicates that the sender of this parameter: a) is capable of 288 receiving silence suppressed speech using DTX, AND b) is 289 capable of and will send out silence suppressed speech using 290 DTX, unless the other end indicates that it does not want to 291 receive silence suppressed speech using DTX. 293 A value of 0 indicates that the sender of this parameter: a) 294 does NOT want to receive silence suppressed speech using DTX, 295 AND b) will NOT send out silence suppressed speech using DTX. 297 If this parameter is not present, the default value 1 MUST be 298 assumed. If the RTP receiver indicates through the use of SIP 299 signaling or other means that it is incapable of or unwilling 300 to use silence suppression using DTX, silence suppression using 301 DTX as specified in this document MUST NOT be used for the 302 session. 304 dtxmax: Permissible values are from 0 to 255. Indicates the 305 maximum DTX update interval in number of frames. During DTX, 306 the RTP sender occasionally updates the RTP receiver about the 307 change in background noise characteristics, etc., by sending a 308 new silence frame to the RTP receiver. The RTP receiver may 309 use 'dtxmax' to indicate to the RTP sender the maximum interval 310 (in number of frames) between any two DTX updates it expects to 311 receive from the RTP sender. 313 If this parameter is not present in a session that uses DTX, 314 the default value, 32, as specified in [8] MUST be assumed. 315 This parameter MUST be ignored if silence suppression using DTX 316 is not used for the session. 318 Note also that if the RTP receiver elects to detect DTX using 319 dtxmax, the dtxmax parameter will affect the amount of delay 320 the RTP receiver sees before detecting DTX in the stream. 322 dtxmin: Permissible values are from 0 to 255. Indicates the 323 minimum DTX update interval in number of frames. The RTP 324 receiver may use 'dtxmin' to indicate to the RTP sender the 325 minimal interval (in number of frames) between any two DTX 326 updates it expects to receive from the RTP sender. 328 If this parameter is not present, the default value, 12, as 329 specified in [8] MUST be assumed. This parameter MUST be 330 ignored if silence suppression using DTX is not used for the 331 session. 333 hangover: Permissible values are from 0 to 255. Indicates the 334 number of consecutive silence frames transmitted at the end of 335 an active speech interval but before the DTX interval begins. 336 When setting up an RTP session that uses DTX, an RTP receiver 337 can use this parameter to signal the number of silence frames 338 it expects to receive before the beginning of DTX. While 339 hangover=0 is allowed, it is RECOMMENDED that hangover be set 340 to 1 or greater since the presence of silence frames at the end 341 of active speech can help the RTP receiver to identify the 342 beginning of the DTX period. 344 If this parameter is not present for a session that uses DTX, 345 the default value, 1, as specified in [8] MUST be assumed. 346 This parameter MUST be ignored if silence suppression using DTX 347 is not used for the session. 349 Encoding considerations: 350 This media type is framed binary data (see RFC 4288, Section 4.8) 351 and is defined for transfer of EVRC encoded data via RTP using the 352 compact bundled format as described in RFC XXXX. 354 Security considerations: See Section 9 of RFC XXXX. 356 Interoperability considerations: none 358 Published specification: 359 The EVRC vocoder is specified in 3GPP2 C.S0014 [2]. Transfer 360 method with compact bundled RTP format is specified in RFC XXXX. 362 Applications that use this media type: 363 It is expected that many VoIP applications (as well as mobile 364 applications) will use this type. 366 Additional information: none 368 Person & email address to contact for further information: 369 Qiaobing Xie 371 Intended usage: COMMON 373 Restrictions on usage: 374 This media type depends on RTP framing, and hence is only defined 375 for transfer via RTP (RFC 3550 [5]). Transfer within other 376 framing protocols is not defined at this time. 378 Author: 379 Qiaobing Xie 381 Change controller: 382 IETF Audio/Video Transport working group delegated from the IESG. 384 6.2 Registration of Media Type EVRCB 386 Type name: audio 388 Subtype names: EVRCB 390 Required parameters: none 392 Optional parameters: 394 ptime: see RFC 4566 [7]. 396 maxptime: The maximum amount of media which can be encapsulated in 397 each packet, expressed as time in milliseconds. The time MUST 398 be calculated as the sum of the time the media present in the 399 packet represents. The time SHOULD be a multiple of the 400 duration of a single codec data frame (20 msec). If not 401 signaled, the default maxptime value MUST be 200 milliseconds. 403 maxinterleave: Maximum number for interleaving length (field LLL 404 in the Interleaving Octet). The interleaving lengths used in 405 the entire session MUST NOT exceed this maximum value. If not 406 signaled, the maxinterleave length MUST be 5. 408 silencesupp: see Section 6.1 for definition. If this parameter is 409 not present, the default value 1 MUST be assumed. 411 dtxmax: see Section 6.1 413 dtxmin: see Section 6.1 415 hangover: see Section 6.1 417 Encoding considerations: 418 This media type is framed binary data (see RFC 4288, Section 4.8) 419 and is defined for transfer of EVRC-B encoded data via RTP using 420 the Interleaved/Bundled packet format specified in RFC 3558 [4]. 422 Security considerations: See Section 9 of RFC XXXX. 424 Interoperability considerations: none 426 Published specification: 427 The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [3]. Transfer 428 method with Interleaved/Bundled packet format via RTP is specified 429 in RFC 3558. 431 Applications that use this media type: 432 It is expected that many VoIP applications (as well as mobile 433 applications) will use this type. 435 Additional information: 436 The following information applies for storage format only. 438 Magic number: #!EVRC-B\n (see Section 5 of RFC XXXX) 439 File extensions: evb, EVB 440 Macintosh file type code: none 441 Object identifier or OID: none 443 Person & email address to contact for further information: 444 Qiaobing Xie 446 Intended usage: COMMON 448 Restrictions on usage: 449 This media type may be used with RTP framing (RFC 3550 [5]) and as 450 a storage format. When used with RTP, the procedures in Section 3 451 MUST be followed. In all other contexts, the storage format 452 defined in Section 5 MUST be used. 454 Author: 455 Qiaobing Xie 457 Change controller: 458 IETF Audio/Video Transport working group delegated from the IESG. 460 6.3 Registration of Media Type EVRCB0 462 Type name: audio 464 Subtype names: EVRCB0 466 Required parameters: none 468 Optional parameters: 470 silencesupp: see Section 6.1 for definition. If this parameter is 471 not present, the default value 1 MUST be assumed. 473 dtxmax: see Section 6.1 475 dtxmin: see Section 6.1 477 hangover: see Section 6.1 479 Encoding considerations: 480 This media type is framed binary data (see RFC 4288, Section 4.8) 481 and is defined for transfer of EVRC-B encoded data via RTP using 482 the Header-Free packet format specified in RFC 3558 [4]. 484 Security considerations: See Section 9 of RFC XXXX. 486 Interoperability considerations: none 488 Published specification: 489 The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [3]. Transfer 490 method with Header-Free packet format via RTP is specified in RFC 491 3558 and RFC XXXX. 493 Applications that use this media type: 494 It is expected that many VoIP applications (as well as mobile 495 applications) will use this type. 497 Additional information: none 499 Person & email address to contact for further information: 500 Qiaobing Xie 502 Intended usage: COMMON 504 Restrictions on usage: 505 This media type depends on RTP framing, and hence is only defined 506 for transfer via RTP (RFC 3550 [5]). Transfer within other 507 framing protocols is not defined at this time. 509 Author: 510 Qiaobing Xie 512 Change controller: 513 IETF Audio/Video Transport working group delegated from the IESG. 515 6.4 Registration of Media Type EVRCB1 517 Type name: audio 519 Subtype names: EVRCB1 521 Required parameters: none 523 Optional parameters: 525 ptime: see RFC 4566 [7]. 527 maxptime: The maximum amount of media which can be encapsulated in 528 each packet, expressed as time in milliseconds. The time MUST 529 be calculated as the sum of the time the media present in the 530 packet represents. The time SHOULD be a multiple of the 531 duration of a single codec data frame (20 msec). If not 532 signaled, the default maxptime value MUST be 200 milliseconds. 534 fixedrate: Indicates the EVRC-B rate of the session while in 535 single rate operation. Valid values include: 0.5 and 1, where 536 a value of 0.5 indicates the 1/2 rate while a value of 1 537 indicates the full rate. If this parameter is not present, 1/2 538 rate is assumed. 540 silencesupp: see Section 6.1 for definition. If this parameter is 541 not present, the default value 1 MUST be assumed. 543 dtxmax: see Section 6.1 545 dtxmin: see Section 6.1 546 hangover: see Section 6.1 548 Encoding considerations: 549 This media type is framed binary data (see RFC 4288, Section 4.8) 550 and is defined for transfer of EVRC-B encoded data via RTP using 551 the compact bundled format as described in RFC XXXX. 553 Security considerations: See Section 9 of RFC XXXX. 555 Interoperability considerations: none. 557 Published specification: 558 The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [3]. Transfer 559 method with compact bundled RTP format is specified in RFC XXXX. 561 Applications that use this media type: 562 It is expected that many VoIP applications (as well as mobile 563 applications) will use this type. 565 Additional information: none 567 Person & email address to contact for further information: 568 Qiaobing Xie 570 Intended usage: COMMON 572 Restrictions on usage: 573 This media type depends on RTP framing, and hence is only defined 574 for transfer via RTP (RFC 3550 [5]). Transfer within other 575 framing protocols is not defined at this time. 577 Author: 578 Qiaobing Xie 580 Change controller: 581 IETF Audio/Video Transport working group delegated from the IESG. 583 6.5 Updated Registration of Media Type EVRC 585 (The definition is from RFC 3558, added with the optional DTX 586 parameters, and updated with the new template specified in [10].) 588 Type name: audio 589 Subtype names: EVRC 591 Required parameters: none 593 Optional parameters: 595 ptime: Defined as usual for RTP audio (see RFC 4566). 597 maxptime: The maximum amount of media which can be encapsulated in 598 each packet, expressed as time in milliseconds. The time SHALL 599 be calculated as the sum of the time the media present in the 600 packet represents. The time SHOULD be a multiple of the 601 duration of a single codec data frame (20 msec). If not 602 signaled, the default maxptime value SHALL be 200 milliseconds. 604 maxinterleave: Maximum number for interleaving length (field LLL 605 in the Interleaving Octet). The interleaving lengths used in 606 the entire session MUST NOT exceed this maximum value. If not 607 signaled, the maxinterleave length SHALL be 5. 609 silencesupp: see Section 6.1 for definition. If this parameter is 610 not present, the default value 1 MUST be assumed. 612 dtxmax: see Section 6.1 614 dtxmin: see Section 6.1 616 hangover: see Section 6.1 618 Encoding considerations: 619 This media type is framed binary data (see RFC 4288, Section 4.8) 620 and is defined for transfer of EVRC-encoded data via RTP using the 621 Interleaved/Bundled packet format specified in Sections 4.1, 6, 622 and 7 of RFC 3558. It is also defined for other transfer methods 623 using the storage format specified in Section 11 of RFC 3558. 625 Security considerations: See Section 14 "Security Considerations" of 626 RFC 3558. 628 Interoperability considerations: 629 The DTX parameters are receiver options. Existing RFC 3558 630 implementations will not send any of the DTX parameters in their 631 SDP and will ignore any DTX parameters they receive. The adaptive 632 DTX behavior of DTX-capable EVRC codecs (as detailed in [8], 633 Section 4.3.5) ensures interoperability with non-DTX EVRC codecs. 635 Published specification: The EVRC vocoder is specified in 3GPP2 636 C.S0014. Transfer methods are specified in RFC 3558. 638 Applications that use this media type: 639 It is expected that many VoIP applications (as well as mobile 640 applications) will use this type. 642 Additional information: 643 The following information applies for storage format only. 645 Magic number: #!EVRC\n (see Section 11 of RFC 3558) 646 File extensions: evc, EVC 647 Macintosh file type code: none 648 Object identifier or OID: none 650 Person & email address to contact for further information: 651 Qiaobing Xie 653 Intended usage: COMMON 655 Restrictions on usage: 656 This media type may be used with RTP framing (RFC 3550 [5]) and as 657 a storage format. When used with RTP, the procedures in RFC 3558, 658 Section 4.1 MUST be followed. In all other contexts, the storage 659 format defined in RFC 3558, Section 11 MUST be used. 661 Author: 662 Adam Li/Qiaobing Xie 664 Change controller: 665 IETF Audio/Video Transport working group delegated from the IESG. 667 6.6 Updated Registration of Media Type EVRC0 669 (The definition is from RFC 3558, added with the optional DTX 670 parameters, and updated with the new template specified in [10].) 672 Type name: audio 674 Subtype names: EVRC0 676 Required parameters: none 678 Optional parameters: 680 silencesupp: see Section 6.1 for definition. If this parameter is 681 not present, the default value 1 MUST be assumed. 683 dtxmax: see Section 6.1 685 dtxmin: see Section 6.1 687 hangover: see Section 6.1 689 Encoding considerations: 690 This media type is framed binary data (see RFC 4288, Section 4.8) 691 and is only defined for transfer of EVRC-encoded data via RTP 692 using the Header-Free packet format specified in Section 4.2 of 693 RFC 3558. 695 Security considerations: See Section 14 "Security Considerations" of 696 RFC 3558. 698 Interoperability considerations: 699 The DTX parameters are receiver options. Existing RFC 3558 700 implementations will not send any of the DTX parameters in their 701 SDP and will ignore any DTX parameters they receive. The adaptive 702 DTX behavior of DTX-capable EVRC codecs (as detailed in [8], 703 Section 4.3.5) ensures interoperability with non-DTX EVRC codecs. 705 Published specification: 706 The EVRC vocoder is specified in 3GPP2 C.S0014. Transfer methods 707 are specified in RFC 3558. 709 Applications that use this media type: 710 It is expected that many VoIP applications (as well as mobile 711 applications) will use this type. 713 Additional information: none 715 Person & email address to contact for further information: 716 Qiaobing Xie 718 Intended usage: COMMON 720 Restrictions on usage: 721 This media type depends on RTP framing, and hence is only defined 722 for transfer via RTP (RFC 3550 [5]). Transfer within other 723 framing protocols is not defined at this time. 725 Author: 726 Adam Li/Qiaobing Xie 728 Change controller: 729 IETF Audio/Video Transport working group delegated from the IESG. 731 6.7 Mapping MIME Parameters into SDP 733 The information carried in the MIME media type specification has a 734 specific mapping to fields in the Session Description Protocol (SDP) 735 [7], which is commonly used to describe RTP sessions. When SDP is 736 used to specify sessions employing the compact bundled format for 737 EVRC/EVRC-B encoded speech, the mapping is as follows: 739 o The MIME type ("audio") goes in SDP "m=" as the media name. 741 o The MIME subtype ("EVRC", "EVRC0", "EVRC1", "EVRCB", EVRCB0", or 742 "EVRCB1") goes in SDP "a=rtpmap" as the encoding name. 744 o The optional parameters "ptime" and "maxptime" (for subtypes EVRC, 745 EVRC1, EVRCB, and EVRCB1) go in the SDP "a=ptime" and "a=maxptime" 746 attributes, respectively. 748 o The optional parameter "maxinterleave" (for subtypes EVRC and 749 EVRCB) goes in the SDP "a=fmtp" attribute by copying it directly 750 from the MIME media type string as "maxinterleave=value". 752 o The optional parameter "fixedrate" (for subtypes EVRC1 and EVRCB1) 753 goes in "a=fmtp" attribute by copying it directly from the MIME 754 media type string as "fixedrate=value". 756 o The optional parameters "silencesupp", "dtxmax", "dtxmin", and 757 "hangover" go in "a=fmtp" attribute by copying it directly from 758 the MIME media type string as "silencesupp=value", "dtxmax=value", 759 "dtxmin=value", and "hangover=value", respectively. 761 Example of usage of EVRC1: 763 m=audio 49120 RTP/AVP 97 764 a=rtpmap:97 EVRC1/8000 765 a=fmtp:97 fixedrate=0.5 766 a=maxptime:120 768 Example of usage of EVRCB: 770 m=audio 49120 RTP/AVP 97 771 a=rtpmap:97 EVRCB/8000 772 a=maxptime:120 774 Example of usage of EVRCB0: 776 m=audio 49120 RTP/AVP 97 777 a=rtpmap:97 EVRCB0/8000 779 Example of usage of EVRCB1: 781 m=audio 49120 RTP/AVP 97 782 a=rtpmap:97 EVRCB1/8000 783 a=fmtp:97 fixedrate=0.5 784 a=maxptime:100 786 Example of usage of EVRC with DTX with silencesupp=1: 788 m=audio 49120 RTP/AVP 97 789 a=rtpmap:97 EVRC/8000 790 a=fmtp:97 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1 792 Examples of usage of EVRC with DTX with silencesupp=0: 794 m=audio 49120 RTP/AVP 97 795 a=rtpmap:97 EVRC/8000 796 a=fmtp:97 silencesupp=0 798 6.8 Usage in Offer/Answer 800 All SDP parameters in this payload format are declarative, and all 801 reasonable values are expected to be supported. In particular, when 802 DTX is supported, the RTP sender implementation SHOULD support 803 hangover, dtxmin, and dtxmax values from 0 to 255. Thus, the 804 standard usage of Offer/Answer as described in RFC 3264 [6] SHOULD be 805 followed. 807 In addition, the following rules MUST be followed while negotiating 808 DTX parameters: 810 1. If any DTX parameter is not present in either offer and/or 811 answer, the default value of the DTX parameter MUST be assumed. 813 2. If silencesupp is present and set to 0 in either offer or answer, 814 the values of all received DTX parameters other than silencesupp 815 SHOULD be ignored. 817 3. In an offer or answer, the value of dtxmax SHOULD always be 818 larger than or equal to the value of dtxmin, regardless of 819 whether the values are indicated explicitly or implicitly by 820 default. Moreover, if the indicated value of dtxmin is larger 821 than that of dtxmax, an RTP sender MUST ignore the indicated 822 values and MUST fall back on using the default dtxmin and dtxmax 823 values. 825 7. Backward Compatibility with RFC 3558 827 This document adds new optional DTX parameters to the original EVRC 828 payload subtypes "EVRC" and "EVRC0" defined in RFC 3558. Since the 829 new DTX parameters are receiver options, we expect the existing RFC 830 3558 implementations will not send any of the DTX parameters in their 831 SDP and will ignore any DTX parameters they receive. The adaptive 832 DTX behavior of DTX-capable EVRC codecs (as detailed in [8], Section 833 4.3.5) ensures the backward interoperability between the DTX-capable 834 EVRC codec and non-DTX EVRC codecs. 836 8. IANA Considerations 838 Four (4) new MIME subtype registrations - "EVRC1", "EVRCB", "EVRCB0", 839 and "EVRCB1" - are defined in this document (see Section 6.1 - 840 Section 6.4) for EVRC-B and compact bundled payload format support. 842 For all the EVRC and EVRC-B RTP payload formats defined in RFC 3558 843 [4] and RFC XXXX, four additional optional parameters - 844 "silencesupp", "dtxmax", "dtxmin", and "hangover" - are defined and 845 used in DTX. 847 The MIME subtype registrations, "EVRC" and "EVRC0" originally defined 848 in RFC 3558 [4], are updated with the optional DTX parameters (see 849 Section 6.5 and Section 6.6). 851 9. Security Considerations 853 Implementations using the payload defined in this specification are 854 subject to the security considerations discussed in RFC 3558 [4], RFC 855 3550 [5], and any appropriate profile (for example RFC 3551 [9]). 856 This payload does not specify any different security services. 858 10. Acknowledgments 860 The following people have made significant contributions to this 861 document (in alphabetic order): Parag Agashe, Jim Ashley, Harikishan 862 Desineni, Serafin Diaz, Harinath Garudadri, Gouri Johanssen, Ananth 863 Kandhadai, Waqar Mohsin, Ashok Roy, Gino Scribano, and Gajinder Singh 864 Vij. 866 Special thanks to Colin Perkins, Magnus Westerlund, and Adam Li for 867 their careful review and comments that significantly improved the 868 quality of this document. 870 11. References 872 11.1 Normative References 874 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 875 Levels", BCP 14, RFC 2119, March 1997. 877 [2] "Enhanced Variable Rate Codec, Speech Service Option 3 for 878 Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014, 879 January 1997. 881 [3] "Enhanced Variable Rate Codec, Speech Service Option 68 for 882 Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B, in 883 progress. 885 [4] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs 886 (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003. 888 [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 889 "RTP: A Transport Protocol for Real-Time Applications", 890 RFC 3550, July 2003. 892 [6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 893 the Session Description Protocol (SDP)", RFC 3264, June 2002. 895 [7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 896 Description Protocol", RFC 4566, July 2006. 898 [8] "Discontinuous Transmission (DTX) of Speech in cdma2000 899 Systems", 3GPP2 C.S0076-0, Version 1.0, December 2005. 901 11.2 Informative References 903 [9] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 904 Conferences with Minimal Control", RFC 3551, July 2003. 906 [10] Casner, S., "Media Type Registration of RTP Payload Formats", 907 draft-ietf-avt-rfc3555bis-03.txt (work in progress), 908 March 2006. 910 Authors' Addresses 912 Qiaobing Xie 913 Motorola, Inc. 914 1501 W. Shure Drive, 2-F9 915 Arlington Heights, IL 60004 916 US 918 Phone: +1-847-632-3028 919 Email: Qiaobing.Xie@Motorola.com 921 Rohit Kapoor 922 Qualcomm Inc. 923 US 925 Phone: +1-858-845-1161 926 Email: rkapoor@qualcomm.com 928 Intellectual Property Statement 930 The IETF takes no position regarding the validity or scope of any 931 Intellectual Property Rights or other rights that might be claimed to 932 pertain to the implementation or use of the technology described in 933 this document or the extent to which any license under such rights 934 might or might not be available; nor does it represent that it has 935 made any independent effort to identify any such rights. Information 936 on the procedures with respect to rights in RFC documents can be 937 found in BCP 78 and BCP 79. 939 Copies of IPR disclosures made to the IETF Secretariat and any 940 assurances of licenses to be made available, or the result of an 941 attempt made to obtain a general license or permission for the use of 942 such proprietary rights by implementers or users of this 943 specification can be obtained from the IETF on-line IPR repository at 944 http://www.ietf.org/ipr. 946 The IETF invites any interested party to bring to its attention any 947 copyrights, patents or patent applications, or other proprietary 948 rights that may cover technology that may be required to implement 949 this standard. Please address the information to the IETF at 950 ietf-ipr@ietf.org. 952 Disclaimer of Validity 954 This document and the information contained herein are provided on an 955 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 956 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 957 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 958 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 959 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 960 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 962 Copyright Statement 964 Copyright (C) The Internet Society (2006). This document is subject 965 to the rights, licenses and restrictions contained in BCP 78, and 966 except as set forth therein, the authors retain all their rights. 968 Acknowledgment 970 Funding for the RFC Editor function is currently provided by the 971 Internet Society.