[Nice] What types of NATs can be traversed when one endpoint is symmetric?

[Youness Alaoui]

Hi John,

Yes, in that use case, it will have to go through TURN. The reason is that B
cannot send to A since there is no port mapping for it, and when A sends to B,
while it creates a mapping, B is unable to receive it because it is received
from a different remote port than the one B sent to and so the port restricted
NAT will reject the packet.

If the user B was using a full cone NAT, then what would happen is that A would
be able to send to B, and B would then detect a "peer-reflexive candidate" and
add it to its local list of remote candidates and start new connectivity checks
with the new peer-reflexive candidate containing the port mapping that the user
A just created on his symetric NAT by sending his connectivity check request.
Then when B replies to A, the agent on the A side will see that the other side
found a new port mapping and will add his own local peer-reflexive candidate to
its list and will start connectivity checks with those.

If the user B was behind an address-restricted NAT, the same would happen but
the first packet from A to B would be rejected (depends on who sends first),
then when B sends to A, the router creates the port mapping to allow A packets
coming in. Then when B retransmits his connectivity check packets, the router
will then allow it to go through, and the whole peer-reflexive candidate system
kicks in again and new connchecks start and it all works.

I like to use the diagrams shown here to help me visualize it :
http://en.wikipedia.org/wiki/Network_address_translation#Methods_of_port_translation

There is no table/data available on which types of NAT pairings would go direct
vs. TURN (that I know of), but it's simply that every types of NAT would work
with a direct connection unless it's symetric with symetric NAT or symetric with
port-restricted NAT, everything else should just work all the time.

As for the distribution of NAT types, I have no idea, but my understanding
(maybe it was just a rumor I heard a long time ago, someone said with no real
data to back it and it stayed in my mind) is that 5% of home routers are
symetric, and that ICE should work generally in about 90% of the cases.
Maybe you can find some better documentation about that on the net. If you do,
please let me know.

Thanks,
Youness.

On 04/01/2013 02:33 PM, John Selbie wrote:
> Assume two hosts using SIP, TURN, and ICE to rendezvous and setup UDP based P2P
> sessions with each other. Assume connectivity to the SIP and TURN service is
> 100% reliable for these hosts.
> 
> User A  is a a host is behind a "symmetric" NAT - most likely a 3G mobile client
> - or any other NAT that doesn't have a consistent port mapping scheme.
> 
> User B - The other host is behind a port-restricted NAT.
> 
> Now A and B want to do a P2P session over UDP with each other.
> 
> My understanding is that the ICE negotiation will most likely fall back to using
> the TURN relay port in this scenario. Is that correct? Or does the connectivity
> check phase of ICE have some way of  connecting the hosts directly?
> 
> I'm also certain that if User B were to be behind a Cone Nat, then ICE has a
> much higher chance of succeeding with a direct connection.
> 
> Is my understanding correct so far?
> 
> Is there a table or data available showing what NAT-pairings are expected to "go
> direct" vs fallback to TURN relay in an ICE session?
> 
> Also, does anyone have data or an "off the cuff" idea of how prevalent the
> different NAT types are (cone, port-restricted, symmetric) in the consumer/home
> case. I would guess most off-the-shelf routers these days are port-restricted. 
> But that is only a guess based on the fact that mine is.
> 
> jrs
> 
> 
> 
> 
> _______________________________________________
> nice mailing list
> nice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nice
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/nice/attachments/20130402/8ba5b4eb/attachment.pgp>