The Missing Protocol: How BFCP Unlocked Dual-Monitor Conferencing for Enterprise Room Systems

By Sagar Deepak Joshi, Staff Software Engineer

This article is part of a series on real-world distributed systems and communication infrastructure.

Enterprise video conferencing has always had two distinct worlds. On one side, browser-based and software clients — Zoom, Teams, Google Meet — where screen sharing is a single click and the protocol complexity is invisible. On the other side, hardware room systems — Polycom, Lifesize, eLink — built for boardrooms and executive suites, with dedicated cameras, microphones, and crucially, support for dual monitors: one for the remote participants’ video, one for shared content.

The promise of dual-monitor room systems is straightforward: video and screen share displayed simultaneously on separate screens, exactly as the hardware was designed. In practice, achieving this promise required a protocol that most open source VoIP stacks simply did not implement.

This is the story of how we added Binary Floor Control Protocol (BFCP) support to OpalVoIP from scratch — and what it took to bridge a decade-old gap between open source telephony infrastructure and enterprise room system expectations.

The Problem: One Stream Where Two Were Needed

The Fuze Telepresence Gateway was designed to allow traditional hardware room systems to join Fuze web conferences. It supported both SIP and H.323 — the two dominant protocols for enterprise room systems — acting as a translation layer between the hardware endpoint world and the modern web conferencing platform.

When a Polycom or Lifesize endpoint joined a Fuze meeting and a participant shared their screen, something subtle but deeply frustrating happened. The gateway had no mechanism to negotiate a separate content stream alongside the video stream. Without that capability, there was only one option: inject the screen share into the existing video feed, producing a single combined stream delivered to the room system endpoint.

For room systems with a single monitor, this was tolerable. For room systems with dual monitors — which many enterprise customers specifically purchased for exactly this use case — it was a significant product failure. Both monitors displayed the same combined feed. The hardware capability was there. The software could not unlock it.

The root cause was the absence of BFCP support in OpalVoIP, the open source VoIP stack the gateway was built on. Without BFCP, there was no standard mechanism to negotiate floor control — the protocol handshake that coordinates who has permission to share content — and no way to signal a second independent content stream in the SDP negotiation.

Before BFCP: both monitors show the same combined feed. After BFCP: video and screen share delivered as independent streams to dedicated monitors.

What BFCP Does and Why It Matters

Floor control is a means to manage joint or exclusive access to shared resources in a multiparty conferencing environment. In the context of video conferencing, that shared resource is the content stream — the screen share that one participant presents to others.

BFCP operates alongside SIP signaling as a separate protocol channel. When a participant wants to share their screen, their endpoint sends a FloorRequest to a floor control server. The server evaluates the request — in a simple two-party call, this is typically granted immediately — and responds with a FloorGrant. The endpoint can then begin transmitting the content stream.

The SDP negotiation handles the stream itself. A BFCP connection is described as any other media stream by using an SDP m= line, followed by SDP lines that apply to the BFCP connection. This means the initial SIP INVITE includes not just the usual audio and video m= lines, but also a BFCP m= line and a separate content video m= line — pre-negotiating the infrastructure for screen sharing before any floor request has been made.

To make this concrete, a standard SDP offer without BFCP looks like this:

m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99

With BFCP support added, the offer includes two additional lines — a floor control channel and a separate content stream:

m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
m=application 50000 TCP/BFCP *
a=floorctrl:c-s
m=video 53000 RTP/AVP 99
a=content:slides

The m=application line establishes the BFCP floor control channel. The second m=video line with a=content:slides is the dedicated content stream — completely separate from the main video feed. The a=floorctrl attribute declares the endpoint's role: client (c), server (s), or both (c-s).

Without these lines in the SDP, there is no floor control channel and no content stream. The gateway had no choice but to inject screen share into the main video feed.

The endpoints negotiate BFCP during call setup using the same INVITE/200OK/ACK messages, electing a floor control server and agreeing on the ports for BFCP messaging when desktop sharing is requested.

SDP offer without BFCP (left) vs with BFCP (right). The two additional m= lines unlock floor control and a dedicated content stream.

