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

JiangXingFeng <jiang.x.f@huawei.com> Fri, 25 January 2008 02:09 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 1JIE07-0003FF-7k; Thu, 24 Jan 2008 21:09:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIE06-0003F9-QO for p2psip@ietf.org; Thu, 24 Jan 2008 21:09:02 -0500
Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIE04-000839-Op for p2psip@ietf.org; Thu, 24 Jan 2008 21:09:02 -0500
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JV600MXIGM06X@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 25 Jan 2008 10:08:24 +0800 (CST)
Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JV60061WGLY20@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 25 Jan 2008 10:08:24 +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 <0JV6005L1GLXK3@szxml03-in.huawei.com> for p2psip@ietf.org; Fri, 25 Jan 2008 10:08:22 +0800 (CST)
Date: Fri, 25 Jan 2008 10:08:21 +0800
From: JiangXingFeng <jiang.x.f@huawei.com>
Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
In-reply-to: <000b01c85eb3$70cc6720$c3f0200a@cisco.com>
To: 'Dan Wing' <dwing@cisco.com>, 'Bruce Lowekamp' <lowekamp@sipeerior.com>
Message-id: <002b01c85ef7$29410840$2d09a40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Thread-index: AchdzJ90kFg6Xq4fTZOyCgPVF+N/zwAif+RQABT2TDAAEsYpMA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: 'P2PSIP Mailing List' <p2psip@ietf.org>
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

> 
> The TURN server is responsible for obtaining a publicly-routable
> address, and giving that address to the TURN client.  The TURN
> specification, as currently written, expects the TURN server
> itself to be on a publicly-routable network ("on the Internet").
> 
> If, however, the TURN server is behind a NAT, and we want the
> TURN server to still be responsible for obtaining a
> publicly-routable IP address, you could do that.  Here is a
> new technique that could be used:  the TURN server could use
> STUN (or NAT-PMP or UPnP, if there is only one NAT between
> the TURN server and the Internet), and obtain a publicly-
> routable mapping:
> 
> 
>   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------------|
> 
> 
> Messages 2-3 are normal STUN request/response messages, and
> tell the TURN server a publicly-routable IP address and UDP
> port.  The IP address and UDP port returned in in the STUN
> Response (message 3) is the TURN server's publicly-routable
> transport address, and is given to the TURN client in message
> 4.
> 
> For the above message flow to work, the NAT has to be
> p2p-friendly, of course -- that is a requirement for a
> successful TURN server behind a NAT.


If the NAT is nested, the location of the STUN server may fail the above the
method. For example, if the STUN server is also behind the NAT and reflects
the inner NAT mapping, not outer most NAT mapping, to the TURN server, the
relayed address will not be used for the TURN client to contact with TURN
server. In order to avoid this kind of failure, stun server's location
should be learned by its clients. In china, due to the lack of the IPv4
address, nested NAT is not a rare situation. 
Comments?

Regards!
JiangXingFeng


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