[XCON] Fwd: How to transport BFCP in the presence of NATs

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mon, 19 July 2010 12:01 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A3753A6AF3 for <xcon@core3.amsl.com>; Mon, 19 Jul 2010 05:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.721
X-Spam-Level:
X-Spam-Status: No, score=-105.721 tagged_above=-999 required=5 tests=[AWL=0.878, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvzu-eAS1m8M for <xcon@core3.amsl.com>; Mon, 19 Jul 2010 05:01:51 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 61DC23A6AF2 for <xcon@ietf.org>; Mon, 19 Jul 2010 05:01:51 -0700 (PDT)
X-AuditID: c1b4fb3d-b7b90ae00000278d-62-4c443ebd74be
Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 17.DE.10125.DBE344C4; Mon, 19 Jul 2010 14:02:05 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 14:02:04 +0200
Received: from [131.160.126.163] ([131.160.126.163]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 14:02:04 +0200
Message-ID: <4C443EBC.4040603@ericsson.com>
Date: Mon, 19 Jul 2010 15:02:04 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: XCON <xcon@ietf.org>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Jul 2010 12:02:04.0728 (UTC) FILETIME=[342F1B80:01CB273A]
X-Brightmail-Tracker: AAAAAA==
Subject: [XCON] Fwd: How to transport BFCP in the presence of NATs
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jul 2010 12:01:52 -0000

Hi,

I have requested feedback on the BFCP over UDP issue to the transport
community (see email below). Please, follow the discussions on the TSV
area mailing list.

Cheers,

Gonzalo


-------- Original Message --------
Subject: How to transport BFCP in the presence of NATs
Date: Mon, 19 Jul 2010 14:00:37 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
To: tsv-area@ietf.org <tsv-area@ietf.org>

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