RFC 7875

Additional WebRTC Audio Codecs for Interoperability

📅 published May 2016, from ietf

RFC 7875: Additional WebRTC Audio Codecs for Interoperability 🎀

Okay bestie, let's talk about RFC 7875 💖 It's titled Additional WebRTC Audio Codecs for Interoperability. The IETF (Internet Engineering Task Force) published it, and the editor is S. Proust, Ed. from Orange. It's an Informational document, not a Standards Track spec, and it came out in May 2016. Its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's just doing its own thing 💅

Abstract

Okay so, WebRTC endpoints need a baseline so they can actually talk to each other 🫶 That's why a minimum set of required codecs gets specified. BUT, to give the session the best shot at connecting without audio transcoding, it's also recommended to put other suitable audio codecs that the browser can handle into the offer ✨

This document gives some guidelines on which codecs are worth considering for WebRTC endpoints, focused on the use cases that matter most for interoperability 🦋

Status of This Memo

Ngl, this part is a little formal, but here's the tea 🍓 This document is not an Internet Standards Track specification. It's published for informational purposes only.

It's a product of the Internet Engineering Task Force (IETF), and it's been approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for more on that.

For the current status of this document, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7875.

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) as they stand on the date of publication. Please read these carefully, because they spell out your rights and restrictions for 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 they come without warranty, as described in the Simplified BSD License.

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Definitions and Abbreviations . . . . . . . . . . . . . . . .   3
3.  Rationale for Additional WebRTC Codecs  . . . . . . . . . . .   4
4.  Additional Suitable Codecs for WebRTC . . . . . . . . . . . .   5
  4.1.  AMR-WB  . . . . . . . . . . . . . . . . . . . . . . . . .   5
    4.1.1.  AMR-WB General Description  . . . . . . . . . . . . .   5
    4.1.2.  WebRTC-Relevant Use Case for AMR-WB . . . . . . . . .   5
    4.1.3.  Guidelines for AMR-WB Usage and Implementation with
            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.1.  G.722 General Description . . . . . . . . . . . . . .   7
    4.3.2.  WebRTC-Relevant Use Case for G.722  . . . . . . . . .   8
    4.3.3.  Guidelines for G.722 Usage and Implementation with
            WebRTC  . . . . . . . . . . . . . . . . . . . . . . .   8
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
  6.2.  Informative References  . . . . . . . . . . . . . . . . .  10
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction 🌸

As [OVERVIEW] says, WebRTC isn't going to stay an isolated island. Some WebRTC endpoints will need to talk to devices on other existing networks, with the help of a gateway 🧚 So, to give the session the best chance of connecting without audio transcoding, [RFC7874] recommends putting other suitable audio codecs into the offer, beyond the ones that are mandatory to implement. This document gives some guidelines on which codecs are worth considering for WebRTC endpoints, focused on the use cases that matter most for interoperability.

The codecs covered here are recommended to be supported and included in the offer only for WebRTC endpoints where interoperability with non-WebRTC endpoints and non-WebRTC-based services is relevant. That's the scenario described in Sections 4.1.2, 4.2.2, and 4.3.2. Other use cases might justify offering other additional codecs to avoid transcoding 👑

2. Definitions and Abbreviations 📚

  • Legacy networks: In this document, legacy networks means the conversational networks that are already deployed, like the PSTN, the PLMN, and the IP/IMS networks offering VoIP services. That includes 3GPP "4G" Evolved Packet System [TS23.002] supporting voice over LTE (VoLTE) radio access [IR.92].
  • WebRTC endpoint: A WebRTC endpoint can be a WebRTC browser or a WebRTC non-browser (also called "WebRTC device" or "WebRTC native application"), as defined in [OVERVIEW].
  • AMR: Adaptive Multi-Rate
  • AMR-WB: Adaptive Multi-Rate Wideband
  • CAT-iq: Cordless Advanced Technology - internet and quality
  • DECT: Digital Enhanced Cordless Telecommunications
  • IMS: IP Multimedia Subsystems
  • LTE: Long Term Evolution (3GPP "4G" wireless data transmission standard)
  • MOS: Mean Opinion Score, defined in ITU-T Recommendation P.800 [P.800]
  • PSTN: Public Switched Telephone Network
  • PLMN: Public Land Mobile Network
  • VoLTE: Voice over LTE

