One document matched: draft-ietf-rtcweb-audio-codecs-for-interop-01.xml

<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [      
  <!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY RFC6716 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6716.xml'>
  <!ENTITY audio-codecs PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-audio.xml'>
<!ENTITY overview PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-overview.xml'>
<!ENTITY use-cases-and-requirements PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-use-cases-and-requirements.xml'>
]>


<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?> 
<rfc ipr="trust200902" docName="draft-ietf-rtcweb-audio-codecs-for-interop-01" category="info" xml:lang="en">
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc sortrefs='yes'?>

  
<front>
	<title abbrev='WebRTC audio codecs for interop'>
     Additional WebRTC audio codecs for interoperability. 
	</title>
	
	<author initials='S.' surname='Proust' fullname='Stephane Proust'>
	<organization>Orange</organization>
	<address>
		<postal>
			<street>2, avenue Pierre Marzin</street>
			<city>Lannion</city> 
			<code>22307</code>
			<country>France</country>
		</postal> 
      <email>stephane.proust@orange.com</email>
	</address>
	</author>
	
	 <author initials='E.' surname='Berger' fullname='Espen Berger'>
	<organization>Cisco</organization>
	<address>
      <email>espeberg@cisco.com</email>
	</address>
	</author>
	
	<author initials='B.' surname='Feiten' fullname='Bernhard Feiten'>
	<organization>Deutsche Telekom</organization>
	<address>
      <email>Bernhard.Feiten@telekom.de</email>
	</address>
	</author>
	
	<author initials='B.' surname='Burman' fullname='Bo Burman'>
	<organization>Ericsson</organization>
	<address>
      <email>bo.burman@ericsson.com</email>
	</address>
	</author>
	
	<author initials='K.' surname='Bogineni' fullname='Kalyani Bogineni'>
	<organization>Verizon Wireless</organization>
	<address> 
      <email>Kalyani.Bogineni@VerizonWireless.com</email>
	</address>
	</author>
	
	<author initials='M.' surname='Lei' fullname='Miao Lei'>
	<organization>Huawei</organization>
	<address>
      <email>lei.miao@huawei.com</email>
	</address>
	</author>
	
	<author initials='E.' surname='Marocco' fullname='Enrico Marocco'>
	<organization>Telecom Italia</organization>
	<address>
      <email>enrico.marocco@telecomitalia.it</email>
	</address>
	</author>
	
	
	<date month='January' year='2015' />
	
	<area>Real-time Applications and Infrastructure Area</area>
	<keyword>WebRTC</keyword>
	<keyword>audio</keyword>
	<keyword>codec</keyword>
	<keyword>G.722</keyword>
	<keyword>AMR</keyword>
	<keyword>AMR-WB</keyword>

	<abstract>
	<t>To ensure a baseline level of interoperability between WebRTC clients, 
	<xref target="I-D.ietf-rtcweb-audio" /> requires a minimum set of codecs. 
	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.
</t>
<t>
This document provides some guidelines on the suitable codecs to be considered 
for WebRTC clients to address the most relevant interoperability use cases. 
</t>

	</abstract>
</front>

<middle>

  <section title="Introduction">

<t>As indicated in <xref target="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 maximize the possibility 
to establish the session without the need for audio transcoding, it is 
recommended in <xref target="I-D.ietf-rtcweb-audio" /> 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. 
</t>
<t>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 end points and non WebRTC based services is relevant as described in sections 5.1.2, 5.2.2 and 5.3.2. Other use cases may justify offering other additional codecs to avoid transcodings. It is the intent of this document to inventory and document any other additional interoperability use cases and codecs if needed.
</t>
</section>

        <section title="Definitions">
      
  
	<t>Legacy networks: In this draft, legacy networks encompass the conversational networks that are already deployed like the PSTN, the PLMN, the IMS, H.323 networks.</t>

	</section>


	<section title="Rationale for additional WebRTC codecs">

	<t>
	The mandatory implementation of OPUS <xref target="RFC6716" /> in WebRTC clients can guarantee the codec interoperability
	(without transcoding) at the state of the art voice quality (better than narrow band "PSTN" 
	quality) between WebRTC clients. The WebRTC technology is however expected to be used to communicate with other types of clients using other technologies. It can be used for instance 
	as an access technology to 3GPP IMS services (e.g. VoLTE, ViLTE) or to interoperate with fixed or mobile Circuit Switched or VoIP services like mobile 3GPP 3G/2G Circuit Switched voice or DECT based VoIP telephony. 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 at both ends or affected 
	by transcoding operations. The drawbacks of such transcoding operations are recalled below:

