idnits 2.17.1 draft-ietf-avt-rtp-evrc-wb-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1076. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1087. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1094. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1100. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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 IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: sendmode: A mode of EVRC-WB codec. Encoder can use this to signal its current mode of operation. Possible values are a comma separated list of modes from the set: 0,4,7 (see Table 2.5.1.2-1 [5]). 'sendmode' with value 0 signals wideband fixed rate (full or half rate, depending on the value of 'fixedrate' parameter) operation. 'sendmode' with value 4 signals narrowband fixed full rate operation. 'sendmode' with value 7 signals narrowband fixed half rate operation. 'fixedrate' parameter MUST not be present when 'sendmode' value is 4 or 7. Absence of this parameter signals mode 0. (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 (July 16, 2007) is 6129 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. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 4566 (ref. '8') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4288 (ref. '9') (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '12') (Obsoleted by RFC 7826) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 11 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 Intended status: Standards Track Motorola 6 Expires: January 17, 2008 July 16, 2007 8 RTP payload format for EVRC-WB codec and media subtype updates for 9 EVRC-B codec 10 draft-ietf-avt-rtp-evrc-wb-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 17, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document specifies real-time transport protocol (RTP) payload 44 formats to be used for the EVRC wideband codec (EVRC-WB) and updates 45 the media type registrations for EVRC-B codec. Several media type 46 registrations are included for EVRC-WB RTP payload formats. In 47 addition, a file format is specified for transport of EVRC-WB speech 48 data in storage mode applications such as e-mail. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. EVRC-WB codec . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 7 57 6. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 8 58 7. Congestion Control Considerations . . . . . . . . . . . . . . 9 59 8. Storage format for EVRC-WB Codec . . . . . . . . . . . . . . . 10 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 61 9.1. Media Type Registration . . . . . . . . . . . . . . . . . 11 62 9.1.1. Registration of Media Type EVRCWB . . . . . . . . . . 11 63 9.1.2. Registration of Media Type EVRCWB0 . . . . . . . . . . 13 64 9.1.3. Registration of Media Type EVRCWB1 . . . . . . . . . . 15 65 9.1.4. Updated Registration of Media Type EVRCB . . . . . . . 17 66 9.1.5. Updated Registration of Media Type EVRCB0 . . . . . . 19 67 10. SDP mode attributs for EVRC-WB and EVRC-B . . . . . . . . . . 21 68 11. EVRC-B RFC XXXX Interoperability with legacy EVRC-B (RFC 69 4788) implementations . . . . . . . . . . . . . . . . . . . . 22 70 12. Mapping EVRC-WB media type parameters into SDP . . . . . . . . 23 71 13. Mapping EVRC-B media type parameters into SDP . . . . . . . . 24 72 14. Offer-Answer Model Considerations for EVRC-WB . . . . . . . . 25 73 15. Offer-Answer Model Considerations for EVRC-B . . . . . . . . . 27 74 16. Declarative SDP Considerations . . . . . . . . . . . . . . . . 28 75 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 76 18. Security Considerations . . . . . . . . . . . . . . . . . . . 33 77 19. Changes to RFC4788 . . . . . . . . . . . . . . . . . . . . . . 34 78 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 79 20.1. Normative References . . . . . . . . . . . . . . . . . . . 35 80 20.2. Informative References . . . . . . . . . . . . . . . . . . 35 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 82 Intellectual Property and Copyright Statements . . . . . . . . . . 37 84 1. Introduction 86 This document specifies the payload formats for packetization of 87 EVRC-WB encoded speech signals into the real-time transport protocol 88 (RTP).It defines support for the header-free, interleaved/bundled and 89 compact bundle packet formats for the EVRC-WB codec as well as 90 discontinuous transmission (DTX) support for EVRC-WB encoded speech 91 transported via RTP.EVRC-WB codec offers better speech quality than 92 EVRC and EVRC-B codecs. EVRC-WB belongs to the EVRC family of 93 codecs.This document also updates the media type registrations for 94 EVRC-B codec. 96 2. Conventions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [1]. 102 3. Background 104 EVRC-WB is a wideband extension of EVRC-B [4] speech codec developed 105 in 3GPP2 with support for discontinuous transmission (DTX). It 106 provides enhanced (wideband) voice quality. 108 EVRC-WB codec operates on 20 ms frames, and the default sampling rate 109 is 16 kHz. Input and output at 8 kHz sampling rate is also 110 supported. EVRC-WB codec can operate in three modes (0,4 and 7) 111 defined in [5]. EVRC-WB modes 4,7 are interoperable with EVRC-B. 112 EVRC-WB mode 4 uses full rate, 1/2 rate and 1/8 rate frames. EVRC-WB 113 mode 7 uses only 1/2 rate and 1/8 rate frames. Mode change results 114 in codec output bit-rate but does not cause any decoding problems at 115 the receiver. For successful decoding, the decoder does not need to 116 know the encoder's current mode of operation. EVRC-WB provides a 117 standardized solution for packetized voice applications that allow 118 transitions between narrowband and wideband telephony. The most 119 important service addressed is IP telephony. Target devices can be 120 IP phones or VoIP handsets, media gateways, voice messaging servers, 121 etc. 123 4. EVRC-WB codec 125 EVRC-WB codec operates on 20 ms frames. It produces output frames of 126 one of the three different sizes: 171 bits, 80 bits or 16 bits. In 127 addition, there are two zero bit codec frame types: blank (null) 128 frames and erasure frames. The default sampling rate is 16 kHz. 129 Input and output at 8 kHz sampling rate is also supported. 131 The frame type values and size of the associated codec data frame are 132 listed in the table below: 134 Value Rate Total codec data frame size (in octets) 135 -------------------------------------------------------------------- 136 0 Blank 0 (0 bit) 137 1 1/8 2 (16 bits) 138 2 1/4 5 (40 bits) 139 3 1/2 10 (80 bits) 140 4 1 22 (171 bits; 5 bits padded at the end) 141 5 Erasure 0 (SHOULD NOT be transmitted by sender) 143 5. RTP header usage 145 The format of the RTP header is specified in RFC 3550 [6]. The 146 EVRC-WB payload formats (Section 6) use the fields of the RTP header 147 in a manner consistent with RFC 3550. 149 EVRC-WB has also the capability to operate with 8 kHz sampled input/ 150 output signals. The decoder does not require a priori knowledge 151 about the sampling rate of the original signal at the input of the 152 encoder. The decoder output can be at 8kHz or 16kHz regardless of 153 the sampling rate used at the encoder. Therefore, depending on the 154 implementation and the audio electro acoustic capabilities of the 155 devices, the input of the encoder and/or the output of the decoder 156 can be configured at 8 kHz; however, a 16 kHz RTP clock rate MUST 157 always be used. The RTP timestamp is increased by 320 for each 20 158 milliseconds. 160 The RTP header marker bit (M) SHALL be set to 1 if the first frame 161 carried in the packet contains a speech frame which is the first in a 162 talkspurt. For all other packets the marker bit SHALL be set to zero 163 (M=0). 165 6. Payload format 167 Three RTP packet formats are supported for the EVRC-WB codec - the 168 interleaved/bundled packet format, the header-free packet format and 169 the compact bundled packet format. For all these formats, the 170 operational details and capabilities, such as ToC, interleaving, DTX, 171 and bundling, of EVRC-WB are exactly the same as those of EVRC-B, as 172 defined in [3], except that the mode change request field in the ToC 173 MUST be interpreted according to the definition of the RATE_REDUC 174 parameter as defined in EVRC-WB [5]. 176 7. Congestion Control Considerations 178 Congestion control for RTP SHALL be used in accordance with RFC 3550 179 [6], and with any applicable RTP profile; e.g., RFC 3551 [10]. 181 Due to the header overhead, the number of frames encapsulated in each 182 RTP packet influences the overall bandwidth of the RTP stream. 183 Packing more frames in each RTP packet can reduce the number of 184 packets sent and hence the header overhead, at the expense of 185 increased delay and reduced error robustness. 187 8. Storage format for EVRC-WB Codec 189 The storage format is used for storing EVRC-WB encoded speech frames, 190 e.g., as a file or e-mail attachment. 192 The file begins with a magic number to identify the vocoder that is 193 used. The magic number for EVRC-WB corresponds to the ASCII 194 character string "#!EVCWB\n", i.e., "0x23 0x21 0x45 0x56 0x43 0x57 195 0x42 0x0A". 197 The codec data frames are stored in consecutive order, with a single 198 TOC entry field, extended to one octet, prefixing each codec data 199 frame. The ToC field is extended to one octet by setting the four 200 most significant bits of the octet to zero. For example, a ToC value 201 of 4 (a full-rate frame) is stored as 0x04. See Section 4 for the 202 mapping from frame type to ToC value. 204 Speech frames lost in transmission and non-received frames MUST be 205 stored as erasure frames (ToC value of 5) to maintain synchronization 206 with the original media. 208 9. IANA Considerations 210 This document updates EVRCB, EVRCB0 media subtypes defined in RFC 211 4788 [3] and adds new EVRC-WB media subtypes. 213 [-- RFC Editor: Please replace all instances of "RFC XXXX" in this 214 document with the RFC number of this document prior to IANA 215 registration and RFC publication, and remove this note.] 217 9.1. Media Type Registration 219 Following the guidelines in RFC 4288 [9], this section registers new 220 media subtypes for EVRC-WB and updates EVRCB, EVRCB0 media subtypes 221 defined in RFC 4788 [3]. 223 9.1.1. Registration of Media Type EVRCWB 225 Type name: audio 227 Subtype names: EVRCWB 229 Required parameters: none 231 Optional parameters: 233 mode-set-recv: A subset of EVRC-WB modes. Possible values are a 234 comma separated list of modes from the set: 0,4,7 (see Table 235 2.5.1.2-1 [5]). A decoder can use this attribute to inform its 236 preference to an encoder to operate in a specified subset of modes. 237 Absence of this parameter signals the mode set {0,4,7}. 239 sendmode: A mode of EVRC-WB codec. Encoder can use this to signal 240 its current mode of operation. Possible values are 0,4,7 (see Table 241 2.5.1.2-1 [5]). Absence of this parameter signals mode 0. 243 ptime: see RFC 4566 [8]. 245 maxptime: see RFC 4566 [8]. 247 maxinterleave: Maximum number for interleaving length (field LLL in 248 the Interleaving Octet). The interleaving lengths used in the entire 249 session MUST NOT exceed this maximum value. If not signaled, the 250 maxinterleave length MUST be 5. 252 silencesupp: see Section 6.1 in [3] 254 dtxmax: see Section 6.1 in [3] 255 dtxmin: see Section 6.1 in [3] 257 hangover: see Section 6.1 in [3] 259 Encoding considerations: 261 This media type is framed binary data (see RFC 4288, Section 4.8) and 262 is defined for transfer of EVRC-WB encoded data via RTP using the 263 Interleaved/Bundled packet format specified in RFC 3558 [2]. 265 Security considerations: See Section 18 of RFC XXXX. 267 Interoperability considerations: none 269 Published specification: 271 The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C [5]. Transfer 272 method with Interleaved/Bundled packet format via RTP is specified in 273 RFC 3558 and RFC XXXX. 275 3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services. 277 3GPP2 specifications are publicly accessible at http://www.3gpp2.org 279 Applications that use this media type: 281 It is expected that many VoIP applications (as well as mobile 282 applications) will use this type. 284 Additional information: 286 The following information applies for storage format only. 288 Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) 290 File extensions: evw, EVW 292 Macintosh file type code: none 294 Object identifier or OID: none 296 EVRC-WB speech frames may also be stored in the file format "3g2" 297 defined in 3GPP2 C.S0050-B, which is identified using the media types 298 "audio/3gpp2" or "video/3gpp2" registered by RFC4393. 300 Person & email address to contact for further information: 302 Harikishan Desineni 303 Intended usage: COMMON 305 Restrictions on usage: 307 This media type depends on RTP framing, and hence is only defined for 308 transfer via RTP (RFC 3550). Transfer within other framing protocols 309 is not defined at this time. 311 Author: 313 Harikishan Desineni 315 Change controller: 317 IETF Audio/Video Transport working group delegated from the IESG. 319 9.1.2. Registration of Media Type EVRCWB0 321 Type name: audio 323 Subtype names: EVRCWB0 325 Required parameters: 327 Optional parameters: 329 mode-set-recv: A subset of EVRC-WB modes. Possible values are a 330 comma separated list of modes from the set: 0,4,7 (see Table 331 2.5.1.2-1 [5]). A decoder can use this attribute to inform its 332 preference to an encoder to operate in a specified subset of modes. 333 Absence of this parameter signals the mode set {0,4,7}. 335 sendmode: A mode of EVRC-WB codec. Encoder can use this to signal 336 its current mode of operation. Possible values are 0,4,7 (see Table 337 2.5.1.2-1 [5]). Absence of this parameter signals mode 0. 339 ptime: see RFC 4566 [8]. 341 silencesupp: see Section 6.1 in [3] 343 dtxmax: see Section 6.1 in [3] 345 dtxmin: see Section 6.1 in [3] 347 hangover: see Section 6.1 in [3] 349 Encoding considerations: 351 This media type is framed binary data (see RFC 4288, Section 4.8) and 352 is defined for transfer of EVRC-WB encoded data via RTP using the 353 Header-Free packet format specified in RFC 3558. 355 Security considerations: See Section 18 of RFC XXXX. 357 Interoperability considerations: none 359 Published specification: 361 The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C [5]. Transfer 362 method with header free packet format via RTP is specified in RFC 363 3558 and RFC XXXX. 365 3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services. 367 3GPP2 specifications are publicly accessible at http://www.3gpp2.org 369 Applications that use this media type: 371 It is expected that many VoIP applications (as well as mobile 372 applications) will use this type. 374 Additional information: 376 The following information applies for storage format only. 378 Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) 380 File extensions: evw, EVW 382 Macintosh file type code: none 384 Object identifier or OID: none 386 EVRC-WB speech frames may also be stored in the file format "3g2" 387 defined in 3GPP2 C.S0050-B, which is identified using the media types 388 "audio/3gpp2" or "video/3gpp2" registered by RFC4393. 390 Person & email address to contact for further information: 392 Harikishan Desineni 394 Intended usage: COMMON 396 Restrictions on usage: 398 This media type depends on RTP framing, and hence is only defined for 399 transfer via RTP (RFC 3550). Transfer within other framing protocols 400 is not defined at this time. 402 Author: 404 Harikishan Desineni 406 Change controller: 408 IETF Audio/Video Transport working group delegated from the IESG. 410 9.1.3. Registration of Media Type EVRCWB1 412 Type name: audio 414 Subtype names: EVRCWB1 416 Required parameters: 418 Optional parameters: 420 mode-set-recv: A subset of EVRC-WB modes. Possible values are a 421 comma separated list of modes from the set: 0,4,7 (see Table 422 2.5.1.2-1 [5]). A decoder can use this attribute to inform its 423 preference to an encoder to operate in a specified subset of modes. 424 Value of 0 signals the support for wideband fixed rate (full or half 425 rate, depending on the value of 'fixedrate' parameter). Value of 4 426 signals narroband fixed full rate. Value of 7 signals narrowband 427 fixed half rate. Absence of this parameter signals mode 0. 429 sendmode: A mode of EVRC-WB codec. Encoder can use this to signal 430 its current mode of operation. Possible values are a comma separated 431 list of modes from the set: 0,4,7 (see Table 2.5.1.2-1 [5]). 432 'sendmode' with value 0 signals wideband fixed rate (full or half 433 rate, depending on the value of 'fixedrate' parameter) operation. 434 'sendmode' with value 4 signals narrowband fixed full rate operation. 435 'sendmode' with value 7 signals narrowband fixed half rate operation. 436 'fixedrate' parameter MUST not be present when 'sendmode' value is 4 437 or 7. Absence of this parameter signals mode 0. 439 ptime: see RFC 4566 [8]. 441 maxptime: see RFC 4566 [8]. 443 fixedrate: Indicates the EVRC-WB rate of the session while in single 444 rate operation. Valid values include: 0.5 and 1, where a value of 445 0.5 indicates the 1/2 rate while a value of 1 indicates the full 446 rate. If this parameter is not present, 1/2 rate is assumed. 448 silencesupp: see Section 6.1 in [3] 450 dtxmax: see Section 6.1 in [3] 452 dtxmin: see Section 6.1 in [3] 454 hangover: see Section 6.1 in [3] 456 Encoding considerations: 458 This media type is framed binary data (see RFC 4288, Section 4.8) and 459 is defined for transfer of EVRC-WB encoded data via RTP using the 460 compact bundle packet format specified in RFC 4788. 462 Security considerations: See Section 18 of RFC XXXX. 464 Interoperability considerations: none 466 Published specification: 468 The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. Transfer method 469 with compact bundled packet format via RTP is specified in RFC 4788 470 and RFC XXXX. 472 3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services. 474 3GPP2 specifications are publicly accessible at http://www.3gpp2.org 476 Applications that use this media type: 478 It is expected that many VoIP applications (as well as mobile 479 applications) will use this type. 481 Additional information: 483 The following information applies for storage format only. 485 Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) 487 File extensions: evw, EVW 489 Macintosh file type code: none 491 Object identifier or OID: none 493 EVRC-WB speech frames may also be stored in the file format "3g2" 494 defined in 3GPP2 C.S0050-B, which is identified using the media types 495 "audio/3gpp2" or "video/3gpp2" registered by RFC 4393. 497 Person & email address to contact for further information: 499 Harikishan Desineni 501 Intended usage: COMMON 503 Restrictions on usage: 505 This media type depends on RTP framing, and hence is only defined for 506 transfer via RTP (RFC 3550). Transfer within other framing protocols 507 is not defined at this time. 509 Author: 511 Harikishan Desineni 513 Change controller: 515 IETF Audio/Video Transport working group delegated from the IESG. 517 9.1.4. Updated Registration of Media Type EVRCB 519 Type name: audio 521 Subtype names: EVRCB 523 Required parameters: none 525 Optional parameters: 527 recvmode: A mode of EVRC-B codec. A decoder can use this attribute 528 to inform its preference to an encoder to operate in a specified 529 mode. Possible values are a comma separated list of modes from the 530 set: 0..7 (see encoder operating point column in Table 2-6 [4]). 532 sendmode: A mode of EVRC-B codec. An encoder can use this to signal 533 its current mode of operation. Possible values are a comma separated 534 list of modes from the set: 0..7 (see encoder operating point column 535 in Table 2-6 [4]). 537 ptime: see RFC 4566 539 maxptime: see RFC 4566 [8]. 541 maxinterleave: Maximum number for interleaving length (field LLL in 542 the Interleaving Octet). The interleaving lengths used in the entire 543 session MUST NOT exceed this maximum value. If not signaled, the 544 maxinterleave length MUST be 5. 546 silencesupp: see Section 6.1 for definition. If this parameter is 547 not present, the default value 1 MUST be assumed. 549 dtxmax: see Section 6.1 of [3] 551 dtxmin: see Section 6.1 of [3] 553 hangover: see Section 6.1 of [3] 555 Encoding considerations: 557 This media type is framed binary data (see RFC 4288, Section 4.8) and 558 is defined for transfer of EVRC-B encoded data via RTP using the 559 Interleaved/Bundled packet format specified in RFC 3558. 561 Security considerations: See Section 9 of RFC 4788. 563 Interoperability considerations: none 565 Published specification: 567 The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. Transfer method 568 with Interleaved/Bundled packet format via RTP is specified in RFC 569 3558,RFC XXXX and RFC 4788. 571 Applications that use this media type: 573 It is expected that many VoIP applications (as well as mobile 574 applications) will use this type. 576 Additional information: The following information applies for storage 577 format only. Magic number: #!EVRC-B\n (see Section 5 of RFC 4788) 578 File extensions: evb, EVB Macintosh file type code: none Object 579 identifier or OID: none 581 Person & email address to contact for further information: 583 Harikishan Desineni 585 Intended usage: COMMON 587 Restrictions on usage: 589 This media type depends on RTP framing, and hence is only defined for 590 transfer via RTP (RFC 3550). Transfer within other framing protocols 591 is not defined at this time. 593 Author: 595 Qiaobing Xie / Harikishan Desineni 597 Change controller: 599 IETF Audio/Video Transport working group delegated from the IESG. 601 9.1.5. Updated Registration of Media Type EVRCB0 603 Type name: audio 605 Subtype names: EVRCB0 607 Required parameters: none 609 Optional parameters: 611 recvmode: A mode of EVRC-B codec. A decoder can use this attribute 612 to inform its preference to an encoder to operate in a specified 613 mode. Possible values are a comma separated list of modes from the 614 set: 0..7 (see encoder operating point column in Table 2-6 [4]). 616 sendmode: A mode of EVRC-B codec. An encoder can use this to signal 617 its current mode of operation. Possible values are a comma separated 618 list of modes from the set: 0..7 (see encoder operating point column 619 in Table 2-6 [4]). 621 silencesupp: see Section 6.1 for definition. If this parameter is 622 not present, the default value 1 MUST be assumed. 624 dtxmax: see Section 6.1 of [3] 626 dtxmin: see Section 6.1 of [3] 628 hangover: see Section 6.1 of [3] 630 Encoding considerations: 632 This media type is framed binary data (see RFC 4288, Section 4.8) and 633 is defined for transfer of EVRC-B encoded data via RTP using the 634 Header-Free packet format specified in RFC 3558. 636 Security considerations: See Section 9 of RFC 4788. 638 Interoperability considerations: none 640 Published specification: 642 The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. Transfer method 643 with Header-Free packet format via RTP is specified in RFC 3558, RFC 644 4788 and RFC XXXX. 646 Applications that use this media type: 648 It is expected that many VoIP applications (as well as mobile 649 applications) will use this type. 651 Additional information: none 653 Person & email address to contact for further information: 655 Harikishan Desineni 657 Intended usage: COMMON 659 Restrictions on usage: 661 This media type depends on RTP framing, and hence is only defined for 662 transfer via RTP (RFC 3550). Transfer within other framing protocols 663 is not defined at this time. 665 Author: 667 Qiaobing Xie / Harikishan Desineni 669 Change controller: 671 IETF Audio/Video Transport working group delegated from the IESG. 673 10. SDP mode attributs for EVRC-WB and EVRC-B 675 'sendmode' can be used by a sender (EVRC-WB or EVRC-B) to announce 676 its encoder's current mode of operation. Sender can change its mode 677 anytime and it does not cause any decoding problems at the receiver. 679 'recvmode' is defined for use with EVRC-B. A decoder can use this 680 attribute to inform its preference to an encoder to operate in a 681 specified mode. Receiver will continue to decode properly even if 682 the sender does not operate in the preferred mode. 684 'mode-set-recv' is defined for use with EVRC-WB. A decoder can use 685 this attribute to inform its preference to an encoder to operate in a 686 specified subset of modes. Receiver will continue to decode properly 687 even if the sender does not operate in one of the preferred modes. A 688 set has been defiend so that several modes can be expressed as a 689 preference in one attempt. For ex., the set {4,7} signals that the 690 receiver prefers the sender to operate in narrowband modes of 691 EVRC-WB. 693 11. EVRC-B RFC XXXX Interoperability with legacy EVRC-B (RFC 4788) 694 implementations 696 This document adds new optional parameters "recvmode" and "sendmode" 697 to the original EVRC-B payload subtypes "EVRCB" and "EVRCB0" defined 698 in RFC 4788. The existing RFC 4788 implementations will not send 699 these parameters in SDP and will ignore if they are received. This 700 will allow interoperability between RFC 4788 and RFC XXXX 701 implementations of EVRC-B. For an example offer and answer exchange, 702 see Section 17. 704 12. Mapping EVRC-WB media type parameters into SDP 706 Information carried in the media type specification has a specific 707 mapping to fields in the Session Description Protocol (SDP) [8], 708 which is commonly used to describe RTP sessions. When SDP is used to 709 specify sessions employing EVRC-WB encoded speech, the mapping is as 710 follows. 712 The media type ("audio") goes in SDP "m=" as the media name. 714 o The media subtype ("EVRCWB", "EVRCWB0" or "EVRCWB1") goes in SDP 715 "a=rtpmap" as the encoding name. 717 o The optional parameters "ptime" and "maxptime" (for subtypes 718 EVRCWB, EVRCWB1) go in the SDP "a=ptime" and "a=maxptime" 719 attributes, respectively. 721 o Any remaining parameters (for subtypes EVRCWB, EVRCWB0 and 722 EVRCWB1) go in the SDP "a=fmtp" attribute by copying them from the 723 media type string as a semicolon separated list of parameter=value 724 pairs. 726 13. Mapping EVRC-B media type parameters into SDP 728 The optional parameters "recvmode" and "sendmode" (for subtypes EVRCB 729 and EVRCB0) go in the SDP "a=fmtp" attribute by copying them directly 730 from the media type string. 732 14. Offer-Answer Model Considerations for EVRC-WB 734 The following considerations apply when using SDP offer-answer 735 procedures [7] to negotiate the use of EVRC-WB payload in RTP: 737 o Since EVRC-WB is an extension of EVRC-B, the offerer SHOULD 738 announce EVRC-B support in its "m=audio" line, with EVRC-WB as the 739 preferred codec. This will allow interoperability with an 740 answerer which supports only EVRC-B. 742 Below is an example of such an offer: 744 m=audio 55954 RTP/AVP 98 99 745 a=rtpmap:98 EVRCWB0/16000 746 a=rtpmap:99 EVRCB0/8000 747 a=fmtp:98 mode-set-recv=0,4;sendmode=0 748 a=fmtp:99 recvmode=0 sendmode=4 750 If the answerer supports EVRC-WB then the answerer can keep the 751 payload type 98 in its answer and the conversation can be done 752 using EVRC-WB. Else, if the answerer supports only EVRC-B then 753 the answerer will leave only the payload type 99 in its answer and 754 the conversation will be done using EVRC-B. 756 An example answer for the above offer: 758 m=audio 55954 RTP/AVP 98 759 a=rtpmap:98 EVRCWB0/16000 760 a=fmtp:98 mode-set-recv=4;sendmode=4 762 o "mode-set-recv" is a uni-directional receive only parameter. 764 o "sendmode" is a uni-directional send only parameter. 766 o Using "sendmode", a sender can signal its current mode of 767 operation. Note that a receiver may receive RTP media well before 768 the arrival of SDP with 'sendmode' parameter. 770 o An offerer can use "mode-set-recv" to request that the remote 771 sender's encoder be limited to the list of modes signaled in 772 "mode-set-recv". A remote sender MAY ignore "mode-set-recv" 773 requests. 775 o The parameters "maxptime" and "ptime" will in most cases not 776 affect interoperability, however the setting of the parameters can 777 affect the performance of the application. The SDP offer-answer 778 handling of the "ptime" parameter is described in RFC3264 [7]. 779 The "maxptime" parameter MUST be handled in the same way. 781 o For a sendonly stream, "mode-set-recv" parameter is not useful and 782 SHOULD NOT be used. 784 o For a recvonly stream, "sendmode" parameter is not useful and 785 SHOULD NOT be used. 787 o When using EVRCWB1, the entire session MUST use the same fixed 788 rate and mode (0-Wideband or 4,7-Narrowband). 790 o For additional rules which MUST be followed while negotiating DTX 791 parameters, see Section 6.8 in [3]. 793 o Any unknown parameter in an SDP offer MUST be ignored by the 794 receiver and MUST NOT be included in the SDP answer. 796 15. Offer-Answer Model Considerations for EVRC-B 798 See Section 6.8 of [3] for offer-answer usage of EVRC-B. The 799 following are several additional considerations for EVRC-B. 801 o "recvmode" is a uni-directional receive only parameter. 803 o "sendmode" is a uni-directional send only parameter. 805 o Using "recvmode", a receiver can signal the remote sender to 806 operate its encoder in the specified mode. A remote sender MAY 807 ignore "recvmode" requests. 809 o Using "sendmode", a sender can signal its current mode of 810 operation. Note that a receiver may receive RTP media well before 811 the arrival of SDP with 'sendmode' parameter. 813 o For a sendonly stream, "recvmode" parameter is not useful and 814 SHOULD NOT be used. 816 o For a recvonly stream, "sendmode" parameter is not useful and 817 SHOULD NOT be used. 819 16. Declarative SDP Considerations 821 For declarative use of SDP in SAP [11] and RTSP [12] , the following 822 considerations apply: 824 o Any "maxptime" and "ptime" values should be selected with care to 825 ensure that the session's participants can achieve reasonable 826 performance. 828 o The payload format configuration parameters are all declarative 829 and a participant MUST use the configuration(s) that is provided 830 for the session. More than one configuration may be provided if 831 necessary by declaring multiple RTP payload types, however the 832 number of types should be kept small. For declarative examples, 833 see Section 17 835 17. Examples 837 Some example SDP session descriptions utilizing EVRC-WB and EVRC-B 838 encodings follow. In these examples, long a=fmtp lines are folded to 839 meet the column width constraints of this document. The backslash 840 ("\") at the end of a line and the carriage return that follows it 841 should be ignored. Note that media subtype names are case- 842 insensitive. Parameter names are case-insensitive both in media 843 types and in the mapping to the SDP a=fmtp attribute. 845 Example usage of EVRCWB: 847 m=audio 49120 RTP/AVP 97 98 848 a=rtpmap:97 EVRCWB/16000 849 a=rtpmap:98 EVRCB0/8000 850 a=fmtp:97 mode-set-recv=0,4;sendmode=0 851 a=fmtp:98 recvmode=0 sendmode=0 852 a=maxptime:120 854 Example usage of EVRCWB0: 856 m=audio 49120 RTP/AVP 97 98 857 a=rtpmap:97 EVRCWB0/16000 858 a=rtpmap:98 EVRCB0/8000 859 a=fmtp:97 mode-set-recv=0,4;sendmode=0 860 a=fmtp:98 recvmode=0 sendmode=0 862 Example SDP answer from a media gateway requesting a terminal to 863 limit its encoder operation to EVRC-WB mode 4. 865 m=audio 49120 RTP/AVP 97 866 a=rtpmap:97 EVRCWB0/16000 867 a=fmtp:97 mode-set-recv=4;sendmode=4 869 Example usage of EVRCWB1: 871 m=audio 49120 RTP/AVP 97 98 872 a=rtpmap:97 EVRCWB1/16000 873 a=fmtp:97 mode-set-recv=4;sendmode=4 874 a=maxptime:100 876 Example usage of EVRCWB with DTX with silencesupp=1: 878 m=audio 49120 RTP/AVP 97 98 879 a=rtpmap:97 EVRCWB/16000 880 a=rtpmap:98 EVRCB0/8000 881 a=fmtp:97 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1 \ 882 mode-set-recv=0,4; sendmode=0 883 a=fmtp:98 recvmode=0 sendmode=0 884 a=maxptime:120 886 Examples usage of EVRCWB with DTX with silencesupp=0: 888 m=audio 49120 RTP/AVP 97 98 889 a=rtpmap:97 EVRCWB/16000 890 a=rtpmap:98 EVRCB0/8000 891 a=fmtp:97 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1 \ 892 mode-set-recv=0,4;sendmode=0 893 a=fmtp:98 recvmode=0 sendmode=0 894 a=maxptime:120 896 Example usage of EVRCB: 898 m=audio 49120 RTP/AVP 97 899 a=rtpmap:97 EVRCB/8000 900 a=fmtp:97 recvmode=0 sendmode=4 901 a=maxptime:120 903 Example usage of EVRCB0: 905 m=audio 49120 RTP/AVP 97 906 a=rtpmap:97 EVRCB0/8000 907 a=fmtp:97 recvmode=0 sendmode=4 909 Example offer answer exchange between EVRC-WB and 910 legacy EVRC-B (RFC 4788): 912 Offer: 914 m=audio 55954 RTP/AVP 98 99 915 a=rtpmap:98 EVRCWB0/16000 916 a=rtpmap:99 EVRCB0/8000 917 a=fmtp:98 mode-set-recv=0,4;sendmode=0 918 a=fmtp:99 recvmode=0 sendmode=0 920 Answer: 922 m=audio 55954 RTP/AVP 99 923 a=rtpmap:99 EVRCB0/8000 925 Example offer answer exchange between EVRC-WB and 926 updated EVRC-B (RFC XXXX): 928 Offer: 930 m=audio 55954 RTP/AVP 98 99 931 a=rtpmap:98 EVRCWB0/16000 932 a=rtpmap:99 EVRCB0/8000 933 a=fmtp:98 mode-set-recv=0,4; sendmode=0 934 a=fmtp:99 recvmode=0 sendmode=0 936 Answer: 938 m=audio 55954 RTP/AVP 99 939 a=rtpmap:99 EVRCB0/8000 940 a=fmtp:99 recvmode=0 sendmode=4 942 In the above example, note that the answerer has chosen 943 to send in mode 4 even though the offerer was willing to 944 receive in mode 0. 'recvmode' is a receiver's preference 945 but the sender can send in a different mode. 947 Example offer answer exchanges for interoperability between 948 legacy (RFC XXXX) and updated EVRC-B(RFC 4788) implementations: 950 Offer from an offer which supports updated EVRC-B (RFC XXXX) 951 implementation: 953 m=audio 55954 RTP/AVP 99 954 a=rtpmap:99 EVRCB0/8000 955 a=fmtp:99 recvmode=0 sendmode=4 957 Answer from an answerer which supports only 958 legacy EVRC-B (RFC 4788) implementation: 960 m=audio 55954 RTP/AVP 99 961 a=rtpmap:99 EVRCB0/8000 963 Offer from an offer which supports only 964 legacy EVRC-B (RFC 4788) implementation: 966 m=audio 55954 RTP/AVP 99 967 a=rtpmap:99 EVRCB0/8000 969 Answer from an answerer which supports updated 970 EVRC-B (RFC XXXX) implementation: 972 m=audio 55954 RTP/AVP 99 973 a=rtpmap:99 EVRCB0/8000 974 a=fmtp:99 recvmode=0 sendmode=4 976 18. Security Considerations 978 Implementations using the payload defined in this specification are 979 subject to the security considerations discussed in RFC3558 [2], 980 RFC3550 [6], and any appropriate profile (for example RFC3551 [10]). 981 This payload does not specify any different security services. 983 19. Changes to RFC4788 985 This document updates RFC 4788 and the updates are summarized below: 987 o Added new media type attribute "sendmode" to media sub-types EVRCB 988 and EVRCB0. This attribute can be used to signal EVRC-B encoder's 989 current mode of operation. 991 o Added new media type attribute "recvmode" to media sub-types EVRCB 992 and EVRCB0. This attribute can be used to signal EVRC-B decoder's 993 preferred operating mode to a remote sender. 995 20. References 997 20.1. Normative References 999 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1000 Levels", BCP 14, RFC 2119, March 1997. 1002 [2] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs 1003 (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, 1004 July 2003. 1006 [3] Xie, Q., "Enhancements to RTP Payload Formats for EVRC Family 1007 Codecs", RFC 4788, January 2007. 1009 [4] "Enhanced Variable Rate Codec, Speech Service Option 3 and 68 1010 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B 1011 v1.0 , May 2006. 1013 [5] "Enhanced Variable Rate Codec, Speech Service Option 3,68 and 1014 70 for Wideband Spread Spectrum Digital Systems", 3GPP2 1015 C.S0014-C v1.0 , October 2006. 1017 [6] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 1018 Applications", STD 64, RFC 3550, March 1997. 1020 [7] Rosenberg, J., "An Offer/Answer Model with Session Description 1021 Protocol (SDP)", RFC 3264, June 2002. 1023 [8] Handley, M., "SDP: Session Description Protocol", RFC 4566, 1024 July 2006. 1026 [9] Freed, N., "Media Type Specifications and Registration 1027 Procedures", BCP 13, RFC 4288, December 2005. 1029 20.2. Informative References 1031 [10] Schulzrinne, H., "RTP Profile for Audio and Video Conferences 1032 with Minimal Control", STD 65, RFC 3551, July 2003. 1034 [11] Handley, M., "Session Announcement Protocol", RFC 2974, 1035 October 2000. 1037 [12] Schulzrinne, H., "Real Time Streaming Protocol (RTSP)", 1038 RFC 2326, April 1998. 1040 Authors' Addresses 1042 Harikishan Desineni 1043 Qualcomm 1044 5775 Morehouse Drive 1045 San Diego, CA 92126 1046 USA 1048 Phone: +1 858 845 8996 1049 Email: hd@qualcomm.com 1050 URI: http://www.qualcomm.com 1052 Qiaobing Xie 1053 Motorola 1054 1501 W. Shure Drive, 2-F9 1055 Arlington Heights, IL 60004 1056 USA 1058 Phone: +1-847-632-3028 1059 Email: Qiaobing.Xie@Motorola.com 1060 URI: http://www.motorola.com 1062 Full Copyright Statement 1064 Copyright (C) The IETF Trust (2007). 1066 This document is subject to the rights, licenses and restrictions 1067 contained in BCP 78, and except as set forth therein, the authors 1068 retain all their rights. 1070 This document and the information contained herein are provided on an 1071 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1072 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1073 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1074 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1075 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1076 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1078 Intellectual Property 1080 The IETF takes no position regarding the validity or scope of any 1081 Intellectual Property Rights or other rights that might be claimed to 1082 pertain to the implementation or use of the technology described in 1083 this document or the extent to which any license under such rights 1084 might or might not be available; nor does it represent that it has 1085 made any independent effort to identify any such rights. Information 1086 on the procedures with respect to rights in RFC documents can be 1087 found in BCP 78 and BCP 79. 1089 Copies of IPR disclosures made to the IETF Secretariat and any 1090 assurances of licenses to be made available, or the result of an 1091 attempt made to obtain a general license or permission for the use of 1092 such proprietary rights by implementers or users of this 1093 specification can be obtained from the IETF on-line IPR repository at 1094 http://www.ietf.org/ipr. 1096 The IETF invites any interested party to bring to its attention any 1097 copyrights, patents or patent applications, or other proprietary 1098 rights that may cover technology that may be required to implement 1099 this standard. Please address the information to the IETF at 1100 ietf-ipr@ietf.org. 1102 Acknowledgment 1104 Funding for the RFC Editor function is provided by the IETF 1105 Administrative Support Activity (IASA).