IETF Logo Mail Archive

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

"Dan Wing" <dwing@cisco.com> Thu, 24 January 2008 22:33 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 1JIAdl-0002PR-IR; Thu, 24 Jan 2008 17:33:45 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIAdk-0002PM-Ge for p2psip@ietf.org; Thu, 24 Jan 2008 17:33:44 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIAdk-0005gC-4M for p2psip@ietf.org; Thu, 24 Jan 2008 17:33:44 -0500
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Jan 2008 14:33:43 -0800
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0OMXhMm006384; Thu, 24 Jan 2008 14:33:43 -0800
Received: from dwingwxp01 (dhcp-128-107-163-68.cisco.com [128.107.163.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id m0OMXKp5029088; Thu, 24 Jan 2008 22:33:38 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Jerry Yin' <jerry_yin@mitel.com>
References: <000b01c85eb3$70cc6720$c3f0200a@cisco.com> <GDEOKMPIPEGAEADGFFKEEEHAHLAA.jerry_yin@mitel.com>
Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
Date: Thu, 24 Jan 2008 14:33:21 -0800
Message-ID: <002501c85ed9$2cbfca60$44a36b80@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcheunYyW4zdec+fSxm/JgJ4n7HZ7gAAYpXQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <GDEOKMPIPEGAEADGFFKEEEHAHLAA.jerry_yin@mitel.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1975; t=1201214023; x=1202078023; 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=C0TWyFChWdAIerJp1Immda8oV5S/LUU5qxjLM3uiJGU=; b=SE2H6E88cV0HghLKVRKJOihnWb3faiZGZwNLCc765XpQn+o1962L35pJRV tz0vydT4/NqrpftATWGv1HKxYtl9kQADyPhxU3N/eagqFqitqlxI1J9FykOc VGv8l85S0B;
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: 3e15cc4fdc61d7bce84032741d11c8e5
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

 

> -----Original Message-----
> From: Jerry Yin [mailto:jerry_yin@mitel.com] 
> Sent: Thursday, January 24, 2008 10:54 AM
> To: Dan Wing
> Cc: 'P2PSIP Mailing List'
> Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
> 
> >
> >
> >   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.
> >
> >
> 
> Does the "p2p-friendly" mean the NAT allows the STUN messages 
> pass through?
> How does the message 1 (STUN) go through the NAT?

The p2p-sip TURN server, prior to those messages above, 
determined its publicly-routable IP address and publicly-
routable UDP port.  It may have determined that via STUN 
(or, if there is only one level of NAT, it might have 
determined that via UPnP or NAT-PMP).

The p2p-sip TURN server also determines that it can receive 
STUN requests from arbitrary STUN clients via that port; Bruce 
I believe has written up how a TURN server makes that 
determination.  Once the TURN server has made that determination, 
it would register itself as a TURN server in the p2p overlay 
network.

> I guess the TURN server has to send STUN keep alive messages 
> to keep the NAT
> hole open before the TURN request expire?

Yes, the p2p-sip TURN server would be responsible for keeping 
open all of the pinholes necessary for the p2p-sip TURN server 
to operate.

-d


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

v2.23.0 | Report a Bug | By Email