Hi,
the following (expired) draft was presented in the XCON session in San
Francisco:
http://www.watersprings.org/pub/id/draft-sandbakken-xcon-bfcp-udp-00.txt
The agreement was that given the problems TCP has with NATs (the
P2PSIP WG is currently discussing the same issue) it would be a good
idea to define a more NAT-friendly transport for BFCP. The proposal
was to simply use UDP (this is what existing deployments do).
Since BFCP messages can be rather long, we would need an applicability
statement saying which types of messages cannot be used over UDP.
In order to specify the new UDP-based transport we can either put
together a new draft or revise the BFCP specification. I got the
action point to list the things that could be fixed in a potential
revised BFCP spec. These are the contents of my notes. Of course, if
someone knows of more issues, please let us know:
o When a user performs a third-party floor request the beneficiary of
the floor is not informed when the floor is granted. This may not be a
problem because endpoints using third-party floor requests probably
have different means to get in synch but we may want to add some text
about this.
o We do not have errors for an unsupported version of the protocol or
for wrong message length. We do not have a general error either.
o When we get more experience on queue management from real
deployments, it would be nice to explaining it further in the spec.
o UserStatus
UserStatus = (COMMON-HEADER)
[BENEFICIARY-INFORMATION]
1*(FLOOR-REQUEST-INFORMATION) -> remove the 1
*[EXTENSION-ATTRIBUTE]
o A message may need to be longer than the maximum message length
supported by the protocol
o A rather small number of typos
As you can see, at this point there are not so many things to fix...
so, the simplest way forward may be to simply specify a new UDP-based
transport for BFCP. In any case, I would like to get feedback from
folks operating BFCP deployments.
A different alternative (the one the P2PSIP WG is looking at) would be
to either use a UDP encapsulation for TCP or to specify a new
transport protocol... but these alternatives may be more complex than
just using UDP.
Comments?
Thanks,
Gonzalo
