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

[Cullen Jennings <[e-mail]>]

On Jan 28, 2008, at 8:01 AM, Bruce Lowekamp wrote:

> But otherwise, the TURN
> protocol seems to work as is.  For the purposes of a TURN server, a
> NAT having endpoint independent mapping seems to be the only real
> requirement on the NAT

Agree on that but ...
I think the hard part we have not fully solved yet is how a peer that  
is thinking of being a TURN server is going to detect if this is the  
case or not.
_______________________________________________
P2PSIP mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/p2psip
From [e-mail]  Thu Jan 31 23:02:12 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 130EC3A6840;
	Thu, 31 Jan 2008 23:02:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[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 CIxaj8xREmA4; Thu, 31 Jan 2008 23:02:11 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 2714D3A6812;
	Thu, 31 Jan 2008 23:02:11 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C1E5E3A6812
	for <[e-mail]>om>; Thu, 31 Jan 2008 23:02:09 -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 iZFh0adp2jkn for <[e-mail]>om>;
	Thu, 31 Jan 2008 23:02:09 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53])
	by core3.amsl.com (Postfix) with ESMTP id D61EE3A680A
	for <[e-mail]>rg>; Thu, 31 Jan 2008 23:02:08 -0800 (PST)
Received: from huawei.com (szxga01-in [172.24.2.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <[e-mail]> for
	[e-mail]; Fri, 01 Feb 2008 15:03:41 +0800 (CST)
Received: from huawei.com ([172.24.1.24])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <[e-mail]> for
	[e-mail]; Fri, 01 Feb 2008 15:03:41 +0800 (CST)
Received: from j36340 ([10.164.9.45])
	by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTPA id <[e-mail]> for
	[e-mail]; Fri, 01 Feb 2008 15:03:33 +0800 (CST)
Date: Fri, 01 Feb 2008 15:03:33 +0800
From: JiangXingFeng <[e-mail]>
In-reply-to: <[e-mail]>
To: 'Bruce Lowekamp' <[e-mail]>
Message-id: <002101c864a0$8f1ac3a0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Office Outlook 11
Thread-index: AchhxwRiKwoxy6LaSZ6TgKaHnj8wdgC2F6bg
Cc: 'P2PSIP Mailing List' <[e-mail]>
Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2psip>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/p2psip>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

Hi, Bruce:

Sorry for late response. See inline. 

--
Jiang XingFeng

> -----Original Message-----
> 
> > >
> > >   TURN client         STUN server          NAT  TURN server
> > >        |                   |                |      |
> > >  1.    |------give me a TURN address------->|----->|
> > >  2.    |                   |<--STUN Request--------|
> > >  3.    |                   |-STUN Response->|----->|
> > >  4.    |<-----here is your TURN address------------|
> > >
> 
> If we allow a TURN server to be behind a NAT, then the only change I
> would see necessary would that 1 and 4 would have to be routed over
> the overlay (a reload tunnel, for example).  But otherwise, the TURN
> protocol seems to work as is.  For the purposes of a TURN server, a
> NAT having endpoint independent mapping seems to be the only real
> requirement on the NAT as long as the two voice endpoints support ICE;
> the connectivity checks should take care of any form of filtering the
> NAT uses.

While TURN client in question gets its relayed address from the TURN server,
it will exchange them with its peer, say B. According to the connectivity
check in ICE, B and ICE will send message to try to find direct connection. 

So if B send the message destined to the relayed address first, it will be
filtered by the TURN server. Then TURN client sends a message destined to
the B's candidate, it will send the message through the TURN server. But in
the message 1 reached the TURN server in a hop-by-hop way, if the message is
sent directly to the TURN server, it will be filtered. If the message is
sent in a hop-by-hop way through the overlay, the immediate peer to the STUN
server may change over time, so the message may also be filtered. Am I
missing something? 


Regards!

JiangXingFeng

_______________________________________________
P2PSIP mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/p2psip
From [e-mail]  Thu Jan 31 23:20:21 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 664AA3A6854;
	Thu, 31 Jan 2008 23:20:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6]
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 TZ4rGDOHfaKW; Thu, 31 Jan 2008 23:20:20 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 946873A6811;
	Thu, 31 Jan 2008 23:20:20 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 85ED33A680A
	for <[e-mail]>om>; Thu, 31 Jan 2008 23:20:19 -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 cJOcJkTgiq6A for <[e-mail]>om>;
	Thu, 31 Jan 2008 23:20:18 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53])
	by core3.amsl.com (Postfix) with ESMTP id 945DC3A6811
	for <[e-mail]>rg>; Thu, 31 Jan 2008 23:20:18 -0800 (PST)
Received: from huawei.com (szxga01-in [172.24.2.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <[e-mail]> for
	[e-mail]; Fri, 01 Feb 2008 15:21:50 +0800 (CST)
Received: from huawei.com ([172.24.1.24])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <[e-mail]> for
	[e-mail]; Fri, 01 Feb 2008 15:21:50 +0800 (CST)
Received: from s64081 ([10.164.9.47])
	by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTPA id <[e-mail]> for
	[e-mail]; Fri, 01 Feb 2008 15:21:49 +0800 (CST)
Date: Fri, 01 Feb 2008 15:21:49 +0800
From: Song Yongchao <[e-mail]>
In-reply-to: <[e-mail]>
To: 'Cullen Jennings' <[e-mail]>om>,
	'Bruce Lowekamp' <[e-mail]>
Message-id: <!&!AAAAAAAAAAAYAAAAAAAAAIILieByQXtOrs7W/bI503TCgAAAEAAAAFv5pjyAF5tIpzg0AE9h2Q8BAAAAAA==@huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Mailer: Microsoft Office Outlook 11
Thread-index: AchkjSjvQqR3LNQzQrWRrcJxx0588gAEzSEA
Cc: 'P2PSIP Mailing List' <[e-mail]>
Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2psip>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/p2psip>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

See inline
> On Jan 28, 2008, at 8:01 AM, Bruce Lowekamp wrote:
> > But otherwise, the TURN
> > protocol seems to work as is.  For the purposes of a TURN server, a
> > NAT having endpoint independent mapping seems to be the only real
> > requirement on the NAT
> 
> Agree on that but ...
> I think the hard part we have not fully solved yet is how a peer that
> is thinking of being a TURN server is going to detect if this is the
> case or not.

In that case,each peer that is willing to be the TURN server must dialog
with several STUN servers with public address to detect its NAT mapping
type, only peers with public addresses or behind endpoint independent NATs
could be TURN servers. However, STUN servers may be behind NAT either, in
the worst case, it may be behind the same outermost NAT with the peer, and
these STUN servers response different reflexive addresses with the public
STUN servers. So, in that case STUN servers must be classified in to public
addressed and non-public addressed, and the peer willing to be the TURN
server must dialog with public addressed STUN servers to detect its NAT
mapping type.

For the simplicity, I think we should only admit peers with public addresses
to be the TURN servers at the first step.

> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> http://www.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/p2psip