The Internet Protocol Journal, Volume 15, No. 3

Binary Floor Control Protocol

Pat Jensen, Cisco Systems

Over the last decade, communication technologies have evolved to encompass new modalities of collaboration across IP networks—from instant messaging on a personal computer, to being able to make Voice-over-IP (VoIP) calls and also now including the growing adoption of High-Definition (HD) videoconferencing.

Operating systems, device types, and physical locations now are less affected as continued growth in networking has evolved to promote high bandwidth across wireless and wired networks. An example is the emergence of growing network-access technologies such as Multiprotocol Label Switching (MPLS), Very-High-Speed Digital Subscriber Line 2 (VDSL2), Long Term Evolution (LTE), and Data over Cable Service Interface Specification (DOCSIS). With both availability of bandwidth and broadband user penetration increasing, the user's expectation of delivering immersive collaboration now becomes more apparent.

This evolution includes modern use cases accelerating the adoption of videoconferencing, such as enabling telemedicine for remote surgeries and diagnostic procedures as well as distance learning applications being used to connect educators with students across the globe.

This article introduces the Binary Floor Control Protocol (BFCP) as a standard for managing floor control during collaboration sessions across dedicated video endpoints, mobile devices, and personal computers running collaboration software. These capabilities can be delivered using an enabled Session Initiation Protocol (SIP) standards-based endpoint or as a software implementation in a collaboration application stack.


BFCP is a deliverable developed as part of the Internet Engineering Task Force (IETF) XCON Centralized Conferencing working group. The IETF XCON working group was formed to focus on delivering a standards-based approach to managing IP conferencing while promoting broad interoperability between software and equipment vendors. [1]

This mandate includes defining the objects, mechanisms, and provisions to assist in scheduling conferencing resources. These resources could be consumed as a conference enabled in a web browser, via an audio conference call or during a videoconference.

As defined, privacy, security, and authorization are considered integral in protecting the ability to join, participate in, and manage each conference session. The IETF XCON working group's initial focus was on unicast media conferences.

The IETF XCON working group was proposed in August 2003, with work starting early in October of that year. [2] Early requirements for BFCP were defined in RFC 4376, which describes important concepts, including a model for floor control and how it should be integrated in a conferencing platform. [3] Other important aspects such as security, including using authentication and encryption to provide protection against man-in-the-middle attacks, were also outlined.

In November 2006, Gonzalo Camarillo, Joerg Ott, and Keith Drage authored RFC 4582, which defined the Binary Floor Control Protocol. [4]

Besides BFCP, other standardization efforts around conference role and content management also were defined, including the ITU-T H.239 recommendation. [5] Unlike BFCP, H.239 applies specifically to H.323-enabled Integrated Services Digital Network (ISDN) and IP conferencing endpoints, whereas BFCP is designed to be agnostic of the underlying signaling protocol.

Protocol Details

The basic concept of floor control is analogous to managing a live in-person presentation, where you want to control who is presenting, manage and transition your presenters, and maintain a feedback loop. Also important is the ability to allow a presenter to show slides and share with your audience a white board or transparency projector.

During an active collaboration session, a presenter may choose to present material to a remote user, or optionally to an audience on a call with multiple endpoints through a Multipoint Control Unit (MCU). This session could include many additional sources; for example, using a secondary video camera to show zoomed-in content (that is, an optical examination camera used in telemedicine) or any external video source.

This floor-control mechanism can also encompass functions available in a collaboration application stack, such as the ability to share the content of the presenter's desktop, application, or web browser.

BFCP provides the ability to manage multiple streams being presented during a collaboration session using floor control. BFCP accomplishes this management using a token-based mechanism where a single presenter can request control of the floor from the floor-control server.

When this request is granted, the presenter holds the token and has the ability to open an additional stream to provide presentation data. Figure 1 examines this process in detail, with a meeting attendee requesting the token from the floor-control server to become an active presenter during the session.

Figure 1: BFCP Floor Request from Floor-Control Server

