| Internet-Draft | MULTI-OPUS | October 2025 |
| Shin | Expires 22 April 2026 | [Page] |
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 extends the Opus RTP payload format defined in [RFC7587] and reuses the channel‑mapping concepts defined for the Ogg container in [RFC7845].¶
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 22 April 2026.¶
Copyright (c) 2025 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 (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.¶
Opus ([RFC6716]) supports up to 255 channels via multistream with explicit channel mapping. The RTP payload format for Opus ([RFC7587]), however, standardizes only mono/stereo signaling for RTP/SDP and leaves multistream out of scope. [RFC7845] defines channel‑mapping families for Opus carried in the Ogg container, but it does not define RTP/SDP signaling or Offer/Answer behavior. This document fills that gap by specifying interoperable SDP signaling and Offer/Answer procedures for multistream Opus in RTP sessions, while aligning channel‑mapping semantics with [RFC7845].¶
This section summarizes the scope and relationship between [RFC6716] (Opus codec), [RFC7587] (Opus over RTP), [RFC7845] (Ogg encapsulation of Opus), and this draft. While RFC 7845 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].¶
+----------------+ +-------------------+ +----------------+
| RFC 6716 | | RFC 7845 | | RFC 7587 |
| Opus Codec | | Ogg Encapsulation | | Opus over RTP |
+----------------+ +-------------------+ +----------------+
| | |
| | |
+-----------------------+------------------------+
|
v
+------------------------------+
| This Draft (Multi-Opus RTP) |
| SDP Signaling + O/A Rules |
+------------------------------+
¶
+------------+----------------------+-----------------------+-----------------------+ | 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) | +------------+----------------------+-----------------------+-----------------------+¶
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.¶
sdp
a=rtpmap:111 multiopus/48000/6
a=fmtp:111 num_streams=4;coupled_streams=2;channel_mapping=0,4,1,2,3,5
### 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
### Field Descriptions¶
An offerer willing to negotiate multichannel Opus MAY include one or more payload types using multiopus with appropriate fmtp, and SHOULD include a stereo alternative using opus/48000/2 ([RFC7587]) for backward compatibility.¶
An answerer that supports the offered multiopus configuration 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]. Down‑conversion to stereo SHOULD NOT occur silently when the answerer supports the offered configuration.¶
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¶
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¶
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.¶
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.¶