--- 1/draft-ietf-rtcweb-audio-codecs-for-interop-03.txt 2015-12-11 07:15:10.097650798 -0800 +++ 2/draft-ietf-rtcweb-audio-codecs-for-interop-04.txt 2015-12-11 07:15:10.125651464 -0800 @@ -1,18 +1,18 @@ Network Working Group S. Proust Internet-Draft Orange -Intended status: Informational December 2, 2015 -Expires: June 4, 2016 +Intended status: Informational December 11, 2015 +Expires: June 13, 2016 Additional WebRTC audio codecs for interoperability. - draft-ietf-rtcweb-audio-codecs-for-interop-03 + draft-ietf-rtcweb-audio-codecs-for-interop-04 Abstract To ensure a baseline level of interoperability between WebRTC clients, a minimum set of required codecs is specified. However, to maximize the possibility to establish the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser. This document provides some guidelines on the suitable codecs to be @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 4, 2016. + This Internet-Draft will expire on June 13, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -59,30 +59,30 @@ 4. Additional suitable codecs for WebRTC . . . . . . . . . . . . 5 4.1. AMR-WB . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. AMR-WB General description . . . . . . . . . . . . . 5 4.1.2. WebRTC relevant use case for AMR-WB . . . . . . . . . 5 4.1.3. Guidelines for AMR-WB usage and implementation with WebRTC . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. AMR General description . . . . . . . . . . . . . . . 6 4.2.2. WebRTC relevant use case for AMR . . . . . . . . . . 6 4.2.3. Guidelines for AMR usage and implementation with - WebRTC . . . . . . . . . . . . . . . . . . . . . . . 7 + WebRTC . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3.1. G.722 General description . . . . . . . . . . . . . . 7 4.3.2. WebRTC relevant use case for G.722 . . . . . . . . . 7 4.3.3. Guidelines for G.722 usage and implementation . . . . 8 4.4. Other codecs . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative references . . . . . . . . . . . . . . . . . . 9 8.2. Informative references . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction As indicated in [I-D.ietf-rtcweb-overview], it has been anticipated that WebRTC will not remain an isolated island and that some WebRTC endpoints will need to communicate with devices used in other existing networks with the help of a gateway. Therefore, in order to @@ -91,21 +91,21 @@ to include in the offer other suitable audio codecs that are available to the browser. This document provides some guidelines on the suitable codecs to be considered for WebRTC clients to address the most relevant interoperability use cases. The codecs considered in this document are recommended to be supported and included in the Offer only for WebRTC clients for which interoperability with other non-WebRTC endpoints and non-WebRTC based services is relevant as described in Section 4.1.2, Section 4.2.2, Section 4.3.2. Other use cases may justify offering other additional - codecs to avoid transcodings. + codecs to avoid transcoding. 2. Definition and abbreviations o Legacy networks: In this document, legacy networks encompass the conversational networks that are already deployed like the PSTN, the PLMN, the IP/IMS networks offering VoIP services, including 3GPP "4G" Evolved Packet System[TS23.002] supporting voice over LTE radio access (VoLTE) [IR.92]. o AMR: Adaptive Multi-Rate. @@ -140,22 +140,22 @@ VoLTE services (Voice over LTE as specified in [IR.92]) or to interoperate with fixed or mobile Circuit Switched or VoIP services like mobile Circuit Switched voice over 3GPP 2G/3G mobile networks [TS23.002] or DECT based VoIP telephony [EN300175-1]. Consequently, a significant number of calls are likely to occur between terminals supporting WebRTC clients and other terminals like mobile handsets, fixed VoIP terminals, DECT terminals that do not support WebRTC clients nor implement OPUS. As a consequence, these calls are likely to be either of low narrow band PSTN quality using G.711 [G.711] at - both ends or affected by transcoding operations. The drawbacks of - such transcoding operations are recalled below: + both ends or affected by transcoding operations. The drawback of + such transcoding operations are listed below: o Degraded user experience with respect to voice quality: voice quality is significantly degraded by transcoding. For instance, the degradation is around 0.2 to 0.3 MOS for most of transcoding use cases with AMR-WB codec (Section 4.1) at 12.65 kbit/s and in the same range for other wideband transcoding cases. It should be stressed that if G.711 is used as a fall back codec for interoperation, wideband voice quality will be lost. Such bandwidth reduction effect down to narrow band clearly degrades the user perceived quality of service leading to shorter and less @@ -172,119 +172,118 @@ quality below the acceptable limit for the customers. o Degraded user experience with respect to conversational interactivity: the degradation of conversational interactivity is due to the increase of end to end latency for both directions that is introduced by the transcoding operations. Transcoding requires full de-packetization for decoding of the media stream (including mechanisms of de-jitter buffering and packet loss recovery) then re-encoding, re-packetization and re-sending. The delays produced by all these operations are additive and may increase the end to - end delay beyond acceptable limits like with more than 1s end to - end latency. + end delay up to 1 second, much beyond the acceptable limit. - o Additional costs in networks: transcoding places important - additional costs on network gateways mainly related to codec - implementation, codecs license, deployments, testing and - validation costs. It must be noted that transcoding of wideband - to wideband would require more CPU processing and be more costly - than between narrowband codecs. + o Additional cost in networks: transcoding places important + additional cost on network gateways mainly related to codec + implementation, codecs licenses, deployment, testing and + validation cost. It must be noted that transcoding of wideband to + wideband would require more CPU processing and be more costly than + transcoding between narrowband codecs. 4. Additional suitable codecs for WebRTC - The following codecs are considered as relevant suitable codecs with - respect to the general purpose described in Section 3. This list - reflects the current status of WebRTC foreseen use cases. It is not + The following codecs are considered as relevant codecs with respect + to the general purpose described in Section 3. This list reflects + the current status of WebRTC foreseen use cases. It is not limitative and opened to further inclusion of other codecs for which relevant use cases can be identified. These additional codecs are recommended to be included in the offer in addition to OPUS and G.711 according to the foreseen interoperability cases to be addressed. 4.1. AMR-WB 4.1.1. AMR-WB General description The Adaptive Multi-Rate WideBand (AMR-WB) is a 3GPP defined speech codec that is mandatory to implement in any 3GPP terminal that supports wideband speech communication. It is being used in circuit switched mobile telephony services and new multimedia telephony - services over IP/IMS like for voice over LTE as specified by GSMA in - [IR.92]. More detailed information on AMR-WB can be found in - [IR.36]. References for AMR-WB related specifications including - detailed codec description and Source code are in [TS26.171], - [TS26.173], [TS26.190], [TS26.204]. + services over IP/IMS. It is especially used for voice over LTE as + specified by GSMA in [IR.92]. More detailed information on AMR-WB + can be found in [IR.36]. References for AMR-WB related + specifications including detailed codec description and source code + are in [TS26.171], [TS26.173], [TS26.190], [TS26.204]. 4.1.2. WebRTC relevant use case for AMR-WB The market of personal voice communication is driven by mobile - terminals. AMR-WB is now implemented in several hundreds of devices + terminals. AMR-WB is now implemented in several hundreds of device models and 145 HD mobile networks in 85 countries with a customer - base of more than 450 millions. A high number of calls are + base of more than 450 million. A high number of calls are consequently likely to occur between WebRTC clients and mobile 3GPP terminals. The use of AMR-WB by WebRTC clients would consequently allow transcoding free interoperation with all mobile 3GPP wideband terminals. Besides, WebRTC clients running on mobile terminals (smartphones) may reuse the AMR-WB codec already implemented on these devices. 4.1.3. Guidelines for AMR-WB usage and implementation with WebRTC The payload format to be used for AMR-WB is described in [RFC4867] with bandwidth efficient format and one speech frame encapsulated in each RTP packets. Further guidelines for implementing and using AMR- WB and ensuring interoperability with 3GPP mobile services can be found in [TS26.114]. In order to ensure interoperability with 4G/ VoLTE as specified by GSMA, the more specific IMS profile for voice derived from [TS26.114] should be considered in [IR.92]. In order to maximize the possibility of successful call establishment for WebRTC client offering AMR-WB it is important that the WebRTC client: - o Offer AMR in addition to AMR-WB with AMR-WB, being a wideband - codec, listed first as preferred payload type with respect to + o Offer AMR in addition to AMR-WB with AMR-WB listed first (AMR-WB + being a wideband codec) as preferred payload type with respect to other narrow band codecs (AMR, G.711...)and with Bandwidth Efficient payload format preferred. o Be capable of operating AMR-WB with any subset of the nine codec modes and source controlled rate operation. Offer at least one AMR-WB configuration with parameter settings as defined in Table 6.1 of [TS26.114]. In order to maximize the interoperability and quality this offer does not restrict the codec modes offered. Restrictions in the use of codec modes may be included in the answer. 4.2. AMR 4.2.1. AMR General description Adaptive Multi-Rate (AMR) is a 3GPP defined speech codec that is mandatory to implement in any 3GPP terminal that supports voice - communication, i.e. several hundred millions of terminals. This + communication, i.e., several hundred millions of terminals. This include both mobile phone calls using GSM and 3G cellular systems as well as multimedia telephony services over IP/IMS and 4G/VoLTE, such - as GSMA voice IMS profile for VoLTE in [IR.92]. In addition to + as, GSMA voice IMS profile for VoLTE in [IR.92]. In addition to impacts listed above, support of AMR can avoid degrading the high efficiency over mobile radio access.References for AMR related - specifications including detailed codec description and Source code + specifications including detailed codec description and source code are in [TS26.071], [TS26.073], [TS26.090], [TS26.104]. 4.2.2. WebRTC relevant use case for AMR A user of a WebRTC endpoint on a device integrating an AMR module wants to communicate with another user that can only be reached on a mobile device that only supports AMR. Although more and more - terminal devices are now "HD voice" and support AMR-WB; there is + terminal devices are now "HD voice" and support AMR-WB; there are still a high number of legacy terminals supporting only AMR - (terminals with no wideband / HD Voice capabilities) are still used. - The use of AMR by WebRTC client would consequently allow transcoding - free interoperation with all mobile 3GPP terminals. Besides, WebRTC - client running on mobile terminals (smartphones) may reuse the AMR - codec already implemented on these devices. + (terminals with no wideband / HD Voice capabilities) that are still + in use. The use of AMR by WebRTC client would consequently allow + transcoding free interoperation with all mobile 3GPP terminals. + Besides, WebRTC client running on mobile terminals (smartphones) may + reuse the AMR codec already implemented on these devices. 4.2.3. Guidelines for AMR usage and implementation with WebRTC The payload format to be used for AMR is described in [RFC4867] with bandwidth efficient format and one speech frame encapsulated in each RTP packets. Further guidelines for implementing and using AMR with purpose to ensure interoperability with 3GPP mobile services can be found in [TS26.114]. In order to ensure interoperability with 4G/ VoLTE as specified by GSMA, the more specific IMS profile for voice derived from [TS26.114] should be considered in [IR.92]. In order to @@ -315,40 +314,40 @@ band to wideband. G.722 is the wideband codec required for CAT-iq DECT certified terminals and the V2.0 of CAT-iq specifications have been approved by GSMA as minimum requirements for HD voice logo usage on "fixed" devices; i.e., broadband connections using the G.722 codec. 4.3.2. WebRTC relevant use case for G.722 G.722 is the wideband codec required for DECT CAT-iq terminals. The market for DECT cordless phones including DECT chipset is more than - 150 Millions per year and CAT-IQ is a registered trade make in 47 + 150 million per year and CAT-IQ is a registered trade make in 47 countries worldwide. G.722 has also been specified by ETSI in [TS181005] as mandatory wideband codec for IMS multimedia telephony communication service and supplementary services using fixed broadband access. The support of G.722 would consequently allow transcoding free IP interoperation between WebRTC client and fixed VoIP terminals including DECT / CAT-IQ terminals supporting G.722. Besides, WebRTC client running on fixed terminals implementing G.722 may reuse the G.722 codec already implemented on these devices. 4.3.3. Guidelines for G.722 usage and implementation The payload format to be used for G.722 is defined in [RFC3551] with each octet of the stream of octets produced by the codec to be octet- aligned in an RTP packet. The sampling frequency for G.722 is 16 kHz but the rtp clock rate is set to 8000Hz in SDP to stay backward compatible with an erroneous definition in the original version of the RTP A/V profile. Further guidelines for implementing and using - G.722 with purpose to ensure interoperability with Multimedia - Telephony services overs IMS can be found in section 7 of [TS26.114]. + G.722 with purpose to ensure interoperability with multimedia + telephony services over IMS can be found in section 7 of [TS26.114]. Additional information of G.722 implementation in DECT can be found in [EN300175-8] and full codec description and C source code in [G.722]. 4.4. Other codecs Other interoperability use cases may justify the use of other codecs. 5. Security Considerations @@ -358,26 +357,44 @@ advised to also report more specifically to the "Security Considerations" sections of [RFC4867] (for AMR and AMR-WB) and [RFC3551]. 6. IANA Considerations None. 7. Acknowledgements - Special thanks to Espen Berger, Bernhard Feiten, Bo Burman, Kalyani - Bogineni, Miao Lei, Enrico Marocco, who co-authored the initial - document. Thanks, as well, to Magnus Westerlund and Barry Dingle who - carefully reviewed the document and helped to improve it. + The authors of this document are + + o Stephane Proust, Orange, stephane.proust@orange.com , + + o Espen Berger, Cisco, espeberg@cisco.com , + + o Bernhard Feiten, Deutsche Telekom, Bernhard.Feiten@telekom.de , + + o Bo Burman, Ericsson, bo.burman@ericsson.com , + + o Kalyani Bogineni, Verizon Wireless, + Kalyani.Bogineni@VerizonWireless.com , + + o Mia Lei, Huawei, lei.miao@huawei.com , + o Enrico Marocco,Telecom Italia, enrico.marocco@telecomitalia.it , + + though only the editor is listed on the front page. + + The authors would like to thank Magnus Westerlund, Barry Dingle and + Sanjay Mishra who carefully reviewed the document and helped to + improve it. 8. References + 8.1. Normative references [G.722] ITU, "Recommendation ITU-T G.722 (2012): 7 kHz audio- coding within 64 kbit/s", 2012-09. [I-D.ietf-rtcweb-audio] Valin, J. and C. Bran, "WebRTC Audio Codec and Processing Requirements", draft-ietf-rtcweb-audio-09 (work in progress), November 2015. @@ -459,25 +476,20 @@ Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-14 (work in progress), June 2015. [IR.36] GSMA, "Adaptive Multirate Wide Band V3.0", September 2014. [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, . - [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- - Time Communication Use Cases and Requirements", RFC 7478, - DOI 10.17487/RFC7478, March 2015, - . - [TS181005] ETSI, "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Service and Capability Requirements V3.3.1 (2009-12)", 2009. [TS23.002] 3GPP, "3GPP TS 23.002 v13.3.0: Network architecture", 2015-09. Author's Address