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

"Dan Wing" <> Sun, 03 February 2008 05:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5803E3A6B73; Sat, 2 Feb 2008 21:35:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.231
X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K50-9ZYiuoaF; Sat, 2 Feb 2008 21:35:05 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 4A8673A6ACB; Sat, 2 Feb 2008 21:35:05 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A16293A6B67 for <>; Sat, 2 Feb 2008 21:35:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vd2e6deNSkLl for <>; Sat, 2 Feb 2008 21:35:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 792353A6B45 for <>; Sat, 2 Feb 2008 21:35:02 -0800 (PST)
Received: from ([]) by with ESMTP; 02 Feb 2008 21:36:38 -0800
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m135ac29014416; Sat, 2 Feb 2008 21:36:38 -0800
Received: from dwingwxp01 ([]) by (8.12.10/8.12.6) with ESMTP id m135aauu026508; Sun, 3 Feb 2008 05:36:37 GMT
From: "Dan Wing" <>
To: "'Cullen Jennings'" <>
References: <174701c85f78$24a386b0$><001501c86156$04a31ee0$><><> <> <2e0701c86576$16be5da0$> <>
Date: Sat, 2 Feb 2008 21:36:36 -0800
Message-ID: <313101c86626$bf1872a0$>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Achl//fjytJnxWE9R/WbFwBpAE2n7QABvTPw
In-Reply-To: <>
Authentication-Results: sj-dkim-2;; dkim=pass ( sig from verified; );
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 2, 2008, at 12:32 AM, Dan Wing wrote:
> > Reports indicate that roughly 25% of NATs would block such 
> > incoming packets.
> Which reports are you thinking of here ?

Google uses a pre-standard version of ICE for their user-to-user connections,
and according to, 8% of
those user-to-connections connections require a relay.  

For this to be a problem 8% of the time that two peers cannot establish a
direct connection, about 28% (28%*28%=7.84%) of NATs have a property
(port-specific filtering or port assignment) that would also break a TURN
server trying to run behind that NAT.

This brings me back to thinking about Bruce's idea that a TURN server be
triggered via a message sent through the overlay.  In
<>, I said I
didn't think it would work.  However, on further reflection, there is an
advantage to communicating to the TURN server using the overlay and also
sending it TURN messages directly (i.e., not through the overlay).  This
combination with the TURN client communicating to the TURN server using the
overlay and using a normal TURN request means that a TURN server that is
behind an address-filtering NAT could still be a viable and usable TURN
server.  This would increase the number of TURN servers available to p2p-sip.

This works because the TURN client would have already learned its public IP
address via STUN (although its port would be wrong, or its port would be
filtered), and the TURN client can communicate that IP address and UDP port
through the overlay to the TURN server.  When the TURN server receives that
communication (containing the TURN client's public IP address and UDP port)
through the overlay, the TURN server can send packets towards it; due to
p2p-unfriendlyness of the NAT in front of the TURN client, though, those
packets would be dropped by the TURN client's NAT.  However, those messages
cause the TURN server's NAT to open a permission towards the TURN client's IP
address.  The next retranmission by the TURN client will then make it through
the TURN server's NAT, to the TURN server, and the response will make it back
to the TURN client.  Here is a diagram, with "-" showing peer-to-peer
messages, and "=" showing messages sent through the p2p-sip overlay:

  TURN client   NAT  STUN Server   NAT      TURN server
       |         |        |         |           |
  1.   |--STUN request--->|         |           |
  2.   |--a.b.c.d/12345---|         |           |
       |         |        |         |           |
  3.   |--TURN request (1st xmit)-->X(dropped)  |
  4.   |====my address=a.b.c.d/12345===========>|
  5.   |         X<---TURN indication-----------|
  6.   |--TURN request (2nd xmit)-->|---------->|
  7.   |<--------|<---TURN response-------------|
       |         |        |         |           |

* Message 3 is dropped because the TURN Server's NAT filters incoming packets
based on their source address -- the TURN server has never sent a packet to
a.b.c.d, so the NAT drops the incoming packet.

* Message 4 is the p2psip overlay message.  

* Message 5 is mostly to mollify the TURN server's NAT.  Once the TURN
server's NAT sees message 5, it adds a permission for traffic from a.b.c.d/*.
(remember: the TURN server's NAT has address filtering behavior, which is what
we're trying to get a TURN Server working with by adding this p2psip overlay
message (4)). Message 5 is dropped by the TURN client's NAT.

* Message 6 is a normal retransmission of the TURN client's message.

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


P2PSIP mailing list