IETF Logo Mail Archive

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

"Dan Wing" <dwing@cisco.com> Wed, 23 January 2008 02:07 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 1JHV1s-0003rC-Vr; Tue, 22 Jan 2008 21:07:52 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHV1r-0003r7-Q7 for p2psip@ietf.org; Tue, 22 Jan 2008 21:07:51 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHV1r-0002eH-Cm for p2psip@ietf.org; Tue, 22 Jan 2008 21:07:51 -0500
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 22 Jan 2008 18:07:50 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0N27oNd010343; Tue, 22 Jan 2008 18:07:50 -0800
Received: from dwingwxp01 ([10.32.240.195]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m0N27oAl012528; Wed, 23 Jan 2008 02:07:50 GMT
From: Dan Wing <dwing@cisco.com>
To: 'JiangXingFeng' <jiang.x.f@huawei.com>, 'P2PSIP Mailing List' <p2psip@ietf.org>
References: <003a01c85cda$61991f30$2d09a40a@china.huawei.com>
Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
Date: Tue, 22 Jan 2008 18:07:50 -0800
Message-ID: <44e301c85d64$c1a11010$c3f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <003a01c85cda$61991f30$2d09a40a@china.huawei.com>
Thread-Index: Achc2mE+N3Ev8YYNRpCsDNPfo2q5cgAijS9Q
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1953; t=1201054070; x=1201918070; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20<dwing@cisco.com> |Subject:=20RE=3A=20[P2PSIP]=20Choice=20of=20STUN=20peer=20 or=20TURN=20peer |Sender:=20; bh=/be3dE4Cjd8cLrezMnfrMT2RCV1mte6dDaMKJbR3/mc=; b=n3dAKlMFi3ITf0PwQ9slja9jqbF3UDzsVtvFR2EdmxXJXU/ya0j9PJ2AlW zhMGhDYonflJg8gTwPBn061ks79xAPRPNAb5BrtMd+JJtjZF0VOfs9hMwWML sVo0MoPfjk;
Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc:
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>
Errors-To: p2psip-bounces@ietf.org

ICE allows you to have multiple STUN servers.  In the diagram you provided,
Peer A could contact Peer C, Peer D, and Peer B, and would notice different
answers from some (or all) of them.  All of those different answers can be
provided as different candidates (a=candidate) in the call setup message.

-d


> -----Original Message-----
> From: JiangXingFeng [mailto:jiang.x.f@huawei.com] 
> Sent: Tuesday, January 22, 2008 1:37 AM
> To: 'P2PSIP Mailing List'
> Subject: [P2PSIP] Choice of STUN peer or TURN peer
> 
> 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

v2.23.0 | Report a Bug | By Email