[libnice] ICE process

[Philip Withnall]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/nice/attachments/20141108/7e2d8f99/attachment.sig>