WebRTC audio codecs for interoperability with legacy networks.

Abstract

This document presents use-cases underlying why WebRTC needs additional audio codecs besides just Opus and G.711. It also presents a way forward that takes into considerations the concerns expressed by the browser manufacturers.

Status of This Memo

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

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 and may be updated, replaced, or obsoleted by other documents 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 July 5, 2013.

Copyright Notice

Copyright (c) 2013 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.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Definitions
• 4. Use cases
• 4.1. AMR, AMR-WB
• 4.1.1. Use case
• 4.1.2. Problem
• 4.2. G.722
• 4.2.1. Use case
• 4.2.2. Problem
• 5. Concerns from the browser manufacturers
• 6. The proposed way-forward
• 7. Security Considerations
• 8. IANA Considerations
• 9. Acknowledgements
• 10. References
• 10.1. Normative references
• 10.2. Informative references
• Authors' Addresses

1. Introduction

The RTCWEB Working Group has currently drafted that Opus and G.711 will be the only audio codecs used in WebRTC (c.f. [I-D.ietf-rtcweb-audio]);

It has been anticipated that WebRTC will not remain an isolated island and that some WebRTC endpoints will need to communicate with devices existing in legacy networks. The Working Group currently thinks that G.711 is sufficient regarding the interoperability of audio codecs

This document presents use-cases underlying why WebRTC needs additional audio codecs besides just Opus and G.711. It also presents a way forward that takes into considerations the concerns expressed by the browser manufacturers.

In Section 4, we summarize the use-cases we want to fullfil.

In Section 5, we underline the concerns expressed by the browser manufacturers.

In Section 6, we present a way forward that will hopefully satisfy all parties.

2. Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119].

3. Definitions

Legacy networks: In this draft, legacy networks encompass the conversational networks that are already deployed like the PSTN, the PLMN, the IMS, H.323 networks.

4. Use cases

4.1. AMR, AMR-WB

4.1.1. Use case

A user of a WebRTC endpoint on a device integrating an AMR or AMR-WB module wants to communicate with another user that can only be reached on a mobile device that only support AMR-WB.

4.1.2. Problem

If OPUS and G.711 were the only codecs supported by the WebRTC endpoints, a gateway would need to transcode them into AMR or AMR-WB, and vice-versa, in order to implement the use-case. This is problematic for two major reasons : first, transcoding decreases the quality of the voice; Next, transcoding is CPU intensive, which dramatically increases the cost of the solution making it irrelevant from a business perspective.

4.2. G.722

4.2.1. Use case

A user of a WebRTC endpoint on a device integrating G.722 module wants to communicate with another user that can only be reached on a device that supports G.711 and G.722.

4.2.2. Problem

If OPUS and G.711 were the only codecs supported by the WebRTC endpoints, G.711 will be used by both endpoints. This may also be problematic given that G.722 has a much better quality than G.711.

5. Concerns from the browser manufacturers

The concern of the browser manufacturer is that they will have to pay if they implement AMR, AMR-WB or/and G.722.

6. The proposed way-forward

We propose that the browser manufacturer re-use the AMR, AMR-WB or/and G.722 module, if already pre-installed. The advantage is twofold: it avoids possible royalties related to such codecs, if any, for the browser manufacturer; it avoids writing significant codec code as the most important part is already written/chipped is the existing audio codec module.

7. Security Considerations

8. IANA Considerations

None.

9. Acknowledgements

10. References

10.1. Normative references

10.2. Informative references

Authors' Addresses