Network Working Group
Internet Engineering Task Force (IETF)                    S. Proust, Ed.
Internet-Draft
Request for Comments: 7875                                        Orange
Intended status:
Category: Informational                            April 22, 2016
Expires: October 24,                                         May 2016
ISSN: 2070-1721

          Additional WebRTC audio codecs Audio Codecs for interoperability.
             draft-ietf-rtcweb-audio-codecs-for-interop-06 Interoperability

Abstract

   To ensure a baseline level of interoperability between WebRTC endpoints, a
   minimum set of required codecs is specified.  However, to maximize
   the possibility to establish of establishing the session without the need for
   audio transcoding, it is also recommended to include in the offer
   other suitable audio codecs that are available to the browser.

   This document provides some guidelines on the suitable codecs to be
   considered for WebRTC endpoints to address the use cases most
   relevant
   interoperability use cases. to interoperability.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working  It has been approved for publication by the Internet
   Engineering Steering Group (IESG).  Not all documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts approved by the
   IESG are draft documents valid for a maximum candidate for any level of Internet Standard; see
   Section 2 of six months RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 24, 2016.
   http://www.rfc-editor.org/info/rfc7875.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definition  Definitions and abbreviations Abbreviations . . . . . . . . . . . . . . . .   3
   3.  Rationale for additional Additional WebRTC codecs Codecs  . . . . . . . . . . .   3
   4.  Additional suitable codecs Suitable Codecs for WebRTC . . . . . . . . . . . .   5
     4.1.  AMR-WB  . . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.1.  AMR-WB General description Description  . . . . . . . . . . . . .   5
       4.1.2.  WebRTC relevant use case  WebRTC-Relevant Use Case for AMR-WB . . . . . . . . .   5
       4.1.3.  Guidelines for AMR-WB usage Usage and implementation Implementation with
               WebRTC  . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  AMR . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.1.  AMR General description Description . . . . . . . . . . . . . . .   6
       4.2.2.  WebRTC relevant use case  WebRTC-Relevant Use Case for AMR  . . . . . . . . . .   6
       4.2.3.  Guidelines for AMR usage Usage and implementation Implementation with
               WebRTC  . . . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  G.722 . . . . . . . . . . . . . . . . . . . . . . . . . .   7
       4.3.1.  G.722 General description Description . . . . . . . . . . . . . .   7
       4.3.2.  WebRTC relevant use case  WebRTC-Relevant Use Case for G.722  . . . . . . . . .   7
       4.3.3.  Guidelines for G.722 usage Usage and implementation Implementation . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations  References  . . . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
   8.
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . .   9
     8.1.  Normative references . . . . . . . . . . . . .  11
   Contributors  . . . . .   9
     8.2.  Informative references . . . . . . . . . . . . . . . . .  10 . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   As indicated in [I-D.ietf-rtcweb-overview], [OVERVIEW], it has been anticipated that WebRTC will
   not remain an isolated island and that some WebRTC endpoints will
   need to communicate with devices used in other existing networks with
   the help of a gateway.  Therefore, in order to maximize the
   possibility to establish of establishing the session without the need for audio
   transcoding, it is recommended in [I-D.ietf-rtcweb-audio] [RFC7874] to include in the offer
   other suitable audio codecs beyond those that are mandatory to
   implement.  This document provides some guidelines on the suitable
   codecs to be considered for WebRTC endpoints to address the use cases
   most relevant interoperability use cases. to interoperability.

   The codecs considered in this document are recommended to be
   supported and included in the Offer offer, only for WebRTC endpoints for
   which interoperability with other non-WebRTC endpoints and non-WebRTC
   based non-
   WebRTC-based services is relevant as described in Section Sections 4.1.2,
   Section
   4.2.2, Section and 4.3.2.  Other use cases may justify offering other
   additional codecs to avoid transcoding.