Why OpalVoIP Had No BFCP Support

OpalVoIP is a mature, widely deployed open source telephony library. It handles SIP, H.323, RTP, codec negotiation, and a broad range of VoIP functionality. But BFCP had never been implemented in the stack. The protocol existed, the RFC was published, and implementations like libbfcp existed as standalone libraries — but no one had built the bridge between libbfcp and OpalVoIP’s call and media model.

This is not unusual in open source. Protocol support gets added when someone has a concrete need and the engineering resources to implement it. For most OpalVoIP deployments, BFCP was not a requirement. For a Telepresence Gateway serving enterprise room systems, it was essential.

The Integration Architecture

The implementation centered on a new file: bfcpinterface.cxx. This was a C++ wrapper around libbfcp — a standalone C-based BFCP implementation — that translated between libbfcp's callback-driven API and OpalVoIP's object model.

The design had to handle a non-trivial asymmetry: the gateway needed to act as a BFCP client on outbound calls and a BFCP server on inbound calls.

Outbound Call (Gateway initiates) Inbound Call (Endpoint initiates) BFCP Role Client Server Floor control Sends FloorRequest to remote server Receives FloorRequest from remote client Grant decision Remote server grants/denies Gateway grants/denies Content stream Activated on FloorGrant received Activated on FloorGrant sent SDP a=floorctrl c-s or c c-s or s

This dual-role design meant bfcpinterface.cxx had to encapsulate both the client-side and server-side protocol state machines from libbfcp, exposing a unified interface to OpalVoIP's call layer that abstracted away which role was active for a given call.

bfcpinterface.cxx acts as the central bridge — wrapping libbfcp and exposing a unified interface to OpalVoIP regardless of call direction.

SDP negotiation for dual streams: The SDP handling required extending OpalVoIP’s offer/answer processing to include the BFCP m= line and the content video m= line in the initial INVITE. This pre-negotiation was essential — the floor control channel and the content stream infrastructure had to be established at call setup time, before any screen sharing was requested, so that a FloorGrant could activate the content stream without requiring a disruptive SDP renegotiation mid-call.

The a=floorctrl attribute in the SDP indicated each endpoint's role — client, server, or both — allowing the gateway to correctly determine which BFCP role to assume based on who initiated the call.

Full BFCP call flow — SIP INVITE with BFCP negotiation, floor control handshake, and dual stream activation.

The Result: Two Streams, Two Monitors

With the BFCP integration complete and deployed in the Fuze Telepresence Gateway on AWS, the dual-monitor experience that enterprise customers had been promised finally worked as designed.

When a Polycom or Lifesize endpoint joined a Fuze meeting, the initial SIP INVITE now included the BFCP negotiation and the pre-negotiated content stream. When a participant shared their screen, the floor control handshake completed cleanly, the content stream activated independently of the video stream, and the room system received two separate feeds — video on one monitor, screen share on the other.

The fix was invisible to end users in the best possible way. There was no new interface to learn, no configuration to change. The hardware that had always been capable of dual-monitor display simply began working as intended.

It is worth noting that the integration was never merged into OpalVoIP’s main branch — it was maintained as a separate production branch for the Fuze deployment. The gap remains open in the main codebase today, which perhaps says something about how niche but real this problem remains.

Lessons for Open Source Protocol Integration

Looking back, a few principles shaped this work that apply broadly to integrating protocol libraries into existing open source stacks:

Understand the object model before writing code. The hardest part of integrating libbfcp into OpalVoIP was not implementing BFCP — libbfcp handled that. It was understanding where in OpalVoIP’s call lifecycle the BFCP state machine needed to hook in: when to initialize the floor control channel, when to send FloorRequests, and how to coordinate floor grants with SDP state. Spending time understanding the host stack’s model before writing the wrapper pays off significantly.

Pre-negotiation is better than renegotiation. Including the BFCP m= line and content stream m= line in the initial SDP offer — rather than adding them via re-INVITE when screen sharing was requested — made the floor control handshake fast and non-disruptive. Mid-call SDP renegotiation is a source of compatibility issues with hardware endpoints. Negotiate everything upfront.