3. Rationale for Additional WebRTC Codecs 💜

Opus [RFC6716] is mandatory to implement in WebRTC endpoints, and that's what gives you codec interoperability without transcoding, at state-of-the-art voice quality (better than narrow-band "PSTN" quality) between WebRTC endpoints. Iconic. 👑 But WebRTC is also expected to talk to other types of endpoints, running other technologies. For example, it can be an access technology for VoLTE services (Voice over LTE, as specified in [IR.92]), or it can interoperate with fixed or mobile Circuit-Switched or VoIP services, like mobile Circuit-Switched voice over 3GPP 2G/3G mobile networks [TS23.002] or DECT-based VoIP telephony [EN300175-1].

So a big number of calls are likely to happen between WebRTC endpoints and terminals like mobile handsets, fixed VoIP terminals, and DECT terminals. Those terminals don't support WebRTC endpoints and don't implement Opus 🙈 As a result, these calls will probably end up either at low narrow-band PSTN quality using G.711 [G.711] on both ends, or affected by transcoding. Here's the drawback of transcoding:

  • Degraded user experience with respect to voice quality: Voice quality gets significantly degraded by transcoding. For instance, the degradation is around 0.2 to 0.3 MOS for most transcoding use cases with the AMR-WB codec (Section 4.1) at 12.65 kbit/s, and it's in the same range for other wideband transcoding cases. It's worth stressing that if G.711 is used as a fallback codec for interoperation, wideband voice quality is lost. That bandwidth drop down to narrow band clearly hurts the user-perceived quality of service, which leads to shorter and less frequent calls. Switching to G.711 is a choice for customers. If transcoding is performed between Opus and any other wideband codec, wideband communication can be maintained, but with degraded quality (the MOSs of transcoding between AMR-WB at 12.65 kbit/s and Opus at 16 kbit/s in both directions are significantly lower than those of AMR-WB at 12.65 kbit/s or Opus at 16 kbit/s). On top of that, in degraded conditions, extra defects like (a) audio artifacts due to packet losses and (b) audio effects due to the cascading of different packet loss recovery algorithms may push the quality below the acceptable limit for customers 😭
  • Degraded user experience with respect to conversational interactivity: Conversational interactivity suffers because transcoding increases the end-to-end latency in both directions. Transcoding requires full de-packetization to decode the media stream (including de-jitter buffering and packet loss recovery), then re-encoding, re-packetization, and resending. Those delays all add up, and they can push the end-to-end delay up to 1 second, which is way beyond the acceptable limit ⏳
  • Additional cost in networks: Transcoding places important additional cost on network gateways. That's mainly tied to codec implementation, codec licenses, deployment, testing, and validation costs. It must be noted that transcoding wideband to wideband would require more CPU processing and be more costly than transcoding between narrowband codecs 💸

4. Additional Suitable Codecs for WebRTC ✨

The codecs below are considered relevant for the general purpose described in Section 3. This list reflects the current status of foreseen use cases for WebRTC. It's not limitative: it's open to including other codecs for which relevant use cases can be identified. It's recommended to include codecs (in addition to Opus and G.711) according to the foreseen interoperability cases you want to address 🦋

4.1. AMR-WB 🎧

4.1.1. AMR-WB General Description

The Adaptive Multi-Rate WideBand (AMR-WB) is a 3GPP-defined speech codec that's mandatory to implement in any 3GPP terminal that supports wideband speech communication. It's used in circuit-switched mobile telephony services and in new multimedia telephony services over IP/IMS. It's especially used for voice over LTE, as specified by GSMA in [IR.92]. You can find more detailed info on AMR-WB in [IR.36]. References for 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 for AMR-WB

