I’m participating in a project which was targeted to dual stream control together with MTs of Polycom and Huawei, by using BFCP protocol while a SIPProxy is invloved.
Working environment:
A. Several MTs working behind different NAT.
B. A Polycom SIP Proxy Server in internet.
MT:
Polycom MT model: POLYCOM RealPresence Group 550, firmware version: unknown.
Huawei MT model: TE60, firmware version: TEX0 V100R001C01B024SP05 Release 1.1.24.5 May 7 2014 04:06:40
Kedacom MT model: HD3
Both of Polycom and Huawei MTs are using BFCP over UDP mode in proxy mode, no matter their SIP stack is using TLS or not, same if we forced to use SIP over TCP only.
Seems the root cause is Polycom SIP Proxy supports only BFCP over UDP for relay BFCP commands.
However, our SIP MT supports only BFCP over TCP.
So to implement BFCP over UDP for our MT, the major job it is.
Here we go.
1. Try get the BFCP related RFC documents
First thing to do is go to ietf to check out the RFC documents which related with BFCP.
http://datatracker.ietf.org/doc/search/?name=bfcp&rfcs=on&activedrafts=on&olddrafts=on&sort=
There you’ll get 3 Standard typed RFC documents:
a. RFC 4582: The Binary Floor Control Protocol (BFCP)
b. RFC 4583: Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
c. RFC 5018: Connection Establishment in the Binary Floor Control Protocol (BFCP)
and some drafts:
a. draft-ietf-bfcpbis-rfc4582bis-11, The Binary Floor Control Protocol (BFCP)
b. draft-sandbakken-dispatch-bfcp-udp-03, Revision of the Binary Floor Control Protocol (BFCP) for use over an unreliable transport
c. draft-ietf-bfcpbis-rfc453bis-09, Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
…
2. Get into the documents for BFCP over UDP
After do some dig into the documents, turns out all the 3 RFCs are not describing BFCP over UDP or relavant.
That is to say we have no standard to follow for BFCP over UDP for now, we can only turn to the draft documents:
A. draft-ietf-bfcpbis-rfc4582bis-11
B. draft-sandbakken-dispatch-bfcp-udp-03
C. draft-ietf-bfcpbis-rfc453bis-09
Relationship of A, B, C:
A is the newest one, it replaced B which once replaced C.
3. About BFCP UDP and TCP
The major difference between BFCP over TCP and BFCP over UDP are:
A. UDP floor control message needs an ACK to confirm the message was received(and processed) properly, while BFCP over TCP can benefit from the TCP reliable machenism.
B. UDP packets can be relayed more easier than TCP packets while using Proxies like in this scenario.
4. Definition confliction in Primitive value
Bad thing happens, even protocol designed by great company as Cisco and Ericsson.
In draft-sandbakken-dispatch-bfcp-udp-03
+——-+———————–+——————–+
| Value | Primitive | Direction |
+——-+———————–+——————–+
| 14 | FloorRequestStatusAck | P -> S ; Ch -> S |
| 15 | ErrorAck | P -> S ; Ch -> S |
| 16 | FloorStatusAck | P -> S ; Ch -> S |
| 17 | Goodbye | P -> S ; Ch -> S ; |
| | | P <- S ; Ch <- S |
| 18 | GoodbyeAck | P -> S ; Ch -> S ; |
| | | P <- S ; Ch <- S |
+——-+———————–+——————–+
In draft-ietf-bfcpbis-rfc4582bis-11
+——-+———————–+——————–+
| Value | Primitive | Direction |
+——-+———————–+——————–+
| 1 | FloorRequest | P -> S |
| 2 | FloorRelease | P -> S |
| 3 | FloorRequestQuery | P -> S ; Ch -> S |
| 4 | FloorRequestStatus | P <- S ; Ch <- S |
| 5 | UserQuery | P -> S ; Ch -> S |
| 6 | UserStatus | P <- S ; Ch <- S |
| 7 | FloorQuery | P -> S ; Ch -> S |
| 8 | FloorStatus | P <- S ; Ch <- S |
| 9 | ChairAction | Ch -> S |
| 10 | ChairActionAck | Ch <- S |
| 11 | Hello | P -> S ; Ch -> S |
| 12 | HelloAck | P <- S ; Ch <- S |
| 13 | Error | P <- S ; Ch <- S |
| 14 | FloorRequestStatusAck | P -> S ; Ch -> S |
| 15 | FloorStatusAck | P -> S ; Ch -> S |
| 16 | Goodbye | P -> S ; Ch -> S ; |
| | | P <- S ; Ch <- S |
| 17 | GoodbyeAck | P -> S ; Ch -> S ; |
| | | P <- S ; Ch <- S |
+——-+———————–+——————–+
Still not find out what the problem it is? Check the Primitive Value from 15 to 17, the definitions in the two drafts are complete different.
BTW: Wireshark, Version 1.10.6 (v1.10.6 from master-1.10), interpret the primitive value according to draft-sandbakken-dispatch-bfcp-udp-03
5. Bug or something else?
Because we are using Polycom’s SIP proxy for test, so we took Polycom’s BFCP protocol command for the standard one.
But their are surprises after digged into Polycom 550:
a. Does not recognize FloorRelease command.
Polycom 550 was a Server (BFCP server role), and Huawei TE60 as a Participant(BFCP client role), when Huawei TE60 sent a FloorRelease command to Polycom 550, Polycom 550 did not response to this command.
However, in the HelloAck reply, Polycom declared that it do support FloorRelease.
Don’t know why.
BFCP – HelloAck – SupportedPrimitives
b. Floor Control Header info
There is a field represents as Transaction Responser flag(the 5th bit of the first byte), 1 means a responder, 0 not. But in Polycom BFCP command protocols, seems there are different rules in it.
Here are two example packets sent out by Polycom 550, first one have the responder field value set to 1, second one 0.
BFCP – FloorControlHeader – Responder – True
BFCP – FloorControlHeader – Responder – False
c. Constructing OverallRequestStatus
Are there any rules about the levels for OverallRequestStatus in FloorRequestInformation? ‘Cause I found out that there are some slight differences between Huawei TE60 and Polycom 550.
BFCP – FloorRequestInformation – Polycom550
BFCP – FloorRequestInformation – HuaweiTE60
See, Huawei puts the OverallRequestStatus parallel with FloorRequestStatus, while Polycom puts the FloorRequestStatus under the OverallRequestStatus.
(Not sure whether I mis-interpret the IETF drafts)
6. A temporary conclusion
BFCP sucks:
1. We don’t have a standard to follow(for BFCP over UDP).
2. The primitive definition conflictions in different drafts are really sick.