RTP/SDP for Opus Multistream
draft-shin-avtcore-rtp-multi-opus-03

Audio/Video Transport Core Maintenance                           S. Shin
Internet-Draft                                                    NVIDIA
Intended status: Informational                             16 April 2026
Expires: 18 October 2026

                      RTP/SDP for Opus Multistream
                  draft-shin-avtcore-rtp-multi-opus-03

Abstract

   This document specifies RTP/SDP signaling for Opus multistream
   (multi-channel) operation, enabling negotiation of layouts such as
   5.1 and 7.1 in real-time communications.  It defines an SDP encoding
   name and format parameters to describe multistream configurations,
   and specifies Offer/Answer procedures for interoperable negotiation.
   This document does not define new Opus codec behavior.  It extends
   the the SDP signaling defined in [RFC7587] and reuses the
   channel-mapping semantics defined in [RFC7845].

Status of This Memo

   This Internet-Draft is submitted 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 https://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 18 October 2026.

Copyright Notice

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

Shin                     Expires 18 October 2026                [Page 1]
Internet-Draft                 MULTI-OPUS                     April 2026

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Relationship to Existing RFCs . . . . . . . . . . . . . . . .   3
   3.  Relationship of RFCs and This Draft:  . . . . . . . . . . . .   3
   4.  Summary of RFCs and This Draft: . . . . . . . . . . . . . . .   3
   5.  Overview and Rationale  . . . . . . . . . . . . . . . . . . .   4
   6.  SDP Signaling for Opus Multistream  . . . . . . . . . . . . .   4
     6.1.  SDP Syntax for Multichannel Opus  . . . . . . . . . . . .   4
       6.1.1.  SDP Example for 5.1 Audio . . . . . . . . . . . . . .   4
       6.1.2.  SDP Example for 7.1 Audio . . . . . . . . . . . . . .   4
       6.1.3.  Mapping Families and Extensibility  . . . . . . . . .   4
       6.1.4.  Field Descriptions  . . . . . . . . . . . . . . . . .   5
       6.1.5.  Field Presence and Constraints  . . . . . . . . . . .   5
   7.  Offer/Answer Procedures . . . . . . . . . . . . . . . . . . .   5
     7.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   6
       7.1.1.  Offer: 5.1 (6 channels) . . . . . . . . . . . . . . .   6
       7.1.2.  Answer: accept 5.1  . . . . . . . . . . . . . . . . .   6
     7.2.  Security Considerations . . . . . . . . . . . . . . . . .   6
     7.3.  IANA Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Opus ([RFC6716]) supports up to 255 channels via multistream encoding
   with explicit channel mapping.  The RTP payload format for Opus
   ([RFC7587]), however, standardizes only mono and stereo signaling and
   does not dfeind for RTP/SDP for multistream operation.

   [RFC7845] defines channel-mapping families for Opus carried in the
   Ogg container, assigning semantic meaning to decoded output channels
   (e.g., speaker positions or spherical harmonics).  Theses mapping
   families do not alter the Opus bitstream or RTP payload format, but
   define how decoded channels are to be interpreted.

Shin                     Expires 18 October 2026                [Page 2]
Internet-Draft                 MULTI-OPUS                     April 2026

   This document fills that gap by specifying interoperable SDP
   signaling and Offer/Answer procedures for multistream operations in
   RTP sessions, while reusing the channel mapping semantics defined in
   [RFC7845].

   This document is limited to RTP/SDP signaling for Opus multistream
   configurations already defined in [RFC6716], [RFC7587], and
   [RFC7845].  It does not define new Opus codec features, bitstream
   formats, or decoding behavior.

   The MLCODEC Working Group is defining extensions to the Opus codec
   that may introduce new codec capabilities.  Such extensions are out
   of scope for this document.  Future Opus codec extensions may reuse
   the SDP signaling framework defined here, subject to the constraints
   of the extension specification.

