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 is supported by default on the following endpoints:
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:
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
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=<media> <port> <transport> <fmt> - 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.
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
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
We are looking at ways to stop users from been able to manually change their status setting on the Jabber windows client.Please can you have a look into this and provide us with a solution on how we are able to lock the Jabber client software down to the ...
Hi All, CUIC integrated with corporate active directory for LDAP authentication. Also enabled use SSL option in CUIC . But Windows team is complaining about the clear text password using unencrypted LDAP authentications. Please let us know how to mak...
Hi guys, I have configured Hunt Pilot with 777XXXXXXXXXX number, calls from CUCM extensions work normally. Calls from trunk directly to extension is ok, but calls to hunt pilot number not work - we have reply sip 404. Trunk CSS is main_css,...
Hi, I am testing outbound voice translation patterns and have come across a weird result. (Numbers are fake for question purposes) Test DID Number: 4123Full Number: 738998723 (7389987XX) voice translation-rulerule 45 /^.*41\([2-3].\)$/...