[libnice] ICE process

Scott Richmond s.t.richmond at gmail.com
Tue Nov 4 16:07:15 PST 2014


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?

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20141105/6f8f881e/attachment.html>


More information about the nice mailing list