缺失的协议：BFCP 如何为企业会议室系统解锁双显示器会议

Source: Dev.to

概述

企业会议室系统（如 Polycom 和 Lifesize）支持双显示器——一个用于视频，另一个用于屏幕共享。然而，当这些系统通过 SIP 网关加入网络会议时，两个显示器都会显示相同的合并画面。硬件本身是支持的；问题在于 OpalVoIP 缺少 BFCP 支持，导致屏幕共享被注入到视频流中。

实现

2018 年，我从零开始为 OpalVoIP 添加了 BFCP 支持：

• 通过 C++ 包装器集成 libbfcp。
• 扩展 SDP offer/answer 处理以包含 BFCP 属性。
• 设计了双角色架构，使网关在外呼时充当 BFCP 客户端，在入呼时充当 BFCP 服务器。

SDP 协商细节

在 添加 BFCP 之前，SDP 中没有任何 BFCP 媒体行，导致只有单一的合并视频流。

在 实现之后，SDP 包含了独立的 BFCP 媒体段，使网关能够协商出一个单独的屏幕共享通道。

双角色客户端/服务器架构

• 外呼：网关发起 BFCP 客户端会话，以接收远端终端的屏幕共享数据。
• 入呼：网关运行 BFCP 服务器，接受来自来电终端的屏幕共享数据。

预协商 vs. 通话中重新协商

在初始 SDP 交换期间预先协商 BFCP，可避免通话中重新协商的复杂性和延迟，从而提供更流畅的用户体验。

WebRTC 今日的处理方式

现代 WebRTC 实现会原生协商视频和数据（包括屏幕共享）的独立媒体流，因而在许多情况下不再需要 BFCP。然而，桥接到传统会议室系统的 SIP 网关仍然需要 BFCP 来实现双显示器功能。

经验教训

• 在通话建立的早期加入 BFCP 可简化整体架构。
• 在网关中明确划分客户端和服务器角色可防止竞争条件。
• 为了兼容旧硬件，往往需要在新协议栈中加入旧协议的扩展。

参考文献

• Medium Article: The Missing Protocol – How BFCP unlocked dual‑monitor conferencing for enterprise room systems
• 开源贡献已在 open.gslab.com 上注明。BFCP 的缺口在 OpalVoIP 主代码库中仍然存在。