[bfcpbis] More comments on RFC 4582

[Gonzalo Camarillo <[e-mail]>]

Hi,

below you can find another old email with more comments on RFC 4582.

Cheers,

Gonzalo

-------- Original Message --------
Subject: BFCP over UDP
Date: Thu, 09 Apr 2009 08:55:57 +0300
From: Gonzalo Camarillo <[e-mail]>
To: XCON <[e-mail]>
CC: [e-mail],  Geir Arne Sandbakken
<[e-mail]>

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