<div dir="ltr"><div>Thanks Youness. That is exactly my understanding as well. </div><div>From what I perceive, symmetric NATs are definitely on the decline in the home. But symmetric NATs are still prevalent in the work place. Although I've never confirmed it, 3G mobile devices are essentially on symmetric NATs. </div><div>jrs </div><div> </div></div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Apr 2, 2013 at 1:12 PM, Youness Alaoui <<a href="mailto:youness.alaoui@collabora.co.uk" target="_blank">youness.alaoui@collabora.co.uk</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 : <a href="http://en.wikipedia.org/wiki/Network_address_translation#Methods_of_port_translation" target="_blank">http://en.wikipedia.org/wiki/Network_address_translation#Methods_of_port_translation</a> 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. <div><div class="h5"> 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 > > > > </div></div>> _______________________________________________ > nice mailing list > <a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a> > _______________________________________________ nice mailing list <a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a> </blockquote></div> </div>