idnits 2.17.1 draft-ietf-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 1167. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1144. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1151. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1157. ** 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 draft header indicates that this document updates RFC4788, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC4788, updated by this document, for RFC5378 checks: 2006-01-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 (January 11, 2007) is 6315 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 1062, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1080, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1083, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1089, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1092, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1110, 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-01 Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 13 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: 4788 (if approved) Q. Xie 5 Expires: July 15, 2007 Motorola 6 January 11, 2007 8 RTP payload format for EVRC-WB codec and MIME updates for EVRC-B codec 9 draft-ietf-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 July 15, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2007). 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 4788) 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 2. Conventions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [1]. 99 3. Background 101 EVRC-WB is a wideband extension of EVRC-B [4] speech codec developed 102 in 3GPP2 with support for discontinuous transmission (DTX). It 103 provides enhanced (wideband) voice quality. 105 EVRC-WB codec operates on 20 ms frames, and the default sampling rate 106 is 16 kHz. Input and output at 8 kHz sampling rate is also 107 supported. EVRC-WB modes are defined in [5]. EVRC-WB mode 4 is 108 interoperable with EVRC-B. EVRC-WB provides a standardized solution 109 for packetized voice applications that allow transitions between 110 narrowband and wideband telephony. The most important service 111 addressed is IP telephony. Target devices can be IP phones or VoIP 112 handsets, media gateways, voice messaging servers, etc. 114 4. EVRC-WB codec 116 EVRC-WB codec operates on 20 ms frames. It produces output frames of 117 one of the three different sizes: 171 bits, 80 bits or 16 bits. In 118 addition, there are two zero bit codec frame types: null frames and 119 erasure frames. The default sampling rate is 16 kHz. Input and 120 output at 8 kHz sampling rate is also supported. 122 The frame type values and size of the associated codec data frame are 123 listed in the table below: 125 Value Rate Total codec data frame size (in octets) 126 -------------------------------------------------------------------- 127 0 Blank 0 (0 bit) 128 1 1/8 2 (16 bits) 129 2 1/4 5 (40 bits; not valid for EVRC-WB) 130 3 1/2 10 (80 bits) 131 4 1 22 (171 bits; 5 bits padded at the end) 132 5 Erasure 0 (SHOULD NOT be transmitted by sender) 134 5. RTP header usage 136 The format of the RTP header is specified in RFC 3550 [6]. The 137 EVRC-WB payload formats (Section 6) use the fields of the RTP header 138 in a manner consistent with RFC 3550. 140 EVRC-WB has also the capability to operate with 8 kHz sampled input/ 141 output signals. The decoder does not require a priori knowledge 142 about the sampling rate of the original signal at the input of the 143 encoder. The decoder output can be at 8kHz or 16kHz regardless of 144 the sampling rate used at the encoder. Therefore, depending on the 145 implementation and the audio electro acoustic capabilities of the 146 devices, the input of the encoder and/or the output of the decoder 147 can be configured at 8 kHz; however, a 16 kHz RTP clock rate MUST 148 always be used. The RTP timestamp is increased by 320 for each 20 149 milliseconds. 151 The assignment of an RTP payload type for the payload formats 152 described in Section 6 is outside the scope of the document, and will 153 not be specified here. It is expected that the RTP profile under 154 which this payload format is being used will assign a payload type 155 for this codec or specify that the payload type is to be bound 156 dynamically (see Section 11). 158 6. Payload format 160 Three RTP packet formats are supported for the EVRC-WB codec - the 161 interleaved/bundled packet format, the header-free packet format and 162 the compact bundled packet format. For all these formats, the 163 operational details and capabilities, such as ToC, interleaving, DTX, 164 and bundling, of EVRC-WB are exactly the same as those of EVRC-B, as 165 defined in [4], except that the mode change request field in the ToC 166 MUST be interpreted according to the definition of the RATE_REDUC 167 parameter as defined in EVRC-WB [5]. 169 7. Congestion Control Considerations 171 Congestion control for RTP SHALL be used in accordance with RFC 3550 172 [6], and with any applicable RTP profile; e.g., RFC 3551 [13]. 174 Due to the header overhead, the number of frames encapsulated in each 175 RTP packet influences the overall bandwidth of the RTP stream. 176 Packing more frames in each RTP packet can reduce the number of 177 packets sent and hence the header overhead, at the expense of 178 increased delay and reduced error robustness. 180 8. Storage format for EVRC-WB Codec 182 The storage format is used for storing EVRC-WB encoded speech frames, 183 e.g., as a file or e-mail attachment. 185 The file begins with a magic number to identify the vocoder that is 186 used. The magic number for EVRC-WB corresponds to the ASCII 187 character string "#!EVCWB\n", i.e., "0x23 0x21 0x45 0x56 0x43 0x57 188 0x42 0x0A". 190 The codec data frames are stored in consecutive order, with a single 191 TOC entry field, extended to one octet, prefixing each codec data 192 frame. The ToC field is extended to one octet by setting the four 193 most significant bits of the octet to zero. For example, a ToC value 194 of 4 (a full-rate frame) is stored as 0x04. See Section 4 for the 195 mapping from frame type to ToC value. 197 Speech frames lost in transmission and non-received frames MUST be 198 stored as erasure frames to maintain synchronization with the 199 original media. 201 9. Media type definitions 203 9.1. Registration of Media Type EVRCWB 205 Type name: audio 207 Subtype names: EVRCWB 209 Required parameters: none 211 Optional parameters: 213 mode-set-recv: A subset of EVRC-WB modes. Possible values are a 214 comma separated list of modes from the set: 0,4,7 (see Table XX [5]). 215 A decoder can use this to signal an encoder to limit its modes to the 216 specified subset. Absence of this parameter signals a set of all 217 EVRC-WB modes. 219 sendmode: A mode of EVRC-WB codec. Encoder can use this to signal 220 its current mode of operation. Possible values are a comma separated 221 list of modes from the set: 0,4,7 (see Table XX [5]). 223 ptime: see RFC 4566 [10]. 225 maxptime: The maximum amount of media which can be encapsulated in 226 each packet, expressed as time in milliseconds. The time MUST be 227 calculated as the sum of the time the media present in the packet 228 represents. The time SHOULD be a multiple of the duration of a 229 single codec data frame (20 msec). If not signaled, the default 230 maxptime value MUST be 200 milliseconds. 232 maxinterleave: Maximum number for interleaving length (field LLL in 233 the Interleaving Octet). The interleaving lengths used in the entire 234 session MUST NOT exceed this maximum value. If not signaled, the 235 maxinterleave length MUST be 5. 237 silencesupp: see Section 6.1 in [2] 239 dtxmax: see Section 6.1 in [2] 241 dtxmin: see Section 6.1 in [2] 243 hangover: see Section 6.1 in [2] 245 Encoding considerations: 247 This media type is framed binary data (see RFC 4288, Section 4.8) and 248 is defined for transfer of EVRC-WB encoded data via RTP using the 249 Interleaved/Bundled packet format specified in RFC 3558 [14]. 251 Security considerations: See Section 17 of RFC XXXX. 253 Interoperability considerations: none 255 Published specification: 257 The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C [5]. Transfer 258 method with Interleaved/Bundled packet format via RTP is specified in 259 RFC 3558 and RFC XXXX. 261 3GPP2 C.S0050-A, 3GPP2 File Formats for Multimedia Services. 263 3GPP2 specifications are publicly accessible at http://www.3gpp2.org 265 Applications that use this media type: 267 It is expected that many VoIP applications (as well as mobile 268 applications) will use this type. 270 Additional information: 272 The following information applies for storage format only. 274 Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) 276 File extensions: evw, EVW 278 Macintosh file type code: none 280 Object identifier or OID: none 282 EVRC-WB speech frames may also be stored in the file format "3g2" 283 defined in 3GPP2 C.S0050-A, which is identified using the media types 284 "audio/3gpp2" or "video/3gpp2" registered by RFC4393. 286 Person & email address to contact for further information: 288 Harikishan Desineni 290 Intended usage: COMMON 292 Restrictions on usage: 294 This media type may be used with RTP framing (RFC 3550 [6]) and as a 295 storage format. When used with RTP, the procedures in Section 6 MUST 296 be followed. In all other contexts, the storage format defined in 297 Section 8 MAY be used. 299 Author: 301 Harikishan Desineni 303 Change controller: 305 IETF Audio/Video Transport working group delegated from the IESG. 307 9.2. Registration of Media Type EVRCWB0 309 Type name: audio 311 Subtype names: EVRCWB0 313 Required parameters: 315 Optional parameters: 317 mode-set-recv: A subset of EVRC-WB modes. Possible values are a 318 comma separated list of modes from the set: 0,4,7 (see Table XX [5]). 319 A decoder can use this to signal an encoder to limit its modes to the 320 specified subset. Absence of this parameter signals a set of all 321 EVRC-WB modes. 323 sendmode: A mode of EVRC-WB codec. Encoder can use this to signal 324 its current mode of operation. Possible values are a comma separated 325 list of modes from the set: 0,4,7 (see Table XX [5]). 327 ptime: see RFC 4566 [10]. 329 silencesupp: see Section 6.1 in [2] 331 dtxmax: see Section 6.1 in [2] 333 dtxmin: see Section 6.1 in [2] 335 hangover: see Section 6.1 in [2] 337 Encoding considerations: 339 This media type is framed binary data (see RFC 4288, Section 4.8) and 340 is defined for transfer of EVRC-WB encoded data via RTP using the 341 Header-Free packet format specified in RFC 3558. 343 Security considerations: See Section 17 of RFC XXXX. 345 Interoperability considerations: none 347 Published specification: 349 The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C [5]. Transfer 350 method with header free packet format via RTP is specified in RFC 351 3558 and RFC XXXX. 353 3GPP2 C.S0050-A, 3GPP2 File Formats for Multimedia Services. 355 3GPP2 specifications are publicly accessible at http://www.3gpp2.org 357 Applications that use this media type: 359 It is expected that many VoIP applications (as well as mobile 360 applications) will use this type. 362 Additional information: 364 The following information applies for storage format only. 366 Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) 368 File extensions: evw, EVW 370 Macintosh file type code: none 372 Object identifier or OID: none 374 EVRC-WB speech frames may also be stored in the file format "3g2" 375 defined in 3GPP2 C.S0050-A, which is identified using the media types 376 "audio/3gpp2" or "video/3gpp2" registered by RFC4393. 378 Person & email address to contact for further information: 380 Harikishan Desineni 382 Intended usage: COMMON 384 Restrictions on usage: 386 This media type may be used with RTP framing (RFC 3550) and as a 387 storage format. When used with RTP, the procedures in Section 6 MUST 388 be followed. In all other contexts, the storage format defined in 389 Section 8 MAY be used. 391 Author: 393 Harikishan Desineni 395 Change controller: 397 IETF Audio/Video Transport working group delegated from the IESG. 399 9.3. Registration of Media Type EVRCWB1 401 Type name: audio 403 Subtype names: EVRCWB1 405 Required parameters: 407 Optional parameters: 409 mode-set-recv: A subset of EVRC-WB modes. Possible values are a 410 comma separated list of modes from the set: 0,4,7 (see Table XX [5]). 411 A decoder can use this to signal an encoder to limit its modes to the 412 specified subset. Absence of this parameter signals a set of all 413 EVRC-WB modes. 415 sendmode: A mode of EVRC-WB codec. Encoder can use this to signal 416 its current mode of operation. Possible values are a comma separated 417 list of modes from the set: 0,4,7 (see Table XX [5]). 419 ptime: see RFC 4566 [10]. 421 maxptime: The maximum amount of media which can be encapsulated in 422 each packet, expressed as time in milliseconds. The time MUST be 423 calculated as the sum of the time the media present in the packet 424 represents. The time SHOULD be an integer multiple of the duration 425 of a single codec data frame (20 msec). If not signaled, the default 426 maxptime value MUST be 200 milliseconds. 428 fixedrate: Indicates the EVRC-WB rate of the session while in single 429 rate operation. Valid values include: 0.5 and 1, where a value of 430 0.5 indicates the 1/2 rate while a value of 1 indicates the full 431 rate. If this parameter is not present, 1/2 rate is assumed. 433 silencesupp: see Section 6.1 in [2] 435 dtxmax: see Section 6.1 in [2] 437 dtxmin: see Section 6.1 in [2] 439 hangover: see Section 6.1 in [2] 440 Encoding considerations: 442 This media type is framed binary data (see RFC 4288, Section 4.8) and 443 is defined for transfer of EVRC-WB encoded data via RTP using the 444 compact bundle packet format specified in RFC 4788. 446 Security considerations: See Section 17 of RFC XXXX. 448 Interoperability considerations: none 450 Published specification: 452 The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. Transfer method 453 with compact bundled packet format via RTP is specified in RFC 4788 454 and RFC XXXX. 456 3GPP2 C.S0050-A, 3GPP2 File Formats for Multimedia Services. 458 3GPP2 specifications are publicly accessible at http://www.3gpp2.org 460 Applications that use this media type: 462 It is expected that many VoIP applications (as well as mobile 463 applications) will use this type. 465 Additional information: 467 The following information applies for storage format only. 469 Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) 471 File extensions: evw, EVW 473 Macintosh file type code: none 475 Object identifier or OID: none 477 EVRC-WB speech frames may also be stored in the file format "3g2" 478 defined in 3GPP2 C.S0050-A, which is identified using the media types 479 "audio/3gpp2" or "video/3gpp2" registered by RFC 4393. 481 Person & email address to contact for further information: 483 Harikishan Desineni 485 Intended usage: COMMON 487 Restrictions on usage: 489 This media type may be used with RTP framing (RFC 3550 [6]) and as a 490 storage format. When used with RTP, the procedures in Section 6 MUST 491 be followed. In all other contexts, the storage format defined in 492 Section 8 MAY be used. 494 Author: 496 Harikishan Desineni 498 Change controller: 500 IETF Audio/Video Transport working group delegated from the IESG. 502 9.4. Updated Registration of Media Type EVRCB 504 Type name: audio 506 Subtype names: EVRCB 508 Required parameters: none 510 Optional parameters: 512 recvmode: A mode of EVRC-B codec. A decoder can use this to signal 513 an encoder to operate in the specified mode. Possible values are a 514 comma separated list of modes from the set: 0..7 (see encoder 515 operating point column in Table 2-6 [4]). 517 sendmode: A mode of EVRC-B codec. An encoder can use this to signal 518 its current mode of operation. Possible values are a comma separated 519 list of modes from the set: 0..7 (see encoder operating point column 520 in Table 2-6 [4]). 522 ptime: see RFC 4566 524 maxptime: The maximum amount of media which can be encapsulated in 525 each packet, expressed as time in milliseconds. The time MUST be 526 calculated as the sum of the time the media present in the packet 527 represents. The time SHOULD be a multiple of the duration of a 528 single codec data frame (20 msec). If not signaled, the default 529 maxptime value MUST be 200 milliseconds. 531 maxinterleave: Maximum number for interleaving length (field LLL in 532 the Interleaving Octet). The interleaving lengths used in the entire 533 session MUST NOT exceed this maximum value. If not signaled, the 534 maxinterleave length MUST be 5. 536 silencesupp: see Section 6.1 for definition. If this parameter is 537 not present, the default value 1 MUST be assumed. 539 dtxmax: see Section 6.1 of [2] 541 dtxmin: see Section 6.1 of [2] 543 hangover: see Section 6.1 of [2] 545 Encoding considerations: 547 This media type is framed binary data (see RFC 4288, Section 4.8) and 548 is defined for transfer of EVRC-B encoded data via RTP using the 549 Interleaved/Bundled packet format specified in RFC 3558. 551 Security considerations: See Section 9 of RFC 4788. 553 Interoperability considerations: none 555 Published specification: 557 The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. Transfer method 558 with Interleaved/Bundled packet format via RTP is specified in RFC 559 3558,RFC XXXX and RFC 4788. 561 Applications that use this media type: 563 It is expected that many VoIP applications (as well as mobile 564 applications) will use this type. 566 Additional information: The following information applies for storage 567 format only. Magic number: #!EVRC-B\n (see Section 5 of RFC 4788) 568 File extensions: evb, EVB Macintosh file type code: none Object 569 identifier or OID: none 571 Person & email address to contact for further information: 573 Harikishan Desineni 575 Intended usage: COMMON 577 Restrictions on usage: 579 This media type depends on RTP framing, and hence is only defined for 580 transfer via RTP (RFC 3550). Transfer within other framing protocols 581 is not defined at this time. 583 Author: 585 Qiaobing Xie / Harikishan Desineni 587 Change controller: 589 IETF Audio/Video Transport working group delegated from the IESG. 591 9.5. Updated Registration of Media Type EVRCB0 593 Type name: audio 595 Subtype names: EVRCB0 597 Required parameters: none 599 Optional parameters: 601 recvmode: A mode of EVRC-B codec. A decoder can use this to signal 602 an encoder to operate in the specified mode. Possible values are a 603 comma separated list of modes from the set: 0..7 (see encoder 604 operating point column in Table 2-6 [4]). 606 sendmode: A mode of EVRC-B codec. An encoder can use this to signal 607 its current mode of operation. Possible values are a comma separated 608 list of modes from the set: 0..7 (see encoder operating point column 609 in Table 2-6 [4]). 611 silencesupp: see Section 6.1 for definition. If this parameter is 612 not present, the default value 1 MUST be assumed. 614 dtxmax: see Section 6.1 of [2] 616 dtxmin: see Section 6.1 of [2] 618 hangover: see Section 6.1 of [2] 620 Encoding considerations: 622 This media type is framed binary data (see RFC 4288, Section 4.8) and 623 is defined for transfer of EVRC-B encoded data via RTP using the 624 Header-Free packet format specified in RFC 3558. 626 Security considerations: See Section 9 of RFC 4788. 628 Interoperability considerations: none 630 Published specification: 632 The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. Transfer method 633 with Header-Free packet format via RTP is specified in RFC 3558, RFC 634 4788 and RFC XXXX. 636 Applications that use this media type: 638 It is expected that many VoIP applications (as well as mobile 639 applications) will use this type. 641 Additional information: none 643 Person & email address to contact for further information: 645 Harikishan Desineni 647 Intended usage: COMMON 649 Restrictions on usage: 651 This media type depends on RTP framing, and hence is only defined for 652 transfer via RTP (RFC 3550). Transfer within other framing protocols 653 is not defined at this time. 655 Author: 657 Qiaobing Xie / Harikishan Desineni 659 Change controller: 661 IETF Audio/Video Transport working group delegated from the IESG. 663 9.6. Updated Registration of Media Type EVRCB1 665 Type name: audio 667 Subtype names: EVRCB1 669 Required parameters: none 671 Optional parameters: 673 recvmode: A mode of EVRC-B codec. A decoder can use this to signal 674 an encoder to operate in the specified mode. Possible values are a 675 comma separated list of modes from the set: 0..7 (see encoder 676 operating point column in Table 2-6 [4]). 678 sendmode: A mode of EVRC-B codec. An encoder can use this to signal 679 its current mode of operation. Possible values are a comma separated 680 list of modes from the set: 0..7 (see encoder operating point column 681 in Table 2-6 [4]). 683 silencesupp: see Section 6.1 for definition. If this parameter is 684 not present, the default value 1 MUST be assumed. 686 dtxmax: see Section 6.1 of [2] 688 dtxmin: see Section 6.1 of [2] 690 hangover: see Section 6.1 of [2] 692 Encoding considerations: 694 This media type is framed binary data (see RFC 4288, Section 4.8) and 695 is defined for transfer of EVRC-B encoded data via RTP using the 696 compact bundle packet format specified in RFC 4788. 698 Security considerations: See Section 9 of RFC 4788. 700 Interoperability considerations: none 702 Published specification: 704 The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. Transfer method 705 with compact bundle packet format via RTP is specified in RFC 4788 706 and RFC XXXX. 708 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: 717 Harikishan Desineni 719 Intended usage: COMMON 721 Restrictions on usage: 723 This media type depends on RTP framing, and hence is only defined for 724 transfer via RTP (RFC 3550). Transfer within other framing protocols 725 is not defined at this time. 727 Author: 729 Qiaobing Xie / Harikishan Desineni 731 Change controller: 733 IETF Audio/Video Transport working group delegated from the IESG. 735 10. EVRC-B RFC XXXX Interoperability with legacy EVRC-B (RFC 4788) 736 implementations 738 This document adds new optional parameters "recvmode" and "sendmode" 739 to the original EVRC-B payload subtypes "EVRCB", "EVRCB0" and 740 "EVRCB1" defined in RFC 4788. Since the new parameters are receiver 741 options, the existing RFC 4788 implementations will not send these 742 parameters in SDP and will ignore if they are received. This will 743 allow interoperability between RFC 4788 and RFC XXXX implementations 744 of EVRC-B. For an example offer and answer exchange, see Section 15. 746 11. Mapping MIME Parameters into SDP 748 Information carried in the MIME media type specification has a 749 specific mapping to fields in the Session Description Protocol (SDP) 750 [10], which is commonly used to describe RTP sessions. When SDP is 751 used to specify sessions employing EVRC-WB encoded speech, the 752 mapping is as follows: 754 The MIME type ("audio") goes in SDP "m=" as the media name. 756 o The MIME subtype ("EVRCWB", "EVRCWB0" or "EVRCWB1") goes in SDP 757 "a=rtpmap" as the encoding name. 759 o The optional parameters "mode-set-recv" and "sendmode" (for 760 subtypes EVRCWB, EVRCWB0 and EVRCWB1) go in the SDP "a=fmtp" 761 attribute by copying them directly from the MIME media type 762 string. 764 o The optional parameters "ptime" and "maxptime" (for subtypes 765 EVRCWB, EVRCWB1) go in the SDP "a=ptime" and "a=maxptime" 766 attributes, respectively. 768 o The optional parameter "maxinterleave" for subtype EVRCWB goes in 769 the SDP "a=fmtp" attribute by copying it directly from the MIME 770 media type string as "maxinterleave=value". 772 o The optional parameter "fixedrate" for subtypes EVRCWB1 goes in 773 "a=fmtp" attribute by copying it directly from the MIME media type 774 string as "fixedrate=value". 776 o The optional parameters "silencesupp", "dtxmax", "dtxmin", and 777 "hangover" go in "a=fmtp" attribute by copying them directly from 778 the MIME media type string as "silencesupp=value", "dtxmax=value", 779 "dtxmin=value", and "hangover=value", respectively. 781 o The optional parameters "recvmode" and "sendmode" (for subtypes 782 EVRCB, EVRCB0 and EVRCB1) go in the SDP "a=fmtp" attribute by 783 copying them directly from the MIME media type string. 785 12. Offer-Answer Model Considerations for EVRC-WB 787 The following considerations apply when using SDP offer-answer 788 procedures [7] to negotiate the use of EVRC-WB payload in RTP: 790 o Since EVRC-WB is an extension of EVRC-B, the offerer SHOULD 791 announce EVRC-B support in its "m=audio" line, with EVRC-WB as the 792 preferred codec. This will allow interoperability with an 793 answerer which supports only EVRC-B. 795 Below is an example of such an offer: 797 m=audio 55954 RTP/AVP 98 99 798 a=rtpmap:98 EVRCWB0/16000 799 a=rtpmap:99 EVRCB0/8000 800 a=fmtp:98 mode-set-recv=0,4 sendmode=0 801 a=fmtp:99 recvmode=0 sendmode=4 803 If the answerer supports EVRC-WB then the answerer can keep the 804 payload type 98 in its answer and the conversation can be done 805 using EVRC-WB. Else, if the answerer supports only EVRC-B then 806 the answerer will leave only the payload type 99 in its answer and 807 the conversation will be done using EVRC-B. 809 An example answer for the above offer: 811 m=audio 55954 RTP/AVP 98 812 a=rtpmap:98 EVRCWB0/16000 813 a=fmtp:98 mode-set-recv=4 sendmode=4 815 o "mode-set-recv" is a uni-directional receive only parameter. 817 o "sendmode" is a uni-directional send only parameter. 819 o Using "sendmode", a sender can signal its current mode of 820 operation. 822 o An offerer can use "mode-set-recv" to request that the remote 823 sender's encoder be limited to the list of modes signaled in 824 "mode-set-recv". A remote sender MAY ignore "mode-set-recv" 825 requests. 827 o The parameters "maxptime" and "ptime" will in most cases not 828 affect interoperability, however the setting of the parameters can 829 affect the performance of the application. The SDP offer-answer 830 handling of the "ptime" parameter is described in RFC3264 [7]. 831 The "maxptime" parameter MUST be handled in the same way. 833 o For a sendonly stream, "mode-set-recv" parameter is not useful and 834 SHOULD NOT be used. 836 o For a recvonly stream, "sendmode" parameter is not useful and 837 SHOULD NOT be used. 839 o For additional rules which MUST be followed while negotiating DTX 840 parameters, see Section 6.8 in [2]. 842 o Any unknown parameter in an SDP offer MUST be ignored by the 843 receiver and MUST NOT be included in the SDP answer. 845 13. Offer-Answer Model Considerations for EVRC-B 847 See Section 6.8 of [2] for offer-answer usage of EVRC-B. The 848 following are several additional considerations for EVRC-B. 850 o "recvmode" is a uni-directional receive only parameter. 852 o "sendmode" is a uni-directional send only parameter. 854 o Using "recvmode", a receiver can signal the remote sender to 855 operate its encoder in the specified mode. A remote sender MAY 856 ignore "recvmode" requests. 858 o Using "sendmode", a sender can signal its current mode of 859 operation. 861 o For a sendonly stream, "recvmode" parameter is not useful and 862 SHOULD NOT be used. 864 o For a recvonly stream, "sendmode" parameter is not useful and 865 SHOULD NOT be used. 867 14. Declarative SDP Considerations 869 For declarative use of SDP in SAP [15] and RTSP [16] , the following 870 considerations apply: 872 o Any "maxptime" and "ptime" values should be selected with care to 873 ensure that the session's participants can achieve reasonable 874 performance. 876 o The payload format configuration parameters are all declarative 877 and a participant MUST use the configuration(s) that is provided 878 for the session. More than one configuration may be provided if 879 necessary by declaring multiple RTP payload types, however the 880 number of types should be kept small. 882 15. Examples 884 Some example SDP session descriptions utilizing EVRC-WB and EVRC-B 885 encodings follow. In these examples, long a=fmtp lines are folded to 886 meet the column width constraints of this document. The backslash 887 ("\") at the end of a line and the carriage return that follows it 888 should be ignored. Note that MIME subtype names are case- 889 insensitive. Parameter names are case-insensitive both in MIME types 890 and in the mapping to the SDP a=fmtp attribute. 892 Example usage of EVRCWB: 894 m=audio 49120 RTP/AVP 97 98 895 a=rtpmap:97 EVRCWB/16000 896 a=rtpmap:98 EVRCB0/8000 897 a=fmtp:97 mode-set-recv=0,4 sendmode=0 898 a=fmtp:98 recvmode=0 sendmode=0 899 a=maxptime:120 901 Example usage of EVRCWB0: 903 m=audio 49120 RTP/AVP 97 98 904 a=rtpmap:97 EVRCWB0/16000 905 a=rtpmap:98 EVRCB0/8000 906 a=fmtp:97 mode-set-recv=0,4 sendmode=0 907 a=fmtp:98 recvmode=0 sendmode=0 909 Example SDP answer from a media gateway requesting a terminal to 910 limit its encoder operation to EVRC-WB mode 4. 912 m=audio 49120 RTP/AVP 97 913 a=rtpmap:97 EVRCWB0/16000 914 a=fmtp:97 mode-set-recv=4 sendmode=4 916 Example usage of EVRCWB1: 918 m=audio 49120 RTP/AVP 97 98 919 a=rtpmap:97 EVRCWB1/16000 920 a=rtpmap:98 EVRCB0/8000 921 a=fmtp:97 fixedrate=0.5 mode-set-recv=4 sendmode=7 922 a=fmtp:98 recvmode=7 sendmode=7 923 a=maxptime:100 925 Example usage of EVRCWB with DTX with silencesupp=1: 927 m=audio 49120 RTP/AVP 97 98 928 a=rtpmap:97 EVRCWB/16000 929 a=rtpmap:98 EVRCB0/8000 930 a=fmtp:97 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1 \ 931 mode-set-recv=0,4 sendmode=0 932 a=fmtp:98 recvmode=0 sendmode=0 933 a=maxptime:120 935 Examples usage of EVRCWB with DTX with silencesupp=0: 937 m=audio 49120 RTP/AVP 97 98 938 a=rtpmap:97 EVRCWB/16000 939 a=rtpmap:98 EVRCB0/8000 940 a=fmtp:97 silencesupp=0 dtxmax=32 dtxmin=12 hangover=1 \ 941 mode-set-recv=0,4 sendmode=0 942 a=fmtp:98 recvmode=0 sendmode=0 943 a=maxptime:120 945 Example usage of EVRCB: 947 m=audio 49120 RTP/AVP 97 948 a=rtpmap:97 EVRCB/8000 949 a=fmtp:97 recvmode=0 sendmode=4 950 a=maxptime:120 952 Example usage of EVRCB0: 954 m=audio 49120 RTP/AVP 97 955 a=rtpmap:97 EVRCB0/8000 956 a=fmtp:97 recvmode=0 sendmode=4 958 Example usage of EVRCB1: 960 m=audio 49120 RTP/AVP 97 961 a=rtpmap:97 EVRCB1/8000 962 a=fmtp:97 fixedrate=0.5 recvmode=7 sendmode=7 963 a=maxptime:100 965 Example offer answer exchange between EVRC-WB and 966 legacy EVRC-B (RFC 4788): 968 Offer: 970 m=audio 55954 RTP/AVP 98 99 971 a=rtpmap:98 EVRCWB0/16000 972 a=rtpmap:99 EVRCB0/8000 973 a=fmtp:98 mode-set-recv=0,4 sendmode=0 974 a=fmtp:99 recvmode=0 sendmode=0 976 Answer: 978 m=audio 55954 RTP/AVP 99 979 a=rtpmap:99 EVRCB0/8000 981 Example offer answer exchange between EVRC-WB and 982 updated EVRC-B (RFC XXXX): 984 Offer: 986 m=audio 55954 RTP/AVP 98 99 987 a=rtpmap:98 EVRCWB0/16000 988 a=rtpmap:99 EVRCB0/8000 989 a=fmtp:98 mode-set-recv=0,4 sendmode=0 990 a=fmtp:99 recvmode=0 sendmode=0 992 Answer: 994 m=audio 55954 RTP/AVP 99 995 a=rtpmap:99 EVRCB0/8000 996 a=fmtp:99 recvmode=0 sendmode=4 998 Example offer answer exchanges for interoperability between 999 legacy (RFC XXXX) and updated EVRC-B(RFC 4788) implementations: 1001 Offer from an offer which supports updated EVRC-B (RFC XXXX) 1002 implementation: 1004 m=audio 55954 RTP/AVP 99 1005 a=rtpmap:99 EVRCB0/8000 1006 a=fmtp:99 recvmode=0 sendmode=4 1008 Answer from an answerer which supports only 1009 legacy EVRC-B (RFC 4788) implementation: 1011 m=audio 55954 RTP/AVP 99 1012 a=rtpmap:99 EVRCB0/8000 1014 Offer from an offer which supports only 1015 legacy EVRC-B (RFC 4788) implementation: 1017 m=audio 55954 RTP/AVP 99 1018 a=rtpmap:99 EVRCB0/8000 1020 Answer from an answerer which supports updated 1021 EVRC-B (RFC XXXX) implementation: 1023 m=audio 55954 RTP/AVP 99 1024 a=rtpmap:99 EVRCB0/8000 1025 a=fmtp:99 recvmode=0 sendmode=4 1027 16. IANA Considerations 1029 Three new MIME subtype registrations ("EVRCWB", "EVRCWB0" and 1030 "EVRCWB1") are defined in this document. 1032 The MIME subtype registrations "EVRCB","EVRCB0" and "EVRCB1" 1033 originally defined in [2] are updated with optional "recvmode" and 1034 "sendmode" parameters (See Section 9.4, Section 9.5 and Section 9.6). 1036 [-- RFC Editor: Please replace all instances of "RFC XXXX" in this 1037 document with the RFC number of this document prior to IANA 1038 registration and RFC publication, and remove this note.] 1040 [-- RFC Editor:Please add MIME subtypes "EVRCWB","EVRCWB0", and 1041 "EVRCWB1" to the IANA registry for "RTP Payload Format MIME types" at 1042 http://www.iana.org/assignments/rtp-parameters, and remove this 1043 note.] 1045 17. Security Considerations 1047 Implementations using the payload defined in this specification are 1048 subject to the security considerations discussed in RFC3558 [14], 1049 RFC3550 [6], and any appropriate profile (for example RFC3551 [13]). 1050 This payload does not specify any different security services. 1052 18. References 1054 18.1. Normative References 1056 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1057 Levels", BCP 14, RFC 2119, March 1997. 1059 [2] Xie, Q., "Enhancements to RTP Payload Formats for EVRC Family 1060 Codecs", RFC 4788, January 2007. 1062 [3] "Enhanced Variable Rate Codec, Speech Service Option 3 for 1063 Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014 , 1064 January 1997. 1066 [4] "Enhanced Variable Rate Codec, Speech Service Option 3 and 68 1067 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B 1068 v1.0 , May 2006. 1070 [5] "Enhanced Variable Rate Codec, Speech Service Option 3,68 and 1071 70 for Wideband Spread Spectrum Digital Systems", 3GPP2 Work 1072 in Progress, October 2006. 1074 [6] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 1075 Applications", STD 64, RFC 3550, March 1997. 1077 [7] Rosenberg, J., "An Offer/Answer Model with Session Description 1078 Protocol (SDP)", RFC 3264, June 2002. 1080 [8] Narten, T., "Guidelines for Writing an IANA Considerations 1081 Section in RFCs", RFC 2434, October 1998. 1083 [9] Johnston, A., "SDP Offer/Answer Examples", RFC 4317, 1084 December 2005. 1086 [10] Handley, M., "SDP: Session Description Protocol", RFC 4566, 1087 July 2006. 1089 [11] Garudadri, H., "3GPP2 Multimedia Registrations", RFC 4393, 1090 March 2006. 1092 [12] "3GPP2 File Formats for Multimedia Services", 3GPP2 C.S0050-A , 1093 March 2006. 1095 18.2. Informative References 1097 [13] Schulzrinne, H., "RTP Profile for Audio and Video Conferences 1098 with Minimal Control", STD 65, RFC 3551, July 2003. 1100 [14] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs 1101 (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, 1102 July 2003. 1104 [15] Handley, M., "Session Announcement Protocol", RFC 2974, 1105 October 2000. 1107 [16] Schulzrinne, H., "Real Time Streaming Protocol (RTSP)", 1108 RFC 2326, April 1998. 1110 [17] Westerlund, M., "How to Write an RTP Payload Format", 1111 draft-ietf-avt-rtp-howto-01.txt(Work in Progress) , Dec 2006. 1113 Authors' Addresses 1115 Harikishan Desineni 1116 Qualcomm 1117 5775 Morehouse Drive 1118 San Diego, CA 92126 1119 USA 1121 Phone: +1 858 845 8996 1122 Email: hd@qualcomm.com 1123 URI: http://www.qualcomm.com 1125 Qiaobing Xie 1126 Motorola 1127 1501 W. Shure Drive, 2-F9 1128 Arlington Heights, IL 60004 1129 USA 1131 Phone: +1-847-632-3028 1132 Email: Qiaobing.Xie@Motorola.com 1133 URI: http://www.motorola.com 1135 Intellectual Property Statement 1137 The IETF takes no position regarding the validity or scope of any 1138 Intellectual Property Rights or other rights that might be claimed to 1139 pertain to the implementation or use of the technology described in 1140 this document or the extent to which any license under such rights 1141 might or might not be available; nor does it represent that it has 1142 made any independent effort to identify any such rights. Information 1143 on the procedures with respect to rights in RFC documents can be 1144 found in BCP 78 and BCP 79. 1146 Copies of IPR disclosures made to the IETF Secretariat and any 1147 assurances of licenses to be made available, or the result of an 1148 attempt made to obtain a general license or permission for the use of 1149 such proprietary rights by implementers or users of this 1150 specification can be obtained from the IETF on-line IPR repository at 1151 http://www.ietf.org/ipr. 1153 The IETF invites any interested party to bring to its attention any 1154 copyrights, patents or patent applications, or other proprietary 1155 rights that may cover technology that may be required to implement 1156 this standard. Please address the information to the IETF at 1157 ietf-ipr@ietf.org. 1159 Disclaimer of Validity 1161 This document and the information contained herein are provided on an 1162 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1163 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1164 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1165 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1166 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1167 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1169 Copyright Statement 1171 Copyright (C) The Internet Society (2007). This document is subject 1172 to the rights, licenses and restrictions contained in BCP 78, and 1173 except as set forth therein, the authors retain all their rights. 1175 Acknowledgment 1177 Funding for the RFC Editor function is currently provided by the 1178 Internet Society.