idnits 2.17.1 draft-zfang-avt-rtp-evrc-nw-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 10, 2010) is 5188 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' ** Obsolete normative reference: RFC 4288 (ref. '8') (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4566 (ref. '9') (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '14') (Obsoleted by RFC 7826) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Fang 3 Internet-Draft Qualcomm 4 Intended status: Standards Track February 10, 2010 5 Expires: August 14, 2010 7 RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec 8 (EVRC-NW) 9 draft-zfang-avt-rtp-evrc-nw-02 11 Abstract 13 This document specifies real-time transport protocol (RTP) payload 14 formats to be used for the Enhanced Variable Rate Narrowband-Wideband 15 Codec (EVRC-NW). Three media type registrations are included for 16 EVRC-NW RTP payload formats. In addition, a file format is specified 17 for transport of EVRC-NW speech data in storage mode applications 18 such as e-mail. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 14, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. EVRC-NW codec . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Congestion Control Considerations . . . . . . . . . . . . . . 9 67 8. Storage format for the EVRC-NW Codec . . . . . . . . . . . . . 10 68 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 69 9.1. Media Type Registrations . . . . . . . . . . . . . . . . . 11 70 9.1.1. Registration of Media Type audio/EVRCNW . . . . . . . 11 71 9.1.2. Registration of Media Type audio/EVRCNW0 . . . . . . . 13 72 9.1.3. Registration of Media Type audio/EVRCNW1 . . . . . . . 14 73 10. SDP mode attributes for EVRC-NW . . . . . . . . . . . . . . . 17 74 11. Mapping EVRC-NW media type parameters into SDP . . . . . . . . 18 75 12. Offer-Answer Model Considerations for EVRC-NW . . . . . . . . 19 76 13. Declarative SDP Considerations . . . . . . . . . . . . . . . . 21 77 14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 78 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 79 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 80 16.1. Normative References . . . . . . . . . . . . . . . . . . . 26 81 16.2. Informative References . . . . . . . . . . . . . . . . . . 26 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 84 1. Introduction 86 This document specifies the payload formats for packetization of 87 EVRC-NW 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-NW codec as well as 90 discontinuous transmission (DTX) support for EVRC-NW encoded speech 91 transported via RTP. The EVRC-NW codec offers better speech quality 92 than the EVRC and EVRC-B codecs and better capacity than EVRC-WB 93 codec. EVRC-NW belongs to the EVRC family of codecs. 95 2. Conventions 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [1]. 101 3. Background 103 EVRC-NW is an extension of both the EVRC-B [2] and EVRC-WB [3] speech 104 codecs developed in 3GPP2 with support for discontinuous transmission 105 (DTX). It provides enhanced voice quality and high spectral 106 efficiency. 108 The EVRC-NW 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-NW codec can operate in eight modes (0 to 7) 111 defined in [4]. EVRC-NW modes 0, 1 and 7 are interoperable with 112 EVRC-WB. EVRC-NW modes 1 to 7 are interoperable with EVRC-B. 113 EVRC-NW modes 0 to 6 use full rate, 1/2 rate, 1/4 rate and 1/8 rate 114 frames. EVRC-NW mode 7 uses only 1/2 rate and 1/8 rate frames. Mode 115 change results in codec output bit-rate change but does not cause any 116 decoding problems at the receiver. For successful decoding, the 117 decoder does not need to know the encoder's current mode of 118 operation. EVRC-NW provides a standardized solution for packetized 119 voice applications that allow transitions between enhanced quality 120 and increased capacity. The most important service addressed is IP 121 telephony. Target devices can be IP phones or VoIP handsets, media 122 gateways, voice messaging servers, etc. 124 4. EVRC-NW codec 126 The EVRC-NW codec operates on 20 ms frames. It produces output 127 frames of one of the four different sizes: 171 bits (Rate 1), 80 bits 128 (Rate 1/2), 40 bits (Rate 1/4) or 16 bits (Rate 1/8 or Rate 1/8 Non- 129 Critical). In addition, there are two zero bit codec frame types: 130 blank (null) frames and erasure frames. For IP based traffic, the 131 Rate 1/8 Non-Critical type frame shall be suppressed and denoted as 132 blank (null) frame of 0 bit. The default sampling rate is 16 kHz. 133 Input and output at 8 kHz sampling rate is also supported. 135 The frame type values and sizes of the associated codec data frames 136 are listed in the table below: 138 Value Rate Total codec data frame size in bytes (and in bits) 139 -------------------------------------------------------------------- 140 0 Blank(Null) 0 (0 bit) 141 1 1/8 2 (16 bits) 142 2 1/4 5 (40 bits) 143 3 1/2 10 (80 bits) 144 4 1 22 (171 bits; 5 bits padded at the end) 145 5 Erasure 0 (SHOULD NOT be transmitted by sender) 147 5. RTP header usage 149 The format of the RTP header is specified in RFC 3550 [5]. The 150 EVRC-NW payload formats (Section 6) use the fields of the RTP header 151 in a manner consistent with RFC 3550 [5]. 153 EVRC-NW has also the capability to operate with 8 kHz sampled input/ 154 output signals. The decoder does not require a priori knowledge 155 about the sampling rate of the original signal at the input of the 156 encoder. The decoder output can be at 8kHz or 16kHz regardless of 157 the sampling rate used at the encoder. Therefore, depending on the 158 implementation and the electroacoustic audio capabilities of the 159 devices, the input of the encoder and/or the output of the decoder 160 can be configured at 8 kHz; however, a 16 kHz RTP clock rate MUST 161 always be used. The RTP timestamp is increased by 320 for each 20 162 milliseconds. 164 The RTP header marker bit (M) SHALL be set to 1 if the first frame 165 carried in the packet contains a speech frame which is the first in a 166 talkspurt. For all other packets the marker bit SHALL be set to zero 167 (M=0). 169 6. Payload format 171 Three RTP packet formats are supported for the EVRC-NW codec - the 172 interleaved/bundled packet format, the header-free packet format and 173 the compact bundled packet format. For all these formats, the 174 operational details and capabilities, such as ToC, interleaving, DTX, 175 and bundling, of EVRC-NW are exactly the same as those of EVRC-B and 176 EVRC-WB, as defined in [2] and [3], except that the mode change 177 request field in the ToC MUST be interpreted according to the 178 definition of the RATE_REDUC parameter as defined in EVRC-NW [4]. 179 The media type audio/EVRCNW maps to the interleaved/bundled packet 180 format, audio/EVRCNW0 maps to the header-free packet format and 181 audio/EVRCNW1 maps to the compact bundled packet format. 183 7. Congestion Control Considerations 185 Congestion control for RTP SHALL be used in accordance with RFC 3550 186 [5], and with any applicable RTP profile; e.g., RFC 3551 [6]. 188 Due to the header overhead, the number of frames encapsulated in each 189 RTP packet influences the overall bandwidth of the RTP stream. 190 Packing more frames in each RTP packet can reduce the number of 191 packets sent and hence the header overhead, at the expense of 192 increased delay and reduced error robustness. 194 8. Storage format for the EVRC-NW Codec 196 The storage format is used for storing EVRC-NW encoded speech frames, 197 e.g., as a file or e-mail attachment. 199 The file begins with a magic number to identify the vocoder that is 200 used. The magic number for EVRC-NW corresponds to the ASCII 201 character string "#!EVRCNW\n", i.e., "0x23 0x21 0x45 0x56 0x52 0x43 202 0x4E 0x57 0x0A". 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 introduces a new EVRC-NW 'audio' media subtype. 219 9.1. Media Type Registrations 221 Following the guidelines in RFC 4855 [7] and RFC 4288 [8], this 222 section registers new 'audio' media subtypes for EVRC-NW. 224 9.1.1. Registration of Media Type audio/EVRCNW 226 Type name: audio 228 Subtype names: EVRCNW 230 Required parameters: None 232 Optional parameters: 234 These parameters apply to RTP transfer only. 236 mode-set-recv: A subset of EVRC-NW modes. Possible values are a 237 comma separated list of modes from the set {0,1,2,3,4,5,6,7} (see 238 Table 2.6.1.2-4 in 3GPP2 C.S0014-D). A decoder can use this 239 attribute to inform an encoder of its preference to operate in a 240 specified subset of modes. Absence of this parameter signals the 241 mode set {0,1,2,3,4,5,6,7}. 243 sendmode: A mode of the EVRC-NW codec. An encoder can use this to 244 signal its current mode of operation. Possible values are 245 0,1,2,3,4,5,6,7 (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D). Absence of 246 this parameter signals mode 0. 248 ptime: see RFC 4566 [9]. 250 maxptime: see RFC 4566. 252 maxinterleave: Maximum number for interleaving length (field LLL in 253 the Interleaving Octet)[0..7]. The interleaving lengths used in the 254 entire session MUST NOT exceed this maximum value. If not signaled, 255 the maxinterleave length MUST be 5. 257 silencesupp: see Section 6.1 in RFC 4788. 259 dtxmax: see Section 6.1 in RFC 4788. 261 dtxmin: see Section 6.1 in RFC 4788. 263 hangover: see Section 6.1 in RFC 4788. 265 Encoding considerations: 267 This media type is framed binary data (see RFC 4288, Section 4.8) and 268 is defined for transfer of EVRC-NW encoded data via RTP using the 269 Interleaved/Bundled packet format specified in RFC 3558. 271 Security considerations: See Section 15. 273 Interoperability considerations: None 275 Published specification: 277 The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer 278 method with the Interleaved/Bundled packet format via RTP is 279 specified in RFC 3558. 281 Applications that use this media type: 283 It is expected that many VoIP applications (as well as mobile 284 applications) will use this type. 286 Additional information: 288 The following applies to stored-file transfer methods: 290 Magic number: #!EVRCNW\n (see Section 8) 292 File extensions: enw, ENW 294 Macintosh file type code: None 296 Object identifier or OID: None 298 EVRC-NW speech frames may also be stored in the file format "3g2" 299 defined in 3GPP2 C.S0050-B, which is identified using the media types 300 "audio/3gpp2" or "video/3gpp2" registered by RFC 4393 [10]. 302 Person & email address to contact for further information: 304 Zheng Fang 306 Intended usage: COMMON 308 Restrictions on usage: 310 When this media type is used in the context of transfer over RTP, the 311 RTP payload format specified in Section 4.1 of RFC 3558 SHALL be 312 used. In all other contexts, the file format defined in Section 8 313 SHALL be used. 315 Author: 317 Zheng Fang 319 Change controller: 321 IETF Audio/Video Transport working group delegated from the IESG. 323 9.1.2. Registration of Media Type audio/EVRCNW0 325 Type name: audio 327 Subtype names: EVRCNW0 329 Required parameters: None 331 Optional parameters: 333 These parameters apply to RTP transfer only. 335 mode-set-recv: A subset of EVRC-NW modes. Possible values are a 336 comma separated list of modes from the set {0,1,2,3,4,5,6,7} (see 337 Table 2.6.1.2-4 in 3GPP2 C.S0014-D). A decoder can use this 338 attribute to inform an encoder of its preference to operate in a 339 specified subset of modes. Absence of this parameter signals the 340 mode set {0,1,2,3,4,5,6,7}. 342 sendmode: A mode of the EVRC-NW codec. An encoder can use this to 343 signal its current mode of operation. Possible values are 344 0,1,2,3,4,5,6,7 (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D). Absence of 345 this parameter signals mode 0. 347 ptime: see RFC 4566. 349 silencesupp: see Section 6.1 in RFC 4788. 351 dtxmax: see Section 6.1 in RFC 4788. 353 dtxmin: see Section 6.1 in RFC 4788. 355 hangover: see Section 6.1 in RFC 4788. 357 Encoding considerations: 359 This media type is framed binary data (see RFC 4288, Section 4.8) and 360 is defined for transfer of EVRC-NW encoded data via RTP using the 361 Header-Free packet format specified in RFC 3558. 363 Security considerations: See Section 15. 365 Interoperability considertaions: None 367 Published specification: 369 The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer 370 method with the Header-Free packet format via RTP is specified in RFC 371 3558. 373 Applications that use this media type: 375 It is expected that many VoIP applications (as well as mobile 376 applications) will use this type. 378 Additional information: None 380 Person & email address to contact for further information: 382 Zheng Fang 384 Intended usage: COMMON 386 Restrictions on usage: 388 This media type depends on RTP framing, and hence is only defined for 389 transfer via RTP [5], the RTP payload format specified in Section 4.2 390 of RFC 3558 SHALL be used. This media type SHALL NOT be used for 391 storage or file transfer, instead audio/EVRCNW SHALL be used. 393 Author: 395 Zheng Fang 397 Change controller: 399 IETF Audio/Video Transport working group delegated from the IESG. 401 9.1.3. Registration of Media Type audio/EVRCNW1 403 Type name: audio 405 Subtype names: EVRCNW1 406 Required parameters: None 408 Optional parameters: 410 These parameters apply to RTP transfer only. 412 mode-set-recv: A subset of EVRC-NW modes. Possible values are a 413 comma separated list of modes from the set {0,1} (see Table 2.6.1.2-4 414 in 3GPP2 C.S0014-D). A decoder can use this attribute to inform an 415 encoder of its preference to operate in a specified subset of modes. 416 A value of 0 signals the support for wideband fixed rate (full or 417 half rate, depending on the value of 'fixedrate' parameter). A value 418 of 1 signals narroband fixed rate (full or half rate, depending on 419 the value of 'fixedrate' parameter). Absence of this parameter 420 signals the mode set {0,1}. 422 sendmode: A mode of the EVRC-NW codec. An encoder can use this to 423 signal its current mode of operation. Possible values are 0,1 (see 424 Table 2.6.1.2-4 in 3GPP2 C.S0014-D). 'sendmode' with value 0 signals 425 wideband fixed rate operation (full or half rate, depending on the 426 value of the 'fixedrate' parameter). 'sendmode' with value 1 signals 427 narrowband fixed rate operation (full or half rate, depending on the 428 value of the 'fixedrate' parameter). Absence of this parameter 429 signals mode 0. 431 ptime: see RFC 4566. 433 maxptime: see RFC 4566. 435 fixedrate: Indicates the EVRC-NW rate of the session while in single 436 rate operation. Valid values include: 0.5 and 1, where a value of 437 0.5 indicates the 1/2 rate while a value of 1 indicates the full 438 rate. If this parameter is not present, 1/2 rate is assumed. 440 silencesupp: see Section 6.1 in RFC 4788. 442 dtxmax: see Section 6.1 in RFC 4788. 444 dtxmin: see Section 6.1 in RFC 4788. 446 hangover: see Section 6.1 in RFC 4788. 448 Encoding considerations: 450 This media type is framed binary data (see RFC 4288, Section 4.8) and 451 is defined for transfer of EVRC-NW encoded data via RTP using the 452 Compact Bundled packet format specified in RFC 4788. 454 Security considerations: See Section 15 456 Interoperability considertaions: None 458 Published specification: 460 The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer 461 method with the Compact Bundled packet format via RTP is specified in 462 RFC 4788. 464 Applications that use this media type: 466 It is expected that many VoIP applications (as well as mobile 467 applications) will use this type. 469 Additional information: None 471 Person & email address to contact for further information: 473 Zheng Fang 475 Intended usage: COMMON 477 Restrictions on usage: 479 This media type depends on RTP framing, and hence is only defined for 480 transfer via RTP [5], the RTP payload format specified in Section 4 481 of RFC 4788 SHALL be used. This media type SHALL NOT be used for 482 storage or file transfer, instead audio/EVRCNW SHALL be used. 484 Author: 486 Zheng Fang 488 Change controller: 490 IETF Audio/Video Transport working group delegated from the IESG. 492 10. SDP mode attributes for EVRC-NW 494 'sendmode' can be used by a sender to announce its encoder's current 495 mode of operation. A sender can change its mode anytime and this 496 does not cause any decoding problems at the receiver. 498 'mode-set-recv' can be used by a decoder to inform an encoder of its 499 preference to operate in a specified subset of modes. The receiver 500 will continue to decode properly even if the sender does not operate 501 in one of the preferred modes. A set has been defined so that 502 several modes can be expressed as a preference in one attempt. For 503 instance, the set {4,5,6,7} signals that the receiver prefers the 504 sender to operate in bandwidth-efficient narrowband modes of EVRC-NW. 506 11. Mapping EVRC-NW media type parameters into SDP 508 Information carried in the media type specification has a specific 509 mapping to fields in the Session Description Protocol (SDP) [9], 510 which is commonly used to describe RTP sessions. When SDP is used to 511 specify sessions employing EVRC-NW encoded speech, the mapping is as 512 follows. 514 o The media type ("audio") goes in SDP "m=" as the media name. 516 o The media subtype ("EVRCNW", "EVRCNW0" or "EVRCNW1") goes in SDP 517 "a=rtpmap" as the encoding name. 519 o The optional parameters 'ptime and 'maxptime' (for subtypes 520 EVRCNW, EVRCNW1) go in the SDP "a=ptime" and "a=maxptime" 521 attributes, respectively. 523 o Any remaining parameters (for subtypes EVRCNW, EVRCNW0 and 524 EVRCNW1) go in the SDP "a=fmtp" attribute by copying them from the 525 media type string as a semicolon separated list of parameter=value 526 pairs. 528 12. Offer-Answer Model Considerations for EVRC-NW 530 The following considerations apply when using the SDP offer-answer 531 procedures of RFC 3264 [11] to negotiate the use of EVRC-NW payload 532 in RTP: 534 o Since EVRC-NW is an extension of both EVRC-B and EVRC-WB, the 535 offerer SHOULD also announce EVRC-B and EVRC-WB support in its 536 "m=audio" lines, with EVRC-NW as the preferred codec. This will 537 allow interoperability with an answerer which supports only EVRC-B 538 and/or EVRC-WB. 540 Below is an example of such an offer: 542 m=audio 55954 RTP/AVP 98 99 100 543 a=rtpmap:98 EVRCNW0/16000 544 a=rtpmap:99 EVRCWB0/16000 545 a=rtpmap:100 EVRCB0/8000 546 a=fmtp:98 mode-set-recv=0,1,2,3,4,5,6;sendmode=0 547 a=fmtp:99 mode-set-recv=0,4;sendmode=0 548 a=fmtp:100 recvmode=0 sendmode=4 550 If the answerer supports EVRC-NW then the answerer can keep the 551 payload type 98 in its answer and the conversation can be done using 552 EVRC-NW. Else, if the answerer supports only EVRC-WB and/or EVRC-B 553 then the answerer will leave only the payload type 99 and/or 100 554 respectively in its answer and the conversation will be done using 555 EVRC-WB and/or EVRC-B respectively. 557 An example answer for the above offer: 559 m=audio 55954 RTP/AVP 98 560 a=rtpmap:98 EVRCNW0/16000 561 a=fmtp:98 mode-set-recv=4;sendmode=4 563 o 'mode-set-recv' is a uni-directional receive only parameter. 565 o 'sendmode' is a uni-directional send only parameter. 567 o Using 'sendmode', a sender can signal its current mode of 568 operation. Note that a receiver may receive RTP media well before 569 the arrival of SDP with a (first time, or updated) 'sendmode' 570 parameter. 572 o An offerer can use 'mode-set-recv' to request that the remote 573 sender's encoder be limited to the list of modes signaled in 574 'mode-set-recv'. A remote sender MAY ignore 'mode-set-recv' 575 requests. 577 o The parameters 'maxptime' and 'ptime' will in most cases not 578 affect interoperability, however the setting of the parameters can 579 affect the performance of the application. The SDP offer-answer 580 handling of the 'ptime' parameter is described in RFC 3264 [11]. 581 The 'maxptime' parameter MUST be handled in the same way. 583 o For a sendonly stream, the 'mode-set-recv' parameter is not useful 584 and SHOULD NOT be used. 586 o For a recvonly stream, the 'sendmode' parameter is not useful and 587 SHOULD NOT be used. 589 o When using EVRCNW1, the entire session MUST use the same fixed 590 rate and mode (0-Wideband or 1-Narrowband). 592 o For additional rules which MUST be followed while negotiating DTX 593 parameters, see Section 6.8 in RFC 4788 [2]. 595 o Any unknown parameter in an SDP offer MUST be ignored by the 596 receiver and MUST NOT be included in the SDP answer. 598 13. Declarative SDP Considerations 600 For declarative use of SDP in SAP [13] and RTSP [14], the following 601 considerations apply: 603 o Any 'maxptime' and 'ptime' values should be selected with care to 604 ensure that the session's participants can achieve reasonable 605 performance. 607 o The payload format configuration parameters are all declarative 608 and a participant MUST use the configuration(s) that is provided 609 for the session. More than one configuration may be provided if 610 necessary by declaring multiple RTP payload types, however the 611 number of types should be kept small. For declarative examples, 612 see Section 14. 614 14. Examples 616 Some example SDP session descriptions utilizing EVRC-NW encodings 617 follow. In these examples, long a=fmtp lines are folded to meet the 618 column width constraints of this document. The backslash ("\") at 619 the end of a line and the carriage return that follows it should be 620 ignored. Note that media subtype names are case-insensitive. 621 Parameter names are case-insensitive both in media types and in the 622 mapping to the SDP a=fmtp attribute. 624 Example usage of EVRCNW: 626 m=audio 49120 RTP/AVP 97 98 99 627 a=rtpmap:97 EVRCNW/16000 628 a=rtpmap:98 EVRCWB/16000 629 a=rtpmap:99 EVRCB/8000 630 a=fmtp:97 mode-set-recv=0,1,2,3,4,5,6;sendmode=0 631 a=fmtp:98 mode-set-recv=0,4;sendmode=0 632 a=fmtp:99 recvmode=0;sendmode=0 633 a=maxptime:120 635 Example usage of EVRCNW0: 637 m=audio 49120 RTP/AVP 97 98 99 638 a=rtpmap:97 EVRCNW0/16000 639 a=rtpmap:98 EVRCWB0/16000 640 a=rtpmap:99 EVRCB0/8000 641 a=fmtp:97 mode-set-recv=0,1,2,3,4,5,6;sendmode=0 642 a=fmtp:98 mode-set-recv=0,4;sendmode=0 643 a=fmtp:99 recvmode=0;sendmode=0 645 Example SDP answer from a media gateway requesting a terminal to 646 limit its encoder operation to EVRC-NW mode 4. 648 m=audio 49120 RTP/AVP 97 649 a=rtpmap:97 EVRCNW0/16000 650 a=fmtp:97 mode-set-recv=4;sendmode=4 652 Example usage of EVRCNW1: 654 m=audio 49120 RTP/AVP 97 98 99 655 a=rtpmap:97 EVRCNW1/16000 656 a=rtpmap:98 EVRCWB1/16000 657 a=rtpmap:99 EVRCB1/8000 658 a=fmtp:97 fixedrate=0.5 659 a=fmtp:98 fixedrate=0.5 660 a=fmtp:99 fixedrate=0.5 661 a=maxptime:100 663 Example usage of EVRCNW with DTX with silencesupp=1: 665 m=audio 49120 RTP/AVP 97 98 99 666 a=rtpmap:97 EVRCNW/16000 667 a=rtpmap:98 EVRCWB/16000 668 a=rtpmap:99 EVRCB/8000 669 a=fmtp:97 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1 \ 670 mode-set-recv=0,1,2,3,4,5,6;sendmode=0 671 a=fmtp:98 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1 \ 672 mode-set-recv=0,4;sendmode=0 673 a=fmtp:99 recvmode=0;sendmode=0 674 a=maxptime:120 676 Examples usage of EVRCNW with DTX with silencesupp=0: 678 m=audio 49120 RTP/AVP 97 98 99 679 a=rtpmap:97 EVRCNW/16000 680 a=rtpmap:98 EVRCWB/16000 681 a=rtpmap:99 EVRCB/8000 682 a=fmtp:97 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1 \ 683 mode-set-recv=0,1,2,3,4,5,6;sendmode=0 684 a=fmtp:98 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1 \ 685 mode-set-recv=0,4;sendmode=0 686 a=fmtp:99 recvmode=0;sendmode=0 687 a=maxptime:120 689 Example offer answer exchange between EVRC-NW and legacy EVRC-B (RFC 690 4788): 692 Offer: 694 m=audio 55954 RTP/AVP 97 98 99 695 a=rtpmap:97 EVRCNW0/16000 696 a=rtpmap:98 EVRCWB0/16000 697 a=rtpmap:99 EVRCB0/8000 698 a=rtpmap:97 mode-set-recv=0,1,2,3,4,5,6;sendmode=0 699 a=fmtp:98 mode-set-recv=0,4;sendmode=0 700 a=fmtp:99 recvmode=0;sendmode=0 702 Answer: 704 m=audio 55954 RTP/AVP 99 705 a=rtpmap:99 EVRCB0/8000 707 Example offer answer exchange between EVRC-NW and legacy EVRC-WB (RFC 708 5188): 710 Offer: 712 m=audio 55954 RTP/AVP 97 98 99 713 a=rtpmap:97 EVRCNW0/16000 714 a=rtpmap:98 EVRCWB0/16000 715 a=rtpmap:99 EVRCB0/8000 716 a=rtpmap:97 mode-set-recv=0,1,2,3,4,5,6;sendmode=0 717 a=fmtp:98 mode-set-recv=0,4;sendmode=0 718 a=fmtp:99 recvmode=0;sendmode=0 720 Answer: 722 m=audio 55954 RTP/AVP 98 99 723 a=rtpmap:98 EVRCWB0/16000 725 15. Security Considerations 727 Since compression is applied to the payload formats end-to-end, and 728 the encodings do not exhibit significant non-uniformity, 729 implementations of this specification are subject to all the security 730 considerations specified in RFC 3558 [12]. Implementations using the 731 payload defined in this specification are subject to the security 732 considerations discussed in RFC 3558 [12], RFC 3550 [5] and any 733 appropriate profile (for example RFC 3551 [6]). 735 16. References 737 16.1. Normative References 739 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 740 Levels", BCP 14, RFC 2119, March 1997. 742 [2] Xie, Q. and R. Kapoor, "Enhancements to RTP Payload Formats for 743 EVRC Family Codecs", RFC 4788, January 2007. 745 [3] Desineni, H. and Q. Xie, "RTP Payload Format for the Enhanced 746 Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype 747 Updates for EVRC-B Codec", RFC 5188, February 2008. 749 [4] "Enhanced Variable Rate Codec, Speech Service Options 3, 68, 750 70, and 73 for Wideband Spread Spectrum Digital Systems", 751 3GPP2 C.S0014-D v1.0, May 2009. 753 [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 754 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 755 RFC 3550, July 2003. 757 [6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 758 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 760 [7] Casner, S., "Media Type Registration of RTP Payload Formats", 761 RFC 4855, February 2007. 763 [8] Freed, N. and J. Klensin, "Media Type Specifications and 764 Registration Procedures", BCP 13, RFC 4288, December 2005. 766 [9] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 767 Description Protocol", RFC 4566, July 2006. 769 [10] Garudadri, H., "MIME Type Registrations for 3GPP2 Multimedia 770 Files", RFC 4393, March 2006. 772 [11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 773 Session Description Protocol (SDP)", RFC 3264, June 2002. 775 [12] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs 776 (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, 777 July 2003. 779 16.2. Informative References 781 [13] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 782 Protocol", RFC 2974, October 2000. 784 [14] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 785 Protocol (RTSP)", RFC 2326, April 1998. 787 Author's Address 789 Zheng Fang 790 Qualcomm 791 5775 Morehouse Drive 792 San Diego, CA 92126 793 USA 795 Phone: +1 858 651 9484 796 Email: zfang@qualcomm.com 797 URI: http://www.qualcomm.com