cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
44377
Views
95
Helpful
8
Comments

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

 

  1. 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.

 

  1. 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
Comments
Ayodeji Okanlawon
VIP Alumni
VIP Alumni

Thank you Mohammed for this. Very good document.

neutrino38
Community Member

Hello,

We have tandberg codec C20 to interoperate with another MCU and we experience the following issue:

1- in the device offer, the SDP indicates that it can act as both server and client and it offers a conf ID, a user ID and a floor ID. This floor ID value is 2.

2- The MCU answers contains an SDP that inticates that the MCU acts as server only and provides its own conf ID, user ID and floor ID. The value of floor ID is 1.

3- when we tray to share the second video the tandberg device sends a FloorRequest on floor ID 2 instead of floor ID 1. (The conf ID and user ID are correct).

4- no video is received on the second stream negociated in SIP.

Question: is the video multiplexed on the first video stream or is it send in the second video stream ?

Jonathan Els
Level 5
Level 5

Excellent work.  Thank you for the level of detail provided!

Awesome Document. Thanks..

Martin Moran
Level 3
Level 3

Hi,

 

I know this is an old post but I have a question regarding the part when you say that video desktop sharing is not supported when using Jabber in Desk Phone Mode... Wasn't this supported at the time of writing this post or it's still not supported?

 

I've tested this using two Jabber clients in Desk Phone Mode (and applying the "allow BFCP..." in the SIP profile of both phones) and desktop sharing works smoothly.

 

I'd appreciate your response.

 

Rgrds.

Hi,

If CISCO sent a re-INVITE with SDP for an existing dialog during CISCO sharing desktop, whether CISCO as BFCP Client will send a new BFCP request?

Thanks!

maabdull
Cisco Employee
Cisco Employee

 

Thank you for your article about BFCB , it's very useful .

 

I have a query hope you can help me to explain so :

I've Call Flow :

Zoom conference bridge -> Expressway-E -> Expressway-C -> CUCM -> SX80 

When SX80 shared screen for more than 30 minutes , then stop share and try to share again, sharing will fail.

In SDL traces, I see that SIP Session Refresh invite is missing, can this cause screen sharing to fail ?

Ramon G.
Cisco Employee
Cisco Employee

Great document, thanks!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: