draft-ietf-rtcweb-audio-codecs-for-interop-04.txt		draft-ietf-rtcweb-audio-codecs-for-interop-05.txt
	Network Working Group S. Proust		Network Working Group S. Proust, Ed.
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Informational December 11, 2015		Intended status: Informational February 10, 2016
	Expires: June 13, 2016		Expires: August 13, 2016
	Additional WebRTC audio codecs for interoperability.		Additional WebRTC audio codecs for interoperability.
	draft-ietf-rtcweb-audio-codecs-for-interop-04		draft-ietf-rtcweb-audio-codecs-for-interop-05
	Abstract		Abstract
	To ensure a baseline level of interoperability between WebRTC		To ensure a baseline level of interoperability between WebRTC
	clients, a minimum set of required codecs is specified. However, to		endpoints, a minimum set of required codecs is specified. However,
	maximize the possibility to establish the session without the need		to maximize the possibility to establish the session without the need
	for audio transcoding, it is also recommended to include in the offer		for audio transcoding, it is also recommended to include in the offer
	other suitable audio codecs that are available to the browser.		other suitable audio codecs that are available to the 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 endpoints 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 June 13, 2016.		This Internet-Draft will expire on August 13, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	skipping to change at page 2, line 24		skipping to change at page 2, line 24
	4. Additional suitable codecs for WebRTC . . . . . . . . . . . . 5		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 . . . . 8		4.3.3. Guidelines for G.722 usage and implementation . . . . 8
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Normative references . . . . . . . . . . . . . . . . . . 9		8.1. Normative references . . . . . . . . . . . . . . . . . . 9
	8.2. Informative references . . . . . . . . . . . . . . . . . 10		8.2. Informative references . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11		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 beyond those that
	available to the browser. This document provides some guidelines on		are mandatory to implement. This document provides some guidelines
	the suitable codecs to be considered for WebRTC clients to address		on the suitable codecs to be considered for WebRTC endpoints to
	the most relevant interoperability use cases.		address 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 endpoints for
	interoperability with other non-WebRTC endpoints and non-WebRTC based		which interoperability with other non-WebRTC endpoints and non-WebRTC
	services is relevant as described in Section 4.1.2, Section 4.2.2,		based services is relevant as described in Section 4.1.2,
	Section 4.3.2. Other use cases may justify offering other additional		Section 4.2.2, Section 4.3.2. Other use cases may justify offering
	codecs to avoid transcoding.		other additional codecs to avoid transcoding.
	2. Definition and abbreviations		2. Definition and abbreviations
	o Legacy networks: In this document, legacy networks encompass the		o Legacy networks: In this document, legacy networks encompass the
	conversational networks that are already deployed like the PSTN,		conversational networks that are already deployed like the PSTN,
	the PLMN, the IP/IMS networks offering VoIP services, including		the PLMN, the IP/IMS networks offering VoIP services, including
	3GPP "4G" Evolved Packet System[TS23.002] supporting voice over		3GPP "4G" Evolved Packet System[TS23.002] supporting voice over
	LTE radio access (VoLTE) [IR.92].		LTE radio access (VoLTE) [IR.92].
			o WebRTC endpoint: a WebRTC endpoint can be a WebRTC browser or a
			WebRTC non browser (also called "WebRTC device" or "WebRTC native
			application") as defined in [I-D.ietf-rtcweb-overview]
	o AMR: Adaptive Multi-Rate.		o AMR: Adaptive Multi-Rate.
	o AMR-WB: Adaptive Multi-Rate WideBand.		o AMR-WB: Adaptive Multi-Rate WideBand.
	o CAT-iq: Cordless Advanced Technology-internet and quality.		o CAT-iq: Cordless Advanced Technology-internet and quality.
	o DECT: Digital Enhanced Cordless Telecommunications		o DECT: Digital Enhanced Cordless Telecommunications
	o IMS: IP Multimedia Subsystem		o IMS: IP Multimedia Subsystem
	skipping to change at page 3, line 43		skipping to change at page 3, line 44
	o MOS: Mean Opinion Score		o MOS: Mean Opinion Score
	o PSTN:Public Switched Telephone Network		o PSTN:Public Switched Telephone Network
	o PLMN: Public Land Mobile Network		o PLMN: Public Land Mobile Network
	o VoLTE: Voice Over LTE		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 endpoints
	guarantee codec interoperability (without transcoding) at state of		can guarantee codec interoperability (without transcoding) at state
	the art voice quality (better than narrow band "PSTN" quality)		of the art voice quality (better than narrow band "PSTN" quality)
	between WebRTC clients. The WebRTC technology is also expected to be		between WebRTC endpoints. The WebRTC technology is also expected to
	used to communicate with other types of clients using other		be used to communicate with other types of endpoints using other
	technologies. It can be used for instance as an access technology to		technologies. It can be used for instance as an access technology to
	VoLTE services (Voice over LTE as specified in [IR.92]) 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 Circuit Switched voice over 3GPP 2G/3G mobile networks		like mobile Circuit Switched voice over 3GPP 2G/3G mobile networks
	[TS23.002] or DECT based VoIP telephony [EN300175-1]. Consequently,		[TS23.002] or DECT based VoIP telephony [EN300175-1]. Consequently,
	a significant number of calls are likely to occur between terminals		a significant number of calls are likely to occur between terminals
	supporting WebRTC clients and other terminals like mobile handsets,		supporting WebRTC endpoints and other terminals like mobile handsets,
	fixed VoIP terminals, DECT terminals that do not support WebRTC		fixed VoIP terminals, DECT terminals that do not support WebRTC
	clients nor implement OPUS. As a consequence, these calls are likely		endpoints nor implement OPUS. As a consequence, these calls are
	to be either of low narrow band PSTN quality using G.711 [G.711] at		likely to be either of low narrow band PSTN quality using G.711
	both ends or affected by transcoding operations. The drawback of		[G.711] at both ends or affected by transcoding operations. The
	such transcoding operations are listed below:		drawback of such transcoding operations are listed 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 codec (Section 4.1) at 12.65 kbit/s and in		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		the same range for other wideband transcoding cases. It should be
	stressed that if G.711 is used as a fall back codec for		stressed that if G.711 is used as a fall back codec for
	interoperation, wideband voice quality will be lost. Such		interoperation, wideband voice quality will be lost. Such
	bandwidth reduction effect down to narrow band clearly degrades		bandwidth reduction effect down to narrow band clearly degrades
	the user perceived quality of service leading to shorter and less		the user perceived quality of service leading to shorter and less
	skipping to change at page 5, line 32		skipping to change at page 5, line 34
	switched mobile telephony services and new multimedia telephony		switched mobile telephony services and new multimedia telephony
	services over IP/IMS. It is especially used for voice over LTE as		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		specified by GSMA in [IR.92]. More detailed information on AMR-WB
	can be found in [IR.36]. References for AMR-WB related		can be found in [IR.36]. References for AMR-WB related
	specifications including detailed codec description and source code		specifications including detailed codec description and source code
	are in [TS26.171], [TS26.173], [TS26.190], [TS26.204].		are in [TS26.171], [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 personal voice 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 device		terminals. AMR-WB is now very widely implemented in devices and
	models and 145 HD mobile networks in 85 countries with a customer		networks offering "HD Voice" A high number of calls are consequently
	base of more than 450 million. A high number of calls are		likely to occur between WebRTC endpoints and mobile 3GPP terminals
	consequently likely to occur between WebRTC clients and mobile 3GPP		offering AMR-WB. The use of AMR-WB by WebRTC endpoints would
	terminals. The use of AMR-WB by WebRTC clients would consequently		consequently allow transcoding free interoperation with all mobile
	allow transcoding free interoperation with all mobile 3GPP wideband		3GPP wideband terminals. Besides, WebRTC endpoints running on mobile
	terminals. Besides, WebRTC clients running on mobile terminals		terminals (smartphones) may reuse the AMR-WB codec already
	(smartphones) may reuse the AMR-WB codec already implemented on these		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
	The payload format to be used for AMR-WB is described in [RFC4867]		The payload format to be used for AMR-WB is described in [RFC4867]
	with bandwidth efficient format and one speech frame encapsulated in		with bandwidth efficient format and one speech frame encapsulated in
	each RTP packets. Further guidelines for implementing and using AMR-		each RTP packets. Further guidelines for implementing and using AMR-
	WB and ensuring interoperability with 3GPP mobile services can be		WB and ensuring interoperability with 3GPP mobile services can be
	found in [TS26.114]. In order to ensure interoperability with 4G/		found in [TS26.114]. In order to ensure interoperability with 4G/
	VoLTE as specified by GSMA, the more specific IMS profile for voice		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		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:		endpoints offering AMR-WB it is important that the WebRTC endpoints:
	o Offer AMR in addition to AMR-WB with AMR-WB listed first (AMR-WB		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		being a wideband codec) 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 [TS26.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. This include both mobile phone calls using GSM and 3G
	include both mobile phone calls using GSM and 3G cellular systems as		cellular systems as well as multimedia telephony services over IP/IMS
	well as multimedia telephony services over IP/IMS and 4G/VoLTE, such		and 4G/VoLTE, such as, GSMA voice IMS profile for VoLTE in [IR.92].
	as, GSMA voice IMS profile for VoLTE in [IR.92]. In addition to		In addition to impacts listed above, support of AMR can avoid
	impacts listed above, support of AMR can avoid degrading the high		degrading the high efficiency over mobile radio access.References for
	efficiency over mobile radio access.References for AMR related		AMR related specifications including detailed codec description and
	specifications including detailed codec description and source code		source code are in [TS26.071], [TS26.073], [TS26.090], [TS26.104].
	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 are		terminal devices are now "HD voice" and support AMR-WB; there are
	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) that are still		(terminals with no wideband / HD Voice capabilities) that are still
	in use. The use of AMR by WebRTC client would consequently allow		in use. The use of AMR by WebRTC endpoints would consequently allow
	transcoding free interoperation with all mobile 3GPP terminals.		transcoding free interoperation with all mobile 3GPP terminals.
	Besides, WebRTC client running on mobile terminals (smartphones) may		Besides, WebRTC endpoints running on mobile terminals (smartphones)
	reuse the AMR codec already implemented on these devices.		may reuse the AMR 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
	The payload format to be used for AMR is described in [RFC4867] with		The payload format to be used for AMR is described in [RFC4867] with
	bandwidth efficient format and one speech frame encapsulated in each		bandwidth efficient format and one speech frame encapsulated in each
	RTP packets. Further guidelines for implementing and using AMR with		RTP packets. Further guidelines for implementing and using AMR with
	purpose to ensure interoperability with 3GPP mobile services can be		purpose to ensure interoperability with 3GPP mobile services can be
	found in [TS26.114]. In order to ensure interoperability with 4G/		found in [TS26.114]. In order to ensure interoperability with 4G/
	VoLTE as specified by GSMA, the more specific IMS profile for voice		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		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:		endpoints offering AMR, it is important that the WebRTC endpoints:
	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.
	skipping to change at page 7, line 38		skipping to change at page 7, line 46
	wideband codec for New Generation DECT with purpose to greatly		wideband codec for New Generation DECT with purpose to greatly
	increase the voice quality by extending the bandwidth from narrow		increase the voice quality by extending the bandwidth from narrow
	band to wideband. G.722 is the wideband codec required for CAT-iq		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		DECT certified terminals and the V2.0 of CAT-iq specifications have
	been approved by GSMA as minimum requirements for HD voice logo usage		been approved by GSMA as minimum requirements for HD voice logo 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. DECT
	market for DECT cordless phones including DECT chipset is more than		cordeless phones are still widely used to offer short range wireless
	150 million per year and CAT-IQ is a registered trade make in 47		connection to PSTN or VoIP services. G.722 has also been specified
	countries worldwide. G.722 has also been specified by ETSI in		by ETSI in [TS181005] as mandatory wideband codec for IMS multimedia
	[TS181005] as mandatory wideband codec for IMS multimedia telephony		telephony communication service and supplementary services using
	communication service and supplementary services using fixed		fixed broadband access. The support of G.722 would consequently
	broadband access. The support of G.722 would consequently allow		allow transcoding free IP interoperation between WebRTC endpoints and
	transcoding free IP interoperation between WebRTC client and fixed		fixed VoIP terminals including DECT / CAT-IQ terminals supporting
	VoIP terminals including DECT / CAT-IQ terminals supporting G.722.		G.722. Besides, WebRTC endpoints running on fixed terminals
	Besides, WebRTC client running on fixed terminals implementing G.722		implementing G.722 may reuse the G.722 codec already implemented on
	may reuse the G.722 codec already implemented on these devices.		these devices.
	4.3.3. Guidelines for G.722 usage and implementation		4.3.3. Guidelines for G.722 usage and implementation
	The payload format to be used for G.722 is defined in [RFC3551] with		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-		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		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		but the rtp clock rate is set to 8000Hz in SDP to stay backward
	compatible with an erroneous definition in the original version of		compatible with an erroneous definition in the original version of
	the RTP A/V profile. Further guidelines for implementing and using		the RTP A/V profile. Further guidelines for implementing and using
	G.722 with purpose to ensure interoperability with multimedia		G.722 with purpose to ensure interoperability with multimedia
	telephony services over IMS can be found in section 7 of [TS26.114].		telephony services over IMS can be found in section 7 of [TS26.114].
	Additional information of G.722 implementation in DECT can be found		Additional information of G.722 implementation in DECT can be found
	in [EN300175-8] and full codec description and C source code in		in [EN300175-8] and full codec description and C source code in
	[G.722].		[G.722].
	4.4. 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		Security considerations for WebRTC Audio Codec and Processing
	Requirements can be found in [I-D.ietf-rtcweb-audio]. Implementors		Requirements can be found in [I-D.ietf-rtcweb-audio]. Implementors
	making use of the additional codecs considered in this document are		making use of the additional codecs considered in this document are
	advised to also report more specifically to the "Security		advised to also refer more specifically to the "Security
	Considerations" sections of [RFC4867] (for AMR and AMR-WB) and		Considerations" sections of [RFC4867] (for AMR and AMR-WB) and
	[RFC3551].		[RFC3551].
	6. IANA Considerations		6. IANA Considerations
	None.		None.
	7. Acknowledgements		7. Acknowledgements
	The authors of this document are		The authors of this document are
	skipping to change at page 11, line 7		skipping to change at page 11, line 7
	[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.711] ITU, "Recommendation ITU-T G.711 (2012): Pulse code		[G.711] ITU, "Recommendation ITU-T G.711 (2012): Pulse code
	modulation (PCM) of voice frequencies", 1988-11.		modulation (PCM) of voice frequencies", 1988-11.
	[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-15
	(work in progress), June 2015.		(work in progress), January 2016.
	[IR.36] GSMA, "Adaptive Multirate Wide Band V3.0", September 2014.		[IR.36] GSMA, "Adaptive Multirate Wide Band V3.0", September 2014.
	[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>.
	[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.
	[TS23.002]		[TS23.002]
	3GPP, "3GPP TS 23.002 v13.3.0: Network architecture",		3GPP, "3GPP TS 23.002 v13.3.0: Network architecture",
	2015-09.		2015-09.
	Author's Address		Author's Address
	Stephane Proust		Stephane Proust (editor)
	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
End of changes. 27 change blocks.
	72 lines changed or deleted		68 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/