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

Bruce Lowekamp <> Mon, 04 February 2008 16:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEEF93A6FB8; Mon, 4 Feb 2008 08:12:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 54ikJ+ExaJLm; Mon, 4 Feb 2008 08:12:24 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id C842C3A6F59; Mon, 4 Feb 2008 08:12:24 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BC453A6F59 for <>; Mon, 4 Feb 2008 08:12:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OoV7HXU0Hg0o for <>; Mon, 4 Feb 2008 08:12:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AB4D73A6E87 for <>; Mon, 4 Feb 2008 08:12:18 -0800 (PST)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id AF183505AD4; Mon, 4 Feb 2008 11:13:51 -0500 (EST)
In-Reply-To: <313101c86626$bf1872a0$>
References: <174701c85f78$24a386b0$><001501c86156$04a31ee0$><><> <> <2e0701c86576$16be5da0$> <> <313101c86626$bf1872a0$>
Mime-Version: 1.0 (Apple Message framework v753)
Message-Id: <>
From: Bruce Lowekamp <>
Date: Mon, 4 Feb 2008 11:13:50 -0500
To: "Dan Wing" <>
X-Mailer: Apple Mail (2.753)
Cc: 'P2PSIP Mailing List' <>
Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Feb 3, 2008, at 12:36 AM, Dan Wing wrote:
> With the functionality to trigger to the TURN server through the  
> overlay, we
> can run a TURN server even behind an address-filtering NAT (but not a
> port-restricting NAT or a symmetric NAT).  Without the  
> functionality to
> trigger the TURN server, we cannot run behind an address-filtering  
> NAT.

I think this is one of the complicated questions about this type of  
service for an overlay.  It allows functionality that is helpful in  
many cases, but is not as helpful as a fully open TURN server.  Is it  
worth the effort to spec, implement, and provide such a service?  My  
suspicion is that it depends on the type of deployment: a commercial  
service provider wouldn't care, a public unhosted overlay might  
consider the service worthwhile.

> I don't know what (pre-standard) version of ICE that Google  
> implemented, nor
> do I recall which version of ICE added the ability to communicate  
> directly
> even with address-restricted NATs.  The standard version of ICE  
> does something
> vaguely like the above:  it sends a message through the overlay (the
> Offer/Answer exchange, using SIP), and that message causes both  
> peers to try
> to communicate with each other, which allows two peers with address- 
> filtering
> NATs to communicate directly with each other (without a relay).   
> The ability
> to communicate through the p2p-sip overlay to the TURN server  
> provides a
> similar capability so that a TURN server can be behind an address- 
> filtering
> NAT.

This was one of the big reasons we put the TUNNEL method into  
reload-01.  It's very useful to use the overlay as a rendezvous  
service for a variety of applications (SIP and ICE being the most  
obvious for sip applications).   For some applications, by itself it  
may be enough to exchange the application-layer messages, although I  
think media is best not relayed through an overlay.


P2PSIP mailing list