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

"Jerry Yin" <jerry_yin@mitel.com> Thu, 24 January 2008 18:53 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 1JI7Cl-0000sm-Cj; Thu, 24 Jan 2008 13:53:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI7Ck-0000sh-7E for p2psip@ietf.org; Thu, 24 Jan 2008 13:53:38 -0500
Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI7Cj-0005pq-Tm for p2psip@ietf.org; Thu, 24 Jan 2008 13:53:38 -0500
Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 9B6C02C015; Thu, 24 Jan 2008 13:53:37 -0500 (EST)
X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com
Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnxjJVxdEvRH; Thu, 24 Jan 2008 13:53:36 -0500 (EST)
Received: from LT4GKCG41 (unknown [10.31.8.26]) by smtp.mitel.com (Postfix) with SMTP id 24FFF2C022; Thu, 24 Jan 2008 13:53:36 -0500 (EST)
From: Jerry Yin <jerry_yin@mitel.com>
To: Dan Wing <dwing@cisco.com>
Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
Date: Thu, 24 Jan 2008 13:53:36 -0500
Message-ID: <GDEOKMPIPEGAEADGFFKEEEHAHLAA.jerry_yin@mitel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <000b01c85eb3$70cc6720$c3f0200a@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
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

>
>
>   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?

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

thanks,
Jerry


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