[libnice] ICE process

[Scott Richmond]

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 <philip at tecnocode.co.uk>
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
> > <philip at tecnocode.co.uk> wrote:
> >         On Tue, 2014-11-04 at 12:55 +0100, fb111 at web.de 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
> >         nice at lists.freedesktop.org
> >         http://lists.freedesktop.org/mailman/listinfo/nice
> >
> >
> >
> > _______________________________________________
> > nice mailing list
> > nice at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/nice
>
>
> _______________________________________________
> nice mailing list
> nice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nice
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20141109/3c2ad459/attachment.html>