<vspace blankLines="1" />
<list style="symbols">

<t>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 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 frequent calls. Such a switch to G.711 
is less than desirable or acceptable choice for customers.  If transcoding is performed between OPUS and any other wideband codec, wideband communication could be maintained but with degraded quality (MOS scores of transcoding between AMR-WB 12.65kbit/s and OPUS at 16 kbit/s in both directions are significantly lower than those of AMR-WB at 12.65kbit/s or OPUS at 16 kbit/s).  Furthermore, in degraded conditions, the addition of defects, like audio artifacts due to packet losses, and the audio effects resulting from the cascading of different packet loss recovery algorithms may result in a quality below the acceptable limit for the customers.<vspace blankLines="1" /></t>

<t>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.<vspace blankLines="1" /></t>

<t>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 and be more costly than between narrowband codecs.<vspace blankLines="1" /></t>

</list>


	</t>
	
</section>





<section title="Additional suitable codecs for WebRTC">

	<t>
	The following codecs are considered as relevant suitable codecs with respect to the general 
	purpose described in section 4. 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.
	</t>
	
	<section title="AMR-WB">
		<section title="AMR-WB General description">
			<t>
			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 and 4G/VoLTE, specified by 
			GSMA as voice IMS profile for VoLTE in <xref target="IR.92" />. More detailed information on 
			AMR-WB can be found in <xref target="IR.36" />. <xref target="IR.36" /> includes references for all 3GPP AMR-WB 
			related specifications including detailed codec description and Source code.  
			</t>
		</section>
		<section title="WebRTC relevant use case for AMR-WB">
			<t>
			The market of voice personal communication is driven by mobile terminals. 
			AMR-WB is now implemented in more than 200 devices models and 85 HD mobile 
			networks in 60 countries with a customer base of more than 100 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 terminal. Besides, 
			WebRTC clients running on mobile terminals (smartphones) may reuse 
			the AMR-WB codec already implemented on these devices.
			</t>
		</section>
		<section title="Guidelines for AMR-WB usage and implementation with WebRTC">
			<t>
			Guidelines for implementing and using AMR-WB and ensuring 
			interoperability with 3GPP mobile services can be found in <xref target="TS26.114" />. 
			In order to ensure interoperability with 4G/VoLTE as specified by GSMA, 
			the more specific IMS profile for voice derived from <xref target="TS26.114" /> 
			should be considered in <xref target="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: 
