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

["Henry Sinnreich" <[e-mail]>]

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

This simplicity may be far too expensive in real deployments.
The effort to develop the protocol for TURN servers behind p2p friendly
NAT is fully justified IMHO.

Henry

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Song Yongchao
Sent: Friday, February 01, 2008 8:22 AM
To: 'Cullen Jennings'; 'Bruce Lowekamp'
Cc: 'P2PSIP Mailing List'
Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer

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
_______________________________________________
P2PSIP mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/p2psip
From [e-mail]  Fri Feb  1 01:58:13 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 B6BAD3A691E;
	Fri,  1 Feb 2008 01:58:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.465
X-Spam-Level: 
X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5
	tests=[AWL=-0.921, BAYES_00=-2.599, FRT_ADOBE2=2.455,
	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 8MCG316keR+G; Fri,  1 Feb 2008 01:58:12 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C445E3A6905;
	Fri,  1 Feb 2008 01:58:12 -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 6335A3A6905
	for <[e-mail]>; Fri,  1 Feb 2008 01:58:11 -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 wMMU0YdWplZK for <[e-mail]>;
	Fri,  1 Feb 2008 01:58:10 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [61.144.161.7])
	by core3.amsl.com (Postfix) with ESMTP id 709D03A6897
	for <[e-mail]>; Fri,  1 Feb 2008 01:58:10 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-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 17:59:40 +0800 (CST)
Received: from huawei.com ([172.24.1.24])
	by szxga04-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 17:59:39 +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 17:59:36 +0800 (CST)
Date: Fri, 01 Feb 2008 17:59:36 +0800
From: Song Yongchao <[e-mail]>
In-reply-to: <[e-mail]>
To: 'Henry Sinnreich' <[e-mail]>,
	'Cullen Jennings' <[e-mail]>,
	'Bruce Lowekamp' <[e-mail]>
Message-id: <!&!AAAAAAAAAAAYAAAAAAAAAIILieByQXtOrs7W/bI503TCgAAAEAAAABEcNmWncshBuVAZFDNGfr0BAAAAAA==@huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Mailer: Microsoft Office Outlook 11
Thread-index: AchkjSjvQqR3LNQzQrWRrcJxx0588gAEzSEAAAQh9iAAAd7vAA==
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]

> -----Original Message-----
> From: Henry Sinnreich [mailto:[e-mail]]
> Sent: Friday, February 01, 2008 5:47 PM
> To: Song Yongchao; Cullen Jennings; Bruce Lowekamp
> Cc: P2PSIP Mailing List
> Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
> 
> 
> > For the simplicity, I think we should only admit peers with public
> addresses
> > to be the TURN servers at the first step.
> 
> This simplicity may be far too expensive in real deployments.
> The effort to develop the protocol for TURN servers behind p2p friendly
> NAT is fully justified IMHO.

I'm very glad to hear that, what I just said is about how a peer that is
willing to be a TURN server to detect whether it is behind a P2P friendly
NAT. Could you please provide some information about the justified
detecting?

> 
> Henry
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Song Yongchao
> Sent: Friday, February 01, 2008 8:22 AM
> To: 'Cullen Jennings'; 'Bruce Lowekamp'
> Cc: 'P2PSIP Mailing List'
> Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer
> 
> 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

_______________________________________________
P2PSIP mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/p2psip
From [e-mail]  Fri Feb  1 03:05:00 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 ADE0A3A6891;
	Fri,  1 Feb 2008 03:05:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.596
X-Spam-Level: 
X-Spam-Status: No, score=-4.596 tagged_above=-999 required=5
	tests=[AWL=-1.052, BAYES_00=-2.599, FRT_ADOBE2=2.455,
	J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4]
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 E17IY0GsGr-g; Fri,  1 Feb 2008 03:04:59 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A6C6D3A68E1;
	Fri,  1 Feb 2008 03:04:59 -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 4CBAE3A68E1
	for <[e-mail]>; Fri,  1 Feb 2008 03:04:58 -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 f5zYwlwW7oVh for <[e-mail]>;
	Fri,  1 Feb 2008 03:04:57 -0800 (PST)
Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181])
	by core3.amsl.com (Postfix) with ESMTP id 62C763A6891
	for <[e-mail]>; Fri,  1 Feb 2008 03:04:47 -0800 (PST)
