<div dir="ltr">Yep all makes sense. Which brings me back to my original assumption: Our application, when run as client-acting-as-a-server, will need to listen on a new local UDP port per client correct?</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 9, 2014 at 8:02 PM, Philip Withnall <span dir="ltr"><<a href="mailto:philip@tecnocode.co.uk" target="_blank">philip@tecnocode.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That is correct for certain NAT configurations, yes. You will need to<br>
perform an ICE negotiation between the client-acting-as-server and each<br>
of the clients trying to connect to it, in order to set up additional<br>
port forwarding rules (if the NAT translator needs them). Each of these<br>
ICE negotiations will need to go through a well-known, non-NATed<br>
signalling server, just to guarantee that the candidate messages are<br>
successfully sent between the two clients trying to connect.<br>
<br>
Does that make sense?<br>
<span class="HOEnZb"><font color="#888888"><br>
Philip<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Sun, 2014-11-09 at 11:48 +1100, Scott Richmond wrote:<br>
> Our application uses the client server model. Our users are typical<br>
> home users with typical NAT routers. At any point our users can start<br>
> a server and tell other users to join it as clients. The server will<br>
> not be run by users with the knowledge to setup port forwards on their<br>
> router. Using STUN, we could punch a port forward for the user to a<br>
> specific client. But no other clients will be able to use the same<br>
> port forward rule if the servers' local NAT router includes the client<br>
> external IP/port as part of the rule. This is correct yes?<br>
><br>
> On Sun, Nov 9, 2014 at 10:08 AM, Philip Withnall<br>
> <<a href="mailto:philip@tecnocode.co.uk">philip@tecnocode.co.uk</a>> wrote:<br>
>         On Wed, 2014-11-05 at 11:07 +1100, Scott Richmond wrote:<br>
>         > This is something that has forced me to avoid ICE as a<br>
>         solution for<br>
>         > our most recent project. Our project uses a server that only<br>
>         listens<br>
>         > on 1 UDP port, expecting all clients to be able to reach it.<br>
>         > Presumably this means we cannot reliably use STUN/TURN to<br>
>         solve the<br>
>         > NAT traversal problem?<br>
><br>
>         The server should be reachable by all clients, unless it’s<br>
>         behind a NAT<br>
>         itself, which is very rare. Using this as a signalling server<br>
>         for<br>
>         transferring the ICE candidates between two clients will allow<br>
>         ICE to<br>
>         work.<br>
><br>
>         I’m not sure I understand where you think ICE will fail in<br>
>         this<br>
>         scenario?<br>
><br>
>         Philip<br>
><br>
>         > On Wed, Nov 5, 2014 at 12:47 AM, Philip Withnall<br>
>         > <<a href="mailto:philip@tecnocode.co.uk">philip@tecnocode.co.uk</a>> wrote:<br>
>         >         On Tue, 2014-11-04 at 12:55 +0100, <a href="mailto:fb111@web.de">fb111@web.de</a><br>
>         wrote:<br>
>         >         > yes, very helpful! Can you describe what the<br>
>         process is when<br>
>         >         a node<br>
>         >         > wants to stay registerd with a singaling/<br>
>         rendevouzserver,<br>
>         >         but does<br>
>         >         > not receive a request for a connection?<br>
>         >         > As far as I understand, the node first performs<br>
>         the binding<br>
>         >         request<br>
>         >         > with STUN and TURN an THEN forwards the<br>
>         information of the<br>
>         >         IPs and<br>
>         >         > ports to the rendezvousserver, so that other nodes<br>
>         know how<br>
>         >         to reach<br>
>         >         > this node, right?<br>
>         >         > Do you need to keep this registration with the<br>
>         >         rendezvousserver alive,<br>
>         >         > to avoid the shutdown of the portmapping on the<br>
>         NAT router<br>
>         >         by sending<br>
>         >         > keep alive STUN signals?<br>
>         ><br>
>         >         That’s incorrect. The STUN and TURN negotiations are<br>
>         specific<br>
>         >         to each<br>
>         >         remote peer, so must be performed at the point when<br>
>         two nodes<br>
>         >         need to<br>
>         >         connect.<br>
>         ><br>
>         >         This has to be the case because various NAT<br>
>         configurations can<br>
>         >         limit<br>
>         >         port bindings to packets coming from specific<br>
>         external IP/port<br>
>         >         combinations. So if you have node A which has<br>
>         established a<br>
>         >         port mapping<br>
>         >         in its NAT and sent the WAN IP/port for that mapping<br>
>         to the<br>
>         >         signalling<br>
>         >         server, then later node B tries to connect, the<br>
>         packets may be<br>
>         >         dropped<br>
>         >         by the NAT because they’re coming from an external<br>
>         IP/port<br>
>         >         combination<br>
>         >         (node B’s WAN address) which the mapping wasn’t<br>
>         created for.<br>
>         ><br>
>         >         You may still want to keep each node registered with<br>
>         the<br>
>         >         signalling<br>
>         >         server, for control purposes, but you will need to<br>
>         design your<br>
>         >         own<br>
>         >         protocol for doing that (or use whatever protocol<br>
>         the existing<br>
>         >         signalling server you’re using uses). That protocol<br>
>         will be<br>
>         >         entirely<br>
>         >         separate from ICE.<br>
>         ><br>
>         >         Philip<br>
>         ><br>
>         >         _______________________________________________<br>
>         >         nice mailing list<br>
>         >         <a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a><br>
>         >         <a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br>
>         ><br>
>         ><br>
>         ><br>
>         > _______________________________________________<br>
>         > nice mailing list<br>
>         > <a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a><br>
>         > <a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br>
><br>
><br>
><br>
>         _______________________________________________<br>
>         nice mailing list<br>
>         <a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a><br>
>         <a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> nice mailing list<br>
> <a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br>
<br>
</div></div><br>_______________________________________________<br>
nice mailing list<br>
<a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br>
<br></blockquote></div><br></div>