<list style="symbols">
<t>Offer AMR in addition to AMR-WB with AMR-WB, being a wideband codec, listed first as preferred payload type with respect to other narrow band codecs (AMR, G.711...)and with Bandwidth Efficient payload format preferred.</t>
<t>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 [TS 26.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.</t>
</list>
	</t>		
		</section>
	</section>
	
	<section title="AMR">
		<section title="AMR General description">
			<t>
			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 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 <xref target="IR.92" />.  
			In addition to impacts listed above, support of AMR can avoid 
			degrading the high efficiency over mobile radio access.
			</t>
		</section>
		<section title="WebRTC relevant use case for AMR">
			<t>
			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 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.
			</t>
		</section>		
		<section title="Guidelines for AMR usage and implementation with WebRTC">
			<t>
			Guidelines for implementing and using AMR with purpose to ensure 
			interoperability with 3GPP mobile services can be found in <xref target="TS26.114" />. 
			In order to ensure interoperability with 4G/VoLTE as specified 
			by GSMA, the more specific IMS profile for voice derived from 
			<xref target="TS26.114" /> should be considered in <xref target="IR.92" />.
In order to maximize the possibility of successful call establishment for WebRTC client offering AMR, it is important that the WebRTC client:
<list style="symbols">
<t>Be capable of operating AMR with any subset of the eight codec modes and source controlled rate operation.</t>
<t>Offer at least one configuration with parameter settings as defined in Table 6.1 and Table 6.2 of [TS26.114]. In order to maximize the interoperability and quality this offer shall not restrict AMR codec modes offered. Restrictions in the use of codec modes may be included in the answer.</t>
</list>
			</t>
			</section>
	</section>
	
	<section title="G.722">
		<section title="G.722 General description">
			<t>
			G.722 is an ITU-T defined wideband speech codec. <xref target="G.722" /> was approved 
			by ITU-T in 1988.  It is a royalty free codec that is common in a 
			wide range of terminals and end-points supporting wideband speech 
			and requiring low complexity.  The complexity of G.722 is estimated 
			to 10 MIPS <xref target="EN300175-8" /> which is 2.5 to 3 times lower than AMR-WB. 
			Especially, G.722 has been chosen by ETSI DECT as the mandatory 
			wideband codec for New Generation DECT with purpose to greatly 
			increase the voice quality by extending the bandwidth from narrow 
			band to wideband. G.722 is the wideband codec required for CAT-iq 
			DECT certified terminal 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. 
			</t>
		</section>
		<section title="WebRTC relevant use case for G.722">
			<t>
			G.722 is the wideband codec required for DECT CAT-iq terminals. 
			The market for DECT cordeless phones including DECT chipset is more 
			than 150 Millions per year and CAT-IQ is a registered trade make in 47 
			countries worldwide. G.722 has also been specified by ETSI in 
			<xref target="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.
			</t>
		</section>
		<section title="Guidelines for G.722 usage and implementation">
			<t>
			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 <xref target="TS26.114" />. Additional information of 
			G.722 implementation in DECT can be found in <xref target="EN300175-8" />  and 
			full codec description and C source code in <xref target="G.722" />.
			</t>
		</section>
	</section>
	
	<section title="Other codecs">
<t>
Other interoperability use cases may justify the use of other codecs. Some further update of this Draft may provide under this section additional use case description and codec implementation guidelines for these codecs.
</t>		
	</section>
	
</section>
    
	<section title="Security Considerations">
  
		<t>
			
	  </t>

	</section>


	<section title="IANA Considerations">

	
		<t>None.</t>


	</section> 


	<section title="Acknowledgements">

		<t>Thanks to Milan Patel for his review.</t>

	</section> 


  
</middle>

<back>

<references title="Normative references">

	&RFC2119;
	
</references>

<references title="Informative references">

	&audio-codecs;
	&overview;
	&use-cases-and-requirements;

	&RFC6716;
	
<reference anchor="TS26.114">
	<front>
		<title>IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction</title>
		<author>
			<organization>3GPP</organization>
		<address>
<uri>http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-c40.zip</uri>
		</address>
		</author>
		<date year="2011"></date>
		
	</front>
</reference>	

<reference anchor="IR.92">
	<front>
		<title>IMS Profile for Voice and SMS</title>
		<author>
			<organization>GSMA</organization>
		<address>
<uri>http://www.gsma.com/newsroom/wp-content/uploads/2013/04/IR.92-v7.0.pdf</uri>
		</address>
		</author>
		<date year="2013"></date>
		
	</front>
</reference>	

<reference anchor="IR.36">
	<front>
		<title>Adaptive Multirate Wide Band</title>
		<author>
			<organization>GSMA</organization>
		<address>
<uri>http://www.gsma.com/newsroom/wp-content/uploads/2012/03/IR-36-v2-0.pdf</uri>
		</address>
		</author>
		<date year="2013"></date>
		
	</front>
</reference>	



<reference anchor="TS181005">
	<front>
		<title>Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN); Service and Capability Requirements V3.3.1 (2009-12)
</title>
		<author>
			<organization>ETSI</organization>
		</author>
		<date year="2009"></date>
		
	</front>
</reference>	

<reference anchor="EN300175-8">
	<front>
		<title>ETSI EN 300 175-8, v2.5.1: "Digital Enhanced Cordless Telecommunications (DECT); 
		Common Interface (CI); Part 8: Speech and audio coding and transmission".
</title>
		<author>
			<organization>ETSI</organization>
		</author>
		<date year="2009"></date>
		
	</front>
</reference>	

<reference anchor="G.722">
	<front>
		<title>Recommendation ITU-T G.722 (2012): "7 kHz audio-coding within 64 kbit/s".
		</title>
		<author>
			<organization>ITU</organization>
		<address>
			<uri>http://www.itu.int/rec/T-REC-G.722/e</uri>
		</address>
		</author>
		<date year="2012"></date>
	</front>
</reference>	

</references>

</back>

</rfc>