This same interaction can also take place during a point-to-point audio or video call with only two parties. In this case, a token can be used to signify which party will be presenting an additional stream, such as a secondary camera or application providing a desktop sharing session. Figure 2 shows an overview of this process. One of the critical differences here is that in a point-to-point call, the floor-control server capability is being provided by the users' device or application instead of using a multipoint control unit or conference server.

Figure 2: BFCP Floor Request in a Point-to-Point SIP Call

For instance, as a presenter, you can choose to present auxiliary streams via your application or endpoint and determine whether it is your primary, secondary, or tertiary stream. As a conference participant, you can also choose which stream you are currently viewing, also including the definition and quality of the secondary stream. In this case, current network conditions such as bandwidth and latency will also dictate the quality of additional streams.

BFCP is designed to be signaling protocol—agnostic, in that it is relying on the capabilities of the underlying signaling and transport protocols to set up each stream that is being managed, including whether voice, video, or content is being provided in the Real-Time Transport Protocol (RTP) stream.

For example, using a standards-based endpoint and Session Initiation Protocol (SIP), a SIP INVITE message is sent with the media capabilities line specifying the session description information about the stream. This data provides relevant information about the underlying video codec being used and the bit rate that is required to support the video and presentation streams.

In this case as multiple RTP media streams are transported across the network carrying audio and video traffic, Call Admission Control (CAC) and Quality of Service (QoS) tagging can be applied and enforced by the call-control platform, providing the ability to limit bandwidth usage and helping ensure that bandwidth is available on the network after the additional media stream is added.

Also important to note, BFCP can use Transport Layer Security (TLS) to provide encryption of floor information pertaining to each resource that is being controlled as well as the participants using and viewing them. BFCP provides the ability to support anonymous users as well for sessions where you may have a large audience or where anonymity is desired. An example of where this feature could be used is hosting a large web conferencing event where you have external attendees who may be outside of your organization.

One use case for BFCP includes the ability to focus on the presenter while the presenter is sharing a desktop application. With the ability to control the presenter's media stream, this feature adds additional immersion in a collaboration session, allowing you to both identify the presenter's visual cues and posture as well as focus on relevant content the presenter supplies.


The Binary Floor Control Protocol plays a very important role in helping manage diverse types of content being shared across multiple parties in a conference session. Today's modern implementations of BFCP span web conferencing applications as well as video and audio conferencing solutions across a wide array of vendors.

While these vendors are focused on delivering these capabilities across screen-led PC-centric types of devices, because of its inherent transport-agnostic capabilities, it is likely we will see BFCP being used to enable new modalities of content sharing across collaboration applications in the future.

Industry efforts are focusing on promoting collaboration applications across new arrays of devices, including using touchscreen technology on handheld computers and stationary LCD televisions to manipulate and visualize data in new ways.

Concepts such as manipulating session content using cognitive mapping as an evolution of electronic whiteboarding and transitioning an active conference from a tablet device to another type of room-based video-enabled endpoint during a collaboration session are two powerful examples of ways BFCP could be used in the future. On the horizon, touchscreen-enabled tablet and smartphone devices and HTML5-enabled web browsers also provide yet another avenue to enable rich standards-based multimedia conferencing with advanced content management.


The views of this article do not necessarily represent the views or positions of Cisco Systems.

For Further Reading



[3] Petri Koskelainen, Joerg Ott, Henning Schulzrinne, and Xiaotao Wu, "Requirements for Floor Control Protocols," RFC 4376, February 2006.

[4] Gonzalo Camarillo, Joerg Ott, and Keith Drage, "The Binary Floor Control Protocol," RFC 4582, November 2006.

[5] "Role management and additional media channels for H.300-series terminals," International Telecommunication Union Standard H.239, September 2005.

PAT JENSEN is a member of the Unified Communications consulting systems engineering team at Cisco Systems. Since 2010, he has designed collaboration architectures for Ciscos' customers across the western United States. Prior to joining Cisco Systems, he served as an IP telephony design engineer designing and implementing unified communications and telepresence technologies at AT&T and SBC DataComm. E-mail, XMPP, SIP: