[XCON] BFCP over UDP

[Gonzalo Camarillo <Gonzalo.Camarillo at ericsson.com>]

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