Re: How to transport BFCP in the presence of NATs

[Jukka Manner <[e-mail]>]

Hi Gonzalo,

Would our GUT-scheme be of any help here, in the BFCP over TCP over UDP? 
We have an implementation out for Linux that works great, and it doesn't 
require any changes to the tunnel protocol and application. People have 
used GUT to tunnel various problematic protocols through NATs.

http://tools.ietf.org/html/draft-manner-tsvwg-gut-02

Yet, GUT is only meant to get "challenging" protocols through a legacy, 
old, NAT. It doesn't introduce any full-fledged NAT-traversal signaling, 
e.g., to get a hole for an incoming flow.

cheers,
Jukka




On 07/19/2010 02:00 PM, Gonzalo Camarillo wrote:
> Folks,
>
> BFCP (Binary Floor Control Protocol), defined in RFC 4582, runs between
> a client and a floor control server. Generally, the floor control server
> has a public IP address. The client establishes a TCP connection towards
> the floor control server so that, even if the client is behind a NAT,
> everything works.
>
> However, in some existing deployment scenarios the floor control server
> functionality is implemented in an endpoint, which may be behind a NAT.
> A typical session between two endpoints in these scenarios consist of a
> BFCP connection and one or more media streams (e.g., audio and video)
> between them. In this type of scenario, NAT traversal becomes a problem.
>
> Existing deployments implement different approaches to address the fact
> that the floor control server is not directly reachable. One of these
> approaches consists of transporting BFCP over UDP instead of over TCP
> (this approach is documented in the draft below). In this way, the
> endpoints can use ICE to find connectivity between them.
>
> https://datatracker.ietf.org/doc/draft-sandbakken-xcon-bfcp-udp/
>
> An alternative approach would be to still use TCP as a transport and use
> ICE TCP. However, the success rate of ICE TCP is not high enough at this
> point. Yet another alternative would be to tunnel BFCP over TCP over UDP.
>
> The XCON WG is aware of the guidelines given in RFC 5405 but would like
> to ask the transport community for further guidance on this issue.
>
> Note that this is actually a general issue that will affect any protocol
> for which TCP would be the natural transport but that would need to run
> between endpoints in NATted environments. RELOAD
> (draft-ietf-p2psip-base) would be an example of a similar protocol
> (which currently intends to use ICE TCP).
>
> Given that this issue appear to be more general than BFCP and may affect
> other protocols, we would appreciate to get input on how to proceed.
>
> Thanks,
>
> Gonzalo
>

-- 
Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+451 2481
Aalto University                  Mobile: +358+(0)50+5112973
Department of Communications      Fax:    +358+(0)9+451 2474
and Networking (Comnet)           Office: G320a (Otakaari 5A)
P.O. Box 13000, FIN-00076 Aalto   E-mail: [e-mail]
Finland                           WWW:    www.comnet.tkk.fi