<div dir="ltr"><div class="gmail_quote"><div dir="ltr">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.<div>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.</div><div>Doesn't sound very elegant does it. :/</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 10, 2014 at 9:26 AM, Philip Withnall <span dir="ltr"><<a href="mailto:philip@tecnocode.co.uk" target="_blank">philip@tecnocode.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">libnice effectively acts as a wrapper around the UDP socket, so you call<br>
nice_agent_recv_messages() and nice_agent_send_messages() instead of<br>
recvmmsg() and sendmmsg(). This is required because connections could be<br>
established through TURN, which requires all packets to have a TURN<br>
header added for use by the relaying server.<br>
<br>
How it typically works is that the signalling channel will notify the<br>
client-as-a-server (A) that a peer (B) is trying to connect. A will call<br>
nice_agent_add_stream() to get a stream ID (representing the connection<br>
between A and B), then nice_agent_gather_candidates() on that stream. B<br>
will do both those calls as well. nice_agent_gather_candidates() will,<br>
internally, start listening on new UDP ports. Both A and B will exchange<br>
candidates via the signalling server, which you need to plumb in from<br>
signal emissions on the NiceAgent. Once ICE negotiation finishes, both A<br>
and B will communicate over the stream by calling<br>
nice_agent_send_messages() and nice_agent_recv_messages().<br>
<span><font color="#888888"><br>
Philip<br>
</font></span><div><div><br>
On Mon, 2014-11-10 at 08:57 +1100, Scott Richmond wrote:<br>
> So does the libNice framework expect the client-as-a-server<br>
> application to be able to listen on new local UDP ports for each<br>
> client that attempts to connect via the signal channel? I guess what<br>
> I'm trying to figure out here is - Does libNice fully hand over the<br>
> UDP port and stream once the ICE process has completed or does it<br>
> broker the client streams down to a single one the application feeds<br>
> from?<br>
><br>
> On Mon, Nov 10, 2014 at 8:39 AM, Philip Withnall<br>
> <<a href="mailto:philip@tecnocode.co.uk" target="_blank">philip@tecnocode.co.uk</a>> wrote:<br>
>         Ah, I see what you mean now. Yes, it will, but that is handled<br>
>         by<br>
>         libnice internally. When doing ICE negotiation, libnice will<br>
>         open UDP<br>
>         ports on each network interface on the client and send those<br>
>         port<br>
>         numbers through to the peer.<br>
><br>
>         You can control the range those ports are allocated from, but<br>
>         it will be<br>
>         a separate UDP port per client-acting-as-a-server / client<br>
>         connection:<br>
><br>
>         <a href="http://nice.freedesktop.org/libnice/NiceAgent.html#nice-agent-set-port-range" target="_blank">http://nice.freedesktop.org/libnice/NiceAgent.html#nice-agent-set-port-range</a><br>
><br>
>         In libnice terminology, you would have a separate ‘stream’ for<br>
>         each<br>
>         client-acting-as-a-server / client connection.<br>
><br>
>         Philip<br></div></div></blockquote></div></div></div></div></div></div>