Received: from source ([192.150.20.142]) by exprod6ob101.postini.com
	([64.18.5.12]) with SMTP; Fri, 01 Feb 2008 03:06:21 PST
Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236])
	by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id
	m11B6JGb021889; Fri, 1 Feb 2008 03:06:19 -0800 (PST)
Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99])
	by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id
	m11B5iFX015051; Fri, 1 Feb 2008 03:06:18 -0800 (PST)
Received: from namail5.corp.adobe.com ([10.8.192.88]) by
	apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 1 Feb 2008 20:06:16 +0900
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 1 Feb 2008 03:06:13 -0800
Message-ID: <[e-mail]>
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAIILieByQXtOrs7W/bI503TCgAAAEAAAABEcNmWncshBuVAZFDNGfr0BAAAAAA==@huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [P2PSIP] Choice of STUN peer or TURN peer
Thread-Index: AchkjSjvQqR3LNQzQrWRrcJxx0588gAEzSEAAAQh9iAAAd7vAAABiXTg
References: <[e-mail]>
	<!&!AAAAAAAAAAAYAAAAAAAAAIILieByQXtOrs7W/bI503TCgAAAEAAAABEcNmWncshBuVAZFDNGfr0BAAAAAA==@huawei.com>
From: "Henry Sinnreich" <[e-mail]>
To: "Song Yongchao" <[e-mail]>,
	"Cullen Jennings" <[e-mail]>,
	"Bruce Lowekamp" <[e-mail]>
X-OriginalArrivalTime: 01 Feb 2008 11:06:16.0123 (UTC)
	FILETIME=[76E548B0:01C864C2]
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]

> how a peer that is willing to be a TURN server to detect whether it is

> behind a P2P friendly NAT.
> Could you please provide some information 

Two excellent papers deal with NAT discovery:

< draft-ietf-behave-nat-behavior-discovery-02>
<draft-wing-behave-nat-control-stun-usage-05>

These are powerful tools not only to detect the NAT behavior but also to
determine the position in multi-level NAT-ed networks.

Deployment on the net may yet reveal some more work is required for fine
tuning, 
but the above are the best I know of today and seem to be the right
approach.

My apology if I have missed some other recent relevant work.

Henry

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Song Yongchao
Sent: Friday, February 01, 2008 11:00 AM
To: Henry Sinnreich; 'Cullen Jennings'; 'Bruce Lowekamp'
Cc: 'P2PSIP Mailing List'
Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer

> -----Original Message-----
> From: Henry Sinnreich [mailto:[e-mail]]
> Sent: Friday, February 01, 2008 5:47 PM
> To: Song Yongchao; Cullen Jennings; Bruce Lowekamp
> Cc: P2PSIP Mailing List
> Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
> 
> 
> > For the simplicity, I think we should only admit peers with public
> addresses
> > to be the TURN servers at the first step.
> 
> This simplicity may be far too expensive in real deployments.
> The effort to develop the protocol for TURN servers behind p2p
friendly
> NAT is fully justified IMHO.

I'm very glad to hear that, what I just said is about how a peer that is
willing to be a TURN server to detect whether it is behind a P2P
friendly
NAT. Could you please provide some information about the justified
detecting?

> 
> Henry
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
Behalf
> Of Song Yongchao
> Sent: Friday, February 01, 2008 8:22 AM
> To: 'Cullen Jennings'; 'Bruce Lowekamp'
> Cc: 'P2PSIP Mailing List'
> Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer
> 
> 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

