[libnice] ICE process
Scott Richmond
s.t.richmond at gmail.com
Sun Nov 9 13:57:12 PST 2014
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?
On Mon, Nov 10, 2014 at 8:39 AM, Philip Withnall <philip at tecnocode.co.uk>
wrote:
> 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:
>
>
> http://nice.freedesktop.org/libnice/NiceAgent.html#nice-agent-set-port-range
>
> In libnice terminology, you would have a separate ‘stream’ for each
> client-acting-as-a-server / client connection.
>
> Philip
>
> 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
> > <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
> >
> >
> >
> > _______________________________________________
> > 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/20141110/7feca811/attachment-0001.html>
More information about the nice
mailing list