draft-ietf-rtcweb-audio-codecs-for-interop-02.txt		draft-ietf-rtcweb-audio-codecs-for-interop-03.txt
	Network Working Group S. Proust		Network Working Group S. Proust
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Informational E. Berger		Intended status: Informational December 2, 2015
	Expires: February 8, 2016 Cisco		Expires: June 4, 2016
	B. Feiten
	Deutsche Telekom
	B. Burman
	Ericsson
	K. Bogineni
	Verizon Wireless
	M. Lei
	Huawei
	E. Marocco
	Telecom Italia
	August 7, 2015
	Additional WebRTC audio codecs for interoperability.		Additional WebRTC audio codecs for interoperability.
	draft-ietf-rtcweb-audio-codecs-for-interop-02		draft-ietf-rtcweb-audio-codecs-for-interop-03
	Abstract		Abstract
	To ensure a baseline level of interoperability between WebRTC		To ensure a baseline level of interoperability between WebRTC
	clients, [I-D.ietf-rtcweb-audio] requires a minimum set of codecs.		clients, a minimum set of required codecs is specified. However, to
	However, to maximize the possibility to establish the session without		maximize the possibility to establish the session without the need
	the need for audio transcoding, it is also recommended to include in		for audio transcoding, it is also recommended to include in the offer
	the offer other suitable audio codecs that are available to the		other suitable audio codecs that are available to the browser.
	browser.
	This document provides some guidelines on the suitable codecs to be		This document provides some guidelines on the suitable codecs to be
	considered for WebRTC clients to address the most relevant		considered for WebRTC clients to address the most relevant
	interoperability use cases.		interoperability use cases.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 8, 2016.
			This Internet-Draft will expire on June 4, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Definition and abbreviations . . . . . . . . . . . . . . . . 3
	3. Rationale for additional WebRTC codecs . . . . . . . . . . . 3		3. Rationale for additional WebRTC codecs . . . . . . . . . . . 3
	4. Additional suitable codecs for WebRTC . . . . . . . . . . . . 4		4. Additional suitable codecs for WebRTC . . . . . . . . . . . . 5
	4.1. AMR-WB . . . . . . . . . . . . . . . . . . . . . . . . . 5		4.1. AMR-WB . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1.1. AMR-WB General description . . . . . . . . . . . . . 5		4.1.1. AMR-WB General description . . . . . . . . . . . . . 5
	4.1.2. WebRTC relevant use case for AMR-WB . . . . . . . . . 5		4.1.2. WebRTC relevant use case for AMR-WB . . . . . . . . . 5
	4.1.3. Guidelines for AMR-WB usage and implementation with		4.1.3. Guidelines for AMR-WB usage and implementation with
	WebRTC . . . . . . . . . . . . . . . . . . . . . . . 5		WebRTC . . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4.2. AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.2.1. AMR General description . . . . . . . . . . . . . . . 6		4.2.1. AMR General description . . . . . . . . . . . . . . . 6
	4.2.2. WebRTC relevant use case for AMR . . . . . . . . . . 6		4.2.2. WebRTC relevant use case for AMR . . . . . . . . . . 6
	4.2.3. Guidelines for AMR usage and implementation with		4.2.3. Guidelines for AMR usage and implementation with
	WebRTC . . . . . . . . . . . . . . . . . . . . . . . 6		WebRTC . . . . . . . . . . . . . . . . . . . . . . . 7
	4.3. G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.3. G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.3.1. G.722 General description . . . . . . . . . . . . . . 7		4.3.1. G.722 General description . . . . . . . . . . . . . . 7
	4.3.2. WebRTC relevant use case for G.722 . . . . . . . . . 7		4.3.2. WebRTC relevant use case for G.722 . . . . . . . . . 7
	4.3.3. Guidelines for G.722 usage and implementation . . . . 7		4.3.3. Guidelines for G.722 usage and implementation . . . . 8
	4.4. Other codecs . . . . . . . . . . . . . . . . . . . . . . 7		4.4. Other codecs . . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative references . . . . . . . . . . . . . . . . . . 8		8.1. Normative references . . . . . . . . . . . . . . . . . . 9
	8.2. Informative references . . . . . . . . . . . . . . . . . 8		8.2. Informative references . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	As indicated in [I-D.ietf-rtcweb-overview], it has been anticipated		As indicated in [I-D.ietf-rtcweb-overview], it has been anticipated
	that WebRTC will not remain an isolated island and that some WebRTC		that WebRTC will not remain an isolated island and that some WebRTC
	endpoints will need to communicate with devices used in other		endpoints will need to communicate with devices used in other
	existing networks with the help of a gateway. Therefore, in order to		existing networks with the help of a gateway. Therefore, in order to
	maximize the possibility to establish the session without the need		maximize the possibility to establish the session without the need
	for audio transcoding, it is recommended in [I-D.ietf-rtcweb-audio]		for audio transcoding, it is recommended in [I-D.ietf-rtcweb-audio]
	to include in the offer other suitable audio codecs that are		to include in the offer other suitable audio codecs that are
	available to the browser. This document provides some guidelines on		available to the browser. This document provides some guidelines on
	the suitable codecs to be considered for WebRTC clients to address		the suitable codecs to be considered for WebRTC clients to address
	the most relevant interoperability use cases.		the most relevant interoperability use cases.
	The codecs considered in this document are recommended to be		The codecs considered in this document are recommended to be
	supported and included in the Offer only for WebRTC clients for which		supported and included in the Offer only for WebRTC clients for which
	interoperability with other non WebRTC end points and non WebRTC		interoperability with other non-WebRTC endpoints and non-WebRTC based
	based services is relevant as described in sections 5.1.2, 5.2.2 and		services is relevant as described in Section 4.1.2, Section 4.2.2,
	5.3.2. Other use cases may justify offering other additional codecs		Section 4.3.2. Other use cases may justify offering other additional
	to avoid transcodings. It is the intent of this document to		codecs to avoid transcodings.
	inventory and document any other additional interoperability use
	cases and codecs if needed.
	2. Definitions		2. Definition and abbreviations
	Legacy networks: In this draft, legacy networks encompass the		o Legacy networks: In this document, legacy networks encompass the
	conversational networks that are already deployed like the PSTN, the		conversational networks that are already deployed like the PSTN,
	PLMN, the IMS, H.323 networks.		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.
			o AMR-WB: Adaptive Multi-Rate WideBand.
			o CAT-iq: Cordless Advanced Technology-internet and quality.
			o DECT: Digital Enhanced Cordless Telecommunications
			o IMS: IP Multimedia Subsystem
			o LTE: Long Term Evolution (3GPP "4G" wireless data transmission
			standard)
			o MOS: Mean Opinion Score
			o PSTN:Public Switched Telephone Network
			o PLMN: Public Land Mobile Network
			o VoLTE: Voice Over LTE
	3. Rationale for additional WebRTC codecs		3. Rationale for additional WebRTC codecs
	The mandatory implementation of OPUS [RFC6716] in WebRTC clients can		The mandatory implementation of OPUS [RFC6716] in WebRTC clients can
	guarantee the codec interoperability (without transcoding) at the		guarantee codec interoperability (without transcoding) at state of
	state of the art voice quality (better than narrow band "PSTN"		the art voice quality (better than narrow band "PSTN" quality)
	quality) between WebRTC clients. The WebRTC technology is however		between WebRTC clients. The WebRTC technology is also expected to be
	expected to be used to communicate with other types of clients using		used to communicate with other types of clients using other
	other technologies. It can be used for instance as an access		technologies. It can be used for instance as an access technology to
	technology to 3GPP IMS services (e.g. VoLTE, ViLTE) or to		VoLTE services (Voice over LTE as specified in [IR.92]) or to
	interoperate with fixed or mobile Circuit Switched or VoIP services		interoperate with fixed or mobile Circuit Switched or VoIP services
	like mobile 3GPP 3G/2G Circuit Switched voice or DECT based VoIP		like mobile Circuit Switched voice over 3GPP 2G/3G mobile networks
	telephony. Consequently, a significant number of calls are likely to
	occur between terminals supporting WebRTC clients and other terminals		[TS23.002] or DECT based VoIP telephony [EN300175-1]. Consequently,
	like mobile handsets, fixed VoIP terminals, DECT terminals that do		a significant number of calls are likely to occur between terminals
	not support WebRTC clients nor implement OPUS. As a consequence,		supporting WebRTC clients and other terminals like mobile handsets,
	these calls are likely to be either of low narrow band PSTN quality		fixed VoIP terminals, DECT terminals that do not support WebRTC
	using G.711 at both ends or affected by transcoding operations. The		clients nor implement OPUS. As a consequence, these calls are likely
	drawbacks of such transcoding operations are recalled below:		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:
	o Degraded user experience with respect to voice quality: voice		o Degraded user experience with respect to voice quality: voice
	quality is significantly degraded by transcoding. For instance,		quality is significantly degraded by transcoding. For instance,
	the degradation is around 0.2 to 0.3 MOS for most of transcoding		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		use cases with AMR-WB codec (Section 4.1) at 12.65 kbit/s and in
	other wideband transcoding cases. It should be stressed that if		the same range for other wideband transcoding cases. It should be
	G.711 is used as a fall back codec for interoperation, wideband		stressed that if G.711 is used as a fall back codec for
	voice quality will be lost. Such bandwidth reduction effect down		interoperation, wideband voice quality will be lost. Such
	to narrow band clearly degrades the user perceived quality of		bandwidth reduction effect down to narrow band clearly degrades
	service leading to shorter and less frequent calls. Such a switch		the user perceived quality of service leading to shorter and less
	to G.711 is less than desirable or acceptable choice for		frequent calls. Such a switch to G.711 is less than desirable or
	customers. If transcoding is performed between OPUS and any other		acceptable choice for customers. If transcoding is performed
	wideband codec, wideband communication could be maintained but		between OPUS and any other wideband codec, wideband communication
	with degraded quality (MOS scores of transcoding between AMR-WB		could be maintained but with degraded quality (MOS scores of
	12.65 kbit/s and OPUS at 16 kbit/s in both directions are		transcoding between AMR-WB 12.65 kbit/s and OPUS at 16 kbit/s in
	significantly lower than those of AMR-WB at 12.65 kbit/s or OPUS		both directions are significantly lower than those of AMR-WB at
	at 16 kbit/s). Furthermore, in degraded conditions, the addition		12.65 kbit/s or OPUS at 16 kbit/s). Furthermore, in degraded
	of defects, like audio artifacts due to packet losses, and the		conditions, the addition of defects, like audio artifacts due to
	audio effects resulting from the cascading of different packet		packet losses, and the audio effects resulting from the cascading
	loss recovery algorithms may result in a quality below the		of different packet loss recovery algorithms may result in a
	acceptable limit for the customers.		quality below the acceptable limit for the customers.
	o Degraded user experience with respect to conversational		o Degraded user experience with respect to conversational
	interactivity: the degradation of conversational interactivity is		interactivity: the degradation of conversational interactivity is
	due to the increase of end to end latency for both directions that		due to the increase of end to end latency for both directions that
	is introduced by the transcoding operations. Transcoding requires		is introduced by the transcoding operations. Transcoding requires
	full de-packetization for decoding of the media stream (including		full de-packetization for decoding of the media stream (including
	mechanisms of de-jitter buffering and packet loss recovery) then		mechanisms of de-jitter buffering and packet loss recovery) then
	re-encoding, re-packetization and re-sending. The delays produced		re-encoding, re-packetization and re-sending. The delays produced
	by all these operations are additive and may increase the end to		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 delay beyond acceptable limits like with more than 1s end to
	end latency.		end latency.
	o Additional costs in networks: transcoding places important		o Additional costs in networks: transcoding places important
	additional costs on network gateways mainly related to codec		additional costs on network gateways mainly related to codec
	implementation, codecs license, deployments, testing and		implementation, codecs license, deployments, testing and
	validation costs. It must be noted that transcoding of wideband		validation costs. It must be noted that transcoding of wideband
	to wideband would require more CPU and be more costly than between		to wideband would require more CPU processing and be more costly
	narrowband codecs.		than between narrowband codecs.
	4. Additional suitable codecs for WebRTC		4. Additional suitable codecs for WebRTC
	The following codecs are considered as relevant suitable codecs with		The following codecs are considered as relevant suitable codecs with
	respect to the general purpose described in section 4. This list		respect to the general purpose described in Section 3. This list
	reflects the current status of WebRTC foreseen use cases. It is not		reflects the current status of WebRTC foreseen use cases. It is not
	limitative and opened to further inclusion of other codecs for which		limitative and opened to further inclusion of other codecs for which
	relevant use cases can be identified. These additional codecs are		relevant use cases can be identified. These additional codecs are
	recommended to be included in the offer in addition to OPUS and G.711		recommended to be included in the offer in addition to OPUS and G.711
	according to the foreseen interoperability cases to be addressed.		according to the foreseen interoperability cases to be addressed.
	4.1. AMR-WB		4.1. AMR-WB
	4.1.1. AMR-WB General description		4.1.1. AMR-WB General description
	The Adaptive Multi-Rate WideBand (AMR-WB) is a 3GPP defined speech		The Adaptive Multi-Rate WideBand (AMR-WB) is a 3GPP defined speech
	codec that is mandatory to implement in any 3GPP terminal that		codec that is mandatory to implement in any 3GPP terminal that
	supports wideband speech communication. It is being used in circuit		supports wideband speech communication. It is being used in circuit
	switched mobile telephony services and new multimedia telephony		switched mobile telephony services and new multimedia telephony
	services over IP/IMS and 4G/VoLTE, specified by GSMA as voice IMS		services over IP/IMS like for voice over LTE as specified by GSMA in
	profile for VoLTE in [IR.92]. More detailed information on AMR-WB		[IR.92]. More detailed information on AMR-WB can be found in
	can be found in [IR.36]. [IR.36] includes references for all 3GPP		[IR.36]. References for AMR-WB related specifications including
	AMR-WB related specifications including detailed codec description		detailed codec description and Source code are in [TS26.171],
	and Source code.		[TS26.173], [TS26.190], [TS26.204].
	4.1.2. WebRTC relevant use case for AMR-WB		4.1.2. WebRTC relevant use case for AMR-WB
	The market of voice personal communication is driven by mobile		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 devices
	models and more than 130 HD mobile networks in 80 countries with a		models and 145 HD mobile networks in 85 countries with a customer
	customer base of more than 300 millions. A high number of calls are		base of more than 450 millions. A high number of calls are
	consequently likely to occur between WebRTC clients and mobile 3GPP		consequently likely to occur between WebRTC clients and mobile 3GPP
	terminals. The use of AMR-WB by WebRTC clients would consequently		terminals. The use of AMR-WB by WebRTC clients would consequently
	allow transcoding free interoperation with all mobile 3GPP wideband		allow transcoding free interoperation with all mobile 3GPP wideband
	terminal. Besides, WebRTC clients running on mobile terminals		terminals. Besides, WebRTC clients running on mobile terminals
	(smartphones) may reuse the AMR-WB codec already implemented on these		(smartphones) may reuse the AMR-WB codec already implemented on these
	devices.		devices.
	4.1.3. Guidelines for AMR-WB usage and implementation with WebRTC		4.1.3. Guidelines for AMR-WB usage and implementation with WebRTC
	Guidelines for implementing and using AMR-WB and ensuring		The payload format to be used for AMR-WB is described in [RFC4867]
	interoperability with 3GPP mobile services can be found in		with bandwidth efficient format and one speech frame encapsulated in
	[TS26.114]. In order to ensure interoperability with 4G/VoLTE as		each RTP packets. Further guidelines for implementing and using AMR-
	specified by GSMA, the more specific IMS profile for voice derived		WB and ensuring interoperability with 3GPP mobile services can be
	from [TS26.114] should be considered in [IR.92]. In order to		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		maximize the possibility of successful call establishment for WebRTC
	client offering AMR-WB it is important that the WebRTC client:		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		o Offer AMR in addition to AMR-WB with AMR-WB, being a wideband
	codec, listed first as preferred payload type with respect to		codec, listed first as preferred payload type with respect to
	other narrow band codecs (AMR, G.711...)and with Bandwidth		other narrow band codecs (AMR, G.711...)and with Bandwidth
	Efficient payload format preferred.		Efficient payload format preferred.
	o Be capable of operating AMR-WB with any subset of the nine codec		o Be capable of operating AMR-WB with any subset of the nine codec
	modes and source controlled rate operation. Offer at least one		modes and source controlled rate operation. Offer at least one
	AMR-WB configuration with parameter settings as defined in		AMR-WB configuration with parameter settings as defined in
	Table 6.1 of [TS 26.114]. In order to maximize the		Table 6.1 of [TS26.114]. In order to maximize the
	interoperability and quality this offer does not restrict the		interoperability and quality this offer does not restrict the
	codec modes offered. Restrictions in the use of codec modes may		codec modes offered. Restrictions in the use of codec modes may
	be included in the answer.		be included in the answer.
	4.2. AMR		4.2. AMR
	4.2.1. AMR General description		4.2.1. AMR General description
	Adaptive Multi-Rate (AMR) is a 3GPP defined speech codec that is		Adaptive Multi-Rate (AMR) is a 3GPP defined speech codec that is
	mandatory to implement in any 3GPP terminal that supports voice		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		include both mobile phone calls using GSM and 3G cellular systems as
	well as multimedia telephony services over IP/IMS and 4G/VoLTE, such		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		impacts listed above, support of AMR can avoid degrading the high
	efficiency over mobile radio access.		efficiency over mobile radio access.References for AMR related
			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		4.2.2. WebRTC relevant use case for AMR
	A user of a WebRTC endpoint on a device integrating an AMR module		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		wants to communicate with another user that can only be reached on a
	mobile device that only supports AMR. Although more and more		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 is
	still a high number of legacy terminals supporting only AMR		still a high number of legacy terminals supporting only AMR
	(terminals with no wideband / HD Voice capabilities) are still used.		(terminals with no wideband / HD Voice capabilities) are still used.
	The use of AMR by WebRTC client would consequently allow transcoding		The use of AMR by WebRTC client would consequently allow transcoding
	free interoperation with all mobile 3GPP terminals. Besides, WebRTC		free interoperation with all mobile 3GPP terminals. Besides, WebRTC
	client running on mobile terminals (smartphones) may reuse the AMR		client running on mobile terminals (smartphones) may reuse the AMR
	codec already implemented on these devices.		codec already implemented on these devices.
	4.2.3. Guidelines for AMR usage and implementation with WebRTC		4.2.3. Guidelines for AMR usage and implementation with WebRTC
	Guidelines for implementing and using AMR with purpose to ensure		The payload format to be used for AMR is described in [RFC4867] with
	interoperability with 3GPP mobile services can be found in		bandwidth efficient format and one speech frame encapsulated in each
	[TS26.114]. In order to ensure interoperability with 4G/VoLTE as		RTP packets. Further guidelines for implementing and using AMR with
	specified by GSMA, the more specific IMS profile for voice derived		purpose to ensure interoperability with 3GPP mobile services can be
	from [TS26.114] should be considered in [IR.92]. In order to		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		maximize the possibility of successful call establishment for WebRTC
	client offering AMR, it is important that the WebRTC client:		client offering AMR, it is important that the WebRTC client:
	o Be capable of operating AMR with any subset of the eight codec		o Be capable of operating AMR with any subset of the eight codec
	modes and source controlled rate operation.		modes and source controlled rate operation.
	o Offer at least one configuration with parameter settings as		o Offer at least one configuration with parameter settings as
	defined in Table 6.1 and Table 6.2 of [TS26.114]. In order to		defined in Table 6.1 and Table 6.2 of [TS26.114]. In order to
	maximize the interoperability and quality this offer shall not		maximize the interoperability and quality this offer shall not
	restrict AMR codec modes offered. Restrictions in the use of		restrict AMR codec modes offered. Restrictions in the use of
	codec modes may be included in the answer.		codec modes may be included in the answer.
	4.3. G.722		4.3. G.722
	4.3.1. G.722 General description		4.3.1. G.722 General description
	G.722 is an ITU-T defined wideband speech codec. [G.722] was		G.722 [G.722] is an ITU-T defined wideband speech codec. G.722 was
	approved by ITU-T in 1988. It is a royalty free codec that is common		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		in a wide range of terminals and endpoints supporting wideband speech
	speech and requiring low complexity. The complexity of G.722 is		and requiring low complexity. The complexity of G.722 is estimated
	estimated to 10 MIPS [EN300175-8] which is 2.5 to 3 times lower than		to 10 MIPS [EN300175-8] which is 2.5 to 3 times lower than AMR-WB.
	AMR-WB. Especially, G.722 has been chosen by ETSI DECT as the		Especially, G.722 has been chosen by ETSI DECT as the mandatory
	mandatory wideband codec for New Generation DECT with purpose to		wideband codec for New Generation DECT with purpose to greatly
	greatly increase the voice quality by extending the bandwidth from		increase the voice quality by extending the bandwidth from narrow
	narrow band to wideband. G.722 is the wideband codec required for		band to wideband. G.722 is the wideband codec required for CAT-iq
	CAT-iq DECT certified terminal and the V2.0 of CAT-iq specifications		DECT certified terminals and the V2.0 of CAT-iq specifications have
	have been approved by GSMA as minimum requirements for HD voice logo		been approved by GSMA as minimum requirements for HD voice logo usage
	usage on "fixed" devices; i.e., broadband connections using the G.722		on "fixed" devices; i.e., broadband connections using the G.722
	codec.		codec.
	4.3.2. WebRTC relevant use case for G.722		4.3.2. WebRTC relevant use case for G.722
	G.722 is the wideband codec required for DECT CAT-iq terminals. The		G.722 is the wideband codec required for DECT CAT-iq terminals. The
	market for DECT cordeless phones including DECT chipset is more than		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 Millions per year and CAT-IQ is a registered trade make in 47
	countries worldwide. G.722 has also been specified by ETSI in		countries worldwide. G.722 has also been specified by ETSI in
	[TS181005] as mandatory wideband codec for IMS multimedia telephony		[TS181005] as mandatory wideband codec for IMS multimedia telephony
	communication service and supplementary services using fixed		communication service and supplementary services using fixed
	broadband access. The support of G.722 would consequently allow		broadband access. The support of G.722 would consequently allow
	transcoding free IP interoperation between WebRTC client and fixed		transcoding free IP interoperation between WebRTC client and fixed
	VoIP terminals including DECT / CAT-IQ terminals supporting G.722.		VoIP terminals including DECT / CAT-IQ terminals supporting G.722.
	Besides, WebRTC client running on fixed terminals implementing G.722		Besides, WebRTC client running on fixed terminals implementing G.722
	may reuse the G.722 codec already implemented on these devices.		may reuse the G.722 codec already implemented on these devices.
	4.3.3. Guidelines for G.722 usage and implementation		4.3.3. Guidelines for G.722 usage and implementation
	Guidelines for implementing and using G.722 with purpose to ensure		The payload format to be used for G.722 is defined in [RFC3551] with
	interoperability with Multimedia Telephony services overs IMS can be		each octet of the stream of octets produced by the codec to be octet-
	found in section 7 of [TS26.114]. Additional information of G.722		aligned in an RTP packet. The sampling frequency for G.722 is 16 kHz
	implementation in DECT can be found in [EN300175-8] and full codec		but the rtp clock rate is set to 8000Hz in SDP to stay backward
	description and C source code in [G.722].		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].
			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		4.4. Other codecs
	Other interoperability use cases may justify the use of other codecs.		Other interoperability use cases may justify the use of other codecs.
	5. Security Considerations		5. Security Considerations
			Security considerations for WebRTC Audio Codec and Processing
			Requirements can be found in [I-D.ietf-rtcweb-audio]. Implementors
			making use of the additional codecs considered in this document are
			advised to also report more specifically to the "Security
			Considerations" sections of [RFC4867] (for AMR and AMR-WB) and
			[RFC3551].
	6. IANA Considerations		6. IANA Considerations
	None.		None.
	7. Acknowledgements		7. Acknowledgements
	None.		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.
	8. References		8. References
	8.1. Normative references		8.1. Normative references
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[G.722] ITU, "Recommendation ITU-T G.722 (2012): 7 kHz audio-
	Requirement Levels", BCP 14, RFC 2119,		coding within 64 kbit/s", 2012-09.
	DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		[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.
			[IR.92] GSMA, "IMS Profile for Voice and SMS V9.0", April 2015.
			[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
			Video Conferences with Minimal Control", STD 65, RFC 3551,
			DOI 10.17487/RFC3551, July 2003,
			<http://www.rfc-editor.org/info/rfc3551>.
			[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie,
			"RTP Payload Format and File Storage Format for the
			Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband
			(AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867,
			April 2007, <http://www.rfc-editor.org/info/rfc4867>.
			[TS26.071]
			3GPP, "3GPP TS 26.071 v12.0.0: Recommendation ITU-T G.722
			(2012): "Mandatory Speech Codec speech processing
			functions; AMR Speech CODEC; General description".",
			2014-09.
			[TS26.073]
			3GPP, "3GPP TS 26.073 v12.0.0: ANSI C code for the
			Adaptive Multi Rate (AMR) speech codec", 2014-09.
			[TS26.090]
			3GPP, "3GPP TS 26.090 v12.0.0: Mandatory Speech Codec
			speech processing functions; Adaptive Multi-Rate (AMR)
			speech codec; Transcoding functions.", 2014-09.
			[TS26.104]
			3GPP, "3GPP TS 26.104 v12.0.0: ANSI C code for the
			floating-point Adaptive Multi Rate (AMR) speech codec.",
			2014-09.
			[TS26.114]
			3GPP, "IP Multimedia Subsystem (IMS); Multimedia
			telephony; Media handling and interaction V13.0.0", June
			2015.
			[TS26.171]
			3GPP, "3GPP TS 26.071 v12.0.0: Recommendation ITU-T G.722
			(2012): "Speech codec speech processing functions;
			Adaptive Multi-Rate - Wideband (AMR-WB) speech codec;
			General description".", 2014-09.
			[TS26.173]
			3GPP, "3GPP TS 26.073 v12.1.0: ANSI-C code for the
			Adaptive Multi-Rate - Wideband (AMR-WB) speech codec.",
			2015-03.
			[TS26.190]
			3GPP, "3GPP TS 26.090 v12.0.0: Speech codec speech
			processing functions; Adaptive Multi-Rate - Wideband (AMR-
			WB) speech codec; Transcoding functions.", 2014-09.
			[TS26.204]
			3GPP, "3GPP TS 26.104 v12.1.0: Speech codec speech
			processing functions; Adaptive Multi-Rate - Wideband (AMR-
			WB) speech codec; ANSI-C code.", 2015-03.
	8.2. Informative references		8.2. Informative references
			[EN300175-1]
			ETSI, "ETSI EN 300 175-1, Digital Enhanced Cordless
			Telecommunications (DECT); Common Interface (CI); Part 1:
			Overview v2.5.1", 2009.
	[EN300175-8]		[EN300175-8]
	ETSI, "ETSI EN 300 175-8, v2.5.1: "Digital Enhanced		ETSI, "ETSI EN 300 175-8, v2.5.1: Digital Enhanced
	Cordless Telecommunications (DECT); Common Interface (CI);		Cordless Telecommunications (DECT); Common Interface (CI);
	Part 8: Speech and audio coding and transmission".", 2009.		Part 8: Speech and audio coding and transmission.", 2009.
	[G.722] ITU, "Recommendation ITU-T G.722 (2012): "7 kHz audio-
	coding within 64 kbit/s".", 2012.
	[I-D.ietf-rtcweb-audio]		[G.711] ITU, "Recommendation ITU-T G.711 (2012): Pulse code
	Valin, J. and C. Bran, "WebRTC Audio Codec and Processing		modulation (PCM) of voice frequencies", 1988-11.
	Requirements", draft-ietf-rtcweb-audio-08 (work in
	progress), April 2015.
	[I-D.ietf-rtcweb-overview]		[I-D.ietf-rtcweb-overview]
	Alvestrand, H., "Overview: Real Time Protocols for		Alvestrand, H., "Overview: Real Time Protocols for
	Browser-based Applications", draft-ietf-rtcweb-overview-14		Browser-based Applications", draft-ietf-rtcweb-overview-14
	(work in progress), June 2015.		(work in progress), June 2015.
	[IR.36] GSMA, "Adaptive Multirate Wide Band V3.0", September 2014.		[IR.36] GSMA, "Adaptive Multirate Wide Band V3.0", September 2014.
	[IR.92] GSMA, "IMS Profile for Voice and SMS V9.0", April 2015.
	[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the		[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the
	Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,		Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,
	September 2012, <http://www.rfc-editor.org/info/rfc6716>.		September 2012, <http://www.rfc-editor.org/info/rfc6716>.
	[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-		[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
	Time Communication Use Cases and Requirements", RFC 7478,		Time Communication Use Cases and Requirements", RFC 7478,
	DOI 10.17487/RFC7478, March 2015,		DOI 10.17487/RFC7478, March 2015,
	<http://www.rfc-editor.org/info/rfc7478>.		<http://www.rfc-editor.org/info/rfc7478>.
	[TS181005]		[TS181005]
	ETSI, "Telecommunications and Internet converged Services		ETSI, "Telecommunications and Internet converged Services
	and Protocols for Advanced Networking (TISPAN); Service		and Protocols for Advanced Networking (TISPAN); Service
	and Capability Requirements V3.3.1 (2009-12)", 2009.		and Capability Requirements V3.3.1 (2009-12)", 2009.
	[TS26.114]		[TS23.002]
	3GPP, "IP Multimedia Subsystem (IMS); Multimedia		3GPP, "3GPP TS 23.002 v13.3.0: Network architecture",
	telephony; Media handling and interaction V13.0.0", June		2015-09.
	2015.
	Authors' Addresses		Author's Address
	Stephane Proust		Stephane Proust
	Orange		Orange
	2, avenue Pierre Marzin		2, avenue Pierre Marzin
	Lannion 22307		Lannion 22307
	France		France
	Email: stephane.proust@orange.com		Email: stephane.proust@orange.com
	Espen Berger
	Cisco
	Email: espeberg@cisco.com
	Bernhard Feiten
	Deutsche Telekom
	Email: Bernhard.Feiten@telekom.de
	Bo Burman
	Ericsson
	Email: bo.burman@ericsson.com
	Kalyani Bogineni
	Verizon Wireless
	Email: Kalyani.Bogineni@VerizonWireless.com
	Miao Lei
	Huawei
	Email: lei.miao@huawei.com
	Enrico Marocco
	Telecom Italia
	Email: enrico.marocco@telecomitalia.it
End of changes. 41 change blocks.
	133 lines changed or deleted		225 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/