Summary of S4-260193: WebRTC Injectable Codecs

Document Overview

This pCR proposes adding detailed technical clauses to 3GPP TR 26.858 regarding support for injectable codecs in libwebrtc. The contribution addresses the need for greater flexibility in codec selection beyond the traditionally fixed set of audio and video codecs supported by libwebrtc.

Main Technical Contributions

5.3.2.4 Injectable Codec Support in libwebrtc

5.3.2.4.1 Introduction

• Feature Origin: Injectable codec mechanism introduced in Chromium M63
• Purpose: Enables integration of additional or custom audio codecs into WebRTC media pipeline without core source code modification
• Key Benefit: Provides flexibility for diverse communication scenarios and evolving service requirements
• 3GPP Relevance: Identified as suitable mechanism to extend libwebrtc with 3GPP codecs

5.3.2.4.2 Architecture and Principles of Operation

High-Level Architecture

• Implementation Approach: Utilizes customizable encoder and decoder factory interfaces
• Key Interfaces:
• AudioEncoderFactory class
• AudioDecoderFactory class
• Integration Point: Factories supplied to CreatePeerConnectionFactory() API during initialization
• Design Principle: Decouples codec implementation from core library
• Media Engine Role: Utilizes provided factories for codec negotiation, instantiation, and media processing

Codec Registration and Negotiation Flow

Three-Step Workflow: 1. Implementation or selection of encoder and decoder factories for desired codecs 2. Registration of factories with PeerConnectionFactory 3. Negotiation of codec capabilities during session establishment via SDP offer/answer exchange

Technical Requirements: - Factories must support SDP mapping functions (e.g., SdpToConfig()) - Must correctly advertise codec capabilities and parameters - Runtime codec selection based on negotiated SDP attributes and payload types - Provides fine-grained control over codec selection and interoperability

5.3.2.4.3 Usage Examples

Built-in Codecs

Basic Approach: Demonstrates usage of built-in codecs (Opus, G.711) through: - CreateBuiltinAudioEncoderFactory() - CreateBuiltinAudioDecoderFactory()

Selective Approach: Shows how to specify codec subset using template-based factory creation: - CreateAudioEncoderFactory<AudioEncoderOpus, AudioEncoderPCM>() - CreateAudioDecoderFactory<AudioDecoderOpus, AudioDecoderPCM>()

External (Injectable) Codecs

Implementation Steps: 1. Load external codec module via dynamic linking (e.g., libamr_codec_module.so) 2. Lookup factory entry points using dlsym() 3. Create codec factories from external module 4. Optionally combine with built-in codecs 5. Pass combined factories into PeerConnectionFactory

Key Capability: Enables runtime integration of external codecs with flexible combination of built-in codecs for advanced interoperability scenarios

5.3.2.4.4 Build and Deployment Options

Integration Approaches: - Built-in only - External module only - Hybrid approaches

Configuration: Controlled via GN flags and build scripts in libwebrtc's build system, supporting both static and dynamic linking of codec modules

Proposal

The document proposes adding these clauses to TR 26.858, either as: - A separate clause, or - Under existing clause 5.3.2.3 ("Libwebrtc")

Summary of S4-260194: Recommendations for TR 26.858 (FS_ACAPI)

Overview

This pCR proposes recommendations for TR 26.858 v0.8.0, adding new clause 7.2 and clause 8 to provide guidance on enabling 3GPP speech and audio codecs (AMR, AMR-WB, EVS, IVAS) in WebRTC-based applications and services. The recommendations build upon the injectable codec mechanism described in the study.

Clause 7.2: Injectable Codec Interfaces and Adapters for 3GPP Codecs in WebRTC

General Approach

The document recommends implementing support for 3GPP codecs (AMR, AMR-WB, EVS, IVAS) in WebRTC through injectable encoder and decoder factories, utilizing established libwebrtc extension points. This approach ensures: - Modularity and maintainability - Alignment with WebRTC architecture - Dynamic or static codec inclusion based on deployment needs

Interface Recommendations

The pCR proposes four key interface elements:

1. Codec Factory Interfaces: Implement AudioEncoderFactory and AudioDecoderFactory classes for each 3GPP codec, exposing all configuration options (mode, bandwidth, channel count, codec-specific parameters) and supporting SDP mapping functions

2. Adapter Layer: Provide translation between 3GPP codec APIs (reference implementations from clause 4 and Annex A) and libwebrtc factory interfaces, encapsulating codec-specific initialization, configuration, and error handling

3. Dynamic and Static Integration: Support both static linking (build-time inclusion) and dynamic loading (shared library via dlopen/dlsym) for flexible deployment

4. SDP and RTP Handling: Ensure correct codec capability advertisement in SDP, handling of codec-specific SDP attributes (EVS, IVAS), and RTP payload formatting per 3GPP and IETF specifications

Integration Steps

The document outlines a four-step integration process: 1. Implement/adapt encoder/decoder wrappers conforming to libwebrtc AudioEncoder and AudioDecoder interfaces 2. Register factories with PeerConnectionFactory at application startup 3. Update SDP negotiation logic to recognize and negotiate new codecs with required fmtp parameters 4. Validate with loopback and interoperability tests, ensuring conformance to 3GPP specifications and RTP payload formats

Complementarity with WebCodecs

The injectable codec mechanism is positioned as complementary to WebCodecs: - Injectable codecs target native and cross-platform WebRTC applications (including browser implementations based on libwebrtc) - WebCodecs supports browser-based deployments - Both approaches can operate in parallel for different use cases

Clause 8: Recommendations for Potential Normative Work

3GPP Responsibilities

The document recommends 3GPP should: - Continue maintaining specifications for 3GPP speech and audio codecs (AMR, AMR-WB, EVS, IVAS), including reference software and conformance test suites - Maintain codec-specific SDP and RTP payload handling in alignment with IETF payload format specifications - Specify codec interface requirements and recommended adapter patterns for real-time communication frameworks - Define APIs for the codecs - Identify and document use cases and requirements for 3GPP codec integration in WebRTC and browser environments

Collaboration with Other Bodies

The pCR identifies three key collaboration areas:

1. IETF: Responsible for RTP protocols, SDP negotiation, and signaling protocols. 3GPP should collaborate to ensure alignment and address gaps in payload/signaling support for new codecs

2. W3C: Responsible for WebRTC and WebCodecs APIs. 3GPP should provide requirements and technical input for 3GPP codec support in browser APIs and collaborate on codec-specific API extensions

3. Enabler Fora and Open-Source Communities: 3GPP should encourage publication of adapters, wrappers, and test assets through platforms like 5G-MAG or GitHub to facilitate adoption and interoperability in open-source projects (libwebrtc, browser engines)

Open Issues and Future Work

Three open issues are identified: - Definition and implementation of custom RTCPeerConnection objects based on RTPTransport for advanced media transport scenarios - Comprehensive browser-based WebRTC support for all 3GPP codecs requiring ongoing coordination - Evolution of WebCodecs and related APIs to support advanced 3GPP codec features (metadata, multi-stream, dynamic reconfiguration)

Summary of Normative Work Recommendations

• 3GPP should focus on codec technology, interface requirements, and reference assets while collaborating with IETF, W3C, and relevant fora (5G-MAG) or public projects
• Prioritize normative work where 3GPP has unique expertise or requirements
• Coordinate with other bodies to avoid duplication and maximize impact
• Track and address open issues through liaisons, joint work items, and public implementation efforts