draft-ietf-rtcweb-audio-codecs-for-interop-03.txt   draft-ietf-rtcweb-audio-codecs-for-interop-04.txt 
Network Working Group S. Proust Network Working Group S. Proust
Internet-Draft Orange Internet-Draft Orange
Intended status: Informational December 2, 2015 Intended status: Informational December 11, 2015
Expires: June 4, 2016 Expires: June 13, 2016
Additional WebRTC audio codecs for interoperability. Additional WebRTC audio codecs for interoperability.
draft-ietf-rtcweb-audio-codecs-for-interop-03 draft-ietf-rtcweb-audio-codecs-for-interop-04
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 clients, a minimum set of required codecs is specified. However, 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 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
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 4, 2016. This Internet-Draft will expire on June 13, 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
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 . . . . . . . . . . . . . . . . . . . . . . . 7 WebRTC . . . . . . . . . . . . . . . . . . . . . . . 6
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 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
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 endpoints and non-WebRTC based interoperability with other non-WebRTC endpoints and non-WebRTC based
services is relevant as described in Section 4.1.2, Section 4.2.2, services is relevant as described in Section 4.1.2, Section 4.2.2,
Section 4.3.2. Other use cases may justify offering other additional Section 4.3.2. Other use cases may justify offering other additional
codecs to avoid transcodings. 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 AMR: Adaptive Multi-Rate. o AMR: Adaptive Multi-Rate.
skipping to change at page 4, line 11 skipping to change at page 4, line 11
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 clients 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 clients nor implement OPUS. As a consequence, these calls are likely
to be either of low narrow band PSTN quality using G.711 [G.711] at 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 both ends or affected by transcoding operations. The drawback of
such transcoding operations are recalled below: 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 4, line 43 skipping to change at page 4, line 43
quality below the 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 up to 1 second, much beyond the acceptable limit.
end latency.
o Additional costs in networks: transcoding places important o Additional cost in networks: transcoding places important
additional costs on network gateways mainly related to codec additional cost on network gateways mainly related to codec
implementation, codecs license, deployments, testing and implementation, codecs licenses, deployment, testing and
validation costs. It must be noted that transcoding of wideband validation cost. It must be noted that transcoding of wideband to
to wideband would require more CPU processing and be more costly wideband would require more CPU processing and be more costly than
than between narrowband codecs. transcoding 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 codecs with respect
respect to the general purpose described in Section 3. This list to the general purpose described in Section 3. This list reflects
reflects the current status of WebRTC foreseen use cases. It is not 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 like for voice over LTE as specified by GSMA in services over IP/IMS. It is especially used for voice over LTE as
[IR.92]. More detailed information on AMR-WB can be found in specified by GSMA in [IR.92]. More detailed information on AMR-WB
[IR.36]. References for AMR-WB related specifications including can be found in [IR.36]. References for AMR-WB related
detailed codec description and Source code are in [TS26.171], specifications including detailed codec description and source code
[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 devices terminals. AMR-WB is now implemented in several hundreds of device
models and 145 HD mobile networks in 85 countries with a customer models and 145 HD mobile networks in 85 countries with a customer
base of more than 450 millions. A high number of calls are base of more than 450 million. 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
terminals. 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
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: 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 listed first (AMR-WB
codec, listed first 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, 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.References for AMR related efficiency over mobile radio access.References for AMR related
specifications including detailed codec description and Source code specifications including detailed codec description and 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 is 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) are still used. (terminals with no wideband / HD Voice capabilities) that are still
The use of AMR by WebRTC client would consequently allow transcoding in use. The use of AMR by WebRTC client would consequently allow
free interoperation with all mobile 3GPP terminals. Besides, WebRTC transcoding free interoperation with all mobile 3GPP terminals.
client running on mobile terminals (smartphones) may reuse the AMR Besides, WebRTC client running on mobile terminals (smartphones) may
codec already implemented on these devices. 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
skipping to change at page 7, line 48 skipping to change at page 7, line 40
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. The
market for DECT cordless 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 million 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
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 overs 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 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
skipping to change at page 8, line 42 skipping to change at page 8, line 38
advised to also report more specifically to the "Security advised to also report 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
Special thanks to Espen Berger, Bernhard Feiten, Bo Burman, Kalyani The authors of this document are
Bogineni, Miao Lei, Enrico Marocco, who co-authored the initial
document. Thanks, as well, to Magnus Westerlund and Barry Dingle who o Stephane Proust, Orange, stephane.proust@orange.com ,
carefully reviewed the document and helped to improve it.
o Espen Berger, Cisco, espeberg@cisco.com ,
o Bernhard Feiten, Deutsche Telekom, Bernhard.Feiten@telekom.de ,
o Bo Burman, Ericsson, bo.burman@ericsson.com ,
o Kalyani Bogineni, Verizon Wireless,
Kalyani.Bogineni@VerizonWireless.com ,
o Mia Lei, Huawei, lei.miao@huawei.com ,
o Enrico Marocco,Telecom Italia, enrico.marocco@telecomitalia.it ,
though only the editor is listed on the front page.
The authors would like to thank Magnus Westerlund, Barry Dingle and
Sanjay Mishra who carefully reviewed the document and helped to
improve it.
8. References 8. References
8.1. Normative references 8.1. Normative references
[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-09. coding within 64 kbit/s", 2012-09.
[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-09 (work in Requirements", draft-ietf-rtcweb-audio-09 (work in
progress), November 2015. progress), November 2015.
skipping to change at page 11, line 5 skipping to change at page 11, line 16
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.
[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-
Time Communication Use Cases and Requirements", RFC 7478,
DOI 10.17487/RFC7478, March 2015,
<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.
[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
 End of changes. 24 change blocks. 
51 lines changed or deleted 63 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/