Understand Binary Floor Control Protocol (BFCP)

BFCP allows users to share presentations/desktops within an ongoing video conversation. Desktop sharing video stream will be running as additional one to the actual call which already has audio and video streams

BFCP Endpoints

BFCP is supported by default on the following endpoints:

Cisco E20, Cisco TelePresence Codec C40, Cisco TelePresence Codec C60, Cisco TelePresence Codec C90, Cisco TelePresence EX60, Cisco TelePresence EX90, Cisco TelePresence Quick Set C20, Cisco TelePresence Profile 42 (C20), Cisco TelePresence Profile 42 (C60), Cisco TelePresence Profile 52 (C40), Cisco TelePresence Profile 52 Dual (C60), Cisco TelePresence Profile 65 (C60), Cisco TelePresence Profile 65 Dual (C90), Cisco TelePresence, Cisco TelePresence 1000, Cisco TelePresence 1100, Cisco TelePresence 1300-47, Cisco TelePresence 1300-65, Cisco TelePresence 1310-65, Cisco TelePresence 3000, Cisco TelePresence 3200, Cisco TelePresence 500-32, Cisco TelePresence 500-37, CSF

Because BFCP is automatically enabled, CUCM does not provide configuration options for these endpoints.

BFCP Floor Control

BFCP is based on floor control mechanism. In floor control mechanism, Floor is the permission to present by presenter or access shared resource(s) by participants.

In a video conference call, the presenter request control of the floor from the floor control server which can be CUCM or VCS (depending on the type of the conference). When this request is granted, the presenter holds the token and has the ability to open an additional video stream to provide presentation data. Later, the participants will send Floor Requests to floor control server to join the stream which will be approved or rejected by presenter.

In a point to point video call, the same mechanism is followed. The only difference that the floor control server is the endpoint instead of conference server. Therefore, the endpoints has to elect a server and client during the call. Usually, the server is the initiator and the client is the participant.

BFCP Signaling (Point to Point Call Only)

BFCP is supported only on SIP networks and SIP endpoints.

BFCP has multiple signaling involved:

1. Negotiating the video parameters for the presentation or desktop sharing stream. This is separate from the video stream of the video call.

During the original call establishment (early offer or delayed offer), the endpoints will agree on the parameters to be used for the RTP streams (audio, video, bfcp video). The video parameters are discussed in details in separate section. Note that endpoints will agree on bfcp video parameters although the stream isn't yet requested

2. Negotiating floor control mechanism and BFCP Messaging Parameters

This negotiation will take place using the same original INVITE/200OK/ACK messages used to establish the call. The endpoints will elect floor control server which will be used later to grant/reject requests when desktop sharing is requested. Also, the endpoints will agree on the ports (TCP/UDP) which will be used for BFCP messaging when desktop sharing is requested. Some other parameters in SDP will be agreed as listed below

• m= - The media field has to be application, port and transport will list the socket for BFCP messaging, while the fmt field is ignored in BFCP and replaced with *.
• a=floorctrl: role - The endpoints participating in BFCP session needs to elect which of them is the floor control server (this is applicable for point to point calls). Each endpoint indicates its capability as:
• Client Only: c-only
• Server Only: s-only
• Client and Server: c-s

In case both endpoints support c-s, the initiator will act as server.

• a=confid:token - Floor control server needs to provide the participants with conference ID. This value is consistent during the BFCP session
• a=userid:token - Floor control server needs to provide the participants with User ID to identify themselves during the session. This value is consistent during the BFCP session
• a=floorid:token mstrm:token - Floor control server will map the floor (permission) ID  with BFCP media stream id
• a=setup:role - This attribute indicates the connection direction and can be:
• setup:active - The endpoint will initiate an outgoing connection
• setup:passive - The endpoint will accept an incoming connection
• setup:actpass - The endpoint is willing to accept an incoming connection or to initiate an outgoing connection
• setup:holdconn - The endpoint does not want the connection to be established for the time being
• a=connection:role - This attribute indicates the status of the connection which be either new or existing

Note: During the initial handshake, each endpoint will generate its own confid and userid tokens since the server isn't yet elected. Once the election is completed, both endpoints will use the tokens generated by the server.

Once BFCP parameters are agreed in the SIP messages (supported by both endpoints and allowed in CUCM/VCS), BFCP Hello Messages will be exchanged between endpoints (Floor client/server) to exchange the supported BFCP attributes.

3. BFCP Messaging when Desktop Sharing is Requested/Released

Here we used Wireshark filter using the BFCP ports negotiated in INVITE/200OK messages and decode-as BFCP feature to see the communication.

When desktop sharing is started by presenter, BFCP Floor messages are exchanged between Floor Participant and Floor Control Server to grant access to BFCP video stream. Similarly, when desktop sharing is stopped, BFCP Floor messages are exchanged between participant and server to release access to BFCP video stream.

Note: There won't be any messaging taking place with CUCM/VCS as this will be already completed during the call setup

Note: MTP Pass-through supports BFCP desktop sharing streams

BFCP Configuration

To configure BFCP on SIP trunks, check the Allow Presentation Sharing using BFCP check box in the Trunk Specific Configuration section of the SIP Profile Configuration window.

To configure BFCP on SIP lines:

• For Cisco video endpoints that support BFCP, no configuration on the SIP line is required. Still the option 'Allow Presentation Sharing using BFCP' check box is present under the Protocol Specific Information section of the Phone Configuration window
• For third-party video endpoints that support BFCP, enable BFCP by checking the Allow Presentation Sharing using BFCP check box in the Protocol Specific Information section of the Phone Configuration window.

BFCP For Jabber

• Cisco Jabber for Windows supports video desktop sharing in software phone mode only. Video desktop sharing is not available in desk phone mode.
• If Cisco Jabber for Windows cannot resolve contacts by their phone numbers, video desktop sharing is not available from chat windows. However, it will be available for already established video calls
• Till CUCM 9.1(2), you need to install cmterm-bfcp-e.8-6-2.cop.sgn COP file to be able to enable Allow Desktop Presentation using BFCP in Phone Configuration window