[P2PSIP] Choice of STUN peer or TURN peer

JiangXingFeng <jiang.x.f@huawei.com> Tue, 22 January 2008 09:38 UTC

Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHFa7-0004zL-A6; Tue, 22 Jan 2008 04:38:11 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHFa5-0004zG-9d for p2psip@ietf.org; Tue, 22 Jan 2008 04:38:09 -0500
Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHFa3-0002ml-1I for p2psip@ietf.org; Tue, 22 Jan 2008 04:38:08 -0500
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 <0JV100J0MHEA7W@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 22 Jan 2008 17:37:23 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JV1003E4HE833@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 22 Jan 2008 17:37:22 +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 <0JV10051OHE61Z@szxml04-in.huawei.com> for p2psip@ietf.org; Tue, 22 Jan 2008 17:37:20 +0800 (CST)
Date: Tue, 22 Jan 2008 17:37:18 +0800
From: JiangXingFeng <jiang.x.f@huawei.com>
To: 'P2PSIP Mailing List' <p2psip@ietf.org>
Message-id: <003a01c85cda$61991f30$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: Achc2mE+N3Ev8YYNRpCsDNPfo2q5cg==
X-Spam-Score: 1.4 (+)
X-Scan-Signature: bec09d1709ba59869cec93c1a1c207e5
Subject: [P2PSIP] Choice of STUN peer or TURN peer
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1776720240=="
Errors-To: p2psip-bounces@ietf.org

Hi, all:

 

In order to make the peers serve each other, some peers with special
capabilities could be exploited to play the STUN/TURN server role for other
peers who are behind NAT. Guys in P2PSIP community has agreed with that peer
behind NAT should seek help from other peers, not centralized STUN/TURN
server.

 

But which kinds of peers are qualified for playing STUN/TURN server? Of
course, Peers on the public internet could take this responsibility. I also
learned from the list that peers behind p2p-friendly NAT (with end-point
independent mapping and filtering behavior) also could do the same work. But
from my point of view, ICE negotiation procedure may fail if choosing this
kind of peer as STUN/TURN server.

 

Let's show an example: 



Peer A and peer B want to communicate directly. NAT2 is a p2p-friendly NAT.
So peer C would be considered as a candidate STUN server. If peer A choose
the Peer C as its STUN server, peer A will get a mapping on the NAT1 which
is in the address realm of private network. And Peer A will tell peer B this
server reflexive address. But peer B could not reach it because it is in
different address realm.  

 

Am I missing something? Comments are appreciated!

 

Regards!

--

Jiang XingFeng

 

 

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip