RTP/SDP Signaling for Opus Multistream Operation

Introduction Opus () supports multistream encoding and channel mapping, enabling representation of multichannel audio configurations beyond mono and stereo. The RTP payload format for Opus defined in specifies signaling and transport procedures for Opus in RTP sessions, but primarily focuses on mono and stereo operation and does not define SDP signaling procedures for multistream multichannel configurations. defines channel mapping families for Opus carried in the Ogg container format. These mapping families assign semantic meaning to decoded output channels, such as speaker positions for surround sound layouts. The channel mappings do not alter the Opus bitstream or RTP payload format but define how decoded channels are to be interpreted by receivers. Several deployed implementations have supported multichannel Opus using implementation-specific SDP signaling approaches, commonly referred to as "multiopus". While these approaches have enabled deployment of surround-sound audio in practical systems, they have not been standardized and may present interoperability challenges across implementations. This document specifies interoperable SDP signaling and Offer/Answer procedures for Opus multistream operation in RTP sessions while continuing to use the Opus RTP payload format defined in and the channel mapping semantics defined in . This document is limited to RTP/SDP signaling for Opus multistream configurations already supported by , , and . It does not define new Opus codec features, bitstream formats, RTP payload formats, or decoding behavior. The MLCODEC Working Group is defining extensions to the Opus codec that may introduce additional codec capabilities. Such extensions are outside the scope of this document. Future Opus extensions may reuse the SDP signaling framework defined here, subject to the requirements and constraints of their respective specifications.

Relationship to Existing RFCs This section summarizes the scope and relationship between (Opus codec), (Opus over RTP), (Ogg encapsulation of Opus), and this document. defines the Opus codec, including support for multistream encoding and channel mapping. defines RTP transport and SDP signaling for Opus in RTP sessions but primarily addresses mono and stereo operation. defines channel mapping families for Opus carried in the Ogg container format. These mappings provide semantic interpretation of decoded output channels but do not define RTP usage or SDP signaling procedures. This document specifies SDP signaling and Offer/Answer procedures for Opus multistream operation in RTP sessions while continuing to use the RTP payload format defined in and the channel mapping semantics defined in .

Relationship of RFCs and This Draft

Summary of RFCs and This Document

Overview and Rationale Opus supports multistream operation and channel mappings that enable multichannel audio configurations such as 5.1 and 7.1. While such configurations have been deployed in practice, interoperable SDP signaling for these configurations has not been standardized for RTP sessions. Several deployed implementations (e.g., based) have historically used implementation-specific SDP signaling approaches, commonly referred to as "multiopus", together with parameters such as num_streams, coupled_streams, and channel_mapping. Although these approaches have enabled deployment of multichannel Opus, they are not standardized and may lead to interoperability challenges. This document standardizes SDP signaling semantics for Opus multistream operation while continuing to use the Opus RTP payload format defined in . Standardizing these semantics improves interoperability and removes the need for application-specific SDP modifications.

SDP Parameters for Opus Multistream

Field Descriptions

a=rtpmap:<pt> opus/<clock-rate>/<channel-count>
- <pt>: Dynamic payload type (e.g., 96).
- <clock-rate>: Fixed Opus RTP clock rate of 48000 Hz, as defined in . This placeholder represents the literal value 48000 in actual SDP.
- <channel-count>: Total number of output channels resulting from decoding.
a=fmtp:<pt> num_streams=<N>;coupled_streams=<M>;channel_mapping=<C>
- <pt>: Same payload type as in the corresponding a=rtpmap attribute.
- 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 according to the channel mapping semantics defined in .

Mapping Families and Extensibility Channel mapping families define the semantic interpretation of decoded output channels and do not alter the Opus bitstream or RTP payload format. This document normatively specifies SDP signaling for Mapping Family 1 (channel-based speaker layouts) as defined in . The signaling framework is designed to be extensible to additional mapping families, including Ambisonics or externally defined mappings, without requiring changes to the underlying Opus RTP payload format. An endpoint that receives an offer specifying a mapping family it does not support MUST reject the corresponding payload type during Offer/Answer negotiation.

