idnits 2.17.1 draft-ietf-avt-rtp-evrc-wb-09.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 1096. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1107. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1114. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1120. 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 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 (December 3, 2007) is 5987 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) -- Looks like a reference, but probably isn't: 'RFC3550' on line 667 -- 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. '10') (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '13') (Obsoleted by RFC 7826) Summary: 3 errors (**), 0 flaws (~~), 2 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: 4788 (if approved) Q. Xie 5 Intended status: Standards Track Motorola 6 Expires: June 5, 2008 December 3, 2007 8 RTP payload format for Enhanced Variable Rate Wideband Codec (EVRC-WB) 9 and media subtype updates for EVRC-B codec 10 draft-ietf-avt-rtp-evrc-wb-09.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 June 5, 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 Enhanced Variable Rate Wideband Codec 45 (EVRC-WB) and updates the media type registrations for EVRC-B codec. 46 Several media type registrations are included for EVRC-WB RTP payload 47 formats. In addition, a file format is specified for transport of 48 EVRC-WB speech 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 the EVRC-WB Codec . . . . . . . . . . . . . 10 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 61 9.1. Media Type Registrations . . . . . . . . . . . . . . . . . 11 62 9.1.1. Registration of Media Type audio/EVRCWB . . . . . . . 11 63 9.1.2. Registration of Media Type audio/EVRCWB0 . . . . . . . 13 64 9.1.3. Registration of Media Type audio/EVRCWB1 . . . . . . . 15 65 9.1.4. Updated Registration of Media Type audio/EVRCB . . . . 17 66 9.1.5. Updated Registration of Media Type audio/EVRCB0 . . . 19 67 10. SDP mode attributes for EVRC-WB and EVRC-B . . . . . . . . . . 21 68 11. EVRC-B Interoperability with legacy implementations (RFC 69 4788) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 RFC 4788 . . . . . . . . . . . . . . . . . . . . . 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 89 and 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. The EVRC-WB codec offers better speech quality 92 than the EVRC and EVRC-B codecs. EVRC-WB belongs to the EVRC family 93 of codecs. This document also updates the media type registrations 94 for the 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 the EVRC-B [4] speech codec 105 developed in 3GPP2 with support for discontinuous transmission (DTX). 106 It provides enhanced (wideband) voice quality. 108 The EVRC-WB codec operates on 20 ms frames, and the default sampling 109 rate is 16 kHz. Input and output at 8 kHz sampling rate is also 110 supported. The EVRC-WB codec can operate in three modes (0, 4 and 7) 111 defined in [5]. EVRC-WB modes 4 and 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 change but does not cause any decoding 115 problems at the receiver. For successful decoding, the decoder does 116 not need to know the encoder's current mode of operation. EVRC-WB 117 provides a standardized solution for packetized voice applications 118 that allow transitions between narrowband and wideband telephony. 119 The most important service addressed is IP telephony. Target devices 120 can be IP phones or VoIP handsets, media gateways, voice messaging 121 servers, etc. 123 4. EVRC-WB codec 125 The EVRC-WB codec operates on 20 ms frames. It produces output 126 frames of one of the three different sizes: 171 bits, 80 bits, or 16 127 bits. In addition, there are two zero bit codec frame types: blank 128 (null) frames and erasure frames. The default sampling rate is 16 129 kHz. Input and output at 8 kHz sampling rate is also supported. 131 The frame type values and sizes of the associated codec data frames 132 are listed in the table below: 134 Value Rate Total codec data frame size in bytes (and in bits) 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 [6]. 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 electro acoustic audio 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]. The media type audio/EVRCWB 175 maps to the interleaved/bundled packet format, audio/EVRCWB0 maps to 176 the header-free packet format and audio/EVRCWB1 maps to the compact 177 bundled packet format. 179 7. Congestion Control Considerations 181 Congestion control for RTP SHALL be used in accordance with RFC 3550 182 [6], and with any applicable RTP profile; e.g., RFC 3551 [11]. 184 Due to the header overhead, the number of frames encapsulated in each 185 RTP packet influences the overall bandwidth of the RTP stream. 186 Packing more frames in each RTP packet can reduce the number of 187 packets sent and hence the header overhead, at the expense of 188 increased delay and reduced error robustness. 190 8. Storage format for the EVRC-WB Codec 192 The storage format is used for storing EVRC-WB encoded speech frames, 193 e.g., as a file or e-mail attachment. 195 The file begins with a magic number to identify the vocoder that is 196 used. The magic number for EVRC-WB corresponds to the ASCII 197 character string "#!EVCWB\n", i.e., "0x23 0x21 0x45 0x56 0x43 0x57 198 0x42 0x0A". 200 The codec data frames are stored in consecutive order, with a single 201 ToC entry field, extended to one octet, prefixing each codec data 202 frame. The ToC field is extended to one octet by setting the four 203 most significant bits of the octet to zero. For example, a ToC value 204 of 4 (a full-rate frame) is stored as 0x04. See Section 4 for the 205 mapping from frame type to ToC value. 207 Speech frames lost in transmission and non-received frames MUST be 208 stored as erasure frames (ToC value of 5) to maintain synchronization 209 with the original media. 211 9. IANA Considerations 213 This document updates the audio/EVRCB and audio/EVRCB0 media types 214 defined in RFC 4788 [3] and adds new EVRC-WB 'audio' media subtypes. 216 [-- RFC Editor: Please replace all instances of "RFC XXXX" in this 217 document with the RFC number of this document prior to IANA 218 registration and RFC publication, and remove this note.] 220 9.1. Media Type Registrations 222 Following the guidelines in RFC 4855 [9] and RFC 4288 [10], this 223 section registers new 'audio' media subtypes for EVRC-WB and updates 224 the audio/EVRCB and audio/EVRCB0 media type registrations contained 225 in RFC 4788 [3]. 227 9.1.1. Registration of Media Type audio/EVRCWB 229 Type name: audio 231 Subtype names: EVRCWB 233 Required parameters: none 235 Optional parameters: 237 These parameters apply to RTP transfer only. 239 mode-set-recv: A subset of EVRC-WB modes. Possible values are a 240 comma separated list of modes from the set {0,4,7} (see Table 241 2.5.1.2-1 in 3GPP2 C.S0014-C). A decoder can use this attribute to 242 inform an encoder of its preference to operate in a specified subset 243 of modes. Absence of this parameter signals the mode set {0,4,7}. 245 sendmode: A mode of the EVRC-WB codec. An encoder can use this to 246 signal its current mode of operation. Possible values are 0,4,7 (see 247 Table 2.5.1.2-1 in 3GPP2 C.S0014-C). Absence of this parameter 248 signals mode 0. 250 ptime: see RFC 4566. 252 maxptime: see RFC 4566. 254 maxinterleave: Maximum number for interleaving length (field LLL in 255 the Interleaving Octet)[0..7]. The interleaving lengths used in the 256 entire session MUST NOT exceed this maximum value. If not signaled, 257 the maxinterleave length MUST be 5. 259 silencesupp: see Section 6.1 in RFC 4788. 261 dtxmax: see Section 6.1 in RFC 4788. 263 dtxmin: see Section 6.1 in RFC 4788. 265 hangover: see Section 6.1 in RFC 4788. 267 Encoding considerations: 269 This media type is framed binary data (see RFC 4288, Section 4.8) and 270 is defined for transfer of EVRC-WB encoded data via RTP using the 271 Interleaved/Bundled packet format specified in RFC 3558. 273 Security considerations: See Section 18 of RFC XXXX. 275 Interoperability considerations: none 277 Published specification: 279 The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. The transfer 280 method with the Interleaved/Bundled packet format via RTP is 281 specified in RFC 3558 and RFC XXXX. 283 3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services. 285 3GPP2 specifications are publicly accessible at http://www.3gpp2.org 287 Applications that use this media type: 289 It is expected that many VoIP applications (as well as mobile 290 applications) will use this type. 292 Additional information: 294 The following applies to stored-file transfer methods: 296 Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) 298 File extensions: evw, EVW 300 Macintosh file type code: none 302 Object identifier or OID: none 304 EVRC-WB speech frames may also be stored in the file format "3g2" 305 defined in 3GPP2 C.S0050-B, which is identified using the media types 306 "audio/3gpp2" or "video/3gpp2" registered by RFC 4393. 308 Person & email address to contact for further information: 310 Harikishan Desineni 312 Intended usage: COMMON 314 Restrictions on usage: 316 When this media type is used in the context of transfer over RTP, the 317 RTP payload format specified in Section 4.1 of RFC 3558 SHALL be 318 used. In all other contexts, the file format defined in Section 8 of 319 RFC XXXX SHALL be used. 321 Author: 323 Harikishan Desineni 325 Change controller: 327 IETF Audio/Video Transport working group delegated from the IESG. 329 9.1.2. Registration of Media Type audio/EVRCWB0 331 Type name: audio 333 Subtype names: EVRCWB0 335 Required parameters: 337 Optional parameters: 339 These parameters apply to RTP transfer only. 341 mode-set-recv: A subset of EVRC-WB modes. Possible values are a 342 comma separated list of modes from the set {0,4,7} (see Table 343 2.5.1.2-1 in 3GPP2 C.S0014-C). A decoder can use this attribute to 344 inform an encoder of its preference to operate in a specified subset 345 of modes. Absence of this parameter signals the mode set {0,4,7}. 347 sendmode: A mode of the EVRC-WB codec. An encoder can use this to 348 signal its current mode of operation. Possible values are 0,4,7 (see 349 Table 2.5.1.2-1 in 3GPP2 C.S0014-C). Absence of this parameter 350 signals mode 0. 352 ptime: see RFC 4566. 354 silencesupp: see Section 6.1 in RFC 4788. 356 dtxmax: see Section 6.1 in RFC 4788. 358 dtxmin: see Section 6.1 in RFC 4788. 360 hangover: see Section 6.1 in RFC 4788. 362 Encoding considerations: 364 This media type is framed binary data (see RFC 4288, Section 4.8) and 365 is defined for transfer of EVRC-WB encoded data via RTP using the 366 Header-Free packet format specified in RFC 3558. 368 Security considerations: See Section 18 of RFC XXXX. 370 Interoperability considerations: none 372 Published specification: 374 The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. The transfer 375 method with the Header-Free packet format via RTP is specified in RFC 376 3558 and RFC XXXX. 378 3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services. 380 3GPP2 specifications are publicly accessible at http://www.3gpp2.org 382 Applications that use this media type: 384 It is expected that many VoIP applications (as well as mobile 385 applications) will use this type. 387 Additional information: None 389 Person & email address to contact for further information: 391 Harikishan Desineni 393 Intended usage: COMMON 395 Restrictions on usage: 397 This media type depends on RTP framing, and hence is only defined for 398 transfer via RTP [RFC3550], the RTP payload format specified in 399 Section 4.2 of RFC 3558 SHALL be used. This media type SHALL NOT be 400 used for storage or file transfer using the file format defined in 401 Section 8 of RFC XXXX, instead audio/EVRCWB SHALL be used. 403 Author: 405 Harikishan Desineni 407 Change controller: 409 IETF Audio/Video Transport working group delegated from the IESG. 411 9.1.3. Registration of Media Type audio/EVRCWB1 413 Type name: audio 415 Subtype names: EVRCWB1 417 Required parameters: 419 Optional parameters: 421 These parameters apply to RTP transfer only. 423 mode-set-recv: A subset of EVRC-WB modes. Possible values are a 424 comma separated list of modes from the set {0,4,7} (see Table 425 2.5.1.2-1 in 3GPP2 C.S0014-C). A decoder can use this attribute to 426 inform an encoder of its preference to operate in a specified subset 427 of modes. A value of 0 signals the support for wideband fixed rate 428 (full or half rate, depending on the value of 'fixedrate' parameter). 429 A value of 4 signals narroband fixed full rate. A value of 7 signals 430 narrowband fixed half rate. Absence of this parameter signals mode 431 0. 433 sendmode: A mode of the EVRC-WB codec. An encoder can use this to 434 signal its current mode of operation. Possible values are 0,4,7 (see 435 Table 2.5.1.2-1 in 3GPP2 C.S0014-C). 'sendmode' with value 0 signals 436 wideband fixed rate operation (full or half rate, depending on the 437 value of the 'fixedrate' parameter). 'sendmode' with value 4 signals 438 narrowband fixed full rate operation. 'sendmode' with value 7 signals 439 narrowband fixed half rate operation. The 'fixedrate' parameter MUST 440 NOT be present when the 'sendmode' value is 4 or 7. Absence of this 441 parameter signals mode 0. 443 ptime: see RFC 4566. 445 maxptime: see RFC 4566. 447 fixedrate: Indicates the EVRC-WB rate of the session while in single 448 rate operation. Valid values include: 0.5 and 1, where a value of 449 0.5 indicates the 1/2 rate while a value of 1 indicates the full 450 rate. If this parameter is not present, 1/2 rate is assumed. 452 silencesupp: see Section 6.1 in RFC 4788. 454 dtxmax: see Section 6.1 in RFC 4788. 456 dtxmin: see Section 6.1 in RFC 4788. 458 hangover: see Section 6.1 in RFC 4788. 460 Encoding considerations: 462 This media type is framed binary data (see RFC 4288, Section 4.8) and 463 is defined for transfer of EVRC-WB encoded data via RTP using the 464 compact bundle packet format specified in RFC 4788. 466 Security considerations: See Section 18 of RFC XXXX. 468 Interoperability considerations: none 470 Published specification: 472 The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. The transfer 473 method with the compact bundled packet format via RTP is specified in 474 RFC 4788 and RFC XXXX. 476 3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services. 478 3GPP2 specifications are publicly accessible at http://www.3gpp2.org 480 Applications that use this media type: 482 It is expected that many VoIP applications (as well as mobile 483 applications) will use this type. 485 Additional information: None 487 Person & email address to contact for further information: 489 Harikishan Desineni 491 Intended usage: COMMON 493 Restrictions on usage: 495 This media type depends on RTP framing, and hence is only defined for 496 transfer via RTP [RFC3550], the RTP payload format specified in 497 Section 4 of RFC 4788 SHALL be used. This media type SHALL NOT be 498 used for storage or file transfer using the file format defined in 499 Section 8 of RFC XXXX, instead audio/EVRCWB SHALL be used. 501 Author: 503 Harikishan Desineni 505 Change controller: 507 IETF Audio/Video Transport working group delegated from the IESG. 509 9.1.4. Updated Registration of Media Type audio/EVRCB 511 Type name: audio 513 Subtype names: EVRCB 515 Required parameters: none 517 Optional parameters: 519 These parameters apply to RTP transfer only. 521 recvmode: A mode of the EVRC-B codec. A decoder can use this 522 attribute to inform an encoder of its preference to operate in a 523 specified mode. Possible values are 0..7 (see the encoder operating 524 point column in Table 2-6 of 3GPP2 C.S0014-B). 526 sendmode: A mode of the EVRC-B codec. An encoder can use this to 527 signal its current mode of operation. Possible values are 0..7 (see 528 encoder operating point column in Table 2-6 of 3GPP2 C.S0014-B). 530 ptime: see RFC 4566. 532 maxptime: see RFC 4566. 534 maxinterleave: Maximum number for interleaving length (field LLL in 535 the Interleaving Octet). The interleaving lengths used in the entire 536 session MUST NOT exceed this maximum value. If not signaled, the 537 maxinterleave length MUST be 5. 539 silencesupp: see Section 6.1 of RFC 4788 for a definition. If this 540 parameter is not present, the default value 1 MUST be assumed. 542 dtxmax: see Section 6.1 of RFC 4788. 544 dtxmin: see Section 6.1 of RFC 4788. 546 hangover: see Section 6.1 of RFC 4788. 548 Encoding considerations: 550 This media type is framed binary data (see RFC 4288, Section 4.8) and 551 is defined for transfer of EVRC-B encoded data via RTP using the 552 Interleaved/Bundled packet format specified in RFC 3558. 554 Security considerations: See Section 9 of RFC 4788. 556 Interoperability considerations: none 558 Published specification: 560 The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. The transfer 561 method with the Interleaved/Bundled packet format via RTP is 562 specified in RFC 3558, RFC 4788 and RFC XXXX. 564 Applications that use this media type: 566 It is expected that many VoIP applications (as well as mobile 567 applications) will use this type. 569 Additional information: The following information applies for the 570 storage format only. 572 Magic number: #!EVRC-B\n (see Section 5 of RFC 4788) 574 File extensions: evb, EVB 576 Macintosh file type code: none 578 Object identifier or OID: none 580 Person & email address to contact for further information: 582 Harikishan Desineni 584 Intended usage: COMMON 586 Restrictions on usage: 588 When this media type is used in the context of transfer over RTP, the 589 RTP payload format specified in Section 4.1 of RFC 3558 SHALL be 590 used. In all other contexts, the file format defined in Section 5 of 591 RFC 4788 SHALL be used. 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 audio/EVRCB0 603 Type name: audio 605 Subtype names: EVRCB0 607 Required parameters: none 609 Optional parameters: 611 These parameters apply to RTP transfer only. 613 recvmode: A mode of the EVRC-B codec. A decoder can use this 614 attribute to inform an encoder of its preference to operate in a 615 specified mode. Possible values are 0..7 (see the encoder operating 616 point column in Table 2-6 of 3GPP2 C.S0014-B). 618 sendmode: A mode of the EVRC-B codec. An encoder can use this to 619 signal its current mode of operation. Possible values are 0..7 (see 620 the encoder operating point column in Table 2-6 of 3GPP2 C.S0014-B). 622 silencesupp: see Section 6.1 of RFC 4788 for a definition. If this 623 parameter is not present, the default value 1 MUST be assumed. 625 dtxmax: see Section 6.1 of RFC 4788. 627 dtxmin: see Section 6.1 of RFC 4788. 629 hangover: see Section 6.1 of RFC 4788. 631 Encoding considerations: 633 This media type is framed binary data (see RFC 4288, Section 4.8) and 634 is defined for transfer of EVRC-B encoded data via RTP using the 635 Header-Free packet format specified in RFC 3558. 637 Security considerations: See Section 9 of RFC 4788. 639 Interoperability considerations: none 641 Published specification: 643 The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. The transfer 644 method with the Header-Free packet format via RTP is specified in RFC 645 3558, RFC 4788 and RFC XXXX. 647 Applications that use this media type: 649 It is expected that many VoIP applications (as well as mobile 650 applications) will use this type. 652 Additional information: None 654 Person & email address to contact for further information: 656 Harikishan Desineni 658 Intended usage: COMMON 660 Restrictions on usage: 662 When this media type is used in the context of transfer over RTP, the 663 RTP payload format specified in Section 4.2 of RFC 3558 SHALL be 664 used. 666 This media type depends on RTP framing, and hence is only defined for 667 transfer via RTP [RFC3550], the RTP payload format specified in 668 Section 4.2 of RFC 3558 SHALL be used. This media type SHALL NOT be 669 used for storage or file transfer using the file format defined in 670 Section 5 of RFC 4788, instead audio/EVRCB SHALL be used. 672 Author: 674 Qiaobing Xie / Harikishan Desineni 676 Change controller: 678 IETF Audio/Video Transport working group delegated from the IESG. 680 10. SDP mode attributes for EVRC-WB and EVRC-B 682 'sendmode' can be used by a sender (EVRC-WB or EVRC-B) to announce 683 its encoder's current mode of operation. A sender can change its 684 mode anytime and this does not cause any decoding problems at the 685 receiver. 687 'recvmode' is defined for use with EVRC-B. A decoder can use this 688 attribute to inform an encoder of its preference to operate in a 689 specified mode. The receiver will continue to decode properly even 690 if the sender does not operate in the preferred mode. 692 'mode-set-recv' is defined for use with EVRC-WB. A decoder can use 693 this attribute to inform an encoder of its preference to operate in a 694 specified subset of modes. The receiver will continue to decode 695 properly even if the sender does not operate in one of the preferred 696 modes. A set has been defined so that several modes can be expressed 697 as a preference in one attempt. For instance, the set {4,7} signals 698 that the receiver prefers the sender to operate in narrowband modes 699 of EVRC-WB. 701 11. EVRC-B Interoperability with legacy implementations (RFC 4788) 703 This document adds new optional parameters "recvmode" and "sendmode" 704 to the original EVRC-B Media types "audio/EVRCB" and "audio/EVRCB0" 705 defined in RFC 4788 [3]. Existing RFC 4788 [3] implementations will 706 not send these parameters in SDP and will ignore them if they are 707 received. This will allow interoperability between RFC 4788 [3] and 708 RFC XXXX implementations of EVRC-B. For an example offer and answer 709 exchange, see Section 17. 711 12. Mapping EVRC-WB media type parameters into SDP 713 Information carried in the media type specification has a specific 714 mapping to fields in the Session Description Protocol (SDP) [8], 715 which is commonly used to describe RTP sessions. When SDP is used to 716 specify sessions employing EVRC-WB encoded speech, the mapping is as 717 follows. 719 o The media type ("audio") goes in SDP "m=" as the media name. 721 o The media subtype ("EVRCWB", "EVRCWB0" or "EVRCWB1") goes in SDP 722 "a=rtpmap" as the encoding name. 724 o The optional parameters 'ptime and 'maxptime' (for subtypes 725 EVRCWB, EVRCWB1) go in the SDP "a=ptime" and "a=maxptime" 726 attributes, respectively. 728 o Any remaining parameters (for subtypes EVRCWB, EVRCWB0 and 729 EVRCWB1) go in the SDP "a=fmtp" attribute by copying them from the 730 media type string as a semicolon separated list of parameter=value 731 pairs. 733 13. Mapping EVRC-B media type parameters into SDP 735 The new optional parameters 'recvmode' and 'sendmode' (for 'audio' 736 subtypes EVRCB and EVRCB0) go in the SDP "a=fmtp" attribute by 737 copying them directly from the media type string. 739 For all other Media Type parameteres, the specification in Section 740 6.7 of RFC 4788 [3] still applies. 742 14. Offer-Answer Model Considerations for EVRC-WB 744 The following considerations apply when using the SDP offer-answer 745 procedures of RFC 3264 [7] to negotiate the use of EVRC-WB payload in 746 RTP: 748 o Since EVRC-WB is an extension of EVRC-B, the offerer SHOULD 749 announce EVRC-B support in its "m=audio" line, with EVRC-WB as the 750 preferred codec. This will allow interoperability with an 751 answerer which supports only EVRC-B. 753 Below is an example of such an offer: 755 m=audio 55954 RTP/AVP 98 99 756 a=rtpmap:98 EVRCWB0/16000 757 a=rtpmap:99 EVRCB0/8000 758 a=fmtp:98 mode-set-recv=0,4;sendmode=0 759 a=fmtp:99 recvmode=0 sendmode=4 761 If the answerer supports EVRC-WB then the answerer can keep the 762 payload type 98 in its answer and the conversation can be done 763 using EVRC-WB. Else, if the answerer supports only EVRC-B then 764 the answerer will leave only the payload type 99 in its answer and 765 the conversation will be done using EVRC-B. 767 An example answer for the above offer: 769 m=audio 55954 RTP/AVP 98 770 a=rtpmap:98 EVRCWB0/16000 771 a=fmtp:98 mode-set-recv=4;sendmode=4 773 o 'mode-set-recv' is a uni-directional receive only parameter. 775 o 'sendmode' is a uni-directional send only parameter. 777 o Using 'sendmode', a sender can signal its current mode of 778 operation. Note that a receiver may receive RTP media well before 779 the arrival of SDP with a (first time, or updated) 'sendmode' 780 parameter. 782 o An offerer can use 'mode-set-recv' to request that the remote 783 sender's encoder be limited to the list of modes signaled in 784 'mode-set-recv'. A remote sender MAY ignore 'mode-set-recv' 785 requests. 787 o The parameters 'maxptime' and 'ptime' will in most cases not 788 affect interoperability, however the setting of the parameters can 789 affect the performance of the application. The SDP offer-answer 790 handling of the 'ptime' parameter is described in RFC 3264 [7]. 791 The 'maxptime' parameter MUST be handled in the same way. 793 o For a sendonly stream, the 'mode-set-recv' parameter is not useful 794 and SHOULD NOT be used. 796 o For a recvonly stream, the 'sendmode' parameter is not useful and 797 SHOULD NOT be used. 799 o When using EVRCWB1, the entire session MUST use the same fixed 800 rate and mode (0-Wideband or 4,7-Narrowband). 802 o For additional rules which MUST be followed while negotiating DTX 803 parameters, see Section 6.8 in [3]. 805 o Any unknown parameter in an SDP offer MUST be ignored by the 806 receiver and MUST NOT be included in the SDP answer. 808 15. Offer-Answer Model Considerations for EVRC-B 810 See Section 6.8 of [3] for offer-answer usage of EVRC-B. The 811 following are several additional considerations for EVRC-B. 813 o 'recvmode' is a uni-directional receive only parameter. 815 o 'sendmode' is a uni-directional send only parameter. 817 o Using 'recvmode', a receiver can signal the remote sender to 818 operate its encoder in the specified mode. A remote sender MAY 819 ignore 'recvmode' requests. 821 o Using 'sendmode', a sender can signal its current mode of 822 operation. Note that a receiver may receive RTP media well before 823 the arrival of SDP with a (first time, or updated)'sendmode' 824 parameter. 826 o For a sendonly stream, the 'recvmode' parameter is not useful and 827 SHOULD NOT be used. 829 o For a recvonly stream, the 'sendmode' parameter is not useful and 830 SHOULD NOT be used. 832 16. Declarative SDP Considerations 834 For declarative use of SDP in SAP [12] and RTSP [13] , the following 835 considerations apply: 837 o Any 'maxptime' and 'ptime' values should be selected with care to 838 ensure that the session's participants can achieve reasonable 839 performance. 841 o The payload format configuration parameters are all declarative 842 and a participant MUST use the configuration(s) that is provided 843 for the session. More than one configuration may be provided if 844 necessary by declaring multiple RTP payload types, however the 845 number of types should be kept small. For declarative examples, 846 see Section 17 848 17. Examples 850 Some example SDP session descriptions utilizing EVRC-WB and EVRC-B 851 encodings follow. In these examples, long a=fmtp lines are folded to 852 meet the column width constraints of this document. The backslash 853 ("\") at the end of a line and the carriage return that follows it 854 should be ignored. Note that media subtype names are case- 855 insensitive. Parameter names are case-insensitive both in media 856 types and in the mapping to the SDP a=fmtp attribute. 858 Example usage of EVRCWB: 860 m=audio 49120 RTP/AVP 97 98 861 a=rtpmap:97 EVRCWB/16000 862 a=rtpmap:98 EVRCB0/8000 863 a=fmtp:97 mode-set-recv=0,4;sendmode=0 864 a=fmtp:98 recvmode=0 sendmode=0 865 a=maxptime:120 867 Example usage of EVRCWB0: 869 m=audio 49120 RTP/AVP 97 98 870 a=rtpmap:97 EVRCWB0/16000 871 a=rtpmap:98 EVRCB0/8000 872 a=fmtp:97 mode-set-recv=0,4;sendmode=0 873 a=fmtp:98 recvmode=0 sendmode=0 875 Example SDP answer from a media gateway requesting a terminal to 876 limit its encoder operation to EVRC-WB mode 4. 878 m=audio 49120 RTP/AVP 97 879 a=rtpmap:97 EVRCWB0/16000 880 a=fmtp:97 mode-set-recv=4;sendmode=4 882 Example usage of EVRCWB1: 884 m=audio 49120 RTP/AVP 97 98 885 a=rtpmap:97 EVRCWB1/16000 886 a=fmtp:97 mode-set-recv=4;sendmode=4 887 a=maxptime:100 889 Example usage of EVRCWB with DTX with silencesupp=1: 891 m=audio 49120 RTP/AVP 97 98 892 a=rtpmap:97 EVRCWB/16000 893 a=rtpmap:98 EVRCB0/8000 894 a=fmtp:97 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1 \ 895 mode-set-recv=0,4; sendmode=0 896 a=fmtp:98 recvmode=0 sendmode=0 897 a=maxptime:120 899 Examples usage of EVRCWB with DTX with silencesupp=0: 901 m=audio 49120 RTP/AVP 97 98 902 a=rtpmap:97 EVRCWB/16000 903 a=rtpmap:98 EVRCB0/8000 904 a=fmtp:97 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1 \ 905 mode-set-recv=0,4;sendmode=0 906 a=fmtp:98 recvmode=0 sendmode=0 907 a=maxptime:120 909 Example usage of EVRCB: 911 m=audio 49120 RTP/AVP 97 912 a=rtpmap:97 EVRCB/8000 913 a=fmtp:97 recvmode=0 sendmode=4 914 a=maxptime:120 916 Example usage of EVRCB0: 918 m=audio 49120 RTP/AVP 97 919 a=rtpmap:97 EVRCB0/8000 920 a=fmtp:97 recvmode=0 sendmode=4 922 Example offer answer exchange between EVRC-WB and 923 legacy EVRC-B (RFC 4788): 925 Offer: 927 m=audio 55954 RTP/AVP 98 99 928 a=rtpmap:98 EVRCWB0/16000 929 a=rtpmap:99 EVRCB0/8000 930 a=fmtp:98 mode-set-recv=0,4;sendmode=0 931 a=fmtp:99 recvmode=0 sendmode=0 933 Answer: 935 m=audio 55954 RTP/AVP 99 936 a=rtpmap:99 EVRCB0/8000 938 Example offer answer exchange between EVRC-WB and 939 updated EVRC-B (RFC XXXX): 941 Offer: 943 m=audio 55954 RTP/AVP 98 99 944 a=rtpmap:98 EVRCWB0/16000 945 a=rtpmap:99 EVRCB0/8000 946 a=fmtp:98 mode-set-recv=0,4; sendmode=0 947 a=fmtp:99 recvmode=0 sendmode=0 949 Answer: 951 m=audio 55954 RTP/AVP 99 952 a=rtpmap:99 EVRCB0/8000 953 a=fmtp:99 recvmode=0 sendmode=4 955 In the above example, note that the answerer has chosen 956 to send in mode 4 even though the offerer was willing to 957 receive in mode 0. 'recvmode' is a receiver's preference 958 but the sender can send in a different mode. 960 Example offer answer exchanges for interoperability between 961 legacy (RFC 4788) and updated EVRC-B(RFC XXXX) implementations: 963 Offer from an offer which supports updated EVRC-B (RFC XXXX) 964 implementation: 966 m=audio 55954 RTP/AVP 99 967 a=rtpmap:99 EVRCB0/8000 968 a=fmtp:99 recvmode=0 sendmode=4 970 Answer from an answerer which supports only 971 legacy EVRC-B (RFC 4788) implementation: 973 m=audio 55954 RTP/AVP 99 974 a=rtpmap:99 EVRCB0/8000 976 Offer from an offer which supports only 977 legacy EVRC-B (RFC 4788) implementation: 979 m=audio 55954 RTP/AVP 99 980 a=rtpmap:99 EVRCB0/8000 982 Answer from an answerer which supports updated 983 EVRC-B (RFC XXXX) implementation: 985 m=audio 55954 RTP/AVP 99 986 a=rtpmap:99 EVRCB0/8000 987 a=fmtp:99 recvmode=0 sendmode=4 989 18. Security Considerations 991 Since compression is applied to the payload formats end-to-end, and 992 the encodings do not exhibit significant non-uniformity, 993 implementations of this specification are subject to all the security 994 considerations specified in RFC 3558 [2]. Implementations using the 995 payload defined in this specification are subject to the security 996 considerations discussed in RFC 3558 [2], RFC 3550 [6] and any 997 appropriate profile (for example RFC 3551 [11]). 999 19. Changes to RFC 4788 1001 This document updates RFC 4788 [3] and the updates are summarized 1002 below: 1004 o Added new media type attribute "sendmode" to media sub-types EVRCB 1005 and EVRCB0. This attribute can be used to signal the EVRC-B 1006 encoder's current mode of operation. 1008 o Added new media type attribute "recvmode" to media sub-types EVRCB 1009 and EVRCB0. This attribute can be used to signal the EVRC-B 1010 decoder's preferred operating mode to a remote sender. 1012 20. References 1014 20.1. Normative References 1016 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1017 Levels", BCP 14, RFC 2119, March 1997. 1019 [2] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs 1020 (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, 1021 July 2003. 1023 [3] Xie, Q., "Enhancements to RTP Payload Formats for EVRC Family 1024 Codecs", RFC 4788, January 2007. 1026 [4] "Enhanced Variable Rate Codec, Speech Service Option 3 and 68 1027 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B 1028 v1.0 , May 2006. 1030 [5] "Enhanced Variable Rate Codec, Speech Service Option 3,68 and 1031 70 for Wideband Spread Spectrum Digital Systems", 3GPP2 1032 C.S0014-C v1.0 , October 2006. 1034 [6] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 1035 Applications", STD 64, RFC 3550, March 1997. 1037 [7] Rosenberg, J., "An Offer/Answer Model with Session Description 1038 Protocol (SDP)", RFC 3264, June 2002. 1040 [8] Handley, M., "SDP: Session Description Protocol", RFC 4566, 1041 July 2006. 1043 [9] Casner, S., "Media Type Specifications and Registration 1044 Procedures", RFC 4855, February 2007. 1046 [10] Freed, N., "Media Type Specifications and Registration 1047 Procedures", BCP 13, RFC 4288, December 2005. 1049 20.2. Informative References 1051 [11] Schulzrinne, H., "RTP Profile for Audio and Video Conferences 1052 with Minimal Control", STD 65, RFC 3551, July 2003. 1054 [12] Handley, M., "Session Announcement Protocol", RFC 2974, 1055 October 2000. 1057 [13] Schulzrinne, H., "Real Time Streaming Protocol (RTSP)", 1058 RFC 2326, April 1998. 1060 Authors' Addresses 1062 Harikishan Desineni 1063 Qualcomm 1064 5775 Morehouse Drive 1065 San Diego, CA 92126 1066 USA 1068 Phone: +1 858 845 8996 1069 Email: hd@qualcomm.com 1070 URI: http://www.qualcomm.com 1072 Qiaobing Xie 1073 Motorola 1074 1501 W. Shure Drive, 2-F9 1075 Arlington Heights, IL 60004 1076 USA 1078 Phone: +1-847-632-3028 1079 Email: Qiaobing.Xie@Motorola.com 1080 URI: http://www.motorola.com 1082 Full Copyright Statement 1084 Copyright (C) The IETF Trust (2007). 1086 This document is subject to the rights, licenses and restrictions 1087 contained in BCP 78, and except as set forth therein, the authors 1088 retain all their rights. 1090 This document and the information contained herein are provided on an 1091 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1092 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1093 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1094 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1095 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1096 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1098 Intellectual Property 1100 The IETF takes no position regarding the validity or scope of any 1101 Intellectual Property Rights or other rights that might be claimed to 1102 pertain to the implementation or use of the technology described in 1103 this document or the extent to which any license under such rights 1104 might or might not be available; nor does it represent that it has 1105 made any independent effort to identify any such rights. Information 1106 on the procedures with respect to rights in RFC documents can be 1107 found in BCP 78 and BCP 79. 1109 Copies of IPR disclosures made to the IETF Secretariat and any 1110 assurances of licenses to be made available, or the result of an 1111 attempt made to obtain a general license or permission for the use of 1112 such proprietary rights by implementers or users of this 1113 specification can be obtained from the IETF on-line IPR repository at 1114 http://www.ietf.org/ipr. 1116 The IETF invites any interested party to bring to its attention any 1117 copyrights, patents or patent applications, or other proprietary 1118 rights that may cover technology that may be required to implement 1119 this standard. Please address the information to the IETF at 1120 ietf-ipr@ietf.org. 1122 Acknowledgment 1124 Funding for the RFC Editor function is provided by the IETF 1125 Administrative Support Activity (IASA).