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

["Dan Wing" <[e-mail]>]

> 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
http://code.google.com/apis/talk/libjingle/important_concepts.html, 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
<http://www.ietf.org/mail-archive/web/p2psip/current/msg03814.html>, 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
NAT.

-d

_______________________________________________
P2PSIP mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/p2psip