Field Presence and Constraints The "channel_mapping" parameter MUST be present when the number of output channels exceeds two. For configurations with one or two output channels, the channel_mapping parameter MAY be omitted. If omitted, the receiver MUST interpret the configuration according to Mapping Family 0 semantics defined in . The values of "num_streams", "coupled_streams", and each entry in "channel_mapping" MUST be integers in the range 0 to 255. For Mapping Family 1, the number of output channels MUST NOT exceed eight.

SDP Examples

5.1 Audio The following example signals six output channels using four Opus streams, two of which are coupled streams. sdp a=rtpmap:111 opus/48000/6 a=fmtp:111 num_streams=4;coupled_streams=2;channel_mapping=0,4,1,2,3,5

7.1 Audio The following example signals eight output channels using five Opus streams, three of which are coupled streams. sdp a=rtpmap:111 opus/48000/8 a=fmtp:111 num_streams=5;coupled_streams=3;channel_mapping=0,6,1,2,3,4,5,7

Offer/Answer Procedures An offerer willing to negotiate multichannel Opus MAY include one or more Opus multistream payload configurations with the appropriate format parameters. For backward compatibility, an offerer SHOULD also include a stereo alternative using opus/<clock-rate>/2 as defined in . An answerer MAY accept an offered multistream configuration if it can parse the offered parameters and decode the resulting multichannel audio without loss of the negotiated channel semantics. If the answerer supports the offered multistream Opus configuration, it MUST select the corresponding payload type and include the selected parameters in the answer. If the offered configuration is not supported, the answerer MAY select a stereo Opus payload type or reject the media section according to . An answerer SHOULD NOT silently down-convert decoded output to stereo without providing an indication of that behavior to the application.

Examples

Offer: 5.1 Audio (6 channels) The following offer advertises a 5.1 multistream Opus configuration using payload type 111 and a stereo Opus fallback using payload type 112 for backward compatibility. sdp m=audio 9 UDP/TLS/RTP/SAVPF 111 112 a=mid:audio a=rtpmap:111 opus/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

Answer: Accept 5.1 Audio The answer selects payload type 111 and echoes the negotiated multistream parameters, indicating support for the offered 5.1-channel layout. sdp m=audio 9 UDP/TLS/RTP/SAVPF 111 a=mid:audio a=rtpmap:111 opus/48000/6 a=fmtp:111 num_streams=4;coupled_streams=2;channel_mapping=0,4,1,2,3,5 a=sendrecv

Security Considerations The SDP signaling procedures defined in this document do not introduce security considerations beyond those already described in . Implementations SHOULD ensure that SDP parsing and RTP payload handling are robust against malformed or malicious input. Implementations SHOULD validate multistream configuration parameters, including channel mappings, stream counts, and coupled-stream counts, before use. Applications using multichannel Opus streams should also consider the privacy implications of transmitting spatial audio information, which may reveal environmental or application context beyond that conveyed by mono or stereo audio. Transport-level security mechanisms such as DTLS-SRTP are RECOMMENDED to protect RTP streams from unauthorized access or modification.

IANA Considerations This document does not request registration of a new RTP payload format or media subtype. The SDP parameters defined by this specification are intended for use with the existing Opus RTP payload format defined in . No IANA action is required by this document.

Acknowledgements The author would like to thank Philipp Hancke for his detailed review and constructive feedback during the AVTCORE adoption discussion. His comments helped shape the direction of this document from standardizing a deployment-specific "multiopus" signaling approach toward specifying interoperable SDP signaling for Opus multistream operation while continuing to use the Opus RTP payload format defined in . The author would also like to thank Hyunsik Yang for his careful review of the document and for identifying editorial issues and textual improvements during the adoption process. The author further thanks Erik Språng, Timothy Terriberry, Mo Zanaty, the AVTCORE chairs, and other working group participants for their review, comments, and support.