Re: [P2PSIP] Choice of STUN peer or TURN peer

JiangXingFeng <jiang.x.f@huawei.com> Sat, 02 February 2008 03:21 UTC

Return-Path: <p2psip-bounces@ietf.org>
X-Original-To: ietfarch-p2psip-archive@core3.amsl.com
Delivered-To: ietfarch-p2psip-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D4D3A6842; Fri, 1 Feb 2008 19:21:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.483
X-Spam-Level:
X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599]
Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75hfgOKDAAVK; Fri, 1 Feb 2008 19:21:18 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0397C28C24F; Fri, 1 Feb 2008 19:21:18 -0800 (PST)
X-Original-To: p2psip@core3.amsl.com
Delivered-To: p2psip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5C813A6912 for <p2psip@core3.amsl.com>; Fri, 1 Feb 2008 19:21:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hOkOkty9RPd for <p2psip@core3.amsl.com>; Fri, 1 Feb 2008 19:21:12 -0800 (PST)
Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [61.144.161.54]) by core3.amsl.com (Postfix) with ESMTP id 8EBBE28C2C1 for <p2psip@ietf.org>; Fri, 1 Feb 2008 19:21:04 -0800 (PST)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JVL003XKDDLWO@szxga02-in.huawei.com> for p2psip@ietf.org; Sat, 02 Feb 2008 11:22:34 +0800 (CST)
Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JVL007BXDDLQ3@szxga02-in.huawei.com> for p2psip@ietf.org; Sat, 02 Feb 2008 11:22:33 +0800 (CST)
Received: from j36340 ([10.164.9.45]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JVL00ILTDDKYX@szxml03-in.huawei.com> for p2psip@ietf.org; Sat, 02 Feb 2008 11:22:33 +0800 (CST)
Date: Sat, 02 Feb 2008 11:22:32 +0800
From: JiangXingFeng <jiang.x.f@huawei.com>
In-reply-to: <077401c864f7$605bfc80$c4f0200a@cisco.com>
To: 'Dan Wing' <dwing@cisco.com>, 'Bruce Lowekamp' <lowekamp@sipeerior.com>
Message-id: <002c01c8654a$d9800450$2d09a40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Office Outlook 11
Thread-index: AchhxwRiKwoxy6LaSZ6TgKaHnj8wdgC2F6bgABX7SuAAEF+0IA==
Cc: 'P2PSIP Mailing List' <p2psip@ietf.org>
Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2psip-bounces@ietf.org
Errors-To: p2psip-bounces@ietf.org

TURN client      Peer X    STUN server        NAT      TURN server
  |               |           |                   |             |
1. |-------------------->|---Give me a Turn Address
--------->|----------------->|
2.                           |<-----------------STUN Request----------|
3.                           |-------------------STUN Response------>|
4. |<--------------------|<---------here is your TURN
address-------------------|
             Figure 1: message flow to get a TURN address
As Bruce suggested that message 1 and 4 will be routed through the overlay.
So here, we assume the Peer X is the neighbor peer to the TURN server.
Message 4 will return to TURN client by traversing Peer X or not. Here, we
assume the NAT has an address-dependent filtering behavior which most NATs
have. 

When TURN servers receives message 1 through the overlay, it will set the
Internal Remote transport address as Peer X's transport address. Then send
message back to the Internal Remote transport address in its Internal
5-tuple. Then NAT will open a port for Peer X. 

TURN client      Peer Y     Peer B        NAT      TURN server
|                  |           |             |             |
5.|--------------------- ->|-------Send
Indication---------------------------->| 
6.                            |----Binding Request-------     | (filtered by
the NAT)
7.
8.
			Figure 2 message flow for connectivity check in ICE

When TURN client wants to communicate with Peer B which is also behind the
NAT (the NAT in front of the Peer B is ignored in the Figure 2), it should
use overlay routing to exchange their candidates.
We assume the candidate pair from TURN client is {relayed candidate, server
reflexive candidate of Peer B}
So In message 5, TURN client will send a binding message which will be
encapsulate in the Send Indication and the message will be sent to TURN
server. 
There are two ways which could be used to send the message:
1. directly, due to NAT has a address-dependent filtering behavior, NAT will
filter the message;
2. through the overlay. yes, the message could arrive at the TURN server.
But you know, overlay topology is changing and the immediate peer to TURN
server in message 5 may not be Peer X any more, may be other peer, such as
Peer Y. For TURN server, it will check its association, and find no matched
internal 5-tuple, because Internal Remoter Transport address has been
changed. It will be discarded by the TURN server. 

On the other hand, Peer B will send a Binding request to TURN client's
relayed address, whose destination is TURN server. But it will also be
filtered by the NAT due to its filtering behavior. 

To be honest, I am not very familiar with ICE. If there is something wrong,
please point it out. Thanks. 

JiangXingFeng

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
http://www.ietf.org/mailman/listinfo/p2psip