<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>