2.  Relationship to Existing RFCs

   This section summarizes the scope and relationship between [RFC6716]
   (Opus codec), [RFC7587] (Opus over RTP), [RFC7845] (Ogg encapsulation
   of Opus), and this draft.  While [RFC7845] defines channel mapping
   families for multistream Opus in the Ogg container, it does not
   define SDP signaling or RTP usage.  [RFC7587] defines the RTP payload
   format for Opus but only covers mono/stereo signaling.  This draft
   extends [RFC7587] to define SDP signaling for multistream Opus in RTP
   sessions and reuses the mapping semantics from [RFC7845].

3.  Relationship of RFCs and This Draft:

     +----------------+     +-------------------+     +----------------+
     |   RFC 6716     |     |     RFC 7845      |     |   RFC 7587     |
     |  Opus Codec    |     | Ogg Encapsulation |     | Opus over RTP  |
     +----------------+     +-------------------+     +----------------+
              |                       |                        |
              |                       |                        |
              +-----------------------+------------------------+
                                      |
                                      v
                      +------------------------------+
                      |  This Draft (Multi-Opus RTP) |
                      |  SDP Signaling + O/A Rules   |
                      +------------------------------+

4.  Summary of RFCs and This Draft:

Shin                     Expires 18 October 2026                [Page 3]
Internet-Draft                 MULTI-OPUS                     April 2026

 +------------+----------------------+-----------------------+-----------------------+
 | RFC/Draft  | Scope                | Defines Channel Map?  | Defines SDP Signaling |
 +------------+----------------------+-----------------------+-----------------------+
 | RFC 6716   | Opus codec           | Yes (API level)       | No                    |
 | RFC 7845   | Ogg encapsulation    | Yes (families)        | No                    |
 | RFC 7587   | RTP payload format   | No (mono/stereo only) | Yes (mono/stereo)     |
 | This Draft | RTP multistream SDP  | Reuses RFC 7845       | Yes (multi-channel)   |
 +------------+----------------------+-----------------------+-----------------------+

5.  Overview and Rationale

   Deployed systems (e.g., [libwebrtc] based) interoperate using a
   non-standard SDP encoding name “multiopus” with fmtp parameters such
   as num_streams, coupled_streams, and channel_mapping.  Standardizing
   these semantics improves interoperability and removes the need for
   application-level SDP text modifications.

6.  SDP Signaling for Opus Multistream

6.1.  SDP Syntax for Multichannel Opus

6.1.1.  SDP Example for 5.1 Audio

   sdp a=rtpmap:111 multiopus/48000/6 a=fmtp:111
   num_streams=4;coupled_streams=2;channel_mapping=0,4,1,2,3,5

6.1.2.  SDP Example for 7.1 Audio

   sdp a=rtpmap:111 multiopus/48000/8 a=fmtp:111
   num_streams=5;coupled_streams=3;channel_mapping=0,6,1,2,3,4,5,7

6.1.3.  Mapping Families and Extensibility

   Channel mapping families define the semantic interpretation of
   decoded output channels and do not affect the RTP payload format
   beyond establishing the number of streams and output channels.

   This document normatively specifies SDP signaling for mapping family
   1 (channel-based speaker layouts) as defined in [RFC7845].  The SDP
   signaling mechanism is designed to be extensible to additional
   mapping families (e.g., Ambisonics or externally defined mappings)
   without changes to the RTP payload format.

   An endpoint that receives an offer specifying a mapping family it
   does not support MUST reject that payload type during Offer/Answer
   negotiation.

Shin                     Expires 18 October 2026                [Page 4]
Internet-Draft                 MULTI-OPUS                     April 2026

6.1.4.  Field Descriptions

   *  a=rtpmap:<pt> multiopus/48000/<channel-count>

      -  <pt>: Dynamic payload type (e.g., 96).

      -  48000: Fixed clock rate for Opus.

      -  <channel-count>: Total number of output channels resulting from
         decoding.

   *  a=fmtp:<pt>
      num_streams=<N>;coupled_streams=<M>;channel_mapping=<C>

      -  num_streams: Total number of Opus streams.

      -  coupled_streams: Number of stereo (coupled) streams.

      -  channel_mapping: Comma-separated list defining the mapping from
         decoded channels to semantic output positions, following the
         channel mapping semantics defined in [RFC7845].

