누락된 프로토콜: BFCP가 엔터프라이즈 룸 시스템의 듀얼 모니터 회의를 가능하게 한 방법

Source: Dev.to

Overview

Polycom 및 Lifesize와 같은 엔터프라이즈 룸 시스템은 비디오용 모니터와 화면 공유용 모니터, 두 개의 모니터를 지원합니다. 하지만 이러한 시스템이 SIP 게이트웨이를 통해 웹 회의에 참여할 때 두 모니터 모두 동일한 결합된 피드를 표시했습니다. 하드웨어는 가능했지만, OpalVoIP에 BFCP 지원이 없어서 화면 공유가 비디오 피드에 삽입되는 문제가 있었습니다.

Implementation

2018년에 저는 BFCP 지원을 OpalVoIP에 처음부터 추가했습니다:

• libbfcp를 C++ 래퍼를 통해 통합했습니다.
• BFCP 속성을 포함하도록 SDP offer/answer 처리를 확장했습니다.
• 게이트웨이가 BFCP 클라이언트 역할을 하는 outbound 호출과 BFCP 서버 역할을 하는 inbound 호출을 모두 수행하도록 하는 이중 역할 아키텍처를 설계했습니다.

SDP Negotiation Details

Before BFCP를 추가했을 때, SDP에는 BFCP 미디어 라인이 전혀 없어 단일 결합 비디오 스트림만 전송되었습니다.

After 구현 후, SDP에 별도의 BFCP 미디어 섹션이 포함되어 게이트웨이가 화면 공유 전용 채널을 협상할 수 있게 되었습니다.

Dual‑Role Client/Server Architecture

• Outbound calls: 게이트웨이는 원격 엔드포인트로부터 화면 공유 데이터를 받기 위해 BFCP 클라이언트 세션을 시작합니다.
• Inbound calls: 게이트웨이는 들어오는 엔드포인트로부터 화면 공유 데이터를 받기 위해 BFCP 서버를 실행합니다.

Pre‑Negotiation vs. Mid‑Call Renegotiation

초기 SDP 교환 단계에서 BFCP를 사전 협상하면 통화 중 재협상의 복잡성과 지연을 피할 수 있어 사용자 경험이 더 부드러워집니다.

How WebRTC Handles It Today

현대 WebRTC 구현은 비디오와 데이터(화면 공유 포함)를 위한 별도 미디어 스트림을 기본적으로 협상하므로 많은 경우 BFCP가 필요하지 않습니다. 그러나 레거시 룸 시스템과 연결되는 SIP 게이트웨이는 여전히 이중 모니터 기능을 제공하기 위해 BFCP가 필요합니다.

Lessons Learned

• 통화 설정 초기에 BFCP를 추가하면 아키텍처가 단순해집니다.
• 게이트웨이에서 클라이언트와 서버 역할을 명확히 분리하면 레이스 컨디션을 방지할 수 있습니다.
• 레거시 하드웨어와의 호환성을 유지하려면 최신 스택에 없는 프로토콜 확장이 종종 필요합니다.

References

• Medium Article: The Missing Protocol – How BFCP unlocked dual‑monitor conferencing for enterprise room systems
• Open‑source contribution credited at open.gslab.com. The BFCP gap still exists in OpalVoIP’s main codebase today.