2.  Definition  Definitions and abbreviations Abbreviations

   o  Legacy networks: In this document, legacy networks encompass the
      conversational networks that are already deployed like the PSTN,
      the PLMN, the IP/IMS networks offering VoIP services, including
      3GPP "4G" Evolved Packet System [TS23.002] supporting voice over
      LTE (VoLTE) radio access (VoLTE) [IR.92].

   o  WebRTC endpoint: a A WebRTC endpoint can be a WebRTC browser or a
      WebRTC non browser non-browser (also called "WebRTC device" or "WebRTC native
      application") as defined in [I-D.ietf-rtcweb-overview] [OVERVIEW].

   o  AMR: Adaptive Multi-Rate. Multi-Rate

   o  AMR-WB: Adaptive Multi-Rate WideBand. Wideband

   o  CAT-iq: Cordless Advanced Technology-internet Technology - internet and quality. quality

   o  DECT: Digital Enhanced Cordless Telecommunications

   o  IMS: IP Multimedia Subsystem Subsystems

   o  LTE: Long Term Evolution (3GPP "4G" wireless data transmission
      standard)

   o  MOS: Mean Opinion Score, defined in ITU-T Recommendation P.800 specification
      [P.800]

   o  PSTN: Public Switched Telephone Network

   o  PLMN: Public Land Mobile Network

   o  VoLTE: Voice Over over LTE

3.  Rationale for additional Additional WebRTC codecs Codecs

   The mandatory implementation of OPUS Opus [RFC6716] in WebRTC endpoints
   can guarantee codec interoperability (without transcoding) at state
   of the art state-
   of-the-art voice quality (better than narrow band narrow-band "PSTN" quality)
   between WebRTC endpoints.  The WebRTC technology is also expected to
   be used to communicate with other types of endpoints using other
   technologies.  It can be used for instance as an access technology to
   VoLTE services (Voice over LTE as specified in [IR.92]) or to
   interoperate with fixed or mobile Circuit Switched Circuit-Switched or VoIP services
   like mobile Circuit Switched Circuit-Switched voice over 3GPP 2G/3G mobile networks
   [TS23.002] or DECT based DECT-based VoIP telephony [EN300175-1].  Consequently,
   a significant number of calls are likely to occur between terminals
   supporting WebRTC endpoints and other terminals like mobile handsets,
   fixed VoIP terminals terminals, and DECT terminals that do not support WebRTC
   endpoints nor implement OPUS. Opus.  As a consequence, these calls are
   likely to be either of low narrow band narrow-band PSTN quality using G.711
   [G.711] at both ends or affected by transcoding operations.  The
   drawback of such transcoding operations are listed below:

   o  Degraded user experience with respect to voice quality: voice
      quality is significantly degraded by transcoding.  For instance,
      the degradation is around 0.2 to 0.3 MOS for most of the
      transcoding 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 stressed that if G.711 is used as a fall back fallback codec
      for interoperation, wideband voice quality will be lost.  Such
      bandwidth reduction effect down to narrow band clearly degrades
      the user perceived user-perceived quality of service leading to shorter and less
      frequent calls.  Such a switch to G.711 is less than desirable or
      acceptable a choice for customers.
      If transcoding is performed between OPUS Opus and any other wideband
      codec, wideband communication could be maintained but with
      degraded quality (MOS scores (MOSs of transcoding between AMR-WB at 12.65
      kbit/s and OPUS Opus at 16 kbit/s in both directions are significantly
      lower than those of AMR-WB at 12.65 kbit/s or OPUS Opus at 16 kbit/s).
      Furthermore, in degraded conditions, the addition of defects, like
      (a) audio artifacts due to packet losses, losses and the (b) audio effects resulting from due
      to the cascading of different packet loss recovery algorithms algorithms, may
      result in a quality below the acceptable limit for the customers.

   o  Degraded user experience with respect to conversational
      interactivity: the degradation of conversational interactivity is
      due to the increase of end to end end-to-end latency for both directions that
      is introduced by the transcoding operations.  Transcoding requires
      full de-packetization for decoding of the media stream (including
      mechanisms of de-jitter buffering and packet loss recovery) then
      re-encoding, re-packetization re-packetization, and re-sending. resending.  The delays produced
      by all these operations are additive and may increase the end to end-to-
      end delay up to 1 second, much beyond the acceptable limit.

   o  Additional cost in networks: transcoding places important
      additional cost on network gateways mainly related to codec
      implementation, codecs licenses, deployment, testing and
      validation cost.  It must be noted that transcoding of wideband to
      wideband would require more CPU processing and be more costly than
      transcoding between narrowband codecs.

4.  Additional suitable codecs Suitable Codecs for WebRTC

   The following codecs are considered as relevant codecs with respect to the
   general purpose described in Section 3.  This list reflects the
   current status of WebRTC foreseen use cases. cases for WebRTC.  It is not
   limitative and opened
   limitative; it is open to further inclusion of other codecs for which
   relevant use cases can be identified.  These additional codecs are  It's recommended to be included in the offer in include
   codecs (in addition to OPUS Opus and G.711 G.711) according to the foreseen
   interoperability cases to be addressed.

4.1.  AMR-WB

4.1.1.  AMR-WB General description Description

   The Adaptive Multi-Rate WideBand (AMR-WB) is a 3GPP defined 3GPP-defined speech
   codec that is mandatory to implement in any 3GPP terminal that
   supports wideband speech communication.  It is being used in circuit circuit-
   switched mobile telephony services and new multimedia telephony
   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
   can be found in [IR.36].  References for AMR-WB related AMR-WB-related
   specifications including the detailed codec description and source
   code are in [TS26.171], [TS26.173], [TS26.190], and [TS26.204].

4.1.2.  WebRTC relevant use case  WebRTC-Relevant Use Case for AMR-WB

   The market of personal voice communication is driven by mobile
   terminals.  AMR-WB is now very widely implemented in devices and
   networks offering "HD Voice" A voice", where "HD" stands for "High
   Definition".  Consequently, a high number of calls are consequently likely to
   occur between WebRTC endpoints and mobile 3GPP terminals offering
   AMR-WB.  The  Thus, the use of AMR-WB by WebRTC endpoints would
   consequently allow transcoding free
   transcoding-free interoperation with all mobile 3GPP wideband
   terminals.  Besides, WebRTC endpoints running on mobile terminals
   (smartphones) may reuse the AMR-WB codec already implemented on these those
   devices.

4.1.3.  Guidelines for AMR-WB usage Usage and implementation Implementation with WebRTC

   The payload format to be used for AMR-WB is described in [RFC4867]
   with bandwidth efficient a bandwidth-efficient format and one speech frame encapsulated
   in each RTP packet.  Further guidelines for implementing and using AMR-
   WB
   AMR-WB and ensuring interoperability with 3GPP mobile services can be
   found in [TS26.114].  In order to ensure interoperability with 4G/
   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
   maximize the possibility of successful call establishment for WebRTC
   endpoints offering AMR-WB AMR-WB, it is important that the WebRTC endpoints:

   o  Offer AMR in addition to AMR-WB AMR-WB, with AMR-WB listed first (AMR-WB
      being a wideband codec) as the preferred payload type with respect
      to other narrow band narrow-band codecs (AMR, G.711...) G.711, etc.) and with Bandwidth
      Efficient a
      bandwidth-efficient payload format preferred.

   o  Be capable of operating AMR-WB with any subset of the nine codec
      modes and source controlled source-controlled rate operation.

   o  Offer at least one AMR-WB configuration with parameter settings as
      defined in Table 6.1 of [TS26.114].  In order to maximize the
      interoperability and quality quality, this offer does not restrict the
      codec modes offered.  Restrictions in on the use of codec modes may
      be included in the answer.

4.2.  AMR

4.2.1.  AMR General description Description

   Adaptive Multi-Rate (AMR) is a 3GPP defined 3GPP-defined speech codec that is
   mandatory to implement in any 3GPP terminal that supports voice
   communication.  This includes both mobile phone calls using GSM and
   3G cellular systems as well as multimedia telephony services over IP/
   IMS and 4G/VoLTE, such as the GSMA voice IMS profile for VoLTE in
   [IR.92].  In addition to the impacts listed above, support of AMR can
   avoid degrading the high efficiency over mobile radio access.
   References for AMR related AMR-related specifications including detailed codec
   description and source code are in [TS26.071], [TS26.073], [TS26.090],
   and [TS26.104].

4.2.2.  WebRTC relevant use case  WebRTC-Relevant Use Case for AMR

   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
   mobile device that only supports AMR.  Although more and more
   terminal devices are now "HD voice" and support AMR-WB; there are
   still a high number of legacy terminals supporting only AMR
   (terminals with no wideband / HD Voice voice capabilities) that are still
   in use.  The use of AMR by WebRTC endpoints would consequently allow
   transcoding free interoperation with all mobile 3GPP terminals.
   Besides, WebRTC endpoints running on mobile terminals (smartphones)
   may reuse the AMR codec already implemented on these devices.

4.2.3.  Guidelines for AMR usage Usage and implementation Implementation with WebRTC

   The payload format to be used for AMR is described in [RFC4867] with
   bandwidth efficient format and one speech frame encapsulated in each
   RTP packet.  Further guidelines for implementing and using AMR with
   purpose to ensure interoperability with 3GPP mobile services can be
   found in [TS26.114].  In order to ensure interoperability with 4G/
   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
   maximize the possibility of successful call establishment for WebRTC
   endpoints offering AMR, it is important that the WebRTC endpoints:

   o  Be capable of operating AMR with any subset of the eight codec
      modes and source controlled source-controlled rate operation.

   o  Offer at least one configuration with parameter settings as
      defined in Table Tables 6.1 and Table 6.2 of [TS26.114].  In order to maximize
      the interoperability and quality quality, this offer shall not restrict
      AMR codec modes offered.  Restrictions in on the use of codec modes
      may be included in the answer.

4.3.  G.722

4.3.1.  G.722 General description Description

   G.722 [G.722] is an ITU-T defined ITU-T-defined wideband speech codec.  G.722 was
   approved by the ITU-T in 1988.  It is a royalty free royalty-free codec that is
   common in a wide range of terminals and endpoints supporting wideband
   speech and requiring low complexity.  The complexity of G.722 is
   estimated to 10 MIPS [EN300175-8] [EN300175-8], which is 2.5 to 3 times lower than
   AMR-WB.
   Especially,  In particular, G.722 has been chosen by ETSI DECT as the
   mandatory wideband codec for New Generation DECT with purpose in order to greatly
   increase the voice quality by extending the bandwidth from narrow
   band to wideband.  G.722 is the wideband codec required for CAT-iq
   DECT certified terminals
   that are certified as CAT-iq DECT, and the V2.0 version 2.0 of the CAT-iq
   specifications have been approved by GSMA as the minimum requirements
   for HD voice the "HD voice" logo usage on "fixed" devices; devices, i.e., broadband
   connections using the G.722 codec.

4.3.2.  WebRTC relevant use case  WebRTC-Relevant Use Case for G.722

   G.722 is the wideband codec required for DECT CAT-iq terminals.  DECT
   cordeless
   cordless phones are still widely used to offer short range short-range wireless
   connection to PSTN or VoIP services.  G.722 has also been specified
   by ETSI in [TS181005] as the mandatory wideband codec for IMS
   multimedia telephony communication service and supplementary services
   using fixed broadband access.  The support of G.722 would
   consequently allow transcoding free transcoding-free IP interoperation between WebRTC
   endpoints and fixed VoIP terminals including DECT / CAT-IQ CAT-iq terminals
   supporting G.722.  Besides, WebRTC endpoints running on fixed
   terminals
   implementing that implement G.722 may reuse the G.722 codec already
   implemented on these devices.

4.3.3.  Guidelines for G.722 usage Usage and implementation Implementation

   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-
   aligned in an RTP packet.  The sampling frequency for the G.722 codec
   is 16 kHz kHz, but the rtp RTP clock rate is set to 8000Hz 8000 Hz in SDP to stay
   backward compatible with an erroneous definition in the original
   version of the RTP A/V audio/video profile.  Further guidelines for
   implementing and using G.722 with purpose to ensure interoperability with
   multimedia telephony services over IMS can be found in section Section 7 of
   [TS26.114].  Additional information of about the G.722 implementation in
   DECT can be found in [EN300175-8] [EN300175-8], and the full codec description and
   C source code are in [G.722].

5.  Security Considerations

   Security

   Relevant security considerations for WebRTC Audio Codec and Processing
   Requirements can be found in [I-D.ietf-rtcweb-audio].  Implementors [RFC7874], "WebRTC
   Audio Codec and Processing Requirements".  Implementers making use of
   the additional codecs considered in this document are advised to also
   refer more specifically to the "Security Considerations" sections of
   [RFC4867] (for AMR and AMR-WB) and
   [RFC3551]. [RFC3551] (for the RTP audio/video
   profile).

6.  IANA Considerations

   None.

8.  References

8.1.

6.1.  Normative references References

   [G.722]    ITU, "Recommendation ITU-T G.722 (2012): 7    ITU-T, "7 kHz audio-
              coding audio-coding within 64 kbit/s", 2012-09, ITU-T
              Recommendation G.722, September 2012,
              <http://www.itu.int/rec/T-REC-G.722-201209-I/en>.

   [I-D.ietf-rtcweb-audio]
              Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
              Requirements", draft-ietf-rtcweb-audio-10 (work in
              progress), February 2016.

   [IR.92]    GSMA, "IMS Profile for Voice and SMS V9.0", SMS", IR.92, Version 9.0,
              April 2015, <http://www.gsma.com/newsroom/all-documents/
              ir-92-ims-profile-for-voice-and-sms/>.

   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
              Video Conferences with Minimal Control", STD 65, RFC 3551,
              DOI 10.17487/RFC3551, July 2003,
              <http://www.rfc-editor.org/info/rfc3551>.

   [RFC4867]  Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie,
              "RTP Payload Format and File Storage Format for the
              Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband
              (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867,
              April 2007, <http://www.rfc-editor.org/info/rfc4867>.

   [RFC7874]  Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
              Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016,
              <http://www.rfc-editor.org/info/rfc7874>.

   [TS26.071]
              3GPP, "3GPP TS 26.071 v13.0.0: Recommendation ITU-T G.722
              (2012): "Mandatory Speech Codec speech processing functions;
              AMR Speech CODEC; General description".",
              2015-12, description", 3GPP TS 26.171
              v13.0.0, December 2015,
              <http://www.3gpp.org/DynaReport/26071.htm>.

   [TS26.073]
              3GPP, "3GPP TS 26.073 v13.0.0: ANSI "ANSI C code for the Adaptive Multi Rate (AMR)
              speech codec", 2015-12, 3GPP TS 26.073 v13.0.0, December 2015,
              <http://www.3gpp.org/DynaReport/26073.htm>.

   [TS26.090]
              3GPP, "3GPP TS 26.090 v13.0.0: Mandatory "Mandatory Speech Codec speech processing functions;
              Adaptive Multi-Rate (AMR) speech codec; Transcoding
              functions.", 2015-12, 3GPP TS 26.090 v13.0.0, December 2015,
              <http://www.3gpp.org/DynaReport/26090.htm>.

   [TS26.104]
              3GPP, "3GPP TS 26.104 v13.0.0: ANSI "ANSI C code for the floating-point Adaptive Multi
              Rate (AMR) speech codec.",
              2015-12, 3GPP TS 26.104 v13.0.0,
              December 2015, <http://www.3gpp.org/DynaReport/26090.htm>.

   [TS26.114]
              3GPP, "3GPP TS 26.114 v13.3.0: IP "IP Multimedia Subsystem (IMS); Multimedia
              telephony; Media handling and interaction", 3GPP TS 26.114
              v13.3.0, March 2016,
              <http://www.3gpp.org/DynaReport/26114.htm>.

   [TS26.171]
              3GPP, "3GPP TS 26.171 v13.0.0: Speech "Speech codec speech processing functions; Adaptive
              Multi-Rate - Wideband (AMR-
              WB) (AMR-WB) speech codec; General
              description.", 2015-12, 3GPP TS 26.171 v13.0.0, December 2015,
              <http://www.3gpp.org/DynaReport/26171.htm>.

   [TS26.173]
              3GPP, "3GPP TS 26.173 v13.1.0: ANSI-C "ANSI-C code for the Adaptive Multi-Rate - Wideband
              (AMR-WB) speech codec.",
              2016-03, codec", 3GPP TS 26.173 v13.1.0, March
              2016, <http://www.3gpp.org/DynaReport/26173.htm>.

   [TS26.190]
              3GPP, "3GPP TS 26.190 v13.0.0: Speech "Speech codec speech processing functions; Adaptive
              Multi-Rate - Wideband (AMR-
              WB) (AMR-WB) speech codec; Transcoding functions.", 2015-12,
              functions", 3GPP TS 26.190 v13.0.0, December 2015,
              <http://www.3gpp.org/DynaReport/26190.htm>.

   [TS26.204]
              3GPP, "3GPP TS 26.204 v13.1.0: Speech "Speech codec speech processing functions; Adaptive
              Multi-Rate - Wideband (AMR-
              WB) (AMR-WB) speech codec; ANSI-C
              code.", 2016-03, 3GPP TS 26.204 v13.1.0, March 2016,
              <http://www.3gpp.org/DynaReport/26204.htm>.

8.2.

6.2.  Informative references References

   [EN300175-1]
              ETSI, "ETSI EN 300 175-1, v2.6.1: Digital "Digital Enhanced Cordless Telecommunications
              (DECT); Common Interface (CI); Part 1: Overview", ETSI
              EN 300 175-1, v2.6.1, 2015, <http://www.etsi.org/deliver/
              etsi_en/300100_300199/30017501/02.06.01_60/
              en_30017501v020601p.pdf>.

   [EN300175-8]
              ETSI, "ETSI EN 300 175-8, v2.6.1: Digital "Digital Enhanced Cordless Telecommunications
              (DECT); Common Interface (CI); Part 8: Speech and audio
              coding and transmission.", ETSI EN 300 175-8, v2.6.1,
              2015, <http://www.etsi.org/deliver/
              etsi_en/300100_300199/30017508/02.06.01_60/
              en_30017508v020601p.pdf>.

   [G.711]    ITU, "Recommendation ITU-T G.711 (2012): Pulse    ITU-T, "Pulse code 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>.

   [I-D.ietf-rtcweb-overview]

   [IR.36]    GSMA, "Adaptive Multirate Wide Band", IR.36, Version 3.0,
              September 2014, <http://www.gsma.com/newsroom/all-
              documents/
              official-document-ir-36-adaptive-multirate-wide-band>.

   [OVERVIEW]
              Alvestrand, H., "Overview: Real Time Protocols for
              Browser-based Applications", draft-ietf-rtcweb-overview-15
              (work Work in progress), Progress, draft-ietf-
              rtcweb-overview-15, January 2016.

   [IR.36]    GSMA, "Adaptive Multirate Wide Band V3.0", September 2014,
              <http://www.gsma.com/newsroom/all-documents/
              official-document-ir-36-adaptive-multirate-wide-band>.

   [P.800]    ITU, "ITU-T P.800: Methods    ITU-T, "Methods for objective and subjective
              assessment determination of
              transmission quality", 1996-08, <https://www.itu.int/rec/
              T-REC-P.800-199608-I/en>. 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
              Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,
              September 2012, <http://www.rfc-editor.org/info/rfc6716>.

   [TS181005]
              ETSI, "Telecommunications and Internet converged Services
              and Protocols for Advanced Networking (TISPAN); Service
              and Capability Requirements V3.3.1 (2009-12)", ETSI
              TS 181005, 2009, <http://www.etsi.org/deliver/
              etsi_ts/181000_181099/181005/03.03.01_60/
              ts_181005v030301p.pdf>.

   [TS23.002]
              3GPP, "3GPP TS 23.002 v13.5.0: Network "Network architecture",
              2016-03, 3GPP TS23.002 v13.5.0, March
              2016, <http://www.3gpp.org/dynareport/23002.htm>.

7.

Acknowledgements

   The authors

   We would like to thank Magnus Westerlund, Barry Dingle Dingle, and Sanjay
   Mishra who carefully reviewed the document and helped to improve it.

Contributors

   The authors of following individuals contributed significantly to this document are 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 Marocco, Telecom Italia, enrico.marocco@telecomitalia.it ,

   though only the editor is listed on the front page.

Author's Address

   Stephane Proust (editor)
   Orange
   2, avenue Pierre Marzin
   Lannion  22307
   France

   Email: stephane.proust@orange.com