Dual-role designs require careful state isolation. The gateway acting as both BFCP client and server depending on call direction meant the wrapper had to maintain clean separation between the two state machines. Conflating client and server state is a subtle source of bugs that only manifest in specific call direction scenarios.

Production deployment validates what unit tests cannot. The real-world test of the integration was hardware room systems — Polycom, Lifesize, eLink — each with their own BFCP implementations and subtle protocol variations. Edge cases around floor control timing, SDP attribute parsing, and connection re-establishment only surfaced with real hardware in real network conditions.

BFCP in the Age of WebRTC

WebRTC, which has become the dominant protocol for browser-based conferencing, solved the dual-stream problem differently and more elegantly. Rather than a floor control protocol, WebRTC uses getDisplayMedia() — a browser API that captures screen content as an independent MediaStream. Adding it to a peer connection via addTrack() triggers automatic SDP renegotiation, delivering a separate screen share track without any explicit floor control handshake.

For software clients — browsers, desktop apps, mobile — this is a better solution. It is simpler, requires no dedicated floor control server, and gives every participant the ability to share without a permission grant cycle.

But hardware room systems still speak SIP. Polycom, Lifesize, and Cisco endpoints do not run browsers. They connect to conferencing platforms via SIP and H.323, and they still require BFCP to negotiate a separate content stream. The Telepresence Gateway problem did not disappear with WebRTC — it simply became more concentrated. Interoperability between the browser WebRTC world and the hardware room system world remains a real engineering challenge, and gateways that bridge them still require BFCP support to deliver the full dual-monitor experience.

In that sense, the work described in this article is not a historical curiosity. Any platform that wants to serve enterprise customers with existing room system investments — and there are many — still needs exactly this kind of SIP-to-BFCP integration today.

Conclusion

BFCP is not a glamorous protocol. It does one thing: coordinate who has the floor to share content in a multiparty call. But for enterprise customers who had invested in dual-monitor room systems and expected to use them as designed, the absence of BFCP support in their conferencing gateway was a daily frustration.

Adding BFCP to OpalVoIP from scratch was a gap-filling contribution — not an invention, but a bridge between a protocol that existed and a stack that needed it. The dual-monitor experience that resulted was not a new feature. It was the hardware finally being allowed to do what it was built to do.

This kind of work — unglamorous, invisible once complete, but essential — represents a significant portion of what senior engineers actually do. The protocols exist. The RFCs are published. The reference implementations are available. The open source stacks are mature and widely deployed. What’s missing is the integration work: the wrapper that bridges two object models, the SDP extensions that unlock a second stream, the production validation with real hardware that surfaces the edge cases no unit test anticipated.

Gluing existing excellence together with precision and depth is not a lesser form of engineering. For the customers whose Polycom endpoints finally showed video on one monitor and screen share on the other, it was the only kind that mattered.

Open source stacks have many such gaps. The next integration is waiting for someone with the concrete need and the engineering patience to close it.

Sagar Joshi is a Staff Software Engineer specializing in distributed systems and large-scale real-time communication platforms. He holds two US patents in communication routing and conferencing continuity, and contributed BFCP support to OpalVoIP, enabling dual-stream screen sharing for enterprise room systems. His open source work is credited at open.gslab.com.

References

1. GS Lab Open Source — OpalVoIP Contribution — Public credit for the BFCP integration authored by Sagar Joshi and Ammar Nasikwala: https://open.gslab.com/project/opalvoip
2. OpalVoIP Project — Open source telephony library: http://www.opalvoip.org/
3. RFC 8855 — The Binary Floor Control Protocol (BFCP) — IETF standard defining the floor control protocol implemented in this work: https://www.rfc-editor.org/rfc/rfc8855
4. RFC 4583 — Session Description Protocol (SDP) Format for BFCP Streams — Defines the SDP m= line extensions for BFCP negotiation: https://www.rfc-editor.org/rfc/rfc4583Tags: VoIP Open Source WebRTC Software Engineering Distributed Systems