[libnice] ICE process
Scott Richmond
s.t.richmond at gmail.com
Sun Nov 9 01:42:31 PST 2014
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 <philip at tecnocode.co.uk>
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
> > <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
> >
> >
> >
> > _______________________________________________
> > 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/f23de218/attachment-0001.html>
More information about the nice
mailing list