draft-ietf-rtcweb-audio-codecs-for-interop-06.txt   rfc7875.txt 
Network Working Group S. Proust, Ed. Internet Engineering Task Force (IETF) S. Proust, Ed.
Internet-Draft Orange Request for Comments: 7875 Orange
Intended status: Informational April 22, 2016 Category: Informational May 2016
Expires: October 24, 2016 ISSN: 2070-1721
Additional WebRTC audio codecs for interoperability. Additional WebRTC Audio Codecs for Interoperability
draft-ietf-rtcweb-audio-codecs-for-interop-06
Abstract Abstract
To ensure a baseline level of interoperability between WebRTC To ensure a baseline of interoperability between WebRTC endpoints, a
endpoints, a minimum set of required codecs is specified. However, minimum set of required codecs is specified. However, to maximize
to maximize the possibility to establish the session without the need the possibility of establishing the session without the need for
for audio transcoding, it is also recommended to include in the offer 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 endpoints to address the most relevant considered for WebRTC endpoints to address the use cases most
interoperability use cases. relevant to interoperability.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It has been approved for publication by the Internet
time. It is inappropriate to use Internet-Drafts as reference Engineering Steering Group (IESG). Not all documents approved by the
material or to cite them other than as "work in progress." IESG are a candidate for any level of Internet Standard; see
Section 2 of RFC 5741.
This Internet-Draft will expire on October 24, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7875.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition and abbreviations . . . . . . . . . . . . . . . . 3 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 3
3. Rationale for additional WebRTC codecs . . . . . . . . . . . 3 3. Rationale for Additional WebRTC Codecs . . . . . . . . . . . 4
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
4.2. AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. AMR General description . . . . . . . . . . . . . . . 6
4.2.2. WebRTC relevant use case for AMR . . . . . . . . . . 6
4.2.3. Guidelines for AMR usage and implementation with
WebRTC . . . . . . . . . . . . . . . . . . . . . . . 6 WebRTC . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. AMR General Description . . . . . . . . . . . . . . . 6
4.2.2. WebRTC-Relevant Use Case for AMR . . . . . . . . . . 7
4.2.3. Guidelines for AMR Usage and Implementation with
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 . . . . . . . . . 8
4.3.3. Guidelines for G.722 usage and implementation . . . . 8 4.3.3. Guidelines for G.722 Usage and Implementation with
WebRTC . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 10
8.1. Normative references . . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Informative references . . . . . . . . . . . . . . . . . 10 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
As indicated in [I-D.ietf-rtcweb-overview], it has been anticipated As indicated in [OVERVIEW], it has been anticipated that WebRTC will
that WebRTC will not remain an isolated island and that some WebRTC not remain an isolated island and that some WebRTC endpoints will
endpoints will need to communicate with devices used in other need to communicate with devices used in other existing networks with
existing networks with the help of a gateway. Therefore, in order to the help of a gateway. Therefore, in order to maximize the
maximize the possibility to establish the session without the need possibility of establishing the session without the need for audio
for audio transcoding, it is recommended in [I-D.ietf-rtcweb-audio] transcoding, it is recommended in [RFC7874] to include in the offer
to include in the offer other suitable audio codecs beyond those that other suitable audio codecs beyond those that are mandatory to
are mandatory to implement. This document provides some guidelines implement. This document provides some guidelines on the suitable
on the suitable codecs to be considered for WebRTC endpoints to codecs to be considered for WebRTC endpoints to address the use cases
address the most relevant interoperability use cases. most relevant to interoperability.
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 endpoints for supported and included in the offer, only for WebRTC endpoints for
which interoperability with other non-WebRTC endpoints and non-WebRTC which interoperability with other non-WebRTC endpoints and non-
based services is relevant as described in Section 4.1.2, WebRTC-based services is relevant as described in Sections 4.1.2,
Section 4.2.2, Section 4.3.2. Other use cases may justify offering 4.2.2, and 4.3.2. Other use cases may justify offering other
other additional codecs to avoid transcoding. additional codecs to avoid transcoding.
2. Definition and abbreviations 2. Definitions 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 (VoLTE) radio access [IR.92].
o WebRTC endpoint: a WebRTC endpoint can be a WebRTC browser or a o WebRTC endpoint: A WebRTC endpoint can be a WebRTC browser or a
WebRTC non browser (also called "WebRTC device" or "WebRTC native WebRTC non-browser (also called "WebRTC device" or "WebRTC native
application") as defined in [I-D.ietf-rtcweb-overview] application") as defined in [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 Subsystems
o LTE: Long Term Evolution (3GPP "4G" wireless data transmission o LTE: Long Term Evolution (3GPP "4G" wireless data transmission
standard) standard)
o MOS: Mean Opinion Score, defined in ITU-T P.800 specification o MOS: Mean Opinion Score, defined in ITU-T Recommendation P.800
[P.800] [P.800]
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 endpoints The mandatory implementation of Opus [RFC6716] in WebRTC endpoints
can guarantee codec interoperability (without transcoding) at state can guarantee codec interoperability (without transcoding) at state-
of the art voice quality (better than narrow band "PSTN" quality) of-the-art voice quality (better than narrow-band "PSTN" quality)
between WebRTC endpoints. The WebRTC technology is also expected to between WebRTC endpoints. The WebRTC technology is also expected to
be used to communicate with other types of endpoints 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 endpoints and other terminals like mobile handsets, supporting WebRTC endpoints and other terminals like mobile handsets,
fixed VoIP terminals and DECT terminals that do not support WebRTC fixed VoIP terminals, and DECT terminals that do not support WebRTC
endpoints nor implement OPUS. As a consequence, these calls are endpoints nor implement Opus. As a consequence, these calls are
likely to be either of low narrow band PSTN quality using G.711 likely to be either of low narrow-band PSTN quality using G.711
[G.711] at both ends or affected by transcoding operations. The [G.711] at both ends or affected by transcoding operations. The
drawback of 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 the
use cases with AMR-WB codec (Section 4.1) at 12.65 kbit/s and in transcoding use cases with AMR-WB codec (Section 4.1) at 12.65
the same range for other wideband transcoding cases. It should be kbit/s and in the same range for other wideband transcoding cases.
stressed that if G.711 is used as a fall back codec for It should be stressed that if G.711 is used as a fallback codec
interoperation, wideband voice quality will be lost. Such for 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
frequent calls. Such a switch to G.711 is less than desirable or frequent calls. Such a switch to G.711 is a choice for customers.
acceptable choice for customers. If transcoding is performed If transcoding is performed between Opus and any other wideband
between OPUS and any other wideband codec, wideband communication codec, wideband communication could be maintained but with
could be maintained but with degraded quality (MOS scores of degraded quality (MOSs of transcoding between AMR-WB at 12.65
transcoding between AMR-WB 12.65 kbit/s and OPUS at 16 kbit/s in kbit/s and Opus at 16 kbit/s in both directions are significantly
both directions are significantly lower than those of AMR-WB at lower than those of AMR-WB at 12.65 kbit/s or Opus at 16 kbit/s).
12.65 kbit/s or OPUS at 16 kbit/s). Furthermore, in degraded Furthermore, in degraded conditions, the addition of defects, like
conditions, the addition of defects, like audio artifacts due to (a) audio artifacts due to packet losses and (b) audio effects due
packet losses, and the audio effects resulting from the cascading to the cascading of different packet loss recovery algorithms, may
of different packet loss recovery algorithms may result in a result in a 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 resending. 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 up to 1 second, much beyond the acceptable limit. end delay up to 1 second, much beyond the acceptable limit.
o Additional cost in networks: transcoding places important o Additional cost in networks: transcoding places important
additional cost on network gateways mainly related to codec additional cost on network gateways mainly related to codec
implementation, codecs licenses, deployment, testing and implementation, codecs licenses, deployment, testing and
validation cost. It must be noted that transcoding of wideband to validation cost. It must be noted that transcoding of wideband to
wideband would require more CPU processing and be more costly than wideband would require more CPU processing and be more costly than
transcoding 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 codecs with respect The following are considered relevant codecs with respect to the
to the general purpose described in Section 3. This list reflects general purpose described in Section 3. This list reflects the
the current status of WebRTC foreseen use cases. It is not current status of foreseen use cases for WebRTC. It is not
limitative and opened to further inclusion of other codecs for which limitative; it is open to inclusion of other codecs for which
relevant use cases can be identified. These additional codecs are relevant use cases can be identified. It's recommended to include
recommended to be included in the offer in addition to OPUS and G.711 codecs (in addition to Opus and G.711) according to the foreseen
according to the foreseen interoperability cases to be addressed. 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. It is specially used for voice over LTE as services over IP/IMS. It is specially 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 the detailed codec description and source
are in [TS26.171], [TS26.173], [TS26.190], [TS26.204]. code are in [TS26.171], [TS26.173], [TS26.190], and [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 very widely implemented in devices and terminals. AMR-WB is now very widely implemented in devices and
networks offering "HD Voice" A high number of calls are consequently networks offering "HD voice", where "HD" stands for "High
likely to occur between WebRTC endpoints and mobile 3GPP terminals Definition". Consequently, a high number of calls are likely to
offering AMR-WB. The use of AMR-WB by WebRTC endpoints would occur between WebRTC endpoints and mobile 3GPP terminals offering
consequently allow transcoding free interoperation with all mobile AMR-WB. Thus, the use of AMR-WB by WebRTC endpoints would allow
3GPP wideband terminals. Besides, WebRTC endpoints running on mobile transcoding-free interoperation with all mobile 3GPP wideband
terminals (smartphones) may reuse the AMR-WB codec already terminals. Besides, WebRTC endpoints running on mobile terminals
implemented on these devices. (smartphones) may reuse the AMR-WB codec already implemented on those
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 a bandwidth-efficient format and one speech frame encapsulated
each RTP packet. Further guidelines for implementing and using AMR- in each RTP packet. Further guidelines for implementing and using
WB and ensuring interoperability with 3GPP mobile services can be AMR-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
endpoints offering AMR-WB it is important that the WebRTC endpoints: 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 the preferred payload type with respect
other narrow band codecs (AMR, G.711...) and with Bandwidth to other narrow-band codecs (AMR, G.711, etc.) and with a
Efficient payload format preferred. bandwidth-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.
AMR-WB configuration with parameter settings as defined in
Table 6.1 of [TS26.114]. In order to maximize the o Offer at least one AMR-WB configuration with parameter settings as
interoperability and quality this offer does not restrict the defined in Table 6.1 of [TS26.114]. In order to maximize
codec modes offered. Restrictions in the use of codec modes may interoperability and quality, this offer does not restrict the
codec modes offered. Restrictions on 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. This includes both mobile phone calls using GSM and communication. This includes both mobile phone calls using GSM and
3G cellular systems as well as multimedia telephony services over IP/ 3G cellular systems as well as multimedia telephony services over IP/
IMS and 4G/VoLTE, such as GSMA voice IMS profile for VoLTE in IMS and 4G/VoLTE, such as the GSMA voice IMS profile for VoLTE in
[IR.92]. In addition to impacts listed above, support of AMR can [IR.92]. References for AMR-related specifications including
avoid degrading the high efficiency over mobile radio access. detailed codec description and source code are [TS26.071],
References for AMR related specifications including detailed codec [TS26.073], [TS26.090], and [TS26.104].
description and source code are in [TS26.071], [TS26.073],
[TS26.090], [TS26.104].
4.2.2. WebRTC relevant use case for AMR 4.2.2. WebRTC-Relevant Use Case for AMR
A user of a WebRTC endpoint on a device integrating an AMR module A user of a WebRTC endpoint on a device integrating an AMR module
wants to communicate with another user that can only be reached on a wants to communicate with another user that can only be reached on a
mobile device that only supports AMR. Although more and more mobile device that only supports AMR. Although more and more
terminal devices are now "HD voice" and support AMR-WB; there 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 endpoints 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 endpoints running on mobile terminals (smartphones) Besides, WebRTC endpoints running on mobile terminals (smartphones)
may 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 packet. Further guidelines for implementing and using AMR with RTP packet. 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
endpoints offering AMR, it is important that the WebRTC endpoints: 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 Tables 6.1 and 6.2 of [TS26.114]. In order to maximize
maximize the interoperability and quality this offer shall not the interoperability and quality, this offer shall not restrict
restrict AMR codec modes offered. Restrictions in the use of AMR codec modes offered. Restrictions on the use of codec modes
codec modes may be included in the answer. may be included in the answer.
4.3. G.722 4.3. G.722
4.3.1. G.722 General description 4.3.1. G.722 General Description
G.722 [G.722] is an ITU-T defined wideband speech codec. G.722 was G.722 [G.722] is an ITU-T-defined wideband speech codec. G.722 was
approved by ITU-T in 1988. It is a royalty free codec that is common approved by the ITU-T in 1988. It is a royalty-free codec that is
in a wide range of terminals and endpoints supporting wideband speech common in a wide range of terminals and endpoints supporting wideband
and requiring low complexity. The complexity of G.722 is estimated speech and requiring low complexity. The complexity of G.722 is
to 10 MIPS [EN300175-8] which is 2.5 to 3 times lower than AMR-WB. estimated to 10 MIPS [EN300175-8], which is 2.5 to 3 times lower than
Especially, G.722 has been chosen by ETSI DECT as the mandatory AMR-WB. In particular, G.722 has been chosen by ETSI DECT as the
wideband codec for New Generation DECT with purpose to greatly mandatory wideband codec for New Generation DECT in order 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 terminals
DECT certified terminals and the V2.0 of CAT-iq specifications have that are certified as CAT-iq DECT, and version 2.0 of the CAT-iq
been approved by GSMA as minimum requirements for HD voice logo usage specifications have been approved by GSMA as the minimum requirements
on "fixed" devices; i.e., broadband connections using the G.722 for the "HD voice" logo usage on "fixed" devices, i.e., broadband
codec. connections using the G.722 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. DECT G.722 is the wideband codec required for DECT CAT-iq terminals. DECT
cordeless phones are still widely used to offer short range wireless cordless phones are still widely used to offer short-range wireless
connection to PSTN or VoIP services. G.722 has also been specified connection to PSTN or VoIP services. G.722 has also been specified
by ETSI in [TS181005] as mandatory wideband codec for IMS multimedia by ETSI in [TS181005] as the mandatory wideband codec for IMS
telephony communication service and supplementary services using multimedia telephony communication service and supplementary services
fixed broadband access. The support of G.722 would consequently using fixed broadband access. The support of G.722 would
allow transcoding free IP interoperation between WebRTC endpoints and consequently allow transcoding-free IP interoperation between WebRTC
fixed VoIP terminals including DECT / CAT-IQ terminals supporting endpoints and fixed VoIP terminals including DECT CAT-iq terminals
G.722. Besides, WebRTC endpoints running on fixed terminals supporting G.722. Besides, WebRTC endpoints running on fixed
implementing G.722 may reuse the G.722 codec already implemented on terminals that implement G.722 may reuse the G.722 codec already
these devices. implemented on these devices.
4.3.3. Guidelines for G.722 usage and implementation 4.3.3. Guidelines for G.722 Usage and Implementation with WebRTC
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 the G.722 codec
but the rtp clock rate is set to 8000Hz in SDP to stay backward is 16 kHz, but the RTP clock rate is set to 8000 Hz in SDP to stay
compatible with an erroneous definition in the original version of backward compatible with an erroneous definition in the original
the RTP A/V profile. Further guidelines for implementing and using version of the RTP audio/video profile. Further guidelines for
G.722 with purpose to ensure interoperability with multimedia implementing and using G.722 to ensure interoperability with
telephony services over IMS can be found in section 7 of [TS26.114]. multimedia telephony services over IMS can be found in Section 7 of
Additional information of G.722 implementation in DECT can be found [TS26.114]. Additional information about the G.722 implementation in
in [EN300175-8] and full codec description and C source code in DECT can be found in [EN300175-8], and the full codec description and
[G.722]. C source code are in [G.722].
5. Security Considerations 5. Security Considerations
Security considerations for WebRTC Audio Codec and Processing Relevant security considerations can be found in [RFC7874], "WebRTC
Requirements can be found in [I-D.ietf-rtcweb-audio]. Implementors Audio Codec and Processing Requirements". Implementers making use of
making use of the additional codecs considered in this document are the additional codecs considered in this document are advised to also
advised to also refer more specifically to the "Security refer more specifically to the "Security Considerations" sections of
Considerations" sections of [RFC4867] (for AMR and AMR-WB) and [RFC4867] (for AMR and AMR-WB) and [RFC3551] (for the RTP audio/video
[RFC3551]. profile).
6. IANA Considerations
None.
7. Acknowledgements
The authors of this document are
o Stephane Proust, Orange, stephane.proust@orange.com ,
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 6. References
8.1. Normative references 6.1. Normative References
[G.722] ITU, "Recommendation ITU-T G.722 (2012): 7 kHz audio- [G.722] ITU-T, "7 kHz audio-coding within 64 kbit/s", ITU-T
coding within 64 kbit/s", 2012-09, Recommendation G.722, September 2012,
<http://www.itu.int/rec/T-REC-G.722-201209-I/en>. <http://www.itu.int/rec/T-REC-G.722-201209-I/en>.
[I-D.ietf-rtcweb-audio] [IR.92] GSMA, "IMS Profile for Voice and SMS", IR.92, Version 9.0,
Valin, J. and C. Bran, "WebRTC Audio Codec and Processing April 2015, <http://www.gsma.com/newsroom/all-documents/
Requirements", draft-ietf-rtcweb-audio-10 (work in
progress), February 2016.
[IR.92] GSMA, "IMS Profile for Voice and SMS V9.0", April 2015,
<http://www.gsma.com/newsroom/all-documents/
ir-92-ims-profile-for-voice-and-sms/>. ir-92-ims-profile-for-voice-and-sms/>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003, DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>. <http://www.rfc-editor.org/info/rfc3551>.
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie,
"RTP Payload Format and File Storage Format for the "RTP Payload Format and File Storage Format for the
Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband
(AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867,
April 2007, <http://www.rfc-editor.org/info/rfc4867>. April 2007, <http://www.rfc-editor.org/info/rfc4867>.
[TS26.071] [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing
3GPP, "3GPP TS 26.071 v13.0.0: Recommendation ITU-T G.722 Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016,
(2012): "Mandatory Speech Codec speech processing <http://www.rfc-editor.org/info/rfc7874>.
functions; AMR Speech CODEC; General description".",
2015-12, <http://www.3gpp.org/DynaReport/26071.htm>.
[TS26.073] [TS26.071] 3GPP, "Mandatory Speech Codec speech processing functions;
3GPP, "3GPP TS 26.073 v13.0.0: ANSI C code for the AMR Speech CODEC; General description", 3GPP TS 26.171
Adaptive Multi Rate (AMR) speech codec", 2015-12, v13.0.0, December 2015,
<http://www.3gpp.org/DynaReport/26071.htm>.
[TS26.073] 3GPP, "ANSI C code for the Adaptive Multi Rate (AMR)
speech codec", 3GPP TS 26.073 v13.0.0, December 2015,
<http://www.3gpp.org/DynaReport/26073.htm>. <http://www.3gpp.org/DynaReport/26073.htm>.
[TS26.090] [TS26.090] 3GPP, "Mandatory Speech Codec speech processing functions;
3GPP, "3GPP TS 26.090 v13.0.0: Mandatory Speech Codec Adaptive Multi-Rate (AMR) speech codec; Transcoding
speech processing functions; Adaptive Multi-Rate (AMR) functions.", 3GPP TS 26.090 v13.0.0, December 2015,
speech codec; Transcoding functions.", 2015-12,
<http://www.3gpp.org/DynaReport/26090.htm>. <http://www.3gpp.org/DynaReport/26090.htm>.
[TS26.104] [TS26.104] 3GPP, "ANSI C code for the floating-point Adaptive Multi
3GPP, "3GPP TS 26.104 v13.0.0: ANSI C code for the Rate (AMR) speech codec.", 3GPP TS 26.104 v13.0.0,
floating-point Adaptive Multi Rate (AMR) speech codec.", December 2015, <http://www.3gpp.org/DynaReport/26090.htm>.
2015-12, <http://www.3gpp.org/DynaReport/26090.htm>.
[TS26.114] [TS26.114] 3GPP, "IP Multimedia Subsystem (IMS); Multimedia
3GPP, "3GPP TS 26.114 v13.3.0: IP Multimedia Subsystem telephony; Media handling and interaction", 3GPP TS 26.114
(IMS); Multimedia telephony; Media handling and v13.3.0, March 2016,
interaction", March 2016,
<http://www.3gpp.org/DynaReport/26114.htm>. <http://www.3gpp.org/DynaReport/26114.htm>.
[TS26.171] [TS26.171] 3GPP, "Speech codec speech processing functions; Adaptive
3GPP, "3GPP TS 26.171 v13.0.0: Speech codec speech Multi-Rate - Wideband (AMR-WB) speech codec; General
processing functions; Adaptive Multi-Rate - Wideband (AMR- description.", 3GPP TS 26.171 v13.0.0, December 2015,
WB) speech codec; General description.", 2015-12,
<http://www.3gpp.org/DynaReport/26171.htm>. <http://www.3gpp.org/DynaReport/26171.htm>.
[TS26.173] [TS26.173] 3GPP, "ANSI-C code for the Adaptive Multi-Rate - Wideband
3GPP, "3GPP TS 26.173 v13.1.0: ANSI-C code for the (AMR-WB) speech codec", 3GPP TS 26.173 v13.1.0, March
Adaptive Multi-Rate - Wideband (AMR-WB) speech codec.", 2016, <http://www.3gpp.org/DynaReport/26173.htm>.
2016-03, <http://www.3gpp.org/DynaReport/26173.htm>.
[TS26.190] [TS26.190] 3GPP, "Speech codec speech processing functions; Adaptive
3GPP, "3GPP TS 26.190 v13.0.0: Speech codec speech Multi-Rate - Wideband (AMR-WB) speech codec; Transcoding
processing functions; Adaptive Multi-Rate - Wideband (AMR- functions", 3GPP TS 26.190 v13.0.0, December 2015,
WB) speech codec; Transcoding functions.", 2015-12,
<http://www.3gpp.org/DynaReport/26190.htm>. <http://www.3gpp.org/DynaReport/26190.htm>.
[TS26.204] [TS26.204] 3GPP, "Speech codec speech processing functions; Adaptive
3GPP, "3GPP TS 26.204 v13.1.0: Speech codec speech Multi-Rate - Wideband (AMR-WB) speech codec; ANSI-C
processing functions; Adaptive Multi-Rate - Wideband (AMR- code.", 3GPP TS 26.204 v13.1.0, March 2016,
WB) speech codec; ANSI-C code.", 2016-03,
<http://www.3gpp.org/DynaReport/26204.htm>. <http://www.3gpp.org/DynaReport/26204.htm>.
8.2. Informative references 6.2. Informative References
[EN300175-1] [EN300175-1]
ETSI, "ETSI EN 300 175-1, v2.6.1: Digital Enhanced ETSI, "Digital Enhanced Cordless Telecommunications
Cordless Telecommunications (DECT); Common Interface (CI); (DECT); Common Interface (CI); Part 1: Overview", ETSI
Part 1: Overview", 2015, <http://www.etsi.org/deliver/ EN 300 175-1, v2.6.1, 2015,
etsi_en/300100_300199/30017501/02.06.01_60/ <http://www.etsi.org/deliver/etsi_en/300100_300199/
en_30017501v020601p.pdf>. 30017501/02.06.01_60/en_30017501v020601p.pdf>.
[EN300175-8] [EN300175-8]
ETSI, "ETSI EN 300 175-8, v2.6.1: Digital Enhanced ETSI, "Digital Enhanced Cordless Telecommunications
Cordless Telecommunications (DECT); Common Interface (CI); (DECT); Common Interface (CI); Part 8: Speech and audio
Part 8: Speech and audio coding and transmission.", 2015, coding and transmission.", ETSI EN 300 175-8, v2.6.1,
<http://www.etsi.org/deliver/ 2015,
etsi_en/300100_300199/30017508/02.06.01_60/ <http://www.etsi.org/deliver/etsi_en/300100_300199/
en_30017508v020601p.pdf>. 30017508/02.06.01_60/en_30017508v020601p.pdf>.
[G.711] ITU, "Recommendation ITU-T G.711 (2012): Pulse code [G.711] ITU-T, "Pulse code modulation (PCM) of voice frequencies",
modulation (PCM) of voice frequencies", 1988-11, ITU-T Recommendation G.711, November 1988,
<http://www.itu.int/rec/T-REC-G.711-198811-I/en>. <http://www.itu.int/rec/T-REC-G.711-198811-I/en>.
[I-D.ietf-rtcweb-overview] [IR.36] GSMA, "Adaptive Multirate Wide Band", IR.36, Version 3.0,
Alvestrand, H., "Overview: Real Time Protocols for September 2014,
Browser-based Applications", draft-ietf-rtcweb-overview-15
(work in progress), January 2016.
[IR.36] GSMA, "Adaptive Multirate Wide Band V3.0", September 2014,
<http://www.gsma.com/newsroom/all-documents/ <http://www.gsma.com/newsroom/all-documents/
official-document-ir-36-adaptive-multirate-wide-band>. official-document-ir-36-adaptive-multirate-wide-band>.
[P.800] ITU, "ITU-T P.800: Methods for objective and subjective [OVERVIEW] Alvestrand, H., "Overview: Real Time Protocols for
assessment of quality", 1996-08, <https://www.itu.int/rec/ Browser-based Applications", Work in Progress,
T-REC-P.800-199608-I/en>. draft-ietf-rtcweb-overview-15, January 2016.
[P.800] ITU-T, "Methods for subjective determination of
transmission quality", ITU-T Recommendation P.800, August
1996, <https://www.itu.int/rec/T-REC-P.800-199608-I/en>.
[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)", ETSI
<http://www.etsi.org/deliver/ TS 181005, 2009,
etsi_ts/181000_181099/181005/03.03.01_60/ <http://www.etsi.org/deliver/etsi_ts/181000_181099/
ts_181005v030301p.pdf>. 181005/03.03.01_60/ts_181005v030301p.pdf>.
[TS23.002] [TS23.002] 3GPP, "Network architecture", 3GPP TS23.002 v13.5.0, March
3GPP, "3GPP TS 23.002 v13.5.0: Network architecture", 2016, <http://www.3gpp.org/dynareport/23002.htm>.
2016-03, <http://www.3gpp.org/dynareport/23002.htm>.
Acknowledgements
We would like to thank Magnus Westerlund, Barry Dingle, and Sanjay
Mishra who carefully reviewed the document and helped to improve it.
Contributors
The following individuals contributed significantly to this document:
o Stephane Proust, Orange, stephane.proust@orange.com
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.
Author's Address Author's Address
Stephane Proust (editor) 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. 84 change blocks. 
300 lines changed or deleted 283 lines changed or added

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