Spoiler alert – BFCP is not the second video channel as many people refer to it. I thought it’s obvious but… then I thought again.
I’ve decided to write this article after speaking to a senior engineer (seemingly) who was rather confused seeing a second video m line in SDP, not to mention all the BFCP related information.
Let’s dive straight into it!

Second video channel

Second video channel is commonly used for presentation sharing in a video call. It’s representation when looking at signaling is the second video m line within SDP.
How do you know it’s indeed used for presenting and how to tell the difference from the main video channel?
Let’s have a look at an example of what a video endpoint would normally advertise (omitting irrelevant lines for clarity):

m=video 22300 RTP/AVP 99 97 126
a=label:11
a=content:main
m=video 20452 RTP/AVP 97 126 96 34
a=label:12
a=content:slides

Yep, as easy as this. The second video channel will have an attribute of content:slides while the main video channel (as expected) content:main.

If you want to know more about the video m line and H.264 have a look at my previous article.

What about BFCP?

Why do you need BFCP then if all has been negotiated?
Well, there needs to be a way of determining who will be the presenter. Imagine a video conference with 10 participants where everybody is eager to present something – there needs to be a mechanism of granting the right to do so for a particular participant.
BFCP allows just this – whoever is granted the permission to share content has the floor, hence the name Binary Floor Control Protocol.

Who should decide whether to allow someone to present?
This is actually the main goal of the Binary Floor Control Protocol – agree who will be the controller of the floor. In BFCP terminology that will be the server. As you might expect there is also a client in a BFCP message exchange.

The following example will help understand how the client – server relationship is established. It’s an early offer B2B call with the initial Invite containing these lines in SDP:

m=application 29299 UDP/BFCP 
a=floorctrl:c-s
a=floorid:2 mstrm:12
a=confid:1
a=userid:8

The BFCP answer comes in with the 200 OK SDP:

m=application 55292 UDP/BFCP
a=confid:11
a=userid:20
a=floorid:10 mstrm:12
a=floorctrl:s-only

Apart from the ports and protocol, you’ll notice the floorctrl attribute.
This can be either c for client, s for server or c-s for client-server.
So in the above example, the initiating endpoint said it can be both – a BFCP client or a BFCP server, while the other side said it can only be a server.
Ok, done, Expressway will be the decision-maker (as it’s a B2B call traversing Expressway).

How about the other attributes?

A simple explanation of each follows below:

• a=confid:11 – conference ID to be used for BFCP message exchange
• a=userid:20 – user ID for the server side
• a=floorid:10 mstrm:12 – floor ID to be used for BFCP message exchange and the media stream that will be sent once the floor is granted

Have a look at the SDP example from the beginning.
The label number (12) equals the mstrm number. That’s how BFCP ties to the actual second video stream.

Finally, let’s see BFCP in action!

It’s important to note that BFCP follows the same path as the media.
Even though the signaling path goes via CUCM, BFCP will flow directly to Expressway:

Call signaling: Endpoint -> CUCM -> Expressway
BFCP messages:  Endpoint -> Expressway

All the screenshots below come from a packet capture taken directly on the endpoint.
10.10.10.10 is the endpoint, while 10.10.10.20 is Expressway.

To open up the BFCP connection, the client is sending a Hello message to the port advertised within SDP and the server responds with a HelloAck:

You will see this message exchange occurring periodically as a keep alive mechanism.
In addition, the HelloAck will contain a list of SupportedPrimitives and SupportedAttributes:

For details have a look at the BFCP RFC available here. It’s worth mentioning that the original standard applies to BFCP over TCP.
You’ve already noticed that UDP is being used – that is still a draft but it’s used for good reasons.

When a BFCP Client (the endpoint in our case) wants to start sharing, it will send a FloorRequest to the BFCP Server (Expressway here).
The FloorRequest contains the previously described Conference ID, User ID and Floor ID:

The server will then normally grant the request with a FloorRequestStatus with the same attribute values and a Request Status: Granted:

To stop presenting, a FloorRelease is being sent by the client, which is then approved with a FloorRequestStatus by the server. This time the Request Status value will be Released.

Summary

While this is not an exhaustive BFCP walkthrough, it contains all the relevant items that will allow you to understand its operation.
And if you have the understanding, troubleshooting any screen sharing issues will be a piece of cake.
Most importantly you can now educate fellow engineers that BFCP is not the second video channel 🙂