The personal voice communication market is driven by mobile terminals 📱 AMR-WB is now very widely implemented in devices and networks offering "HD voice," where "HD" stands for "High Definition." So a high number of calls are likely to happen between WebRTC endpoints and mobile 3GPP terminals offering AMR-WB. That means WebRTC endpoints using AMR-WB would allow transcoding-free interoperation with all mobile 3GPP wideband terminals, which is giving main character energy 👑 Plus, WebRTC endpoints running on mobile terminals (smartphones) may reuse the AMR-WB codec that's already implemented on those devices 🌈

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

okay so the AMR-WB payload format is in [RFC4867] 🧚. You want the bandwidth-efficient format with one speech frame in each RTP packet. For more tips on implementing AMR-WB and keeping it compatible with 3GPP mobile services, check [TS26.114]. And if you're aiming for 4G/VoLTE interop as GSMA defines it, the more specific IMS voice profile derived from [TS26.114] should be considered in [IR.92] 💜.

To give your call the best shot at actually connecting, it is important that the WebRTC endpoints:

  • Offer AMR in addition to AMR-WB, with AMR-WB listed first (AMR-WB being a wideband codec) as the preferred payload type with respect to other narrow-band codecs (AMR, G.711, etc.) and with a bandwidth-efficient payload format preferred. 👑
  • Be capable of operating AMR-WB with any subset of the nine codec modes and source-controlled rate operation. 🌈
  • Offer at least one AMR-WB configuration with parameter settings as defined in Table 6.1 of [TS26.114]. In order to maximize 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. 🫶

4.2. AMR 🦋

4.2.1. AMR General Description

AMR (Adaptive Multi-Rate) is a 3GPP-defined speech codec that is mandatory to implement in any 3GPP terminal that supports voice communication ✨. That covers mobile phone calls over GSM and 3G cellular systems, plus multimedia telephony over IP/IMS and 4G/VoLTE, like the GSMA voice IMS profile for VoLTE in [IR.92]. If you want the deep details, including the codec description and source code, the AMR-related specs are [TS26.071], [TS26.073], [TS26.090], and [TS26.104] 📚.

4.2.2. WebRTC-Relevant Use Case for AMR 📱

picture this: a user on a WebRTC endpoint, on a device with an AMR module, wants to call someone who can only be reached on a mobile device that supports only AMR 🙈. More and more terminals are "HD voice" and support AMR-WB, but there are still a lot of legacy terminals that only do AMR (no wideband or HD voice) and are still in use. So WebRTC endpoints using AMR would allow transcoding-free interoperation with all mobile 3GPP terminals, which is so iconic 💅. Plus, WebRTC endpoints running on mobile terminals (smartphones) may reuse the AMR codec that's already implemented on those devices.

4.2.3. Guidelines for AMR Usage and Implementation with WebRTC 🌸

The AMR payload format is described in [RFC4867] with a bandwidth-efficient format and one speech frame in each RTP packet. For more guidelines on implementing and using AMR to ensure interoperability with 3GPP mobile services, see [TS26.114]. For 4G/VoLTE interop as specified by GSMA, the more specific IMS voice profile derived from [TS26.114] should be considered in [IR.92]. To maximize the chance of successful call establishment for WebRTC endpoints offering AMR, it is important that the WebRTC endpoints:

  • Be capable of operating AMR with any subset of the eight codec modes and source-controlled rate operation. 🍓
  • Offer at least one configuration with parameter settings as defined in Tables 6.1 and 6.2 of [TS26.114]. In order to maximize the interoperability and quality, this offer shall not restrict AMR codec modes offered. Restrictions on the use of codec modes may be included in the answer. 💖

4.3. G.722 🧚

4.3.1. G.722 General Description

G.722 [G.722] is an ITU-T-defined wideband speech codec 🎧. It was approved by the ITU-T in 1988. It's royalty-free and common in a wide range of terminals and endpoints that support wideband speech and need low complexity, so it's very much a classic ✨. Its complexity is estimated at 10 MIPS [EN300175-8], which is 2.5 to 3 times lower than AMR-WB. ETSI DECT chose G.722 as the mandatory wideband codec for New Generation DECT, to greatly boost voice quality by extending the bandwidth from narrow band to wideband 🔥. G.722 is also the wideband codec required for terminals certified as CAT-iq DECT. Version 2.0 of the CAT-iq specifications was approved by GSMA as the minimum requirements for the "HD voice" logo on "fixed" devices, meaning broadband connections using the G.722 codec 👑.