_______________________________________________
P2PSIP mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/p2psip
From [e-mail]  Fri Feb  1 05:52:20 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 28F732944A7
	for <[e-mail]>; Fri,  1 Feb 2008 05:50:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level: 
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010,
	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 C2NX+JS7M6ae
	for <[e-mail]>;
	Fri,  1 Feb 2008 05:50:55 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 176E329452D
	for <[e-mail]>; Fri,  1 Feb 2008 05:26:00 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: ietf.org mailing list memberships reminder
From: [e-mail]
To: [e-mail]
X-No-Archive: yes
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2008 05:04:25 -0800
Precedence: bulk
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
List-Id: <mailman.core3.amsl.com>
X-List-Administrivia: yes
Sender: [e-mail]
Errors-To: [e-mail]

This is a reminder, sent out once a month, about your ietf.org mailing
list memberships.  It includes your subscription info and how to use
it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, [e-mail]) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.

If you have questions, problems, comments, etc, send them to
[e-mail].  Thanks!

http://www.ietf.org/mailman/options/p2psip/p2psip-archive%40optimus.ietf.org
From [e-mail]  Fri Feb  1 05:52:23 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 373E6294411
	for <[e-mail]>; Fri,  1 Feb 2008 05:50:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level: 
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010,
	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 njJi0ABwuxMg
	for <[e-mail]>;
	Fri,  1 Feb 2008 05:50:31 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id AFB5D2944C7
	for <[e-mail]>; Fri,  1 Feb 2008 05:25:51 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: ietf.org mailing list memberships reminder
From: [e-mail]
To: [e-mail]
X-No-Archive: yes
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2008 05:04:24 -0800
Precedence: bulk
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
List-Id: <mailman.core3.amsl.com>
X-List-Administrivia: yes
Sender: [e-mail]
Errors-To: [e-mail]

This is a reminder, sent out once a month, about your ietf.org mailing
list memberships.  It includes your subscription info and how to use
it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, [e-mail]) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.

If you have questions, problems, comments, etc, send them to
[e-mail].  Thanks!

http://www.ietf.org/mailman/options/p2psip/p2psip-archive%40optimus.ietf.org
From [e-mail]  Fri Feb  1 08:54:41 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 D60653A698C;
	Fri,  1 Feb 2008 08:54:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.525
X-Spam-Level: 
X-Spam-Status: No, score=-4.525 tagged_above=-999 required=5
	tests=[AWL=-0.981, BAYES_00=-2.599, FRT_ADOBE2=2.455,
	J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4]
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 O+HcaHLOb7h4; Fri,  1 Feb 2008 08:54:40 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A498D3A68A9;
	Fri,  1 Feb 2008 08:54:40 -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 5DF653A6891
	for <[e-mail]>; Fri,  1 Feb 2008 08:54:39 -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 RSRT4RQNpOQc for <[e-mail]>;
	Fri,  1 Feb 2008 08:54:38 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117])
	by core3.amsl.com (Postfix) with ESMTP id 0F2713A6888
	for <[e-mail]>; Fri,  1 Feb 2008 08:54:38 -0800 (PST)
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-6.cisco.com with ESMTP; 01 Feb 2008 08:56:13 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m11GuCTO002355; 
	Fri, 1 Feb 2008 08:56:12 -0800
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m11GuBZx005503;
	Fri, 1 Feb 2008 16:56:12 GMT
From: "Dan Wing" <[e-mail]>
To: "'Henry Sinnreich'" <[e-mail]>
References: <[e-mail]>
	<!&!AAAAAAAAAAAYAAAAAAAAAIILieByQXtOrs7W/bI503TCgAAAEAAAABEcNmWncshBuVAZFDNGfr0BAAAAAA==@huawei.com>
	<[e-mail]>
Date: Fri, 1 Feb 2008 08:56:11 -0800
Message-ID: <069d01c864f3$59cdf700$[e-mail]>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AchkjSjvQqR3LNQzQrWRrcJxx0588gAEzSEAAAQh9iAAAd7vAAABiXTgAA0J+vA=
In-Reply-To: <[e-mail]>
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
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]

 

> -----Original Message-----
> From: Henry Sinnreich [mailto:[e-mail]] 
> Sent: Friday, February 01, 2008 3:06 AM
> To: Song Yongchao; Cullen Jennings; Bruce Lowekamp
> Cc: P2PSIP Mailing List; Dan Wing
> Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
> 
> > how a peer that is willing to be a TURN server to detect 
> whether it is
> 
> > behind a P2P friendly NAT.
> > Could you please provide some information 
> 
> Two excellent papers deal with NAT discovery:
> 
> < draft-ietf-behave-nat-behavior-discovery-02>
> <draft-wing-behave-nat-control-stun-usage-05>

The second paper, draft-wing-behave-nat-control-stun-usage, 
resulted in a BoF at the last IETF in Vancouver.  The consensus
at that BoF was that IETF would not be successful building
such a protocol.  Minutes of the BoF are at
http://www.ietf.org/proceedings/07dec/safe.html and audio is available at
http://videolab.uoregon.edu/events/ietf/.  A mailing list, SAFE, was created
to discuss it.  Archives are at
http://www.ietf.org/mail-archive/web/safe/current/index.html

If there is interest in pursuing SAFE or the NAT Control STUN Usage, please
email [e-mail] or email me off-list.

-d

> These are powerful tools not only to detect the NAT behavior 
> but also to
> determine the position in multi-level NAT-ed networks.
> 
> Deployment on the net may yet reveal some more work is 
> required for fine
> tuning, 
> but the above are the best I know of today and seem to be the right
> approach.
> 
> My apology if I have missed some other recent relevant work.
> 
> Henry
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf
> Of Song Yongchao
> Sent: Friday, February 01, 2008 11:00 AM
> To: Henry Sinnreich; 'Cullen Jennings'; 'Bruce Lowekamp'
> Cc: 'P2PSIP Mailing List'
> Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer
> 
> > -----Original Message-----
> > From: Henry Sinnreich [mailto:[e-mail]]
> > Sent: Friday, February 01, 2008 5:47 PM
> > To: Song Yongchao; Cullen Jennings; Bruce Lowekamp
> > Cc: P2PSIP Mailing List
> > Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
> > 
> > 
> > > For the simplicity, I think we should only admit peers with public
> > addresses
> > > to be the TURN servers at the first step.
> > 
> > This simplicity may be far too expensive in real deployments.
> > The effort to develop the protocol for TURN servers behind p2p
> friendly
> > NAT is fully justified IMHO.
> 
> I'm very glad to hear that, what I just said is about how a 
> peer that is
> willing to be a TURN server to detect whether it is behind a P2P
> friendly
> NAT. Could you please provide some information about the justified
> detecting?
> 
> > 
> > Henry
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> Behalf
> > Of Song Yongchao
> > Sent: Friday, February 01, 2008 8:22 AM
> > To: 'Cullen Jennings'; 'Bruce Lowekamp'
> > Cc: 'P2PSIP Mailing List'
> > Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer
> > 
> > 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
> 
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> http://www.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/p2psip
From [e-mail]  Fri Feb  1 09:23:32 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 A14873A69A1;
	Fri,  1 Feb 2008 09:23:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.81
X-Spam-Level: 
X-Spam-Status: No, score=-5.81 tagged_above=-999 required=5 tests=[AWL=0.789,
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ynMGoAicDMLX; Fri,  1 Feb 2008 09:23:32 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E7F003A68CB;
	Fri,  1 Feb 2008 09:23:29 -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 BF39E3A68CB
	for <[e-mail]>; Fri,  1 Feb 2008 09:23:28 -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 tQC5DlLRAK0I for <[e-mail]>;
	Fri,  1 Feb 2008 09:23:27 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71])
	by core3.amsl.com (Postfix) with ESMTP id E1D5E3A68B0
	for <[e-mail]>; Fri,  1 Feb 2008 09:23:26 -0800 (PST)
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-2.cisco.com with ESMTP; 01 Feb 2008 09:25:01 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m11HP1p9013533; 
	Fri, 1 Feb 2008 09:25:01 -0800
Received: from dwingwxp01 ([10.32.240.196])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m11HOuZx003990;
	Fri, 1 Feb 2008 17:24:56 GMT
From: "Dan Wing" <[e-mail]>
To: "'JiangXingFeng'" <[e-mail]>,
	"'Bruce Lowekamp'" <[e-mail]>
References: <[e-mail]>
	<002101c864a0$8f1ac3a0$[e-mail]>
Date: Fri, 1 Feb 2008 09:24:55 -0800
Message-ID: <077401c864f7$605bfc80$[e-mail]>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AchhxwRiKwoxy6LaSZ6TgKaHnj8wdgC2F6bgABX7SuA=
In-Reply-To: <002101c864a0$8f1ac3a0$[e-mail]>
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
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]

 

> -----Original Message-----
> From: JiangXingFeng [mailto:[e-mail]] 
> Sent: Thursday, January 31, 2008 11:04 PM
> To: 'Bruce Lowekamp'
> Cc: 'Dan Wing'; 'P2PSIP Mailing List'
> Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
> 
> 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? 
> 

Can you draw a diagram of that (in PowerPoint/JPEG/GIF or ASCII)?

-d


> Regards!
> 
> JiangXingFeng
> 

_______________________________________________
P2PSIP mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/p2psip
From [e-mail]  Fri Feb  1 16:12:39 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 E0AB828C502;
	Fri,  1 Feb 2008 16:12:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4]
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 tyCeloETohnI; Fri,  1 Feb 2008 16:12:39 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 0F1B828C47C;
	Fri,  1 Feb 2008 16:12:39 -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 0B04328C445
	for <[e-mail]>; Fri,  1 Feb 2008 16:12:38 -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 O2evCOIIP8mZ for <[e-mail]>;
	Fri,  1 Feb 2008 16:12:37 -0800 (PST)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56])
	by core3.amsl.com (Postfix) with ESMTP id 0399328C363
	for <[e-mail]>; Fri,  1 Feb 2008 16:12:36 -0800 (PST)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	m120E6G19940; Sat, 2 Feb 2008 00:14:06 GMT
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 1 Feb 2008 18:13:52 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [P2PSIP] Choice of STUN peer or TURN peer
Thread-Index: AchkjSnVj/XzQBCHRDyw9Ba1icG9uwAn2nGg
References: <174701c85f78$24a386b0$[e-mail]>
	<001501c86156$04a31ee0$[e-mail]>
	<[e-mail]>
	<[e-mail]>
From: "Francois Audet" <[e-mail]>
To: "Cullen Jennings" <[e-mail]>,
	"Bruce Lowekamp" <[e-mail]>
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]

I'm sure this is an incredibly dumb question: but why does a peer need to
think of being a TURN server (by presumably "testing" if it is behind a NAT)?

Wouldn't it work if all peer always try to be TURN/STUN servers?
A peer would advertize a TURN server for the any public IP addresses
it has. That includes both local public IP addresses as well as
self-discovered IP addresses (gathered through STUN using other peers).

If it happens that the peer is behind a NAT that does not have an 
endpoint independent mapping, then it just won't receive any TURN/STUN packets.

The algorithm could work something like this, upon connecting to the network:

- If local IP address is public then advertize it (both STUN and TURN)
- Then, when another peer STUN server is discovered, discover if you have another public IP address
  binding (that would occur for example if you have NATing of public IP addresses)
- Then advertize new IP address (both for STUN and TURN server) on discovered IP address and port
- And so on

You just won't get any incoming STUN/TURN destined to your local IP:port if you are NATed (public to
public). Similarly, you won't get any incoming STUN/TURN destined to your discovered IP:port if the
NAT is not endpoint-independent.

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Cullen Jennings
> Sent: Thursday, January 31, 2008 20:44
> To: Bruce Lowekamp
> Cc: P2PSIP Mailing List
> Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer
> 
> 
> 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
> 
_______________________________________________
P2PSIP mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/p2psip