draft-ietf-rtcweb-audio-codecs-for-interop-01.txt   draft-ietf-rtcweb-audio-codecs-for-interop-02.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: July 20, 2015 Cisco Expires: February 8, 2016 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
January 16, 2015 August 7, 2015
Additional WebRTC audio codecs for interoperability. Additional WebRTC audio codecs for interoperability.
draft-ietf-rtcweb-audio-codecs-for-interop-01 draft-ietf-rtcweb-audio-codecs-for-interop-02
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 July 20, 2015. This Internet-Draft will expire on February 8, 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 4, line 18 skipping to change at page 4, line 18
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
to G.711 is less than desirable or acceptable choice for to G.711 is less than desirable or acceptable choice for
customers. If transcoding is performed between OPUS and any other customers. If transcoding is performed between OPUS and any other
wideband codec, wideband communication could be maintained but wideband codec, wideband communication could be maintained but
with degraded quality (MOS scores of transcoding between AMR-WB with degraded quality (MOS scores of transcoding between AMR-WB
12.65kbit/s and OPUS at 16 kbit/s in both directions are 12.65 kbit/s and OPUS at 16 kbit/s in both directions are
significantly lower than those of AMR-WB at 12.65kbit/s or OPUS at significantly lower than those of AMR-WB at 12.65 kbit/s or OPUS
16 kbit/s). Furthermore, in degraded conditions, the addition of at 16 kbit/s). Furthermore, in degraded conditions, the addition
defects, like audio artifacts due to packet losses, and the audio of defects, like audio artifacts due to packet losses, and the
effects resulting from the cascading of different packet loss audio effects resulting from the cascading of different packet
recovery algorithms may result in a quality below the acceptable loss recovery algorithms may result in a quality below the
limit for the customers. acceptable limit for the customers.
o Degraded user experience with respect to conversational o Degraded user experience with respect to conversational
interactivity: the degradation of conversational interactivity is interactivity: the degradation of conversational interactivity is
due to the increase of end to end latency for both directions that due to the increase of end to end latency for both directions that
is introduced by the transcoding operations. Transcoding requires is introduced by the transcoding operations. Transcoding requires
full de-packetization for decoding of the media stream (including full de-packetization for decoding of the media stream (including
mechanisms of de-jitter buffering and packet loss recovery) then mechanisms of de-jitter buffering and packet loss recovery) then
re-encoding, re-packetization and re-sending. The delays produced re-encoding, re-packetization and re-sending. The delays produced
by all these operations are additive and may increase the end to by all these operations are additive and may increase the end to
end delay beyond acceptable limits like with more than 1s end to end delay beyond acceptable limits like with more than 1s end to
skipping to change at page 5, line 25 skipping to change at page 5, line 25
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.
4.1.2. WebRTC relevant use case for AMR-WB 4.1.2. WebRTC relevant use case for AMR-WB
The market of voice personal communication is driven by mobile The market of 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 several hundreds of devices
and 85 HD mobile networks in 60 countries with a customer base of models and more than 130 HD mobile networks in 80 countries with a
more than 100 million. A high number of calls are consequently customer base of more than 300 millions. A high number of calls are
likely to occur between WebRTC clients and mobile 3GPP terminals. consequently likely to occur between WebRTC clients and mobile 3GPP
The use of AMR-WB by WebRTC clients would consequently allow terminals. The use of AMR-WB by WebRTC clients would consequently
transcoding free interoperation with all mobile 3GPP wideband allow transcoding free interoperation with all mobile 3GPP wideband
terminal. Besides, WebRTC clients running on mobile terminals 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.
4.1.3. Guidelines for AMR-WB usage and implementation with WebRTC 4.1.3. Guidelines for AMR-WB usage and implementation with WebRTC
Guidelines for implementing and using AMR-WB and ensuring 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
skipping to change at page 7, line 50 skipping to change at page 8, line 4
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].
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.
Some further update of this Draft may provide under this section
additional use case description and codec implementation guidelines
for these codecs.
5. Security Considerations 5. Security Considerations
6. IANA Considerations 6. IANA Considerations
None. None.
7. Acknowledgements 7. Acknowledgements
Thanks to Milan Patel for his review. None.
8. References 8. References
8.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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
8.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-07 (work in Requirements", draft-ietf-rtcweb-audio-08 (work in
progress), October 2014. progress), April 2015.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-13 Browser-based Applications", draft-ietf-rtcweb-overview-14
(work in progress), November 2014. (work in progress), June 2015.
[I-D.ietf-rtcweb-use-cases-and-requirements]
Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use-cases and Requirements", draft-
ietf-rtcweb-use-cases-and-requirements-15 (work in
progress), December 2014.
[IR.36] GSMA, "Adaptive Multirate Wide Band", 2013. [IR.36] GSMA, "Adaptive Multirate Wide Band V3.0", September 2014.
[IR.92] GSMA, "IMS Profile for Voice and SMS", 2013. [IR.92] GSMA, "IMS Profile for Voice and SMS V9.0", April 2015.
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the
Opus Audio Codec", RFC 6716, September 2012. Opus Audio Codec", RFC 6716, DOI 10.17487/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.
[TS26.114] [TS26.114]
3GPP, "IP Multimedia Subsystem (IMS); Multimedia 3GPP, "IP Multimedia Subsystem (IMS); Multimedia
telephony; Media handling and interaction", 2011. telephony; Media handling and interaction V13.0.0", June
2015.
Authors' Addresses Authors' Addresses
Stephane Proust Stephane Proust
Orange Orange
2, avenue Pierre Marzin 2, avenue Pierre Marzin
Lannion 22307 Lannion 22307
France France
Email: stephane.proust@orange.com Email: stephane.proust@orange.com
 End of changes. 15 change blocks. 
36 lines changed or deleted 36 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/