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

Published: (March 14, 2026 at 06:57 PM EDT)
2 min read
Source: Dev.to

Source: Dev.to

Overview

Enterprise room systems such as Polycom and Lifesize support dual monitors—one for video and one for screen share. However, when these systems joined a web conference through a SIP gateway, both monitors displayed the same combined feed. The hardware was capable; the issue was that OpalVoIP lacked BFCP support, causing screen share to be injected into the video feed.

Implementation

In 2018 I added BFCP support to OpalVoIP from scratch:

  • Integrated libbfcp via a C++ wrapper.
  • Extended SDP offer/answer processing to include BFCP attributes.
  • Designed a dual‑role architecture where the gateway acts as a BFCP client on outbound calls and a BFCP server on inbound calls.

SDP Negotiation Details

Before adding BFCP, the SDP lacked any BFCP media lines, resulting in a single combined video stream.

After the implementation, the SDP includes a separate BFCP media section, allowing the gateway to negotiate a distinct screen‑share channel.

Dual‑Role Client/Server Architecture

  • Outbound calls: The gateway initiates a BFCP client session to receive screen‑share data from the remote endpoint.
  • Inbound calls: The gateway runs a BFCP server to accept screen‑share data from the incoming endpoint.

Pre‑Negotiation vs. Mid‑Call Renegotiation

Pre‑negotiating BFCP during the initial SDP exchange avoids the complexity and latency of mid‑call renegotiation, resulting in a smoother user experience.

How WebRTC Handles It Today

Modern WebRTC implementations negotiate separate media streams for video and data (including screen share) natively, eliminating the need for BFCP in many cases. However, SIP gateways that bridge to legacy room systems still require BFCP to expose dual‑monitor functionality.

Lessons Learned

  • Adding BFCP early in the call setup simplifies architecture.
  • A clear separation of client and server roles in the gateway prevents race conditions.
  • Maintaining compatibility with legacy hardware often demands protocol extensions not present in newer stacks.

References

0 views
Back to Blog

Related posts

Read more »

Travigo

Travel as fast as you speak with Gemini! Where live agents meet immersive storytelling & 3D navigation. This project was created for entering the Gemini Live Ag...

Micro games

Hey Gamers! 👾 As part of the Rapid Games Prototyping module, we are tasked with reviewing a peer's game. The challenge is to analyse a prototype built in just...