idnits 2.17.1 draft-ietf-rtcweb-audio-codecs-for-interop-01.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 (January 16, 2015) is 3387 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtcweb-use-cases-and-requirements' is defined on line 369, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-rtcweb-audio-07 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-13 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-15 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: July 20, 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 January 16, 2015 18 Additional WebRTC audio codecs for interoperability. 19 draft-ietf-rtcweb-audio-codecs-for-interop-01 21 Abstract 23 To ensure a baseline level of interoperability between WebRTC 24 clients, [I-D.ietf-rtcweb-audio] requires a minimum set of codecs. 25 However, to maximize the possibility to establish the session without 26 the need for audio transcoding, it is also recommended to include in 27 the offer other suitable audio codecs that are available to the 28 browser. 30 This document provides some guidelines on the suitable codecs to be 31 considered for WebRTC clients to address the most relevant 32 interoperability use cases. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 20, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Rationale for additional WebRTC codecs . . . . . . . . . . . 3 70 4. Additional suitable codecs for WebRTC . . . . . . . . . . . . 4 71 4.1. AMR-WB . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4.1.1. AMR-WB General description . . . . . . . . . . . . . 5 73 4.1.2. WebRTC relevant use case for AMR-WB . . . . . . . . . 5 74 4.1.3. Guidelines for AMR-WB usage and implementation with 75 WebRTC . . . . . . . . . . . . . . . . . . . . . . . 5 76 4.2. AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 4.2.1. AMR General description . . . . . . . . . . . . . . . 6 78 4.2.2. WebRTC relevant use case for AMR . . . . . . . . . . 6 79 4.2.3. Guidelines for AMR usage and implementation with 80 WebRTC . . . . . . . . . . . . . . . . . . . . . . . 6 81 4.3. G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 4.3.1. G.722 General description . . . . . . . . . . . . . . 7 83 4.3.2. WebRTC relevant use case for G.722 . . . . . . . . . 7 84 4.3.3. Guidelines for G.722 usage and implementation . . . . 7 85 4.4. Other codecs . . . . . . . . . . . . . . . . . . . . . . 7 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 90 8.1. Normative references . . . . . . . . . . . . . . . . . . 8 91 8.2. Informative references . . . . . . . . . . . . . . . . . 8 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 94 1. Introduction 96 As indicated in [I-D.ietf-rtcweb-overview], it has been anticipated 97 that WebRTC will not remain an isolated island and that some WebRTC 98 endpoints will need to communicate with devices used in other 99 existing networks with the help of a gateway. Therefore, in order to 100 maximize the possibility to establish the session without the need 101 for audio transcoding, it is recommended in [I-D.ietf-rtcweb-audio] 102 to include in the offer other suitable audio codecs that are 103 available to the browser. This document provides some guidelines on 104 the suitable codecs to be considered for WebRTC clients to address 105 the most relevant interoperability use cases. 107 The codecs considered in this document are recommended to be 108 supported and included in the Offer only for WebRTC clients for which 109 interoperability with other non WebRTC end points and non WebRTC 110 based services is relevant as described in sections 5.1.2, 5.2.2 and 111 5.3.2. Other use cases may justify offering other additional codecs 112 to avoid transcodings. It is the intent of this document to 113 inventory and document any other additional interoperability use 114 cases and codecs if needed. 116 2. Definitions 118 Legacy networks: In this draft, legacy networks encompass the 119 conversational networks that are already deployed like the PSTN, the 120 PLMN, the IMS, H.323 networks. 122 3. Rationale for additional WebRTC codecs 124 The mandatory implementation of OPUS [RFC6716] in WebRTC clients can 125 guarantee the codec interoperability (without transcoding) at the 126 state of the art voice quality (better than narrow band "PSTN" 127 quality) between WebRTC clients. The WebRTC technology is however 128 expected to be used to communicate with other types of clients using 129 other technologies. It can be used for instance as an access 130 technology to 3GPP IMS services (e.g. VoLTE, ViLTE) or to 131 interoperate with fixed or mobile Circuit Switched or VoIP services 132 like mobile 3GPP 3G/2G Circuit Switched voice or DECT based VoIP 133 telephony. Consequently, a significant number of calls are likely to 134 occur between terminals supporting WebRTC clients and other terminals 135 like mobile handsets, fixed VoIP terminals, DECT terminals that do 136 not support WebRTC clients nor implement OPUS. As a consequence, 137 these calls are likely to be either of low narrow band PSTN quality 138 using G.711 at both ends or affected by transcoding operations. The 139 drawbacks of such transcoding operations are recalled below: 141 o Degraded user experience with respect to voice quality: voice 142 quality is significantly degraded by transcoding. For instance, 143 the degradation is around 0.2 to 0.3 MOS for most of transcoding 144 use cases with AMR-WB at 12.65 kbit/s and in the same range for 145 other wideband transcoding cases. It should be stressed that if 146 G.711 is used as a fall back codec for interoperation, wideband 147 voice quality will be lost. Such bandwidth reduction effect down 148 to narrow band clearly degrades the user perceived quality of 149 service leading to shorter and less frequent calls. Such a switch 150 to G.711 is less than desirable or acceptable choice for 151 customers. If transcoding is performed between OPUS and any other 152 wideband codec, wideband communication could be maintained but 153 with degraded quality (MOS scores of transcoding between AMR-WB 154 12.65kbit/s and OPUS at 16 kbit/s in both directions are 155 significantly lower than those of AMR-WB at 12.65kbit/s or OPUS at 156 16 kbit/s). Furthermore, in degraded conditions, the addition of 157 defects, like audio artifacts due to packet losses, and the audio 158 effects resulting from the cascading of different packet loss 159 recovery algorithms may result in a quality below the acceptable 160 limit for the customers. 162 o Degraded user experience with respect to conversational 163 interactivity: the degradation of conversational interactivity is 164 due to the increase of end to end latency for both directions that 165 is introduced by the transcoding operations. Transcoding requires 166 full de-packetization for decoding of the media stream (including 167 mechanisms of de-jitter buffering and packet loss recovery) then 168 re-encoding, re-packetization and re-sending. The delays produced 169 by all these operations are additive and may increase the end to 170 end delay beyond acceptable limits like with more than 1s end to 171 end latency. 173 o Additional costs in networks: transcoding places important 174 additional costs on network gateways mainly related to codec 175 implementation, codecs license, deployments, testing and 176 validation costs. It must be noted that transcoding of wideband 177 to wideband would require more CPU and be more costly than between 178 narrowband codecs. 180 4. Additional suitable codecs for WebRTC 182 The following codecs are considered as relevant suitable codecs with 183 respect to the general purpose described in section 4. This list 184 reflects the current status of WebRTC foreseen use cases. It is not 185 limitative and opened to further inclusion of other codecs for which 186 relevant use cases can be identified. These additional codecs are 187 recommended to be included in the offer in addition to OPUS and G.711 188 according to the foreseen interoperability cases to be addressed. 190 4.1. AMR-WB 192 4.1.1. AMR-WB General description 194 The Adaptive Multi-Rate WideBand (AMR-WB) is a 3GPP defined speech 195 codec that is mandatory to implement in any 3GPP terminal that 196 supports wideband speech communication. It is being used in circuit 197 switched mobile telephony services and new multimedia telephony 198 services over IP/IMS and 4G/VoLTE, specified by GSMA as voice IMS 199 profile for VoLTE in [IR.92]. More detailed information on AMR-WB 200 can be found in [IR.36]. [IR.36] includes references for all 3GPP 201 AMR-WB related specifications including detailed codec description 202 and Source code. 204 4.1.2. WebRTC relevant use case for AMR-WB 206 The market of voice personal communication is driven by mobile 207 terminals. AMR-WB is now implemented in more than 200 devices models 208 and 85 HD mobile networks in 60 countries with a customer base of 209 more than 100 million. A high number of calls are consequently 210 likely to occur between WebRTC clients and mobile 3GPP terminals. 211 The use of AMR-WB by WebRTC clients would consequently allow 212 transcoding free interoperation with all mobile 3GPP wideband 213 terminal. Besides, WebRTC clients running on mobile terminals 214 (smartphones) may reuse the AMR-WB codec already implemented on these 215 devices. 217 4.1.3. Guidelines for AMR-WB usage and implementation with WebRTC 219 Guidelines for implementing and using AMR-WB and ensuring 220 interoperability with 3GPP mobile services can be found in 221 [TS26.114]. In order to ensure interoperability with 4G/VoLTE as 222 specified by GSMA, the more specific IMS profile for voice derived 223 from [TS26.114] should be considered in [IR.92]. In order to 224 maximize the possibility of successful call establishment for WebRTC 225 client offering AMR-WB it is important that the WebRTC client: 227 o Offer AMR in addition to AMR-WB with AMR-WB, being a wideband 228 codec, listed first as preferred payload type with respect to 229 other narrow band codecs (AMR, G.711...)and with Bandwidth 230 Efficient payload format preferred. 232 o Be capable of operating AMR-WB with any subset of the nine codec 233 modes and source controlled rate operation. Offer at least one 234 AMR-WB configuration with parameter settings as defined in 235 Table 6.1 of [TS 26.114]. In order to maximize the 236 interoperability and quality this offer does not restrict the 237 codec modes offered. Restrictions in the use of codec modes may 238 be included in the answer. 240 4.2. AMR 242 4.2.1. AMR General description 244 Adaptive Multi-Rate (AMR) is a 3GPP defined speech codec that is 245 mandatory to implement in any 3GPP terminal that supports voice 246 communication, i.e. several hundred millions of terminals. This 247 include both mobile phone calls using GSM and 3G cellular systems as 248 well as multimedia telephony services over IP/IMS and 4G/VoLTE, such 249 as GSMA voice IMS profile for VoLTE in [IR.92]. In addition to 250 impacts listed above, support of AMR can avoid degrading the high 251 efficiency over mobile radio access. 253 4.2.2. WebRTC relevant use case for AMR 255 A user of a WebRTC endpoint on a device integrating an AMR module 256 wants to communicate with another user that can only be reached on a 257 mobile device that only supports AMR. Although more and more 258 terminal devices are now "HD voice" and support AMR-WB; there is 259 still a high number of legacy terminals supporting only AMR 260 (terminals with no wideband / HD Voice capabilities) are still used. 261 The use of AMR by WebRTC client would consequently allow transcoding 262 free interoperation with all mobile 3GPP terminals. Besides, WebRTC 263 client running on mobile terminals (smartphones) may reuse the AMR 264 codec already implemented on these devices. 266 4.2.3. Guidelines for AMR usage and implementation with WebRTC 268 Guidelines for implementing and using AMR with purpose to ensure 269 interoperability with 3GPP mobile services can be found in 270 [TS26.114]. In order to ensure interoperability with 4G/VoLTE as 271 specified by GSMA, the more specific IMS profile for voice derived 272 from [TS26.114] should be considered in [IR.92]. In order to 273 maximize the possibility of successful call establishment for WebRTC 274 client offering AMR, it is important that the WebRTC client: 276 o Be capable of operating AMR with any subset of the eight codec 277 modes and source controlled rate operation. 279 o Offer at least one configuration with parameter settings as 280 defined in Table 6.1 and Table 6.2 of [TS26.114]. In order to 281 maximize the interoperability and quality this offer shall not 282 restrict AMR codec modes offered. Restrictions in the use of 283 codec modes may be included in the answer. 285 4.3. G.722 287 4.3.1. G.722 General description 289 G.722 is an ITU-T defined wideband speech codec. [G.722] was 290 approved by ITU-T in 1988. It is a royalty free codec that is common 291 in a wide range of terminals and end-points supporting wideband 292 speech and requiring low complexity. The complexity of G.722 is 293 estimated to 10 MIPS [EN300175-8] which is 2.5 to 3 times lower than 294 AMR-WB. Especially, G.722 has been chosen by ETSI DECT as the 295 mandatory wideband codec for New Generation DECT with purpose to 296 greatly increase the voice quality by extending the bandwidth from 297 narrow band to wideband. G.722 is the wideband codec required for 298 CAT-iq DECT certified terminal and the V2.0 of CAT-iq specifications 299 have been approved by GSMA as minimum requirements for HD voice logo 300 usage on "fixed" devices; i.e., broadband connections using the G.722 301 codec. 303 4.3.2. WebRTC relevant use case for G.722 305 G.722 is the wideband codec required for DECT CAT-iq terminals. The 306 market for DECT cordeless phones including DECT chipset is more than 307 150 Millions per year and CAT-IQ is a registered trade make in 47 308 countries worldwide. G.722 has also been specified by ETSI in 309 [TS181005] as mandatory wideband codec for IMS multimedia telephony 310 communication service and supplementary services using fixed 311 broadband access. The support of G.722 would consequently allow 312 transcoding free IP interoperation between WebRTC client and fixed 313 VoIP terminals including DECT / CAT-IQ terminals supporting G.722. 314 Besides, WebRTC client running on fixed terminals implementing G.722 315 may reuse the G.722 codec already implemented on these devices. 317 4.3.3. Guidelines for G.722 usage and implementation 319 Guidelines for implementing and using G.722 with purpose to ensure 320 interoperability with Multimedia Telephony services overs IMS can be 321 found in section 7 of [TS26.114]. Additional information of G.722 322 implementation in DECT can be found in [EN300175-8] and full codec 323 description and C source code in [G.722]. 325 4.4. Other codecs 327 Other interoperability use cases may justify the use of other codecs. 328 Some further update of this Draft may provide under this section 329 additional use case description and codec implementation guidelines 330 for these codecs. 332 5. Security Considerations 334 6. IANA Considerations 336 None. 338 7. Acknowledgements 340 Thanks to Milan Patel for his review. 342 8. References 344 8.1. Normative references 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 8.2. Informative references 351 [EN300175-8] 352 ETSI, "ETSI EN 300 175-8, v2.5.1: "Digital Enhanced 353 Cordless Telecommunications (DECT); Common Interface (CI); 354 Part 8: Speech and audio coding and transmission".", 2009. 356 [G.722] ITU, "Recommendation ITU-T G.722 (2012): "7 kHz audio- 357 coding within 64 kbit/s".", 2012. 359 [I-D.ietf-rtcweb-audio] 360 Valin, J. and C. Bran, "WebRTC Audio Codec and Processing 361 Requirements", draft-ietf-rtcweb-audio-07 (work in 362 progress), October 2014. 364 [I-D.ietf-rtcweb-overview] 365 Alvestrand, H., "Overview: Real Time Protocols for 366 Browser-based Applications", draft-ietf-rtcweb-overview-13 367 (work in progress), November 2014. 369 [I-D.ietf-rtcweb-use-cases-and-requirements] 370 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 371 Time Communication Use-cases and Requirements", draft- 372 ietf-rtcweb-use-cases-and-requirements-15 (work in 373 progress), December 2014. 375 [IR.36] GSMA, "Adaptive Multirate Wide Band", 2013. 377 [IR.92] GSMA, "IMS Profile for Voice and SMS", 2013. 379 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the 380 Opus Audio Codec", RFC 6716, September 2012. 382 [TS181005] 383 ETSI, "Telecommunications and Internet converged Services 384 and Protocols for Advanced Networking (TISPAN); Service 385 and Capability Requirements V3.3.1 (2009-12)", 2009. 387 [TS26.114] 388 3GPP, "IP Multimedia Subsystem (IMS); Multimedia 389 telephony; Media handling and interaction", 2011. 391 Authors' Addresses 393 Stephane Proust 394 Orange 395 2, avenue Pierre Marzin 396 Lannion 22307 397 France 399 Email: stephane.proust@orange.com 401 Espen Berger 402 Cisco 404 Email: espeberg@cisco.com 406 Bernhard Feiten 407 Deutsche Telekom 409 Email: Bernhard.Feiten@telekom.de 411 Bo Burman 412 Ericsson 414 Email: bo.burman@ericsson.com 416 Kalyani Bogineni 417 Verizon Wireless 419 Email: Kalyani.Bogineni@VerizonWireless.com 420 Miao Lei 421 Huawei 423 Email: lei.miao@huawei.com 425 Enrico Marocco 426 Telecom Italia 428 Email: enrico.marocco@telecomitalia.it