Summary
Add support for 3-way calling to the WebRTC APIs, allowing a user to merge two calls into a single conference and to switch (swap/hold) between two active calls.
Motivation
Multi-party and call-swapping are baseline telephony features users expect from a softphone. Today the call-handling API models one-to-one media sessions with no mechanism to bridge two of them or to toggle active/held state between them.
Proposed capability
- Merge: combine two existing media sessions (call A + call B) into one 3-way session.
- Switch: place one call on hold while making the other active, and toggle between them.
- Consider whether this extends to N-way beyond three, or is explicitly scoped to three for now.
Open questions for the WG
- Modelled as a new operation on
webrtc-call-handling (e.g. merge/hold actions on mediaSessionId), a new "conference" resource, or client-side mixing signalled via SDP?
- How is hold represented — an SDP renegotiation, a session state, or a dedicated action?
- Event/notification implications (
webrtc-events) for participants.
- Interaction with per-user/per-registration session limits.
@stroncoso @teikuran
Summary
Add support for 3-way calling to the WebRTC APIs, allowing a user to merge two calls into a single conference and to switch (swap/hold) between two active calls.
Motivation
Multi-party and call-swapping are baseline telephony features users expect from a softphone. Today the call-handling API models one-to-one media sessions with no mechanism to bridge two of them or to toggle active/held state between them.
Proposed capability
Open questions for the WG
webrtc-call-handling(e.g. merge/hold actions onmediaSessionId), a new "conference" resource, or client-side mixing signalled via SDP?webrtc-events) for participants.@stroncoso @teikuran