[libnice] ICE process
Philip Withnall
philip at tecnocode.co.uk
Sun Nov 9 14:26:30 PST 2014
libnice effectively acts as a wrapper around the UDP socket, so you call
nice_agent_recv_messages() and nice_agent_send_messages() instead of
recvmmsg() and sendmmsg(). This is required because connections could be
established through TURN, which requires all packets to have a TURN
header added for use by the relaying server.
How it typically works is that the signalling channel will notify the
client-as-a-server (A) that a peer (B) is trying to connect. A will call
nice_agent_add_stream() to get a stream ID (representing the connection
between A and B), then nice_agent_gather_candidates() on that stream. B
will do both those calls as well. nice_agent_gather_candidates() will,
internally, start listening on new UDP ports. Both A and B will exchange
candidates via the signalling server, which you need to plumb in from
signal emissions on the NiceAgent. Once ICE negotiation finishes, both A
and B will communicate over the stream by calling
nice_agent_send_messages() and nice_agent_recv_messages().
Philip
On Mon, 2014-11-10 at 08:57 +1100, Scott Richmond wrote:
> 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
>
>
>
> _______________________________________________
> 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/20141109/e7de8da3/attachment.sig>
More information about the nice
mailing list