6.1.5.  Field Presence and Constraints

   The "channel_mapping" parameter is REQUIRED for configurations with
   more than two output channels.

   For configurations with a single stream and one or two output
   channels, "channel_mapping" MAY be omitted.  If omitted, the receiver
   MUST interpret the configuration as equivalent to [RFC7845] mapping
   family 0 semantics for mono or stereo output.

   The values of "num_streams", "coupled_streams", and each entry in
   "channel_mapping" MUST be integers in the range 0..255.

   For mapping family 1, the number of output channels MUST NOT exceed
   8.

7.  Offer/Answer Procedures

   An offerer willing to negotiate multichannel Opus MAY include one or
   more payload types using multiopus with appropriate fmtp parameters,
   and SHOULD include a stereo alternative using opus/48000/2
   ([RFC7587]) for backward compatibility.

   An answerer that supports the offered configuration if it can parse
   the offered paramters and decode the resulting multichannel audio
   without loss of the negotiated channel semantics.

Shin                     Expires 18 October 2026                [Page 5]
Internet-Draft                 MULTI-OPUS                     April 2026

   If the answer supports the offered multiopus configration, it MUST
   select the corresponding payload type and include the selected
   multistream parameters in the answer.

   If unsupported, the answerer MAY select a stereo opus payload or
   reject the m-section per [RFC3264].  An answer that supports the
   offered configurations SHOULD NOT silently down-convert the decoded
   output to streo without indicating that behavor to the application.

7.1.  Examples

7.1.1.  Offer: 5.1 (6 channels)

   m=audio 9 UDP/TLS/RTP/SAVPF 111 112 a=mid:audio a=rtpmap:111
   multiopus/48000/6 a=fmtp:111
   num_streams=4;coupled_streams=2;channel_mapping=0,4,1,2,3,5
   a=rtpmap:112 opus/48000/2 a=sendrecv

7.1.2.  Answer: accept 5.1

   m=audio 9 UDP/TLS/RTP/SAVPF 111 a=mid:audio a=rtpmap:111
   multiopus/48000/6 a=fmtp:111
   num_streams=4;coupled_streams=2;channel_mapping=0,4,1,2,3,5
   a=sendrecv

7.2.  Security Considerations

   The use of the multiopus encoding in SDP does not introduce new
   security concerns beyond those already described in [RFC7587].
   Implementers should ensure that SDP parsing and RTP payload handling
   are robust against malformed or malicious input.  Applications using
   multichannel Opus streams must also consider the privacy implications
   of transmitting spatial audio data, which may reveal environmental
   context.

   Transport-level security mechanisms such as DTLS-SRTP are recommended
   to protect RTP streams.

7.3.  IANA Considerations

   This document does not require any new IANA registrations.  The
   multiopus encoding name and associated SDP attributes are used in
   accordance with existing conventions and do not introduce new
   protocol elements.

8.  Informative References

Shin                     Expires 18 October 2026                [Page 6]
Internet-Draft                 MULTI-OPUS                     April 2026

   [libwebrtc]
              WebRTC, "Opus multistream mapping", n.d.,
              <https://webrtc-review.googlesource.com/c/src/+/129768>.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,
              <https://www.rfc-editor.org/rfc/rfc3264>.

   [RFC6716]  Valin, JM., Vos, K., and T. Terriberry, "Definition of the
              Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,
              September 2012, <https://www.rfc-editor.org/rfc/rfc6716>.

   [RFC7587]  Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format
              for the Opus Speech and Audio Codec", RFC 7587,
              DOI 10.17487/RFC7587, June 2015,
              <https://www.rfc-editor.org/rfc/rfc7587>.

   [RFC7845]  Terriberry, T., Lee, R., and R. Giles, "Ogg Encapsulation
              for the Opus Audio Codec", RFC 7845, DOI 10.17487/RFC7845,
              April 2016, <https://www.rfc-editor.org/rfc/rfc7845>.

Author's Address

   Sun Shin
   NVIDIA
   Email: sushin@nvidia.com

Shin                     Expires 18 October 2026                [Page 7]