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

[JiangXingFeng <[e-mail]>]

Great! The overlay could be thought of as a rendezvous point and could be
used to exchange candidates. Further, the TURN client and the TURN server
could use ICE with the help of the rendezvous point to get a direct
connection. (It will exist if the NAT in front of the STUN server has
end-point independent mapping behavior.) And then TURN client could use the
TURN server to communicate with other peers.

--
Jiang XingFeng

> -----Original Message-----
> From: Dan Wing [mailto:[e-mail]]
> Sent: Sunday, February 03, 2008 1:37 PM
> To: 'Cullen Jennings'
> Cc: 'Francois Audet'; 'Bruce Lowekamp'; 'P2PSIP Mailing List';
'JiangXingFeng'
> Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
> 
> > 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