Multiplexing lets independent signals or data streams share a communication resource while remaining separable at the receiver. In real-time voice, that resource might be a circuit, a Real-time Transport Protocol (RTP) session, or a network transport. Knowing which one is shared helps explain how audio reaches the right decoder, what endpoints must negotiate, and which failures affect more than one stream.
What multiplexing means
Multiplexing, often shortened to muxing, carries several independent inputs over a shared resource. Demultiplexing, or demuxing, separates them again. The receiver needs an agreed way to identify each input, such as its frequency band, time slot, or packet identifier.
The combining side is the multiplexer. The separating side is the demultiplexer.
A simple packet example is two microphone streams, A and B. Their packets can travel as A1, B1, A2, B2 over one transport. The receiver sorts them back into A and B before decoding. Sharing the transport does not require combining the microphone recordings into one audible track.
The RTP multiplexing guidelines define the important boundary: the individual inputs remain addressable and can be separated unambiguously. A shared resource without enough identification information is an incomplete design.
The main types of multiplexing
Traditional multiplexing divides a physical communication resource:
- Frequency-division multiplexing (FDM): signals occupy different frequency bands on the same medium.
- Time-division multiplexing (TDM): signals take turns in assigned time slots. Synchronous TDM uses a repeating frame and a known slot position for each channel.
- Wavelength-division multiplexing (WDM): optical signals share a fiber at different wavelengths.
- Code-division multiplexing (CDM): signals share time and frequency resources and are distinguished through their codes.
Packet networks also share links by interleaving packets from different flows as traffic arrives. This statistical sharing differs from reserving a fixed slot in every synchronous frame. These are established communications multiplexing techniques, with different identification and resource-allocation rules.
For voice engineers, TDM is the useful circuit-network contrast. The International Telecommunication Union's G.704 frame structures define synchronous digital frames with channel time slots. An RTP packet arriving on a network socket is identified through packet and session context rather than its position in that circuit frame.
Multiplexing, mixing, and simultaneous calls are different
An audio mixer combines audio content. A conference mixer can turn several participants' inputs into one outgoing audio stream. An RTP mixer sends that result under its own source identifier and can identify contributing sources. Those contribution labels do not generally let the receiver reconstruct each original recording from the mixed audio. The RTP mixer definition makes this distinction explicit.
Multiplexed microphone streams remain separate inputs. Mixed microphone audio becomes a combined signal. A voice application may need both operations at different points, for example, separate inputs for analysis and a mixed output for playback.
Concurrent calls describe how many conversations are active at once. Concurrency does not specify whether those calls share a physical link, a process, a socket, or a media session. Several calls using the same telephony trunk are not evidence that all their audio belongs to one RTP session.
We manage the conversation runtime at Dasha and connect phone calls through customer-configured telephony. The distinction between application ownership and media transport matters: choosing a managed runtime does not define the multiplexing arrangement on every call leg. Our voice AI stack guide explains that ownership boundary.
A layer map for real-time voice
The Real-time Transport Protocol (RTP) carries media packets. Its companion, the RTP Control Protocol (RTCP), carries reports and control information. An RTP session can contain multiple source streams, each identified by a synchronization source (SSRC) identifier.
The Session Description Protocol (SDP) describes media and transport parameters exchanged during session negotiation. A media description starts with an m= line. WebRTC, the browser-oriented real-time communications protocol suite, uses these descriptions to negotiate media transport.
UDP means User Datagram Protocol. A transport here is identified by a 5-tuple: source address, source port, destination address, destination port, and transport protocol.
These mechanisms share different things:
| Mechanism | Shared resource | How inputs are distinguished | Required agreement |
|---|---|---|---|
| Synchronous TDM | Digital circuit frame | Channel time-slot position | Framing, clock, and channel allocation |
| Multiple RTP source streams | One RTP session | SSRC, plus agreed payload-format mappings | Stream support and session configuration |
| RTP/RTCP multiplexing | One UDP port for media and control | Packet header fields that distinguish RTP from RTCP | a=rtcp-mux negotiation and compatible payload types |
| WebRTC BUNDLE | One transport across multiple SDP media descriptions | Protocol identification, SSRC, and media-identification mappings | BUNDLE group, media identifiers, and compatible transport parameters |
The table's rows can coexist. A bundled WebRTC transport can carry several RTP sources while also sharing its port between RTP and RTCP. Counting ports alone cannot describe the full arrangement.
How RTP and WebRTC share media
Multiple RTP streams in one session
Different sources can send RTP streams in the same session using different SSRC values. Each source retains its own packet sequence and timing context. A receiver uses that source identity to keep the streams separate, following the RTP source-stream model.
The RTP payload type identifies how the media payload is interpreted. It is not a substitute for source identity. Two microphones can use the same codec and payload type while remaining separate streams. Changing a codec also does not make a source a new participant.
Separate RTP sessions use transport and signaling context for separation. The relationship is more complex than “one port equals one session”: an RTP session can span multiple transport flows. The session groups communicating participants within a common SSRC space. These distinctions are covered by the RTP session model.
RTP and RTCP on one port
RTP and RTCP traditionally use separate UDP ports. RTP/RTCP multiplexing allows media and control packets to share one port. The receiver distinguishes packet classes through their headers, under rules that restrict which RTP payload-type values are usable.
In SDP offer/answer, a=rtcp-mux requests this arrangement. An answer accepting it also includes the attribute. An offer alone does not establish acceptance. If the answer omits it, the offerer cannot simply send multiplexed media and control anyway.
The RTP/RTCP multiplexing standard addresses a single media type. It does not, by itself, define sharing one port between audio and video. That distinction prevents a common error: treating rtcp-mux as a synonym for BUNDLE.
BUNDLE across media descriptions
BUNDLE negotiates one transport for multiple SDP media descriptions. SDP identifies group membership with a=group:BUNDLE and gives each media description an a=mid identifier. An audio description and a video description can therefore share a 5-tuple while retaining separate source streams. All RTP-based media in one BUNDLE group belong to one RTP session and share its SSRC numbering space.
The media identification tag, MID, associates an RTP stream with the relevant media description. BUNDLE requires support for the MID mechanism and negotiation of its RTP header extension. The receiver maintains mappings between source identifiers and media descriptions; the shared destination port cannot supply that distinction.
The current BUNDLE standard is RFC 9143, which supersedes RFC 8843. BUNDLE preserves the distinct media descriptions and encoded streams. It does not produce a mixed soundtrack.
For a browser product, the choice of WebRTC versus an application-defined WebSocket audio path is a separate architecture decision. Our WebRTC versus WebSocket guide covers the responsibilities associated with that choice.
Where SIP fits
The Session Initiation Protocol (SIP) creates, modifies, and terminates sessions. The SIP signaling standard defines those operations. RTP carries the media. A SIP message can carry an SDP offer or answer describing how the endpoints intend to exchange that media.
For example, a call can negotiate an audio codec and request RTP/RTCP port sharing through SDP, then send the resulting audio packets over a separate media path. The SIP signaling transport does not become the audio transport because the negotiation happened inside a SIP message.
The SDP offer/answer model establishes agreed session parameters. SIP does not make every optional media-sharing mechanism available on every endpoint. A gateway also has separate negotiation contexts on its different legs; a browser-side arrangement does not automatically carry through unchanged to a carrier-side leg.
This separation explains why a completed call setup can coexist with a media-path problem. Signaling acceptance and correct media delivery are different conditions. Our SIP trunking guide goes deeper into the signaling and media boundaries without treating SIP as a media multiplexer.
What multiplexing changes, and what it leaves alone
It can reduce transport resources. RTP/RTCP port sharing reduces the need for separate media and control port mappings. BUNDLE lets several media descriptions use one transport. This can simplify the resource model for network address translation, which maps addresses and ports between networks.
It does not compress audio. Putting two streams on one transport preserves both streams' payloads. Fewer ports are not a promise of lower media bandwidth. Codec choice, packetization, redundancy, and actual traffic determine the bytes sent.
It does not guarantee faster responses. Multiplexing does not shorten model inference, business-tool execution, or speech generation. It can change connection setup work, but end-to-end conversational delay includes much more than transport establishment.
Shared transport needs traffic policy. Audio, video, and data can compete for sending capacity. The WebRTC transport specification describes local prioritization and the constraints of network traffic differentiation. Sharing a transport does not automatically prioritize speech.
Demultiplexing adds state. A receiving stack may first distinguish connectivity messages, security-handshake packets, and protected media, then distinguish media from control, then route source streams to the right media description and decoder. These are successive decisions. The packet demultiplexing rules address protocol identification on a shared port, a different task from identifying an individual microphone stream.
The engineering consequence is a shared failure boundary. Losing a common transport can disrupt every stream using it. Separate transports offer separate control points, although they may still share an underlying network bottleneck.
Choose the sharing boundary by architecture
A useful design record answers five questions:
- What is shared? A physical link, RTP session, UDP port, or BUNDLE transport is named explicitly. “We multiplex audio” is too vague.
- Which identities survive? The design identifies each source stream and its association with the application. A mixed recording cannot supply isolated speaker inputs later.
- What was negotiated on each leg? The accepted media descriptions, codecs, port-sharing attributes, and group membership describe the running session. Configuration intent alone is insufficient.
- Who owns the receiver? A browser, gateway, media server, or application handles the relevant demultiplexing. Its stream and signaling state are part of the operating responsibility.
- What fails together? Transport-level events and source-level events remain distinguishable in diagnostics. “Audio stopped” has different meanings when one source disappears versus when the entire transport fails.
Consider an illustrative browser-to-telephone architecture with a media gateway between the two. The browser-facing leg might bundle audio and video. The telephone-facing leg might carry only audio with separately negotiated RTP and RTCP behavior. The gateway translates between those arrangements. The system needs a per-leg map of transports and stream identities, rather than one global “multiplexing enabled” flag.
The same principle applies to operational ownership. A custom media stack is a reasonable choice when direct control over transport topology, individual streams, or audio processing is part of your product's differentiation. That control includes responsibility for negotiation, demultiplexing, interoperability, and failure handling.
At Dasha, we provide a managed production platform for technical teams building conversational AI products. We manage the conversation runtime through our application programming interfaces (APIs) and web application, with phone connectivity through your Twilio account or configured SIP credentials. Your team retains carrier setup, business rules, downstream systems, and production acceptance.
If your product needs custom conversational workflows without owning the full voice runtime, build with Dasha around one real call path and one business integration.
