idnits 2.17.1 draft-hdesinen-avt-rtp-evrc-wb-00.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 1176. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1153. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1160. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1166. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 27, 2006) is 6353 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) == Unused Reference: '3' is defined on line 1071, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1089, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1092, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1098, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1101, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1119, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 4317 (ref. '9') ** Obsolete normative reference: RFC 4566 (ref. '10') (Obsoleted by RFC 8866) -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '16') (Obsoleted by RFC 7826) == Outdated reference: A later version (-06) exists of draft-ietf-avt-rtp-howto-00 Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Desineni 3 Internet-Draft Qualcomm 4 Updates: YYYY (if approved) Q. Xie 5 Expires: May 31, 2007 Motorola 6 November 27, 2006 8 RTP payload format for EVRC-WB codec and MIME updates for EVRC-B codec 9 draft-hdesinen-avt-rtp-evrc-wb-00.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 May 31, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies real-time transport protocol (RTP) payload 43 formats to be used for the EVRC wideband codec (EVRC-WB) and updates 44 the MIME registrations for EVRC-B codec. Several media type 45 registrations are included for EVRC-WB RTP payload formats. In 46 addition, a file format is specified for transport of EVRC-WB speech 47 data in storage mode applications such as e-mail. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. EVRC-WB codec . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 7 56 6. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 8 57 7. Congestion Control Considerations . . . . . . . . . . . . . . 9 58 8. Storage format for EVRC-WB Codec . . . . . . . . . . . . . . . 10 59 9. Media type definitions . . . . . . . . . . . . . . . . . . . . 11 60 9.1. Registration of Media Type EVRCWB . . . . . . . . . . . . 11 61 9.2. Registration of Media Type EVRCWB0 . . . . . . . . . . . . 13 62 9.3. Registration of Media Type EVRCWB1 . . . . . . . . . . . . 15 63 9.4. Updated Registration of Media Type EVRCB . . . . . . . . . 17 64 9.5. Updated Registration of Media Type EVRCB0 . . . . . . . . 19 65 9.6. Updated Registration of Media Type EVRCB1 . . . . . . . . 20 66 10. EVRC-B RFC XXXX Interoperability with legacy EVRC-B (RFC 67 YYYY) implementations . . . . . . . . . . . . . . . . . . . . 23 68 11. Mapping MIME Parameters into SDP . . . . . . . . . . . . . . . 24 69 12. Offer-Answer Model Considerations for EVRC-WB . . . . . . . . 25 70 13. Offer-Answer Model Considerations for EVRC-B . . . . . . . . . 27 71 14. Declarative SDP Considerations . . . . . . . . . . . . . . . . 28 72 15. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 73 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 74 17. Security Considerations . . . . . . . . . . . . . . . . . . . 34 75 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 76 18.1. Normative References . . . . . . . . . . . . . . . . . . . 35 77 18.2. Informative References . . . . . . . . . . . . . . . . . . 35 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 79 Intellectual Property and Copyright Statements . . . . . . . . . . 38 81 1. Introduction 83 This document specifies the payload formats for packetization of 84 EVRC-WB encoded speech signals into the real-time transport protocol 85 (RTP).It defines support for the header-free, interleaved/bundled and 86 compact bundle packet formats for the EVRC-WB codec as well as 87 discontinuous transmission (DTX) support for EVRC-WB encoded speech 88 transported via RTP.EVRC-WB codec offers better speech quality than 89 EVRC and EVRC-B codecs. EVRC-WB belongs to the EVRC family of 90 codecs.This document also updates the MIME registrations for EVRC-B 91 codec. 93 [-- RFC Editor: Please replace "YYYY" in the "Updates" header of this 94 document with the RFC number of [2] prior to RFC publication, and 95 remove this note.] 97 2. Conventions 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [1]. 103 3. Background 105 EVRC-WB is a wideband extension of EVRC-B [4] speech codec developed 106 in 3GPP2 with support for discontinuous transmission (DTX). It 107 provides enhanced (wideband) voice quality. 109 EVRC-WB codec operates on 20 ms frames, and the default sampling rate 110 is 16 kHz. Input and output at 8 kHz sampling rate is also 111 supported. EVRC-WB modes are defined in [5]. EVRC-WB mode 4 is 112 interoperable with EVRC-B. EVRC-WB provides a standardized solution 113 for packetized voice applications that allow transitions between 114 narrowband and wideband telephony. The most important service 115 addressed is IP telephony. Target devices can be IP phones or VoIP 116 handsets, media gateways, voice messaging servers, etc. 118 4. EVRC-WB codec 120 EVRC-WB codec operates on 20 ms frames. It produces output frames of 121 one of the three different sizes: 171 bits, 80 bits or 16 bits. In 122 addition, there are two zero bit codec frame types: null frames and 123 erasure frames. The default sampling rate is 16 kHz. Input and 124 output at 8 kHz sampling rate is also supported. 126 The frame type values and size of the associated codec data frame are 127 listed in the table below: 129 Value Rate Total codec data frame size (in octets) 130 -------------------------------------------------------------------- 131 0 Blank 0 (0 bit) 132 1 1/8 2 (16 bits) 133 2 1/4 5 (40 bits; not valid for EVRC-WB) 134 3 1/2 10 (80 bits) 135 4 1 22 (171 bits; 5 bits padded at the end) 136 5 Erasure 0 (SHOULD NOT be transmitted by sender) 138 5. RTP header usage 140 The format of the RTP header is specified in RFC 3550 [6]. The 141 EVRC-WB payload formats (Section 6) use the fields of the RTP header 142 in a manner consistent with RFC 3550. 144 EVRC-WB has also the capability to operate with 8 kHz sampled input/ 145 output signals. The decoder does not require a priori knowledge 146 about the sampling rate of the original signal at the input of the 147 encoder. The decoder output can be at 8kHz or 16kHz regardless of 148 the sampling rate used at the encoder. Therefore, depending on the 149 implementation and the audio electro acoustic capabilities of the 150 devices, the input of the encoder and/or the output of the decoder 151 can be configured at 8 kHz; however, a 16 kHz RTP clock rate MUST 152 always be used. The RTP timestamp is increased by 320 for each 20 153 milliseconds. 155 The assignment of an RTP payload type for the payload formats 156 described in Section 6 is outside the scope of the document, and will 157 not be specified here. It is expected that the RTP profile under 158 which this payload format is being used will assign a payload type 159 for this codec or specify that the payload type is to be bound 160 dynamically (see Section 11). 162 6. Payload format 164 Three RTP packet formats are supported for the EVRC-WB codec - the 165 interleaved/bundled packet format, the header-free packet format and 166 the compact bundled packet format. For all these formats, the 167 operational details and capabilities, such as ToC, interleaving, DTX, 168 and bundling, of EVRC-WB are exactly the same as those of EVRC-B, as 169 defined in [4], except that the mode change request field in the ToC 170 MUST be interpreted according to the definition of the RATE_REDUC 171 parameter as defined in EVRC-WB [5]. 173 7. Congestion Control Considerations 175 Congestion control for RTP SHALL be used in accordance with RFC 3550 176 [6], and with any applicable RTP profile; e.g., RFC 3551 [13]. 178 Due to the header overhead, the number of frames encapsulated in each 179 RTP packet influences the overall bandwidth of the RTP stream. 180 Packing more frames in each RTP packet can reduce the number of 181 packets sent and hence the header overhead, at the expense of 182 increased delay and reduced error robustness. 184 8. Storage format for EVRC-WB Codec 186 The storage format is used for storing EVRC-WB encoded speech frames, 187 e.g., as a file or e-mail attachment. 189 The file begins with a magic number to identify the vocoder that is 190 used. The magic number for EVRC-WB corresponds to the ASCII 191 character string "#!EVCWB\n", i.e., "0x23 0x21 0x45 0x56 0x43 0x57 192 0x42 0x0A". 194 The codec data frames are stored in consecutive order, with a single 195 TOC entry field, extended to one octet, prefixing each codec data 196 frame. The ToC field is extended to one octet by setting the four 197 most significant bits of the octet to zero. For example, a ToC value 198 of 4 (a full-rate frame) is stored as 0x04. See Section 4 for the 199 mapping from frame type to ToC value. 201 Speech frames lost in transmission and non-received frames MUST be 202 stored as erasure frames to maintain synchronization with the 203 original media. 205 9. Media type definitions 207 9.1. Registration of Media Type EVRCWB 209 Type name: audio 211 Subtype names: EVRCWB 213 Required parameters: none 215 Optional parameters: 217 mode-set-recv: A subset of EVRC-WB modes. Possible values are a 218 comma separated list of modes from the set: 0,4,7 (see Table XX [5]). 219 A decoder can use this to signal an encoder to limit its modes to the 220 specified subset. Absence of this parameter signals a set of all 221 EVRC-WB modes. 223 sendmode: A mode of EVRC-WB codec. Encoder can use this to signal 224 its current mode of operation. Possible values are a comma separated 225 list of modes from the set: 0,4,7 (see Table XX [5]). 227 ptime: see RFC 4566 [10]. 229 maxptime: The maximum amount of media which can be encapsulated in 230 each packet, expressed as time in milliseconds. The time MUST be 231 calculated as the sum of the time the media present in the packet 232 represents. The time SHOULD be a multiple of the duration of a 233 single codec data frame (20 msec). If not signaled, the default 234 maxptime value MUST be 200 milliseconds. 236 maxinterleave: Maximum number for interleaving length (field LLL in 237 the Interleaving Octet). The interleaving lengths used in the entire 238 session MUST NOT exceed this maximum value. If not signaled, the 239 maxinterleave length MUST be 5. 241 silencesupp: see Section 6.1 in [2] 243 dtxmax: see Section 6.1 in [2] 245 dtxmin: see Section 6.1 in [2] 247 hangover: see Section 6.1 in [2] 249 Encoding considerations: 251 This media type is framed binary data (see RFC 4288, Section 4.8) and 252 is defined for transfer of EVRC-WB encoded data via RTP using the 253 Interleaved/Bundled packet format specified in RFC 3558 [14]. 255 Security considerations: See Section 17 of RFC XXXX. 257 Interoperability considerations: none 259 Published specification: 261 The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C [5]. Transfer 262 method with Interleaved/Bundled packet format via RTP is specified in 263 RFC 3558 and RFC XXXX. 265 3GPP2 C.S0050-A, 3GPP2 File Formats for Multimedia Services. 267 3GPP2 specifications are publicly accessible at http://www.3gpp2.org 269 Applications that use this media type: 271 It is expected that many VoIP applications (as well as mobile 272 applications) will use this type. 274 Additional information: 276 The following information applies for storage format only. 278 Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) 280 File extensions: evw, EVW 282 Macintosh file type code: none 284 Object identifier or OID: none 286 EVRC-WB speech frames may also be stored in the file format "3g2" 287 defined in 3GPP2 C.S0050-A, which is identified using the media types 288 "audio/3gpp2" or "video/3gpp2" registered by RFC4393. 290 Person & email address to contact for further information: 292 Harikishan Desineni 294 Intended usage: COMMON 296 Restrictions on usage: 298 This media type may be used with RTP framing (RFC 3550 [6]) and as a 299 storage format. When used with RTP, the procedures in Section 6 MUST 300 be followed. In all other contexts, the storage format defined in 301 Section 8 MAY be used. 303 Author: 305 Harikishan Desineni 307 Change controller: 309 IETF Audio/Video Transport working group delegated from the IESG. 311 9.2. Registration of Media Type EVRCWB0 313 Type name: audio 315 Subtype names: EVRCWB0 317 Required parameters: 319 Optional parameters: 321 mode-set-recv: A subset of EVRC-WB modes. Possible values are a 322 comma separated list of modes from the set: 0,4,7 (see Table XX [5]). 323 A decoder can use this to signal an encoder to limit its modes to the 324 specified subset. Absence of this parameter signals a set of all 325 EVRC-WB modes. 327 sendmode: A mode of EVRC-WB codec. Encoder can use this to signal 328 its current mode of operation. Possible values are a comma separated 329 list of modes from the set: 0,4,7 (see Table XX [5]). 331 ptime: see RFC 4566 [10]. 333 silencesupp: see Section 6.1 in [2] 335 dtxmax: see Section 6.1 in [2] 337 dtxmin: see Section 6.1 in [2] 339 hangover: see Section 6.1 in [2] 341 Encoding considerations: 343 This media type is framed binary data (see RFC 4288, Section 4.8) and 344 is defined for transfer of EVRC-WB encoded data via RTP using the 345 Header-Free packet format specified in RFC 3558. 347 Security considerations: See Section 17 of RFC XXXX. 349 Interoperability considerations: none 351 Published specification: 353 The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C [5]. Transfer 354 method with header free packet format via RTP is specified in RFC 355 3558 and RFC XXXX. 357 3GPP2 C.S0050-A, 3GPP2 File Formats for Multimedia Services. 359 3GPP2 specifications are publicly accessible at http://www.3gpp2.org 361 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: 368 The following information applies for storage format only. 370 Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) 372 File extensions: evw, EVW 374 Macintosh file type code: none 376 Object identifier or OID: none 378 EVRC-WB speech frames may also be stored in the file format "3g2" 379 defined in 3GPP2 C.S0050-A, which is identified using the media types 380 "audio/3gpp2" or "video/3gpp2" registered by RFC4393. 382 Person & email address to contact for further information: 384 Harikishan Desineni 386 Intended usage: COMMON 388 Restrictions on usage: 390 This media type may be used with RTP framing (RFC 3550) and as a 391 storage format. When used with RTP, the procedures in Section 6 MUST 392 be followed. In all other contexts, the storage format defined in 393 Section 8 MAY be used. 395 Author: 397 Harikishan Desineni 399 Change controller: 401 IETF Audio/Video Transport working group delegated from the IESG. 403 9.3. Registration of Media Type EVRCWB1 405 Type name: audio 407 Subtype names: EVRCWB1 409 Required parameters: 411 Optional parameters: 413 mode-set-recv: A subset of EVRC-WB modes. Possible values are a 414 comma separated list of modes from the set: 0,4,7 (see Table XX [5]). 415 A decoder can use this to signal an encoder to limit its modes to the 416 specified subset. Absence of this parameter signals a set of all 417 EVRC-WB modes. 419 sendmode: A mode of EVRC-WB codec. Encoder can use this to signal 420 its current mode of operation. Possible values are a comma separated 421 list of modes from the set: 0,4,7 (see Table XX [5]). 423 ptime: see RFC 4566 [10]. 425 maxptime: The maximum amount of media which can be encapsulated in 426 each packet, expressed as time in milliseconds. The time MUST be 427 calculated as the sum of the time the media present in the packet 428 represents. The time SHOULD be an integer multiple of the duration 429 of a single codec data frame (20 msec). If not signaled, the default 430 maxptime value MUST be 200 milliseconds. 432 fixedrate: Indicates the EVRC-WB rate of the session while in single 433 rate operation. Valid values include: 0.5 and 1, where a value of 434 0.5 indicates the 1/2 rate while a value of 1 indicates the full 435 rate. If this parameter is not present, 1/2 rate is assumed. 437 silencesupp: see Section 6.1 in [2] 439 dtxmax: see Section 6.1 in [2] 441 dtxmin: see Section 6.1 in [2] 443 hangover: see Section 6.1 in [2] 444 Encoding considerations: 446 This media type is framed binary data (see RFC 4288, Section 4.8) and 447 is defined for transfer of EVRC-WB encoded data via RTP using the 448 compact bundle packet format specified in RFC YYYY. 450 Security considerations: See Section 17 of RFC XXXX. 452 Interoperability considerations: none 454 Published specification: 456 The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. Transfer method 457 with compact bundled packet format via RTP is specified in RFC YYYY 458 and RFC XXXX. 460 3GPP2 C.S0050-A, 3GPP2 File Formats for Multimedia Services. 462 3GPP2 specifications are publicly accessible at http://www.3gpp2.org 464 Applications that use this media type: 466 It is expected that many VoIP applications (as well as mobile 467 applications) will use this type. 469 Additional information: 471 The following information applies for storage format only. 473 Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) 475 File extensions: evw, EVW 477 Macintosh file type code: none 479 Object identifier or OID: none 481 EVRC-WB speech frames may also be stored in the file format "3g2" 482 defined in 3GPP2 C.S0050-A, which is identified using the media types 483 "audio/3gpp2" or "video/3gpp2" registered by RFC 4393. 485 Person & email address to contact for further information: 487 Harikishan Desineni 489 Intended usage: COMMON 491 Restrictions on usage: 493 This media type may be used with RTP framing (RFC 3550 [6]) and as a 494 storage format. When used with RTP, the procedures in Section 6 MUST 495 be followed. In all other contexts, the storage format defined in 496 Section 8 MAY be used. 498 Author: 500 Harikishan Desineni 502 Change controller: 504 IETF Audio/Video Transport working group delegated from the IESG. 506 9.4. Updated Registration of Media Type EVRCB 508 Type name: audio 510 Subtype names: EVRCB 512 Required parameters: none 514 Optional parameters: 516 recvmode: A mode of EVRC-B codec. A decoder can use this to signal 517 an encoder to operate in the specified mode. Possible values are a 518 comma separated list of modes from the set: 0..7 (see encoder 519 operating point column in Table 2-6 [4]). 521 sendmode: A mode of EVRC-B codec. An encoder can use this to signal 522 its current mode of operation. Possible values are a comma separated 523 list of modes from the set: 0..7 (see encoder operating point column 524 in Table 2-6 [4]). 526 ptime: see RFC 4566 528 maxptime: The maximum amount of media which can be encapsulated in 529 each packet, expressed as time in milliseconds. The time MUST be 530 calculated as the sum of the time the media present in the packet 531 represents. The time SHOULD be a multiple of the duration of a 532 single codec data frame (20 msec). If not signaled, the default 533 maxptime value MUST be 200 milliseconds. 535 maxinterleave: Maximum number for interleaving length (field LLL in 536 the Interleaving Octet). The interleaving lengths used in the entire 537 session MUST NOT exceed this maximum value. If not signaled, the 538 maxinterleave length MUST be 5. 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 of [2] 545 dtxmin: see Section 6.1 of [2] 547 hangover: see Section 6.1 of [2] 549 Encoding considerations: 551 This media type is framed binary data (see RFC 4288, Section 4.8) and 552 is defined for transfer of EVRC-B encoded data via RTP using the 553 Interleaved/Bundled packet format specified in RFC 3558. 555 Security considerations: See Section 9 of RFC YYYY. 557 Interoperability considerations: none 559 Published specification: 561 The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. Transfer method 562 with Interleaved/Bundled packet format via RTP is specified in RFC 563 3558,RFC XXXX and RFC YYYY. 565 Applications that use this media type: 567 It is expected that many VoIP applications (as well as mobile 568 applications) will use this type. 570 Additional information: The following information applies for storage 571 format only. Magic number: #!EVRC-B\n (see Section 5 of RFC YYYY) 572 File extensions: evb, EVB Macintosh file type code: none Object 573 identifier or OID: none 575 Person & email address to contact for further information: 577 Harikishan Desineni 579 Intended usage: COMMON 581 Restrictions on usage: 583 This media type depends on RTP framing, and hence is only defined for 584 transfer via RTP (RFC 3550). Transfer within other framing protocols 585 is not defined at this time. 587 Author: 589 Qiaobing Xie / Harikishan Desineni 591 Change controller: 593 IETF Audio/Video Transport working group delegated from the IESG. 595 9.5. Updated Registration of Media Type EVRCB0 597 Type name: audio 599 Subtype names: EVRCB0 601 Required parameters: none 603 Optional parameters: 605 recvmode: A mode of EVRC-B codec. A decoder can use this to signal 606 an encoder to operate in the specified mode. Possible values are a 607 comma separated list of modes from the set: 0..7 (see encoder 608 operating point column in Table 2-6 [4]). 610 sendmode: A mode of EVRC-B codec. An encoder can use this to signal 611 its current mode of operation. Possible values are a comma separated 612 list of modes from the set: 0..7 (see encoder operating point column 613 in Table 2-6 [4]). 615 silencesupp: see Section 6.1 for definition. If this parameter is 616 not present, the default value 1 MUST be assumed. 618 dtxmax: see Section 6.1 of [2] 620 dtxmin: see Section 6.1 of [2] 622 hangover: see Section 6.1 of [2] 624 Encoding considerations: 626 This media type is framed binary data (see RFC 4288, Section 4.8) and 627 is defined for transfer of EVRC-B encoded data via RTP using the 628 Header-Free packet format specified in RFC 3558. 630 Security considerations: See Section 9 of RFC YYYY. 632 Interoperability considerations: none 634 Published specification: 636 The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. Transfer method 637 with Header-Free packet format via RTP is specified in RFC 3558, RFC 638 YYYY and RFC XXXX. 640 Applications that use this media type: 642 It is expected that many VoIP applications (as well as mobile 643 applications) will use this type. 645 Additional information: none 647 Person & email address to contact for further information: 649 Harikishan Desineni 651 Intended usage: COMMON 653 Restrictions on usage: 655 This media type depends on RTP framing, and hence is only defined for 656 transfer via RTP (RFC 3550). Transfer within other framing protocols 657 is not defined at this time. 659 Author: 661 Qiaobing Xie / Harikishan Desineni 663 Change controller: 665 IETF Audio/Video Transport working group delegated from the IESG. 667 9.6. Updated Registration of Media Type EVRCB1 669 Type name: audio 671 Subtype names: EVRCB1 673 Required parameters: none 675 Optional parameters: 677 recvmode: A mode of EVRC-B codec. A decoder can use this to signal 678 an encoder to operate in the specified mode. Possible values are a 679 comma separated list of modes from the set: 0..7 (see encoder 680 operating point column in Table 2-6 [4]). 682 sendmode: A mode of EVRC-B codec. An encoder can use this to signal 683 its current mode of operation. Possible values are a comma separated 684 list of modes from the set: 0..7 (see encoder operating point column 685 in Table 2-6 [4]). 687 silencesupp: see Section 6.1 for definition. If this parameter is 688 not present, the default value 1 MUST be assumed. 690 dtxmax: see Section 6.1 of [2] 692 dtxmin: see Section 6.1 of [2] 694 hangover: see Section 6.1 of [2] 696 Encoding considerations: 698 This media type is framed binary data (see RFC 4288, Section 4.8) and 699 is defined for transfer of EVRC-B encoded data via RTP using the 700 compact bundle packet format specified in RFC YYYY. 702 Security considerations: See Section 9 of RFC YYYY. 704 Interoperability considerations: none 706 Published specification: 708 The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. Transfer method 709 with compact bundle packet format via RTP is specified in RFC YYYY 710 and RFC XXXX. 712 Applications that use this media type: 714 It is expected that many VoIP applications (as well as mobile 715 applications) will use this type. 717 Additional information: none 719 Person & email address to contact for further information: 721 Harikishan Desineni 723 Intended usage: COMMON 725 Restrictions on usage: 727 This media type depends on RTP framing, and hence is only defined for 728 transfer via RTP (RFC 3550). Transfer within other framing protocols 729 is not defined at this time. 731 Author: 733 Qiaobing Xie / Harikishan Desineni 735 Change controller: 737 IETF Audio/Video Transport working group delegated from the IESG. 739 10. EVRC-B RFC XXXX Interoperability with legacy EVRC-B (RFC YYYY) 740 implementations 742 This document adds new optional parameters "recvmode" and "sendmode" 743 to the original EVRC-B payload subtypes "EVRCB", "EVRCB0" and 744 "EVRCB1" defined in RFC YYYY. Since the new parameters are receiver 745 options, the existing RFC YYYY implementations will not send these 746 parameters in SDP and will ignore if they are received. This will 747 allow interoperability between RFC YYYY and RFC XXXX implementations 748 of EVRC-B. For an example offer and answer exchange, see Section 15. 750 11. Mapping MIME Parameters into SDP 752 Information carried in the MIME media type specification has a 753 specific mapping to fields in the Session Description Protocol (SDP) 754 [10], which is commonly used to describe RTP sessions. When SDP is 755 used to specify sessions employing EVRC-WB encoded speech, the 756 mapping is as follows: 758 The MIME type ("audio") goes in SDP "m=" as the media name. 760 o The MIME subtype ("EVRCWB", "EVRCWB0" or "EVRCWB1") goes in SDP 761 "a=rtpmap" as the encoding name. 763 o The optional parameters "mode-set-recv" and "sendmode" (for 764 subtypes EVRCWB, EVRCWB0 and EVRCWB1) go in the SDP "a=fmtp" 765 attribute by copying them directly from the MIME media type 766 string. 768 o The optional parameters "ptime" and "maxptime" (for subtypes 769 EVRCWB, EVRCWB1) go in the SDP "a=ptime" and "a=maxptime" 770 attributes, respectively. 772 o The optional parameter "maxinterleave" for subtype EVRCWB goes in 773 the SDP "a=fmtp" attribute by copying it directly from the MIME 774 media type string as "maxinterleave=value". 776 o The optional parameter "fixedrate" for subtypes EVRCWB1 goes in 777 "a=fmtp" attribute by copying it directly from the MIME media type 778 string as "fixedrate=value". 780 o The optional parameters "silencesupp", "dtxmax", "dtxmin", and 781 "hangover" go in "a=fmtp" attribute by copying them directly from 782 the MIME media type string as "silencesupp=value", "dtxmax=value", 783 "dtxmin=value", and "hangover=value", respectively. 785 o The optional parameters "recvmode" and "sendmode" (for subtypes 786 EVRCB, EVRCB0 and EVRCB1) go in the SDP "a=fmtp" attribute by 787 copying them directly from the MIME media type string. 789 12. Offer-Answer Model Considerations for EVRC-WB 791 The following considerations apply when using SDP offer-answer 792 procedures [7] to negotiate the use of EVRC-WB payload in RTP: 794 o Since EVRC-WB is an extension of EVRC-B, the offerer SHOULD 795 announce EVRC-B support in its "m=audio" line, with EVRC-WB as the 796 preferred codec. This will allow interoperability with an 797 answerer which supports only EVRC-B. 799 Below is an example of such an offer: 801 m=audio 55954 RTP/AVP 98 99 802 a=rtpmap:98 EVRCWB0/16000 803 a=rtpmap:99 EVRCB0/8000 804 a=fmtp:98 mode-set-recv=0,4 sendmode=0 805 a=fmtp:99 recvmode=0 sendmode=4 807 If the answerer supports EVRC-WB then the answerer can keep the 808 payload type 98 in its answer and the conversation can be done 809 using EVRC-WB. Else, if the answerer supports only EVRC-B then 810 the answerer will leave only the payload type 99 in its answer and 811 the conversation will be done using EVRC-B. 813 An example answer for the above offer: 815 m=audio 55954 RTP/AVP 98 816 a=rtpmap:98 EVRCWB0/16000 817 a=fmtp:98 mode-set-recv=4 sendmode=4 819 o "mode-set-recv" is a uni-directional receive only parameter. 821 o "sendmode" is a uni-directional send only parameter. 823 o Using "sendmode", a sender can signal its current mode of 824 operation. 826 o An offerer can use "mode-set-recv" to request that the remote 827 sender's encoder be limited to the list of modes signaled in 828 "mode-set-recv". A remote sender MAY ignore "mode-set-recv" 829 requests. 831 o The parameters "maxptime" and "ptime" will in most cases not 832 affect interoperability, however the setting of the parameters can 833 affect the performance of the application. The SDP offer-answer 834 handling of the "ptime" parameter is described in RFC3264 [7]. 835 The "maxptime" parameter MUST be handled in the same way. 837 o For a sendonly stream, "mode-set-recv" parameter is not useful and 838 SHOULD NOT be used. 840 o For a recvonly stream, "sendmode" parameter is not useful and 841 SHOULD NOT be used. 843 o For additional rules which MUST be followed while negotiating DTX 844 parameters, see Section 6.8 in [2]. 846 o Any unknown parameter in an SDP offer MUST be ignored by the 847 receiver and MUST NOT be included in the SDP answer. 849 13. Offer-Answer Model Considerations for EVRC-B 851 See Section 6.8 of [2] for offer-answer usage of EVRC-B. The 852 following are several additional considerations for EVRC-B. 854 o "recvmode" is a uni-directional receive only parameter. 856 o "sendmode" is a uni-directional send only parameter. 858 o Using "recvmode", a receiver can signal the remote sender to 859 operate its encoder in the specified mode. A remote sender MAY 860 ignore "recvmode" requests. 862 o Using "sendmode", a sender can signal its current mode of 863 operation. 865 o For a sendonly stream, "recvmode" parameter is not useful and 866 SHOULD NOT be used. 868 o For a recvonly stream, "sendmode" parameter is not useful and 869 SHOULD NOT be used. 871 14. Declarative SDP Considerations 873 For declarative use of SDP in SAP [15] and RTSP [16] , the following 874 considerations apply: 876 o Any "maxptime" and "ptime" values should be selected with care to 877 ensure that the session's participants can achieve reasonable 878 performance. 880 o The payload format configuration parameters are all declarative 881 and a participant MUST use the configuration(s) that is provided 882 for the session. More than one configuration may be provided if 883 necessary by declaring multiple RTP payload types, however the 884 number of types should be kept small. 886 15. Examples 888 Some example SDP session descriptions utilizing EVRC-WB and EVRC-B 889 encodings follow. In these examples, long a=fmtp lines are folded to 890 meet the column width constraints of this document. The backslash 891 ("\") at the end of a line and the carriage return that follows it 892 should be ignored. Note that MIME subtype names are case- 893 insensitive. Parameter names are case-insensitive both in MIME types 894 and in the mapping to the SDP a=fmtp attribute. 896 Example usage of EVRCWB: 898 m=audio 49120 RTP/AVP 97 98 899 a=rtpmap:97 EVRCWB/16000 900 a=rtpmap:98 EVRCB0/8000 901 a=fmtp:97 mode-set-recv=0,4 sendmode=0 902 a=fmtp:98 recvmode=0 sendmode=0 903 a=maxptime:120 905 Example usage of EVRCWB0: 907 m=audio 49120 RTP/AVP 97 98 908 a=rtpmap:97 EVRCWB0/16000 909 a=rtpmap:98 EVRCB0/8000 910 a=fmtp:97 mode-set-recv=0,4 sendmode=0 911 a=fmtp:98 recvmode=0 sendmode=0 913 Example SDP answer from a media gateway requesting a terminal to 914 limit its encoder operation to EVRC-WB mode 4. 916 m=audio 49120 RTP/AVP 97 917 a=rtpmap:97 EVRCWB0/16000 918 a=fmtp:97 mode-set-recv=4 sendmode=4 920 Example usage of EVRCWB1: 922 m=audio 49120 RTP/AVP 97 98 923 a=rtpmap:97 EVRCWB1/16000 924 a=rtpmap:98 EVRCB0/8000 925 a=fmtp:97 fixedrate=0.5 mode-set-recv=4 sendmode=7 926 a=fmtp:98 recvmode=7 sendmode=7 927 a=maxptime:100 929 Example usage of EVRCWB with DTX with silencesupp=1: 931 m=audio 49120 RTP/AVP 97 98 932 a=rtpmap:97 EVRCWB/16000 933 a=rtpmap:98 EVRCB0/8000 934 a=fmtp:97 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1 \ 935 mode-set-recv=0,4 sendmode=0 936 a=fmtp:98 recvmode=0 sendmode=0 937 a=maxptime:120 939 Examples usage of EVRCWB with DTX with silencesupp=0: 941 m=audio 49120 RTP/AVP 97 98 942 a=rtpmap:97 EVRCWB/16000 943 a=rtpmap:98 EVRCB0/8000 944 a=fmtp:97 silencesupp=0 dtxmax=32 dtxmin=12 hangover=1 \ 945 mode-set-recv=0,4 sendmode=0 946 a=fmtp:98 recvmode=0 sendmode=0 947 a=maxptime:120 949 Example usage of EVRCB: 951 m=audio 49120 RTP/AVP 97 952 a=rtpmap:97 EVRCB/8000 953 a=fmtp:97 recvmode=0 sendmode=4 954 a=maxptime:120 956 Example usage of EVRCB0: 958 m=audio 49120 RTP/AVP 97 959 a=rtpmap:97 EVRCB0/8000 960 a=fmtp:97 recvmode=0 sendmode=4 962 Example usage of EVRCB1: 964 m=audio 49120 RTP/AVP 97 965 a=rtpmap:97 EVRCB1/8000 966 a=fmtp:97 fixedrate=0.5 recvmode=7 sendmode=7 967 a=maxptime:100 969 Example offer answer exchange between EVRC-WB and 970 legacy EVRC-B (RFC YYYY): 972 Offer: 974 m=audio 55954 RTP/AVP 98 99 975 a=rtpmap:98 EVRCWB0/16000 976 a=rtpmap:99 EVRCB0/8000 977 a=fmtp:98 mode-set-recv=0,4 sendmode=0 978 a=fmtp:99 recvmode=0 sendmode=0 980 Answer: 982 m=audio 55954 RTP/AVP 99 983 a=rtpmap:99 EVRCB0/8000 985 Example offer answer exchange between EVRC-WB and 986 updated EVRC-B (RFC XXXX): 988 Offer: 990 m=audio 55954 RTP/AVP 98 99 991 a=rtpmap:98 EVRCWB0/16000 992 a=rtpmap:99 EVRCB0/8000 993 a=fmtp:98 mode-set-recv=0,4 sendmode=0 994 a=fmtp:99 recvmode=0 sendmode=0 996 Answer: 998 m=audio 55954 RTP/AVP 99 999 a=rtpmap:99 EVRCB0/8000 1000 a=fmtp:99 recvmode=0 sendmode=4 1002 Example offer answer exchanges for interoperability between 1003 legacy (RFC XXXX) and updated EVRC-B(RFC YYYY) implementations: 1005 Offer from an offer which supports updated EVRC-B (RFC XXXX) 1006 implementation: 1008 m=audio 55954 RTP/AVP 99 1009 a=rtpmap:99 EVRCB0/8000 1010 a=fmtp:99 recvmode=0 sendmode=4 1012 Answer from an answerer which supports only 1013 legacy EVRC-B (RFC YYYY) implementation: 1015 m=audio 55954 RTP/AVP 99 1016 a=rtpmap:99 EVRCB0/8000 1018 Offer from an offer which supports only 1019 legacy EVRC-B (RFC YYYY) implementation: 1021 m=audio 55954 RTP/AVP 99 1022 a=rtpmap:99 EVRCB0/8000 1024 Answer from an answerer which supports updated 1025 EVRC-B (RFC XXXX) implementation: 1027 m=audio 55954 RTP/AVP 99 1028 a=rtpmap:99 EVRCB0/8000 1029 a=fmtp:99 recvmode=0 sendmode=4 1031 16. IANA Considerations 1033 Three new MIME subtype registrations ("EVRCWB", "EVRCWB0" and 1034 "EVRCWB1") are defined in this document. 1036 The MIME subtype registrations "EVRCB","EVRCB0" and "EVRCB1" 1037 originally defined in [2] are updated with optional "recvmode" and 1038 "sendmode" parameters (See Section 9.4, Section 9.5 and Section 9.6). 1040 [-- RFC Editor: Please replace all instances of "RFC XXXX" in this 1041 document with the RFC number of this document prior to IANA 1042 registration and RFC publication, and remove this note.] 1044 [-- RFC Editor: Please replace all instances of "RFC YYYY" in this 1045 document with the RFC number of [2] prior to IANA registration and 1046 RFC publication, and remove this note.] 1048 [-- RFC Editor:Please add MIME subtypes "EVRCWB","EVRCWB0", and 1049 "EVRCWB1" to the IANA registry for "RTP Payload Format MIME types" at 1050 http://www.iana.org/assignments/rtp-parameters, and remove this 1051 note.] 1053 17. Security Considerations 1055 Implementations using the payload defined in this specification are 1056 subject to the security considerations discussed in RFC3558 [14], 1057 RFC3550 [6], and any appropriate profile (for example RFC3551 [13]). 1058 This payload does not specify any different security services. 1060 18. References 1062 18.1. Normative References 1064 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1065 Levels", BCP 14, RFC 2119, March 1997. 1067 [2] Xie, Q., "Enhancements to RTP Payload Formats for EVRC Family 1068 Codecs", draft-ietf-avt-compact-bundled-evrc-11.txt(Work in 1069 Progress) , October 2006. 1071 [3] "Enhanced Variable Rate Codec, Speech Service Option 3 for 1072 Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014 , 1073 January 1997. 1075 [4] "Enhanced Variable Rate Codec, Speech Service Option 3 and 68 1076 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B 1077 v1.0 , May 2006. 1079 [5] "Enhanced Variable Rate Codec, Speech Service Option 3,68 and 1080 70 for Wideband Spread Spectrum Digital Systems", 3GPP2 Work 1081 in Progress, October 2006. 1083 [6] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 1084 Applications", STD 64, RFC 3550, March 1997. 1086 [7] Rosenberg, J., "An Offer/Answer Model with Session Description 1087 Protocol (SDP)", RFC 3264, June 2002. 1089 [8] Narten, T., "Guidelines for Writing an IANA Considerations 1090 Section in RFCs", RFC 2434, October 1998. 1092 [9] Johnston, A., "SDP Offer/Answer Examples", RFC 4317, 1093 December 2005. 1095 [10] Handley, M., "SDP: Session Description Protocol", RFC 4566, 1096 July 2006. 1098 [11] Garudadri, H., "3GPP2 Multimedia Registrations", RFC 4393, 1099 March 2006. 1101 [12] "3GPP2 File Formats for Multimedia Services", 3GPP2 C.S0050-A , 1102 March 2006. 1104 18.2. Informative References 1106 [13] Schulzrinne, H., "RTP Profile for Audio and Video Conferences 1107 with Minimal Control", STD 65, RFC 3551, July 2003. 1109 [14] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs 1110 (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, 1111 July 2003. 1113 [15] Handley, M., "Session Announcement Protocol", RFC 2974, 1114 October 2000. 1116 [16] Schulzrinne, H., "Real Time Streaming Protocol (RTSP)", 1117 RFC 2326, April 1998. 1119 [17] Westerlund, M., "How to Write an RTP Payload Format", 1120 draft-ietf-avt-rtp-howto-00.txt(Work in Progress) , May 2006. 1122 Authors' Addresses 1124 Harikishan Desineni 1125 Qualcomm 1126 5775 Morehouse Drive 1127 San Diego, CA 92126 1128 USA 1130 Phone: +1 858 845 8996 1131 Email: hd@qualcomm.com 1132 URI: http://www.qualcomm.com 1134 Qiaobing Xie 1135 Motorola 1136 1501 W. Shure Drive, 2-F9 1137 Arlington Heights, IL 60004 1138 USA 1140 Phone: +1-847-632-3028 1141 Email: Qiaobing.Xie@Motorola.com 1142 URI: http://www.motorola.com 1144 Intellectual Property Statement 1146 The IETF takes no position regarding the validity or scope of any 1147 Intellectual Property Rights or other rights that might be claimed to 1148 pertain to the implementation or use of the technology described in 1149 this document or the extent to which any license under such rights 1150 might or might not be available; nor does it represent that it has 1151 made any independent effort to identify any such rights. Information 1152 on the procedures with respect to rights in RFC documents can be 1153 found in BCP 78 and BCP 79. 1155 Copies of IPR disclosures made to the IETF Secretariat and any 1156 assurances of licenses to be made available, or the result of an 1157 attempt made to obtain a general license or permission for the use of 1158 such proprietary rights by implementers or users of this 1159 specification can be obtained from the IETF on-line IPR repository at 1160 http://www.ietf.org/ipr. 1162 The IETF invites any interested party to bring to its attention any 1163 copyrights, patents or patent applications, or other proprietary 1164 rights that may cover technology that may be required to implement 1165 this standard. Please address the information to the IETF at 1166 ietf-ipr@ietf.org. 1168 Disclaimer of Validity 1170 This document and the information contained herein are provided on an 1171 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1172 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1173 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1174 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1175 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1176 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1178 Copyright Statement 1180 Copyright (C) The Internet Society (2006). This document is subject 1181 to the rights, licenses and restrictions contained in BCP 78, and 1182 except as set forth therein, the authors retain all their rights. 1184 Acknowledgment 1186 Funding for the RFC Editor function is currently provided by the 1187 Internet Society.