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