One document matched: draft-marjou-rtcweb-audio-codecs-for-interop-00.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 RFC2616 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
  <!ENTITY audio-codecs PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-audio.xml'>
]>


<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?> 
<rfc ipr='trust200811' category='info'>
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc sortrefs='yes'?>

<front>
	<title abbrev='WebRTC audio codecs for interop'>
     WebRTC audio codecs for interoperability with legacy networks. 
	</title>
	
	<author initials='X.' surname='Marjou' fullname='Xavier Marjou'>
	<organization>France Telecom Orange</organization>
	<address>
		<postal>
			<street>2, avenue Pierre Marzin</street>
			<city>Lannion</city> 
			<code>22307</code>
			<country>France</country>
		</postal> 
      <email>xavier.marjou@orange.com</email>
	</address>
	</author>
	
	<author initials='S.' surname='Proust' fullname='Stephane Proust'>
	<organization>France Telecom 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>
	
	<date month='January' year='2013' />
	
	<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>This document presents use-cases underlying why WebRTC needs additional audio codecs besides just Opus and G.711.
	It also presents a way forward that takes into considerations the concerns expressed by the browser manufacturers.</t>
	</abstract>
</front>

<middle>

  <section title="Introduction">

	<t>The RTCWEB Working Group has currently drafted that Opus and G.711 will be the only audio codecs used in WebRTC (c.f. [I-D.ietf-rtcweb-audio]);</t>

 	<t>It has been anticipated that WebRTC will not remain an isolated island and that some WebRTC endpoints
	  will need to communicate with devices existing in legacy networks. The Working Group currently thinks that G.711 is sufficient regarding the interoperability of audio codecs</t>

	<t>This document presents use-cases underlying why WebRTC needs additional audio codecs besides just Opus and G.711.
	It also presents a way forward that takes into considerations the concerns expressed by the browser manufacturers.</t>

	<t>In Section 4, we summarize the use-cases we want to fullfil.</t>

	<t>In Section 5, we underline the concerns expressed by the browser manufacturers.</t>

	<t>In Section 6, we present a way forward that will hopefully satisfy all parties.</t>


</section>
 
	<section title="Terminology">
      
	<t> In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 <xref target="RFC2119" />.</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="Use cases">


	  <section title="AMR, AMR-WB">

		<section title="Use case">
			<t>A user of a WebRTC endpoint on a device integrating an AMR or AMR-WB module wants to communicate with another user that can only be reached on a mobile device that only support AMR-WB.</t>
		</section>

		<section title="Problem">
			<t>If OPUS and G.711 were the only codecs supported by the WebRTC endpoints, a gateway would need to transcode them into AMR or AMR-WB, and vice-versa,
			in order to implement the use-case. This is problematic for two major reasons : first, transcoding decreases the quality of the voice; Next, 
			transcoding is CPU intensive, which dramatically increases the cost of the solution making it irrelevant from a business perspective.</t>
		</section>		
	   </section>
	


	  <section title="G.722">


		<section title="Use case">
			<t>A user of a WebRTC endpoint on a device integrating G.722 module wants to communicate with another user that can only be reached on a device that supports G.711 and G.722.</t>
		</section>

		<section title="Problem">
			<t>If OPUS and G.711 were the only codecs supported by the WebRTC endpoints, G.711 will be used by both endpoints. This may also be
			problematic given that G.722 has a much better quality than G.711.</t>
		</section>		
	   </section>

	</section>

	<section title="Concerns from the browser manufacturers">

	<t>The concern of the browser manufacturer is that they will have to pay if they implement AMR, AMR-WB or/and G.722.</t>

	</section>
 
	<section title="The proposed way-forward">
  	
	<t>We propose that the browser manufacturer re-use the AMR, AMR-WB or/and G.722 module, if already pre-installed. The advantage is twofold: it avoids  possible royalties 
	related to such codecs, if any, for the browser manufacturer; it avoids writing significant codec code as the most important part is already written/chipped is the existing
        audio codec module.</t>
		
	</section>

    
    
	<section title="Security Considerations">
  
		<t>
			
	  </t>

	</section>


	<section title="IANA Considerations">

	
		<t>None.</t>


	</section> 


	<section title="Acknowledgements">

		<t></t>

	</section> 


  
</middle>

<back>

<references title="Normative references">

	&RFC2119;
  	&RFC2616;  	
 
</references>

<references title="Informative references">

	&audio-codecs;

</references>

</back>

</rfc>