Why Conferencing Is Harder Than It Looks
On the surface, a three-way call is just “mix three audio streams together.” In a real VoLTE network, it is anything but. A compliant conference has to coordinate SIP signaling across multiple independent user agents, anchor and mix media in the network, manage participants joining and leaving mid-call, and present a consistent view of the conference to every device — including handsets from vendors who each interpret the specifications a little differently.
Early in development, we built a naive mixer: take the legs of a call, bridge the RTP, done. It worked in the lab with two identical test clients. The moment we tested against real commercial handsets, it fell apart. The audio mixed fine — but the call control was broken.
The clearest signal that something was fundamentally wrong came straight from the handsets themselves. Instead of just failing to render a conference UI, several phones actively tore the call down and told us exactly why, via an RFC 3326 reason header in their BYE:
BYE sip:focus@ims.volte.io SIP/2.0
Reason: SIP;cause=200;text="Conference call is empty"That message is worth dwelling on. The handset had decided it was now in a conference, looked for valid conference state — participants, a focus it could correlate its dialog to — and found none. So it concluded the conference was empty and hung up. The media path was perfectly fine; the device terminated a working audio call because the call control did not add up. Other phones simply refused to treat the call as a conference at all, or dropped the third participant.
That was the moment RFC 4579 went from “a spec we should probably read” to “the foundation the entire feature stands on.”
The Role of the MRF: A Conference Focus, Not Just a Mixer
In the IMS architecture, multi-party media is handled by the Media Resource Function (MRF) — split into the MRFC (the controller that speaks SIP) and the MRFP (the processor that mixes media). Together they act as what RFC 4579 calls a conference focus: a single logical SIP entity that every participant has a dialog with.
This is the key conceptual shift. Participants are not connected to each other. Each one holds exactly one SIP dialog — to the focus. The focus:
- Terminates the SIP signaling for each participant leg
- Anchors the media in the network (MRFP) for centralized mixing
- Maintains authoritative conference state — who is in the call, who is talking
- Advertises itself as a focus so handsets render the correct conferencing UI
Anchoring media in the network rather than on the device also means consistent, high voice quality (wideband AMR-WB / EVS), no reliance on device-side mixing, and the ability to scale a conference well beyond three legs.
Why RFC 4579 Was Non-Negotiable
This is the part we most want to emphasize, because it cost us the most time and taught us the most: without proper RFC 4579 support, the conference simply does not work — not “works with quirks,” but does not work as a conference at all. The Conference call is empty teardown was the symptom; missing call-control semantics was the disease.
RFC 4579 defines the call-control contract between user agents and the conference focus. The pieces that turned out to be critical:
The isfocus feature tag
When the focus includes ;isfocus in the Contact header, it tells the handset “you are now in a conference, not a point-to-point call.” Omit it — or send it inconsistently — and the phone either treats the call as ordinary or, as we saw, triggers its conference logic, finds no coherent state behind it, and tears the call down as empty. This single parameter was the difference between a working feature and a broken one.
The conference URI
A well-defined conference identity that all participants reference, allowing the focus to correlate every dialog to the same conference.
Standards-based join semantics
Using REFER and re-INVITE flows the way the RFC prescribes, so that adding Participant C to an existing A–B call is interpreted identically by every device.
Consistent state across participants
Every leg sees the same conference, because the focus is the single source of truth.
Once we implemented this strictly to the letter of the RFC — rather than reverse-engineering what one particular handset seemed to want — the interoperability problems disappeared across the board. The phones that had previously hung up with Conference call is empty suddenly stayed in the call and rendered the conference correctly. That was the moment the feature went from a fragile demo to something we would put in front of subscribers.
How a Conference Comes Together: The Call Flow
The diagram below traces a complete three-party conference, from an ordinary two-party VoLTE call to a fully mixed conference with media anchored in the MRF. Notice how every participant ends up with exactly one dialog to the focus, and how the ;isfocus tag on each 200 OK is what tells the handset it is genuinely in a conference.
;isfocus tag marks the call as a conference, and the MRFP mixes media for all legs.What makes this robust is exactly what made our first attempt fragile: there is one authoritative entity — the focus — and every device talks only to it. No peer-to-peer media, no device-side mixing, no ambiguity about who is in the call. Add a participant and the focus re-mixes; drop one and the rest of the conference is unaffected.
What We Learned
A few hard-won lessons from the development process:
- Standards compliance is interoperability. Every shortcut we took away from RFC 4579 created a device-specific bug. Every step back toward strict compliance eliminated a whole class of them at once. In a multi-vendor ecosystem, the spec is the contract.
- Media and signaling are separate problems. Mixing audio was the easy 20%. Getting the call control right — the focus model, the feature tags, the join/leave flows — was the hard 80%.
- Listen to what the handsets tell you. A reason header like
Conference call is emptyis not noise; it is the device handing you a precise diagnosis. Reading it literally pointed straight at the focus semantics we were getting wrong. - Anchoring media in the MRF pays off. Centralized mixing gave us predictable quality, clean scaling, and a single place to enforce policy, rather than depending on what each handset could or couldn’t do.
- Test against real devices early. Lab clients lie. Commercial handsets are the real specification.
The Result
volte.io now offers standards-based, RFC 4579-compliant conferencing as an integrated part of the platform:
Standards compliant
Full RFC 4579 SIP conferencing, implemented to the letter of the specification.
IMS optimized
Built for VoLTE networks and IMS best practices, with the focus living in the MRF.
Superior voice quality
Network-anchored RTP media with wideband AMR-WB / EVS, mixed centrally in the MRFP.
Wide interoperability
Works across IMS vendors and handsets — because we follow the contract, not one device’s quirks.
Dynamic conferences
Add or remove participants seamlessly while the conference stays live.
Future ready
Scalable, interoperable, and ready for 5G.
No Shortcuts Around the Standards
Conferencing is one of those features that is invisible when it works and infuriating when it doesn’t. Getting there taught us that there are no shortcuts around the standards — and that proper RFC 4579 support isn’t a nice-to-have, it’s the thing that makes the conference a conference at all.