idnits 2.17.1 draft-ietf-avt-rtp-evrc-wb-07.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 1107. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1118. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1125. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1131. 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 the EVRC-WB codec. An encoder can use this to signal its current mode of operation. Possible values are 0,4,7 (see Table 2.5.1.2-1 in 3GPP2 C.S0014-C). 'sendmode' with value 0 signals wideband fixed rate operation (full or half rate, depending on the value of the 'fixedrate' parameter). 'sendmode' with value 4 signals narrowband fixed full rate operation. 'sendmode' with value 7 signals narrowband fixed half rate operation. The 'fixedrate' parameter MUST not be present when the '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 (November 12, 2007) is 6003 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. '10') (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '13') (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: May 15, 2008 November 12, 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-07.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 May 15, 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/EVWB0 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". Magic number has no relationship with media type and 199 packet format. The same magic number can be used irrespective of the 200 media type and packet format used. The storage format defined in 201 this section can be used by all EVRCWB media types (audio/EVRCWB, 202 audio/EVRCWB0 and audio/EVRCWB1) registered by this document. 204 The codec data frames are stored in consecutive order, with a single 205 ToC entry field, extended to one octet, prefixing each codec data 206 frame. The ToC field is extended to one octet by setting the four 207 most significant bits of the octet to zero. For example, a ToC value 208 of 4 (a full-rate frame) is stored as 0x04. See Section 4 for the 209 mapping from frame type to ToC value. 211 Speech frames lost in transmission and non-received frames MUST be 212 stored as erasure frames (ToC value of 5) to maintain synchronization 213 with the original media. 215 9. IANA Considerations 217 This document updates the audio/EVRCB and audio/EVRCB0 media types 218 defined in RFC 4788 [3] and adds new EVRC-WB 'audio' media subtypes. 220 [-- RFC Editor: Please replace all instances of "RFC XXXX" in this 221 document with the RFC number of this document prior to IANA 222 registration and RFC publication, and remove this note.] 224 9.1. Media Type Registrations 226 Following the guidelines in RFC 4855 [9] and RFC 4288 [10], this 227 section registers new 'audio' media subtypes for EVRC-WB and updates 228 the audio/EVRCB and audio/EVRCB0 media type registrations contained 229 in RFC 4788 [3]. 231 9.1.1. Registration of Media Type audio/EVRCWB 233 Type name: audio 235 Subtype names: EVRCWB 237 Required parameters: none 239 Optional parameters: 241 mode-set-recv: A subset of EVRC-WB modes. Possible values are a 242 comma separated list of modes from the set {0,4,7} (see Table 243 2.5.1.2-1 in 3GPP2 C.S0014-C). A decoder can use this attribute to 244 inform an encoder of its preference to operate in a specified subset 245 of modes. Absence of this parameter signals the mode set {0,4,7}. 247 sendmode: A mode of the EVRC-WB codec. An encoder can use this to 248 signal its current mode of operation. Possible values are 0,4,7 (see 249 Table 2.5.1.2-1 in 3GPP2 C.S0014-C). Absence of this parameter 250 signals mode 0. 252 ptime: see RFC 4566. 254 maxptime: see RFC 4566. 256 maxinterleave: Maximum number for interleaving length (field LLL in 257 the Interleaving Octet)[0..7]. The interleaving lengths used in the 258 entire session MUST NOT exceed this maximum value. If not signaled, 259 the maxinterleave length MUST be 5. 261 silencesupp: see Section 6.1 in RFC 4788. 263 dtxmax: see Section 6.1 in RFC 4788. 265 dtxmin: see Section 6.1 in RFC 4788. 267 hangover: see Section 6.1 in RFC 4788. 269 Encoding considerations: 271 This media type is framed binary data (see RFC 4288, Section 4.8) and 272 is defined for transfer of EVRC-WB encoded data via RTP using the 273 Interleaved/Bundled packet format specified in RFC 3558. 275 Security considerations: See Section 18 of RFC XXXX. 277 Interoperability considerations: none 279 Published specification: 281 The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. The transfer 282 method with the Interleaved/Bundled packet format via RTP is 283 specified in RFC 3558 and RFC XXXX. 285 3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services. 287 3GPP2 specifications are publicly accessible at http://www.3gpp2.org 289 Applications that use this media type: 291 It is expected that many VoIP applications (as well as mobile 292 applications) will use this type. 294 Additional information: 296 The following information applies for the storage format only. 298 Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) 300 File extensions: evw, EVW 302 Macintosh file type code: none 304 Object identifier or OID: none 306 EVRC-WB speech frames may also be stored in the file format "3g2" 307 defined in 3GPP2 C.S0050-B, which is identified using the media types 308 "audio/3gpp2" or "video/3gpp2" registered by RFC 4393. 310 Person & email address to contact for further information: 312 Harikishan Desineni 314 Intended usage: COMMON 316 Restrictions on usage: 318 This basic form of this media type depends on RTP framing, and hence 319 is only defined for transfer via RTP (RFC 3550). For storage and/or 320 transfer within other protocols, the storage format according to the 321 Additional Information clause above must be used. 323 Author: 325 Harikishan Desineni 327 Change controller: 329 IETF Audio/Video Transport working group delegated from the IESG. 331 9.1.2. Registration of Media Type audio/EVRCWB0 333 Type name: audio 335 Subtype names: EVRCWB0 337 Required parameters: 339 Optional parameters: 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: 389 The following information applies for the storage format only. 391 Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) 393 File extensions: evw, EVW 395 Macintosh file type code: none 397 Object identifier or OID: none 399 EVRC-WB speech frames may also be stored in the file format "3g2" 400 defined in 3GPP2 C.S0050-B, which is identified using the media types 401 "audio/3gpp2" or "video/3gpp2" registered by RFC 4393. 403 Person & email address to contact for further information: 405 Harikishan Desineni 407 Intended usage: COMMON 408 Restrictions on usage: 410 This basic form of this media type depends on RTP framing, and hence 411 is only defined for transfer via RTP (RFC 3550). For storage and/or 412 transfer within other protocols, the storage format according to the 413 Additional Information clause above must be used. 415 Author: 417 Harikishan Desineni 419 Change controller: 421 IETF Audio/Video Transport working group delegated from the IESG. 423 9.1.3. Registration of Media Type audio/EVRCWB1 425 Type name: audio 427 Subtype names: EVRCWB1 429 Required parameters: 431 Optional parameters: 433 mode-set-recv: A subset of EVRC-WB modes. Possible values are a 434 comma separated list of modes from the set {0,4,7} (see Table 435 2.5.1.2-1 in 3GPP2 C.S0014-C). A decoder can use this attribute to 436 inform an encoder of its preference to operate in a specified subset 437 of modes. A value of 0 signals the support for wideband fixed rate 438 (full or half rate, depending on the value of 'fixedrate' parameter). 439 A value of 4 signals narroband fixed full rate. A value of 7 signals 440 narrowband fixed half rate. Absence of this parameter signals mode 441 0. 443 sendmode: A mode of the EVRC-WB codec. An encoder can use this to 444 signal its current mode of operation. Possible values are 0,4,7 (see 445 Table 2.5.1.2-1 in 3GPP2 C.S0014-C). 'sendmode' with value 0 signals 446 wideband fixed rate operation (full or half rate, depending on the 447 value of the 'fixedrate' parameter). 'sendmode' with value 4 signals 448 narrowband fixed full rate operation. 'sendmode' with value 7 signals 449 narrowband fixed half rate operation. The 'fixedrate' parameter MUST 450 not be present when the 'sendmode' value is 4 or 7. Absence of this 451 parameter signals mode 0. 453 ptime: see RFC 4566. 455 maxptime: see RFC 4566. 457 fixedrate: Indicates the EVRC-WB rate of the session while in single 458 rate operation. Valid values include: 0.5 and 1, where a value of 459 0.5 indicates the 1/2 rate while a value of 1 indicates the full 460 rate. If this parameter is not present, 1/2 rate is assumed. 462 silencesupp: see Section 6.1 in RFC 4788. 464 dtxmax: see Section 6.1 in RFC 4788. 466 dtxmin: see Section 6.1 in RFC 4788. 468 hangover: see Section 6.1 in RFC 4788. 470 Encoding considerations: 472 This media type is framed binary data (see RFC 4288, Section 4.8) and 473 is defined for transfer of EVRC-WB encoded data via RTP using the 474 compact bundle packet format specified in RFC 4788. 476 Security considerations: See Section 18 of RFC XXXX. 478 Interoperability considerations: none 480 Published specification: 482 The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. The transfer 483 method with the compact bundled packet format via RTP is specified in 484 RFC 4788 and RFC XXXX. 486 3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services. 488 3GPP2 specifications are publicly accessible at http://www.3gpp2.org 490 Applications that use this media type: 492 It is expected that many VoIP applications (as well as mobile 493 applications) will use this type. 495 Additional information: 497 The following information applies for the storage format only. 499 Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) 501 File extensions: evw, EVW 503 Macintosh file type code: none 504 Object identifier or OID: none 506 EVRC-WB speech frames may also be stored in the file format "3g2" 507 defined in 3GPP2 C.S0050-B, which is identified using the media types 508 "audio/3gpp2" or "video/3gpp2" registered by RFC 4393. 510 Person & email address to contact for further information: 512 Harikishan Desineni 514 Intended usage: COMMON 516 Restrictions on usage: 518 This basic form of this media type depends on RTP framing, and hence 519 is only defined for transfer via RTP (RFC 3550). For storage and/or 520 transfer within other protocols, the storage format according to the 521 Additional Information clause above must be used. 523 Author: 525 Harikishan Desineni 527 Change controller: 529 IETF Audio/Video Transport working group delegated from the IESG. 531 9.1.4. Updated Registration of Media Type audio/EVRCB 533 Type name: audio 535 Subtype names: EVRCB 537 Required parameters: none 539 Optional parameters: 541 recvmode: A mode of the EVRC-B codec. A decoder can use this 542 attribute to inform an encoder of its preference to operate in a 543 specified mode. Possible values are 0..7 (see the encoder operating 544 point column in Table 2-6 of 3GPP2 C.S0014-B). 546 sendmode: A mode of the EVRC-B codec. An encoder can use this to 547 signal its current mode of operation. Possible values are 0..7 (see 548 encoder operating point column in Table 2-6 of 3GPP2 C.S0014-B). 550 ptime: see RFC 4566. 552 maxptime: see RFC 4566. 554 maxinterleave: Maximum number for interleaving length (field LLL in 555 the Interleaving Octet). The interleaving lengths used in the entire 556 session MUST NOT exceed this maximum value. If not signaled, the 557 maxinterleave length MUST be 5. 559 silencesupp: see Section 6.1 of RFC 4788 for a definition. If this 560 parameter is not present, the default value 1 MUST be assumed. 562 dtxmax: see Section 6.1 of RFC 4788. 564 dtxmin: see Section 6.1 of RFC 4788. 566 hangover: see Section 6.1 of RFC 4788. 568 Encoding considerations: 570 This media type is framed binary data (see RFC 4288, Section 4.8) and 571 is defined for transfer of EVRC-B encoded data via RTP using the 572 Interleaved/Bundled packet format specified in RFC 3558. 574 Security considerations: See Section 9 of RFC 4788. 576 Interoperability considerations: none 578 Published specification: 580 The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. The transfer 581 method with the Interleaved/Bundled packet format via RTP is 582 specified in RFC 3558, RFC 4788 and RFC XXXX. 584 Applications that use this media type: 586 It is expected that many VoIP applications (as well as mobile 587 applications) will use this type. 589 Additional information: The following information applies for the 590 storage format only. 592 Magic number: #!EVRC-B\n (see Section 5 of RFC 4788) 594 File extensions: evb, EVB 596 Macintosh file type code: none 598 Object identifier or OID: none 599 Person & email address to contact for further information: 601 Harikishan Desineni 603 Intended usage: COMMON 605 Restrictions on usage: 607 This basic form of this media type depends on RTP framing, and hence 608 is only defined for transfer via RTP (RFC 3550). For storage and/or 609 transfer within other protocols, the storage format according to the 610 Additional Information clause above must be used. 612 Author: 614 Qiaobing Xie / Harikishan Desineni 616 Change controller: 618 IETF Audio/Video Transport working group delegated from the IESG. 620 9.1.5. Updated Registration of Media Type audio/EVRCB0 622 Type name: audio 624 Subtype names: EVRCB0 626 Required parameters: none 628 Optional parameters: 630 recvmode: A mode of the EVRC-B codec. A decoder can use this 631 attribute to inform an encoder of its preference to operate in a 632 specified mode. Possible values are 0..7 (see the encoder operating 633 point column in Table 2-6 of 3GPP2 C.S0014-B). 635 sendmode: A mode of the EVRC-B codec. An encoder can use this to 636 signal its current mode of operation. Possible values are 0..7 (see 637 the encoder operating point column in Table 2-6 of 3GPP2 C.S0014-B). 639 silencesupp: see Section 6.1 of RFC 4788 for a definition. If this 640 parameter is not present, the default value 1 MUST be assumed. 642 dtxmax: see Section 6.1 of RFC 4788. 644 dtxmin: see Section 6.1 of RFC 4788. 646 hangover: see Section 6.1 of RFC 4788. 648 Encoding considerations: 650 This media type is framed binary data (see RFC 4288, Section 4.8) and 651 is defined for transfer of EVRC-B encoded data via RTP using the 652 Header-Free packet format specified in RFC 3558. 654 Security considerations: See Section 9 of RFC 4788. 656 Interoperability considerations: none 658 Published specification: 660 The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. The transfer 661 method with the Header-Free packet format via RTP is specified in RFC 662 3558, RFC 4788 and RFC XXXX. 664 Applications that use this media type: 666 It is expected that many VoIP applications (as well as mobile 667 applications) will use this type. 669 Additional information: none 671 Person & email address to contact for further information: 673 Harikishan Desineni 675 Intended usage: COMMON 677 Restrictions on usage: 679 This media type depends on RTP framing, and hence is only defined for 680 transfer via RTP (RFC 3550). Transfer within other framing protocols 681 is not defined at this time. 683 Author: 685 Qiaobing Xie / Harikishan Desineni 687 Change controller: 689 IETF Audio/Video Transport working group delegated from the IESG. 691 10. SDP mode attributes for EVRC-WB and EVRC-B 693 'sendmode' can be used by a sender (EVRC-WB or EVRC-B) to announce 694 its encoder's current mode of operation. A sender can change its 695 mode anytime and this does not cause any decoding problems at the 696 receiver. 698 'recvmode' is defined for use with EVRC-B. A decoder can use this 699 attribute to inform an encoder of its preference to operate in a 700 specified mode. The receiver will continue to decode properly even 701 if the sender does not operate in the preferred mode. 703 'mode-set-recv' is defined for use with EVRC-WB. A decoder can use 704 this attribute to inform an encoder of its preference to operate in a 705 specified subset of modes. The receiver will continue to decode 706 properly even if the sender does not operate in one of the preferred 707 modes. A set has been defined so that several modes can be expressed 708 as a preference in one attempt. For instance, the set {4,7} signals 709 that the receiver prefers the sender to operate in narrowband modes 710 of EVRC-WB. 712 11. EVRC-B Interoperability with legacy implementations (RFC 4788) 714 This document adds new optional parameters "recvmode" and "sendmode" 715 to the original EVRC-B Media types "audio/EVRCB" and "audio/EVRCB0" 716 defined in RFC 4788 [3]. Existing RFC 4788 [3] implementations will 717 not send these parameters in SDP and will ignore them if they are 718 received. This will allow interoperability between RFC 4788 [3] and 719 RFC XXXX implementations of EVRC-B. For an example offer and answer 720 exchange, see Section 17. 722 12. Mapping EVRC-WB media type parameters into SDP 724 Information carried in the media type specification has a specific 725 mapping to fields in the Session Description Protocol (SDP) [8], 726 which is commonly used to describe RTP sessions. When SDP is used to 727 specify sessions employing EVRC-WB encoded speech, the mapping is as 728 follows. 730 o The media type ("audio") goes in SDP "m=" as the media name. 732 o The media subtype ("EVRCWB", "EVRCWB0" or "EVRCWB1") goes in SDP 733 "a=rtpmap" as the encoding name. 735 o The optional parameters 'ptime and 'maxptime' (for subtypes 736 EVRCWB, EVRCWB1) go in the SDP "a=ptime" and "a=maxptime" 737 attributes, respectively. 739 o Any remaining parameters (for subtypes EVRCWB, EVRCWB0 and 740 EVRCWB1) go in the SDP "a=fmtp" attribute by copying them from the 741 media type string as a semicolon separated list of parameter=value 742 pairs. 744 13. Mapping EVRC-B media type parameters into SDP 746 The new optional parameters 'recvmode' and 'sendmode' (for 'audio' 747 subtypes EVRCB and EVRCB0) go in the SDP "a=fmtp" attribute by 748 copying them directly from the media type string. 750 For all other Media Type parameteres, the specification in Section 751 6.7 of RFC 4788 [3] still applies. 753 14. Offer-Answer Model Considerations for EVRC-WB 755 The following considerations apply when using the SDP offer-answer 756 procedures of RFC 3264 [7] to negotiate the use of EVRC-WB payload in 757 RTP: 759 o Since EVRC-WB is an extension of EVRC-B, the offerer SHOULD 760 announce EVRC-B support in its "m=audio" line, with EVRC-WB as the 761 preferred codec. This will allow interoperability with an 762 answerer which supports only EVRC-B. 764 Below is an example of such an offer: 766 m=audio 55954 RTP/AVP 98 99 767 a=rtpmap:98 EVRCWB0/16000 768 a=rtpmap:99 EVRCB0/8000 769 a=fmtp:98 mode-set-recv=0,4;sendmode=0 770 a=fmtp:99 recvmode=0 sendmode=4 772 If the answerer supports EVRC-WB then the answerer can keep the 773 payload type 98 in its answer and the conversation can be done 774 using EVRC-WB. Else, if the answerer supports only EVRC-B then 775 the answerer will leave only the payload type 99 in its answer and 776 the conversation will be done using EVRC-B. 778 An example answer for the above offer: 780 m=audio 55954 RTP/AVP 98 781 a=rtpmap:98 EVRCWB0/16000 782 a=fmtp:98 mode-set-recv=4;sendmode=4 784 o 'mode-set-recv' is a uni-directional receive only parameter. 786 o 'sendmode' is a uni-directional send only parameter. 788 o Using 'sendmode', a sender can signal its current mode of 789 operation. Note that a receiver may receive RTP media well before 790 the arrival of SDP with a (first time, or updated) 'sendmode' 791 parameter. 793 o An offerer can use 'mode-set-recv' to request that the remote 794 sender's encoder be limited to the list of modes signaled in 795 'mode-set-recv'. A remote sender MAY ignore 'mode-set-recv' 796 requests. 798 o The parameters 'maxptime' and 'ptime' will in most cases not 799 affect interoperability, however the setting of the parameters can 800 affect the performance of the application. The SDP offer-answer 801 handling of the 'ptime' parameter is described in RFC 3264 [7]. 802 The 'maxptime' parameter MUST be handled in the same way. 804 o For a sendonly stream, the 'mode-set-recv' parameter is not useful 805 and SHOULD NOT be used. 807 o For a recvonly stream, the 'sendmode' parameter is not useful and 808 SHOULD NOT be used. 810 o When using EVRCWB1, the entire session MUST use the same fixed 811 rate and mode (0-Wideband or 4,7-Narrowband). 813 o For additional rules which MUST be followed while negotiating DTX 814 parameters, see Section 6.8 in [3]. 816 o Any unknown parameter in an SDP offer MUST be ignored by the 817 receiver and MUST NOT be included in the SDP answer. 819 15. Offer-Answer Model Considerations for EVRC-B 821 See Section 6.8 of [3] for offer-answer usage of EVRC-B. The 822 following are several additional considerations for EVRC-B. 824 o 'recvmode' is a uni-directional receive only parameter. 826 o 'sendmode' is a uni-directional send only parameter. 828 o Using 'recvmode', a receiver can signal the remote sender to 829 operate its encoder in the specified mode. A remote sender MAY 830 ignore 'recvmode' requests. 832 o Using 'sendmode', a sender can signal its current mode of 833 operation. Note that a receiver may receive RTP media well before 834 the arrival of SDP with a (first time, or updated)'sendmode' 835 parameter. 837 o For a sendonly stream, the 'recvmode' parameter is not useful and 838 SHOULD NOT be used. 840 o For a recvonly stream, the 'sendmode' parameter is not useful and 841 SHOULD NOT be used. 843 16. Declarative SDP Considerations 845 For declarative use of SDP in SAP [12] and RTSP [13] , the following 846 considerations apply: 848 o Any 'maxptime' and 'ptime' values should be selected with care to 849 ensure that the session's participants can achieve reasonable 850 performance. 852 o The payload format configuration parameters are all declarative 853 and a participant MUST use the configuration(s) that is provided 854 for the session. More than one configuration may be provided if 855 necessary by declaring multiple RTP payload types, however the 856 number of types should be kept small. For declarative examples, 857 see Section 17 859 17. Examples 861 Some example SDP session descriptions utilizing EVRC-WB and EVRC-B 862 encodings follow. In these examples, long a=fmtp lines are folded to 863 meet the column width constraints of this document. The backslash 864 ("\") at the end of a line and the carriage return that follows it 865 should be ignored. Note that media subtype names are case- 866 insensitive. Parameter names are case-insensitive both in media 867 types and in the mapping to the SDP a=fmtp attribute. 869 Example usage of EVRCWB: 871 m=audio 49120 RTP/AVP 97 98 872 a=rtpmap:97 EVRCWB/16000 873 a=rtpmap:98 EVRCB0/8000 874 a=fmtp:97 mode-set-recv=0,4;sendmode=0 875 a=fmtp:98 recvmode=0 sendmode=0 876 a=maxptime:120 878 Example usage of EVRCWB0: 880 m=audio 49120 RTP/AVP 97 98 881 a=rtpmap:97 EVRCWB0/16000 882 a=rtpmap:98 EVRCB0/8000 883 a=fmtp:97 mode-set-recv=0,4;sendmode=0 884 a=fmtp:98 recvmode=0 sendmode=0 886 Example SDP answer from a media gateway requesting a terminal to 887 limit its encoder operation to EVRC-WB mode 4. 889 m=audio 49120 RTP/AVP 97 890 a=rtpmap:97 EVRCWB0/16000 891 a=fmtp:97 mode-set-recv=4;sendmode=4 893 Example usage of EVRCWB1: 895 m=audio 49120 RTP/AVP 97 98 896 a=rtpmap:97 EVRCWB1/16000 897 a=fmtp:97 mode-set-recv=4;sendmode=4 898 a=maxptime:100 900 Example usage of EVRCWB with DTX with silencesupp=1: 902 m=audio 49120 RTP/AVP 97 98 903 a=rtpmap:97 EVRCWB/16000 904 a=rtpmap:98 EVRCB0/8000 905 a=fmtp:97 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1 \ 906 mode-set-recv=0,4; sendmode=0 907 a=fmtp:98 recvmode=0 sendmode=0 908 a=maxptime:120 910 Examples usage of EVRCWB with DTX with silencesupp=0: 912 m=audio 49120 RTP/AVP 97 98 913 a=rtpmap:97 EVRCWB/16000 914 a=rtpmap:98 EVRCB0/8000 915 a=fmtp:97 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1 \ 916 mode-set-recv=0,4;sendmode=0 917 a=fmtp:98 recvmode=0 sendmode=0 918 a=maxptime:120 920 Example usage of EVRCB: 922 m=audio 49120 RTP/AVP 97 923 a=rtpmap:97 EVRCB/8000 924 a=fmtp:97 recvmode=0 sendmode=4 925 a=maxptime:120 927 Example usage of EVRCB0: 929 m=audio 49120 RTP/AVP 97 930 a=rtpmap:97 EVRCB0/8000 931 a=fmtp:97 recvmode=0 sendmode=4 933 Example offer answer exchange between EVRC-WB and 934 legacy EVRC-B (RFC 4788): 936 Offer: 938 m=audio 55954 RTP/AVP 98 99 939 a=rtpmap:98 EVRCWB0/16000 940 a=rtpmap:99 EVRCB0/8000 941 a=fmtp:98 mode-set-recv=0,4;sendmode=0 942 a=fmtp:99 recvmode=0 sendmode=0 944 Answer: 946 m=audio 55954 RTP/AVP 99 947 a=rtpmap:99 EVRCB0/8000 949 Example offer answer exchange between EVRC-WB and 950 updated EVRC-B (RFC XXXX): 952 Offer: 954 m=audio 55954 RTP/AVP 98 99 955 a=rtpmap:98 EVRCWB0/16000 956 a=rtpmap:99 EVRCB0/8000 957 a=fmtp:98 mode-set-recv=0,4; sendmode=0 958 a=fmtp:99 recvmode=0 sendmode=0 960 Answer: 962 m=audio 55954 RTP/AVP 99 963 a=rtpmap:99 EVRCB0/8000 964 a=fmtp:99 recvmode=0 sendmode=4 966 In the above example, note that the answerer has chosen 967 to send in mode 4 even though the offerer was willing to 968 receive in mode 0. 'recvmode' is a receiver's preference 969 but the sender can send in a different mode. 971 Example offer answer exchanges for interoperability between 972 legacy (RFC 4788) and updated EVRC-B(RFC XXXX) implementations: 974 Offer from an offer which supports updated EVRC-B (RFC XXXX) 975 implementation: 977 m=audio 55954 RTP/AVP 99 978 a=rtpmap:99 EVRCB0/8000 979 a=fmtp:99 recvmode=0 sendmode=4 981 Answer from an answerer which supports only 982 legacy EVRC-B (RFC 4788) implementation: 984 m=audio 55954 RTP/AVP 99 985 a=rtpmap:99 EVRCB0/8000 987 Offer from an offer which supports only 988 legacy EVRC-B (RFC 4788) implementation: 990 m=audio 55954 RTP/AVP 99 991 a=rtpmap:99 EVRCB0/8000 993 Answer from an answerer which supports updated 994 EVRC-B (RFC XXXX) implementation: 996 m=audio 55954 RTP/AVP 99 997 a=rtpmap:99 EVRCB0/8000 998 a=fmtp:99 recvmode=0 sendmode=4 1000 18. Security Considerations 1002 Since compression is applied to the payload formats end-to-end, and 1003 the encodings do not exhibit significant non-uniformity, 1004 implementations of this specification are subject to all the security 1005 considerations specified in RFC 3558 [2]. Implementations using the 1006 payload defined in this specification are subject to the security 1007 considerations discussed in RFC 3558 [2], RFC 3550 [6] and any 1008 appropriate profile (for example RFC 3551 [11]). 1010 19. Changes to RFC 4788 1012 This document updates RFC 4788 [3] and the updates are summarized 1013 below: 1015 o Added new media type attribute "sendmode" to media sub-types EVRCB 1016 and EVRCB0. This attribute can be used to signal the EVRC-B 1017 encoder's current mode of operation. 1019 o Added new media type attribute "recvmode" to media sub-types EVRCB 1020 and EVRCB0. This attribute can be used to signal the EVRC-B 1021 decoder's preferred operating mode to a remote sender. 1023 20. References 1025 20.1. Normative References 1027 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1028 Levels", BCP 14, RFC 2119, March 1997. 1030 [2] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs 1031 (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, 1032 July 2003. 1034 [3] Xie, Q., "Enhancements to RTP Payload Formats for EVRC Family 1035 Codecs", RFC 4788, January 2007. 1037 [4] "Enhanced Variable Rate Codec, Speech Service Option 3 and 68 1038 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B 1039 v1.0 , May 2006. 1041 [5] "Enhanced Variable Rate Codec, Speech Service Option 3,68 and 1042 70 for Wideband Spread Spectrum Digital Systems", 3GPP2 1043 C.S0014-C v1.0 , October 2006. 1045 [6] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 1046 Applications", STD 64, RFC 3550, March 1997. 1048 [7] Rosenberg, J., "An Offer/Answer Model with Session Description 1049 Protocol (SDP)", RFC 3264, June 2002. 1051 [8] Handley, M., "SDP: Session Description Protocol", RFC 4566, 1052 July 2006. 1054 [9] Casner, S., "Media Type Specifications and Registration 1055 Procedures", RFC 4855, February 2007. 1057 [10] Freed, N., "Media Type Specifications and Registration 1058 Procedures", BCP 13, RFC 4288, December 2005. 1060 20.2. Informative References 1062 [11] Schulzrinne, H., "RTP Profile for Audio and Video Conferences 1063 with Minimal Control", STD 65, RFC 3551, July 2003. 1065 [12] Handley, M., "Session Announcement Protocol", RFC 2974, 1066 October 2000. 1068 [13] Schulzrinne, H., "Real Time Streaming Protocol (RTSP)", 1069 RFC 2326, April 1998. 1071 Authors' Addresses 1073 Harikishan Desineni 1074 Qualcomm 1075 5775 Morehouse Drive 1076 San Diego, CA 92126 1077 USA 1079 Phone: +1 858 845 8996 1080 Email: hd@qualcomm.com 1081 URI: http://www.qualcomm.com 1083 Qiaobing Xie 1084 Motorola 1085 1501 W. Shure Drive, 2-F9 1086 Arlington Heights, IL 60004 1087 USA 1089 Phone: +1-847-632-3028 1090 Email: Qiaobing.Xie@Motorola.com 1091 URI: http://www.motorola.com 1093 Full Copyright Statement 1095 Copyright (C) The IETF Trust (2007). 1097 This document is subject to the rights, licenses and restrictions 1098 contained in BCP 78, and except as set forth therein, the authors 1099 retain all their rights. 1101 This document and the information contained herein are provided on an 1102 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1103 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1104 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1105 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1106 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1107 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1109 Intellectual Property 1111 The IETF takes no position regarding the validity or scope of any 1112 Intellectual Property Rights or other rights that might be claimed to 1113 pertain to the implementation or use of the technology described in 1114 this document or the extent to which any license under such rights 1115 might or might not be available; nor does it represent that it has 1116 made any independent effort to identify any such rights. Information 1117 on the procedures with respect to rights in RFC documents can be 1118 found in BCP 78 and BCP 79. 1120 Copies of IPR disclosures made to the IETF Secretariat and any 1121 assurances of licenses to be made available, or the result of an 1122 attempt made to obtain a general license or permission for the use of 1123 such proprietary rights by implementers or users of this 1124 specification can be obtained from the IETF on-line IPR repository at 1125 http://www.ietf.org/ipr. 1127 The IETF invites any interested party to bring to its attention any 1128 copyrights, patents or patent applications, or other proprietary 1129 rights that may cover technology that may be required to implement 1130 this standard. Please address the information to the IETF at 1131 ietf-ipr@ietf.org. 1133 Acknowledgment 1135 Funding for the RFC Editor function is provided by the IETF 1136 Administrative Support Activity (IASA).