4.3.2. WebRTC-Relevant Use Case for G.722 📞

G.722 is the wideband codec required for DECT CAT-iq terminals. DECT cordless phones are still widely used to offer short-range wireless connections to PSTN or VoIP services 🌈. ETSI also specified G.722 in [TS181005] as the mandatory wideband codec for the IMS multimedia telephony communication service and supplementary services over fixed broadband access. So supporting G.722 would allow transcoding-free IP interoperation between WebRTC endpoints and fixed VoIP terminals, including DECT CAT-iq terminals that support G.722 🫶. Plus, WebRTC endpoints on fixed terminals that implement G.722 may reuse the G.722 codec already on those devices.

4.3.3. Guidelines for G.722 Usage and Implementation with WebRTC 🛠️

The G.722 payload format is defined in [RFC3551], with each octet of the stream of octets produced by the codec octet-aligned in an RTP packet 🦋. The G.722 sampling frequency is 16 kHz, but the RTP clock rate is set to 8000 Hz in SDP. That keeps it backward compatible with an erroneous definition in the original version of the RTP audio/video profile, which is a little oof 🙈. For more guidelines on implementing and using G.722 to ensure interoperability with multimedia telephony services over IMS, see Section 7 of [TS26.114]. More info about the G.722 implementation in DECT is in [EN300175-8], and the full codec description and C source code are in [G.722] 💜.

5. Security Considerations 🔐

Relevant security considerations are in [RFC7874], "WebRTC Audio Codec and Processing Requirements", and this part is seriously important, bestie 😭. Implementers using 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] (for the RTP audio/video profile) 🔒.

6. References 📚

6.1. Normative References

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

[IR.92]    GSMA, "IMS Profile for Voice and 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, JM. 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, "Mandatory Speech Codec speech processing functions;
           AMR Speech CODEC; General description", 3GPP TS 26.171
           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>.

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

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

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

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

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

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

6.2. Informative References 📚

Okay bestie, these are the "for more reading" references. They're not required to build the thing, but they're the receipts behind the stuff we're talking about. 💅

[EN300175-1] ETSI, "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, "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-T, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988, <http://www.itu.int/rec/T-REC-G.711-198811-I/en>. The OG codec of the phone world, iconic and timeless. 🎀

[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>. Mobile networks really be out here with the AMR-WB paperwork. 📱

[OVERVIEW] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, draft-ietf-rtcweb-overview-15, January 2016. This is the big-picture map of how the real-time browser stuff fits together. 🗺️

[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>. This one's all about how people actually rate how good a call sounds. Real listeners, real opinions. 🎧

[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>. Opus is the queen of the audio codecs, no debate. 👑

[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>. Requirements, but make it a service. 💼

[TS23.002] 3GPP, "Network architecture", 3GPP TS23.002 v13.5.0, March 2016, <http://www.3gpp.org/dynareport/23002.htm>. The blueprint for how the whole mobile network is wired together. Structure is everything. 🏗️

Acknowledgements 🫶

We would like to thank Magnus Westerlund, Barry Dingle, and Sanjay Mishra who carefully reviewed the document and helped to improve it. Honestly, the reviewers are the unsung heroes, so big shoutout to them. 🌸

Contributors 💜

The following individuals contributed significantly to this document:

  • Stephane Proust, Orange, stephane.proust@orange.com
  • Espen Berger, Cisco, espeberg@cisco.com
  • Bernhard Feiten, Deutsche Telekom, Bernhard.Feiten@telekom.de
  • Bo Burman, Ericsson, bo.burman@ericsson.com
  • Kalyani Bogineni, Verizon Wireless, Kalyani.Bogineni@VerizonWireless.com
  • Mia Lei, Huawei, lei.miao@huawei.com
  • Enrico 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

And that's the whole spec, bestie! 🌈💖🎀

📦 where this page comes from