draft-ietf-rtcweb-audio-codecs-for-interop-00.txt   draft-ietf-rtcweb-audio-codecs-for-interop-01.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 E. Berger
Expires: April 2, 2015 Cisco Expires: July 20, 2015 Cisco
B. Feiten B. Feiten
Deutsche Telekom Deutsche Telekom
B. Burman B. Burman
Ericsson Ericsson
K. Bogineni K. Bogineni
Verizon Wireless Verizon Wireless
M. Lei M. Lei
Huawei Huawei
E. Marocco E. Marocco
Telecom Italia Telecom Italia
September 29, 2014 January 16, 2015
Additional WebRTC audio codecs for interoperability with legacy Additional WebRTC audio codecs for interoperability.
networks. draft-ietf-rtcweb-audio-codecs-for-interop-01
draft-ietf-rtcweb-audio-codecs-for-interop-00
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, [I-D.ietf-rtcweb-audio] requires a minimum set of codecs.
However, to maximize the possibility to establish the session without However, to maximize the possibility to establish the session without
the need for audio transcoding, it is also recommended to include in the need for audio transcoding, it is also recommended to include in
the offer other suitable audio codecs that are available to the the offer other suitable audio codecs that are available to the
browser. browser.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 April 2, 2015. This Internet-Draft will expire on July 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Rationale for additional WebRTC codecs . . . . . . . . . . . 3
4. Rationale for additional WebRTC codecs . . . . . . . . . . . 3 4. Additional suitable codecs for WebRTC . . . . . . . . . . . . 4
5. Additional suitable codecs for WebRTC . . . . . . . . . . . . 5 4.1. AMR-WB . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. AMR-WB . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. AMR-WB General description . . . . . . . . . . . . . 5
5.1.1. AMR-WB General description . . . . . . . . . . . . . 5 4.1.2. WebRTC relevant use case for AMR-WB . . . . . . . . . 5
5.1.2. WebRTC relevant use case for AMR-WB . . . . . . . . . 5 4.1.3. Guidelines for AMR-WB usage and implementation with
5.1.3. Guidelines for AMR-WB usage and implementation with
WebRTC . . . . . . . . . . . . . . . . . . . . . . . 5 WebRTC . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2.1. AMR General description . . . . . . . . . . . . . . . 6 4.2.1. AMR General description . . . . . . . . . . . . . . . 6
5.2.2. WebRTC relevant use case for AMR . . . . . . . . . . 6 4.2.2. WebRTC relevant use case for AMR . . . . . . . . . . 6
5.2.3. Guidelines for AMR usage and implementation with 4.2.3. Guidelines for AMR usage and implementation with
WebRTC . . . . . . . . . . . . . . . . . . . . . . . 6 WebRTC . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3.1. G.722 General description . . . . . . . . . . . . . . 6 4.3.1. G.722 General description . . . . . . . . . . . . . . 7
5.3.2. WebRTC relevant use case for G.722 . . . . . . . . . 7 4.3.2. WebRTC relevant use case for G.722 . . . . . . . . . 7
5.3.3. Guidelines for G.722 usage and implementation . . . . 7 4.3.3. Guidelines for G.722 usage and implementation . . . . 7
5.4. [Codec x] (tbd) . . . . . . . . . . . . . . . . . . . . . 7 4.4. Other codecs . . . . . . . . . . . . . . . . . . . . . . 7
5.4.1. [Codec X] General description . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.4.2. WebRTC relevant use case for [Codec X] . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.4.3. Guidelines for [Codec X] usage and implementation 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
with WebRTC . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8.1. Normative references . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8.2. Informative references . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative references . . . . . . . . . . . . . . . . . . 8
9.2. Informative references . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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]
skipping to change at page 3, line 29 skipping to change at page 3, line 27
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 end points and non WebRTC
based services is relevant as described in sections 5.1.2, 5.2.2 and 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 5.3.2. Other use cases may justify offering other additional codecs
to avoid transcodings. It is the intent of this document to to avoid transcodings. It is the intent of this document to
inventory and document any other additional interoperability use inventory and document any other additional interoperability use
cases and codecs if needed. cases and codecs if needed.
2. Terminology 2. Definitions
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
[RFC2119].
3. Definitions
Legacy networks: In this draft, legacy networks encompass the Legacy networks: In this draft, legacy networks encompass the
conversational networks that are already deployed like the PSTN, the conversational networks that are already deployed like the PSTN, the
PLMN, the IMS, H.323 networks. PLMN, the IMS, H.323 networks.
4. 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 the codec interoperability (without transcoding) at the
state of the art voice quality (better than narrow band "PSTN" state of the art voice quality (better than narrow band "PSTN"
quality) only between WebRTC clients. The WebRTC technology is quality) between WebRTC clients. The WebRTC technology is however
however expected to have more extended usage to communicate with expected to be used to communicate with other types of clients using
other types of clients. It can be used for instance as an access other technologies. It can be used for instance as an access
technology to 3GPP IMS services or to interoperate with fixed or technology to 3GPP IMS services (e.g. VoLTE, ViLTE) or to
mobile VoIP legacy HD voice service. Consequently, a significant interoperate with fixed or mobile Circuit Switched or VoIP services
number of calls are likely to occur between terminals supporting like mobile 3GPP 3G/2G Circuit Switched voice or DECT based VoIP
WebRTC clients and other terminals like mobile handsets, fixed VoIP telephony. Consequently, a significant number of calls are likely to
terminals, DECT terminals that do not support WebRTC clients nor occur between terminals supporting WebRTC clients and other terminals
implement OPUS. As a consequence, these calls are likely to be like mobile handsets, fixed VoIP terminals, DECT terminals that do
either of low narrow band PSTN quality using G.711 at both ends or not support WebRTC clients nor implement OPUS. As a consequence,
affected by transcoding operations. The drawbacks of such these calls are likely to be either of low narrow band PSTN quality
transcoding operations are recalled below: using 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 at 12.65 kbit/s and in the same range for
other wideband transcoding cases. It should be stressed that if other wideband transcoding cases. It should be stressed that if
G.711 is used as a fall back codec for interoperation, wideband G.711 is used as a fall back codec for interoperation, wideband
voice quality will be lost. Such bandwidth reduction effect down voice quality will be lost. Such bandwidth reduction effect down
to narrow band clearly degrades the user perceived quality of to narrow band clearly degrades the user perceived quality of
service leading to shorter and less frequent calls. Such a switch service leading to shorter and less frequent calls. Such a switch
skipping to change at page 5, line 7 skipping to change at page 4, line 44
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 and be more costly than between
narrowband codecs. narrowband codecs.
5. 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 4. 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. 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.
5.1. AMR-WB 4.1. AMR-WB
5.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 and 4G/VoLTE, specified by GSMA as voice IMS
profile for VoLTE in [IR.92]. More detailed information on AMR-WB profile for VoLTE in [IR.92]. More detailed information on AMR-WB
can be found in [IR.36]. [IR.36] includes references for all 3GPP can be found in [IR.36]. [IR.36] includes references for all 3GPP
AMR-WB related specifications including detailed codec description AMR-WB related specifications including detailed codec description
and Source code. and Source code.
5.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 voice personal communication is driven by mobile
terminals. AMR-WB is now implemented in more than 200 devices models 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 and 85 HD mobile networks in 60 countries with a customer base of
more than 100 million. A high number of calls are consequently more than 100 million. A high number of calls are consequently
likely to occur between WebRTC clients and mobile 3GPP terminals. likely to occur between WebRTC clients and mobile 3GPP terminals.
The use of AMR-WB by WebRTC clients would consequently allow The use of AMR-WB by WebRTC clients would consequently allow
transcoding free interoperation with all mobile 3GPP wideband transcoding free interoperation with all mobile 3GPP wideband
terminal. Besides, WebRTC clients running on mobile terminals terminal. 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.
5.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 Guidelines for implementing and using AMR-WB and ensuring
interoperability with 3GPP mobile services can be found in interoperability with 3GPP mobile services can be found in
[TS26.114]. In order to ensure interoperability with 4G/VoLTE as [TS26.114]. In order to ensure interoperability with 4G/VoLTE as
specified by GSMA, the more specific IMS profile for voice derived specified by GSMA, the more specific IMS profile for voice derived
from [TS26.114] should be considered in [IR.92]. from [TS26.114] should be considered in [IR.92]. In order to
maximize the possibility of successful call establishment for WebRTC
client offering AMR-WB it is important that the WebRTC client:
5.2. AMR o 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.
5.2.1. AMR General description o Be capable of operating AMR-WB with any subset of the nine codec
modes and source controlled rate operation. Offer at least one
AMR-WB configuration with parameter settings as defined in
Table 6.1 of [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.
4.2. AMR
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.
5.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.
5.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 Guidelines for implementing and using AMR with purpose to ensure
interoperability with 3GPP mobile services can be found in interoperability with 3GPP mobile services can be found in
[TS26.114]. In order to ensure interoperability with 4G/VoLTE as [TS26.114]. In order to ensure interoperability with 4G/VoLTE as
specified by GSMA, the more specific IMS profile for voice derived specified by GSMA, the more specific IMS profile for voice derived
from [TS26.114] should be considered in [IR.92]. from [TS26.114] should be considered in [IR.92]. In order to
maximize the possibility of successful call establishment for WebRTC
client offering AMR, it is important that the WebRTC client:
5.3. G.722 o Be capable of operating AMR with any subset of the eight codec
modes and source controlled rate operation.
5.3.1. G.722 General description 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
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.
4.3. G.722
4.3.1. G.722 General description
G.722 is an ITU-T defined wideband speech codec. [G.722] was 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 end-points supporting wideband
speech and requiring low complexity. The complexity of G.722 is speech and requiring low complexity. The complexity of G.722 is
estimated to 10 MIPS [EN300175-8] which is 2.5 to 3 times lower than estimated to 10 MIPS [EN300175-8] which is 2.5 to 3 times lower than
AMR-WB. Especially, G.722 has been chosen by ETSI DECT as the AMR-WB. Especially, G.722 has been chosen by ETSI DECT as the
mandatory wideband codec for New Generation DECT with purpose to mandatory wideband codec for New Generation DECT with purpose to
greatly increase the voice quality by extending the bandwidth from greatly increase the voice quality by extending the bandwidth from
narrow band to wideband. G.722 is the wideband codec required for 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 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 have been approved by GSMA as minimum requirements for HD voice logo
usage on "fixed" devices; i.e., broadband connections using the G.722 usage on "fixed" devices; i.e., broadband connections using the G.722
codec. codec.
5.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 cordeless 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.
5.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 Guidelines for implementing and using G.722 with purpose to ensure
interoperability with Multimedia Telephony services overs IMS can be interoperability with Multimedia Telephony services overs IMS can be
found in section 7 of [TS26.114]. Additional information of G.722 found in section 7 of [TS26.114]. Additional information of G.722
implementation in DECT can be found in [EN300175-8] and full codec implementation in DECT can be found in [EN300175-8] and full codec
description and C source code in [G.722]. description and C source code in [G.722].
5.4. [Codec x] (tbd) 4.4. Other codecs
5.4.1. [Codec X] General description
tbd
5.4.2. WebRTC relevant use case for [Codec X]
tbd
5.4.3. Guidelines for [Codec X] usage and implementation with WebRTC
tbd 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.
6. Security Considerations 5. Security Considerations
7. IANA Considerations 6. IANA Considerations
None. None.
8. Acknowledgements 7. Acknowledgements
Thanks to Milan Patel for his review. Thanks to Milan Patel for his review.
9. References 8. References
9.1. Normative references 8.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative references 8.2. Informative references
[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- [G.722] ITU, "Recommendation ITU-T G.722 (2012): "7 kHz audio-
coding within 64 kbit/s".", 2012. coding within 64 kbit/s".", 2012.
[I-D.ietf-rtcweb-audio] [I-D.ietf-rtcweb-audio]
Valin, J. and C. Bran, "WebRTC Audio Codec and Processing Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
Requirements", draft-ietf-rtcweb-audio-06 (work in Requirements", draft-ietf-rtcweb-audio-07 (work in
progress), September 2014. progress), October 2014.
[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-11 Browser-based Applications", draft-ietf-rtcweb-overview-13
(work in progress), August 2014. (work in progress), November 2014.
[I-D.ietf-rtcweb-use-cases-and-requirements] [I-D.ietf-rtcweb-use-cases-and-requirements]
Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use-cases and Requirements", draft- Time Communication Use-cases and Requirements", draft-
ietf-rtcweb-use-cases-and-requirements-14 (work in ietf-rtcweb-use-cases-and-requirements-15 (work in
progress), February 2014. progress), December 2014.
[IR.36] GSMA, "Adaptive Multirate Wide Band", 2013. [IR.36] GSMA, "Adaptive Multirate Wide Band", 2013.
[IR.92] GSMA, "IMS Profile for Voice and SMS", 2013. [IR.92] GSMA, "IMS Profile for Voice and SMS", 2013.
[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, September 2012. Opus Audio Codec", RFC 6716, September 2012.
[TS181005] [TS181005]
ETSI, "Telecommunications and Internet converged Services ETSI, "Telecommunications and Internet converged Services
 End of changes. 38 change blocks. 
95 lines changed or deleted 104 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/