idnits 2.17.1 draft-ietf-rtcweb-audio-codecs-for-interop-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-rtcweb-audio]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 29, 2014) is 3496 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Codec X' is mentioned on line 319, but not defined == Unused Reference: 'I-D.ietf-rtcweb-use-cases-and-requirements' is defined on line 360, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-rtcweb-audio-06 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-11 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-14 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Proust 3 Internet-Draft Orange 4 Intended status: Informational E. Berger 5 Expires: April 2, 2015 Cisco 6 B. Feiten 7 Deutsche Telekom 8 B. Burman 9 Ericsson 10 K. Bogineni 11 Verizon Wireless 12 M. Lei 13 Huawei 14 E. Marocco 15 Telecom Italia 16 September 29, 2014 18 Additional WebRTC audio codecs for interoperability with legacy 19 networks. 20 draft-ietf-rtcweb-audio-codecs-for-interop-00 22 Abstract 24 To ensure a baseline level of interoperability between WebRTC 25 clients, [I-D.ietf-rtcweb-audio] requires a minimum set of codecs. 26 However, to maximize the possibility to establish the session without 27 the need for audio transcoding, it is also recommended to include in 28 the offer other suitable audio codecs that are available to the 29 browser. 31 This document provides some guidelines on the suitable codecs to be 32 considered for WebRTC clients to address the most relevant 33 interoperability use cases. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 2, 2015. 51 Copyright Notice 53 Copyright (c) 2014 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 4. Rationale for additional WebRTC codecs . . . . . . . . . . . 3 72 5. Additional suitable codecs for WebRTC . . . . . . . . . . . . 5 73 5.1. AMR-WB . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 5.1.1. AMR-WB General description . . . . . . . . . . . . . 5 75 5.1.2. WebRTC relevant use case for AMR-WB . . . . . . . . . 5 76 5.1.3. Guidelines for AMR-WB usage and implementation with 77 WebRTC . . . . . . . . . . . . . . . . . . . . . . . 5 78 5.2. AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 5.2.1. AMR General description . . . . . . . . . . . . . . . 6 80 5.2.2. WebRTC relevant use case for AMR . . . . . . . . . . 6 81 5.2.3. Guidelines for AMR usage and implementation with 82 WebRTC . . . . . . . . . . . . . . . . . . . . . . . 6 83 5.3. G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 5.3.1. G.722 General description . . . . . . . . . . . . . . 6 85 5.3.2. WebRTC relevant use case for G.722 . . . . . . . . . 7 86 5.3.3. Guidelines for G.722 usage and implementation . . . . 7 87 5.4. [Codec x] (tbd) . . . . . . . . . . . . . . . . . . . . . 7 88 5.4.1. [Codec X] General description . . . . . . . . . . . . 7 89 5.4.2. WebRTC relevant use case for [Codec X] . . . . . . . 7 90 5.4.3. Guidelines for [Codec X] usage and implementation 91 with WebRTC . . . . . . . . . . . . . . . . . . . . . 7 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 96 9.1. Normative references . . . . . . . . . . . . . . . . . . 8 97 9.2. Informative references . . . . . . . . . . . . . . . . . 8 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 100 1. Introduction 102 As indicated in [I-D.ietf-rtcweb-overview], it has been anticipated 103 that WebRTC will not remain an isolated island and that some WebRTC 104 endpoints will need to communicate with devices used in other 105 existing networks with the help of a gateway. Therefore, in order to 106 maximize the possibility to establish the session without the need 107 for audio transcoding, it is recommended in [I-D.ietf-rtcweb-audio] 108 to include in the offer other suitable audio codecs that are 109 available to the browser. This document provides some guidelines on 110 the suitable codecs to be considered for WebRTC clients to address 111 the most relevant interoperability use cases. 113 The codecs considered in this document are recommended to be 114 supported and included in the Offer only for WebRTC clients for which 115 interoperability with other non WebRTC end points and non WebRTC 116 based services is relevant as described in sections 5.1.2, 5.2.2 and 117 5.3.2. Other use cases may justify offering other additional codecs 118 to avoid transcodings. It is the intent of this document to 119 inventory and document any other additional interoperability use 120 cases and codecs if needed. 122 2. Terminology 124 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 125 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 126 and "OPTIONAL" are to be interpreted as described in RFC 2119 127 [RFC2119]. 129 3. Definitions 131 Legacy networks: In this draft, legacy networks encompass the 132 conversational networks that are already deployed like the PSTN, the 133 PLMN, the IMS, H.323 networks. 135 4. Rationale for additional WebRTC codecs 137 The mandatory implementation of OPUS [RFC6716] in WebRTC clients can 138 guarantee the codec interoperability (without transcoding) at the 139 state of the art voice quality (better than narrow band "PSTN" 140 quality) only between WebRTC clients. The WebRTC technology is 141 however expected to have more extended usage to communicate with 142 other types of clients. It can be used for instance as an access 143 technology to 3GPP IMS services or to interoperate with fixed or 144 mobile VoIP legacy HD voice service. Consequently, a significant 145 number of calls are likely to occur between terminals supporting 146 WebRTC clients and other terminals like mobile handsets, fixed VoIP 147 terminals, DECT terminals that do not support WebRTC clients nor 148 implement OPUS. As a consequence, these calls are likely to be 149 either of low narrow band PSTN quality using G.711 at both ends or 150 affected by transcoding operations. The drawbacks of such 151 transcoding operations are recalled below: 153 o Degraded user experience with respect to voice quality: voice 154 quality is significantly degraded by transcoding. For instance, 155 the degradation is around 0.2 to 0.3 MOS for most of transcoding 156 use cases with AMR-WB at 12.65 kbit/s and in the same range for 157 other wideband transcoding cases. It should be stressed that if 158 G.711 is used as a fall back codec for interoperation, wideband 159 voice quality will be lost. Such bandwidth reduction effect down 160 to narrow band clearly degrades the user perceived quality of 161 service leading to shorter and less frequent calls. Such a switch 162 to G.711 is less than desirable or acceptable choice for 163 customers. If transcoding is performed between OPUS and any other 164 wideband codec, wideband communication could be maintained but 165 with degraded quality (MOS scores of transcoding between AMR-WB 166 12.65kbit/s and OPUS at 16 kbit/s in both directions are 167 significantly lower than those of AMR-WB at 12.65kbit/s or OPUS at 168 16 kbit/s). Furthermore, in degraded conditions, the addition of 169 defects, like audio artifacts due to packet losses, and the audio 170 effects resulting from the cascading of different packet loss 171 recovery algorithms may result in a quality below the acceptable 172 limit for the customers. 174 o Degraded user experience with respect to conversational 175 interactivity: the degradation of conversational interactivity is 176 due to the increase of end to end latency for both directions that 177 is introduced by the transcoding operations. Transcoding requires 178 full de-packetization for decoding of the media stream (including 179 mechanisms of de-jitter buffering and packet loss recovery) then 180 re-encoding, re-packetization and re-sending. The delays produced 181 by all these operations are additive and may increase the end to 182 end delay beyond acceptable limits like with more than 1s end to 183 end latency. 185 o Additional costs in networks: transcoding places important 186 additional costs on network gateways mainly related to codec 187 implementation, codecs license, deployments, testing and 188 validation costs. It must be noted that transcoding of wideband 189 to wideband would require more CPU and be more costly than between 190 narrowband codecs. 192 5. Additional suitable codecs for WebRTC 194 The following codecs are considered as relevant suitable codecs with 195 respect to the general purpose described in section 4. This list 196 reflects the current status of WebRTC foreseen use cases. It is not 197 limitative and opened to further inclusion of other codecs for which 198 relevant use cases can be identified. 200 5.1. AMR-WB 202 5.1.1. AMR-WB General description 204 The Adaptive Multi-Rate WideBand (AMR-WB) is a 3GPP defined speech 205 codec that is mandatory to implement in any 3GPP terminal that 206 supports wideband speech communication. It is being used in circuit 207 switched mobile telephony services and new multimedia telephony 208 services over IP/IMS and 4G/VoLTE, specified by GSMA as voice IMS 209 profile for VoLTE in [IR.92]. More detailed information on AMR-WB 210 can be found in [IR.36]. [IR.36] includes references for all 3GPP 211 AMR-WB related specifications including detailed codec description 212 and Source code. 214 5.1.2. WebRTC relevant use case for AMR-WB 216 The market of voice personal communication is driven by mobile 217 terminals. AMR-WB is now implemented in more than 200 devices models 218 and 85 HD mobile networks in 60 countries with a customer base of 219 more than 100 million. A high number of calls are consequently 220 likely to occur between WebRTC clients and mobile 3GPP terminals. 221 The use of AMR-WB by WebRTC clients would consequently allow 222 transcoding free interoperation with all mobile 3GPP wideband 223 terminal. Besides, WebRTC clients running on mobile terminals 224 (smartphones) may reuse the AMR-WB codec already implemented on these 225 devices. 227 5.1.3. Guidelines for AMR-WB usage and implementation with WebRTC 229 Guidelines for implementing and using AMR-WB and ensuring 230 interoperability with 3GPP mobile services can be found in 231 [TS26.114]. In order to ensure interoperability with 4G/VoLTE as 232 specified by GSMA, the more specific IMS profile for voice derived 233 from [TS26.114] should be considered in [IR.92]. 235 5.2. AMR 237 5.2.1. AMR General description 239 Adaptive Multi-Rate (AMR) is a 3GPP defined speech codec that is 240 mandatory to implement in any 3GPP terminal that supports voice 241 communication, i.e. several hundred millions of terminals. This 242 include both mobile phone calls using GSM and 3G cellular systems as 243 well as multimedia telephony services over IP/IMS and 4G/VoLTE, such 244 as GSMA voice IMS profile for VoLTE in [IR.92]. In addition to 245 impacts listed above, support of AMR can avoid degrading the high 246 efficiency over mobile radio access. 248 5.2.2. WebRTC relevant use case for AMR 250 A user of a WebRTC endpoint on a device integrating an AMR module 251 wants to communicate with another user that can only be reached on a 252 mobile device that only supports AMR. Although more and more 253 terminal devices are now "HD voice" and support AMR-WB; there is 254 still a high number of legacy terminals supporting only AMR 255 (terminals with no wideband / HD Voice capabilities) are still used. 256 The use of AMR by WebRTC client would consequently allow transcoding 257 free interoperation with all mobile 3GPP terminals. Besides, WebRTC 258 client running on mobile terminals (smartphones) may reuse the AMR 259 codec already implemented on these devices. 261 5.2.3. Guidelines for AMR usage and implementation with WebRTC 263 Guidelines for implementing and using AMR with purpose to ensure 264 interoperability with 3GPP mobile services can be found in 265 [TS26.114]. In order to ensure interoperability with 4G/VoLTE as 266 specified by GSMA, the more specific IMS profile for voice derived 267 from [TS26.114] should be considered in [IR.92]. 269 5.3. G.722 271 5.3.1. G.722 General description 273 G.722 is an ITU-T defined wideband speech codec. [G.722] was 274 approved by ITU-T in 1988. It is a royalty free codec that is common 275 in a wide range of terminals and end-points supporting wideband 276 speech and requiring low complexity. The complexity of G.722 is 277 estimated to 10 MIPS [EN300175-8] which is 2.5 to 3 times lower than 278 AMR-WB. Especially, G.722 has been chosen by ETSI DECT as the 279 mandatory wideband codec for New Generation DECT with purpose to 280 greatly increase the voice quality by extending the bandwidth from 281 narrow band to wideband. G.722 is the wideband codec required for 282 CAT-iq DECT certified terminal and the V2.0 of CAT-iq specifications 283 have been approved by GSMA as minimum requirements for HD voice logo 284 usage on "fixed" devices; i.e., broadband connections using the G.722 285 codec. 287 5.3.2. WebRTC relevant use case for G.722 289 G.722 is the wideband codec required for DECT CAT-iq terminals. The 290 market for DECT cordeless phones including DECT chipset is more than 291 150 Millions per year and CAT-IQ is a registered trade make in 47 292 countries worldwide. G.722 has also been specified by ETSI in 293 [TS181005] as mandatory wideband codec for IMS multimedia telephony 294 communication service and supplementary services using fixed 295 broadband access. The support of G.722 would consequently allow 296 transcoding free IP interoperation between WebRTC client and fixed 297 VoIP terminals including DECT / CAT-IQ terminals supporting G.722. 298 Besides, WebRTC client running on fixed terminals implementing G.722 299 may reuse the G.722 codec already implemented on these devices. 301 5.3.3. Guidelines for G.722 usage and implementation 303 Guidelines for implementing and using G.722 with purpose to ensure 304 interoperability with Multimedia Telephony services overs IMS can be 305 found in section 7 of [TS26.114]. Additional information of G.722 306 implementation in DECT can be found in [EN300175-8] and full codec 307 description and C source code in [G.722]. 309 5.4. [Codec x] (tbd) 311 5.4.1. [Codec X] General description 313 tbd 315 5.4.2. WebRTC relevant use case for [Codec X] 317 tbd 319 5.4.3. Guidelines for [Codec X] usage and implementation with WebRTC 321 tbd 323 6. Security Considerations 325 7. IANA Considerations 327 None. 329 8. Acknowledgements 331 Thanks to Milan Patel for his review. 333 9. References 335 9.1. Normative references 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 9.2. Informative references 342 [EN300175-8] 343 ETSI, "ETSI EN 300 175-8, v2.5.1: "Digital Enhanced 344 Cordless Telecommunications (DECT); Common Interface (CI); 345 Part 8: Speech and audio coding and transmission".", 2009. 347 [G.722] ITU, "Recommendation ITU-T G.722 (2012): "7 kHz audio- 348 coding within 64 kbit/s".", 2012. 350 [I-D.ietf-rtcweb-audio] 351 Valin, J. and C. Bran, "WebRTC Audio Codec and Processing 352 Requirements", draft-ietf-rtcweb-audio-06 (work in 353 progress), September 2014. 355 [I-D.ietf-rtcweb-overview] 356 Alvestrand, H., "Overview: Real Time Protocols for 357 Browser-based Applications", draft-ietf-rtcweb-overview-11 358 (work in progress), August 2014. 360 [I-D.ietf-rtcweb-use-cases-and-requirements] 361 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 362 Time Communication Use-cases and Requirements", draft- 363 ietf-rtcweb-use-cases-and-requirements-14 (work in 364 progress), February 2014. 366 [IR.36] GSMA, "Adaptive Multirate Wide Band", 2013. 368 [IR.92] GSMA, "IMS Profile for Voice and SMS", 2013. 370 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the 371 Opus Audio Codec", RFC 6716, September 2012. 373 [TS181005] 374 ETSI, "Telecommunications and Internet converged Services 375 and Protocols for Advanced Networking (TISPAN); Service 376 and Capability Requirements V3.3.1 (2009-12)", 2009. 378 [TS26.114] 379 3GPP, "IP Multimedia Subsystem (IMS); Multimedia 380 telephony; Media handling and interaction", 2011. 382 Authors' Addresses 384 Stephane Proust 385 Orange 386 2, avenue Pierre Marzin 387 Lannion 22307 388 France 390 Email: stephane.proust@orange.com 392 Espen Berger 393 Cisco 395 Email: espeberg@cisco.com 397 Bernhard Feiten 398 Deutsche Telekom 400 Email: Bernhard.Feiten@telekom.de 402 Bo Burman 403 Ericsson 405 Email: bo.burman@ericsson.com 407 Kalyani Bogineni 408 Verizon Wireless 410 Email: Kalyani.Bogineni@VerizonWireless.com 412 Miao Lei 413 Huawei 415 Email: lei.miao@huawei.com 416 Enrico Marocco 417 Telecom Italia 419 Email: enrico.marocco@telecomitalia.it