]> NVIDIA

sushin@nvidia.com

General avtcore WG Internet-Draft 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 and reuses the channel‑mapping concepts defined for the Ogg container in .

Introduction Opus () supports up to 255 channels via multistream with explicit channel mapping. The RTP payload format for Opus (), however, standardizes only mono/stereo signaling for RTP/SDP and leaves multistream out of scope. 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 .

Relationship to Existing RFCs This section summarizes the scope and relationship between (Opus codec), (Opus over RTP), (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. defines the RTP payload format for Opus but only covers mono/stereo signaling. This draft extends to define SDP signaling for multistream Opus in RTP sessions and reuses the mapping semantics from .

Relationship of RFCs and This Draft:

Summary of RFCs and This Draft:

Overview and Rationale Deployed systems (e.g., 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 Signaling for Opus Multistream

SDP Syntax for Multichannel Opus

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

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

• 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 (e.g., 6 for 5.1, 8 for 7.1).
• 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 mapping RTP channels to speaker positions.
• The channel_mapping values follow the Opus multistream mapping used by .

Offer/Answer Procedures 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 () 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 . Down‑conversion to stereo SHOULD NOT occur silently when the answerer supports the offered configuration.

Examples

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

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

Security Considerations The use of the multiopus encoding in SDP does not introduce new security concerns beyond those already described in . 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.

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.

Informative References WebRTC n.d. This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus-encoded speech and audio data necessary to integrate the codec in the most compatible way. It also provides an applicability statement for the use of Opus over RTP. Further, it describes media type registrations for the RTP payload format. This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream. This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK] This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]