[libnice] ICE process

[Scott Richmond]

Hrm. Thanks for the explanation. We're using a closed-source networking
framework for our application. I'm wondering out loud here if it would be
possible to 'wrap' libnice around it by transparently
passing nice_agent_recv_messages() to the local UDP port the networking
framework listens on.
Ah but that wouldn't work - The traffic coming from the networking
framework wouldn't go back the same way through the logical libnice tunnel
wrapper. Unless I made all the clients appear to originate from other local
ports, which I broker through to the libNice framework.
Doesn't sound very elegant does it. :/

On Mon, Nov 10, 2014 at 9:26 AM, Philip Withnall <philip at tecnocode.co.uk>
wrote:

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