[libnice] Force an external address (srflx) candidate?

Stuart Marshall stuart at seelye.net
Sun Oct 18 19:39:57 UTC 2020

I think your suggestions make sense.

As I recall, the switch to turn off IPv6 is at compile time. Being able to turn that off (or on) at runtime would be good too.

Being able to restrict gathering to the default interface sounds good. As it is, I see libnice grabbing addresses from interfaces like the virtual ones used for virtual machines. This is not useful and clogs up negotiation.

The other challenge that I run into is exposure of these controls when using gstreamer.

With gstreamer people sometime interface directly with C++. But also through the text based pipeline construction. And through interfaces like the Java ones.

Is there an easy and natural way to talk with libnice (e.g. use nice_agent_add_local_address()) when using gstreamer? Does it make any sense to provide side channel communication to libnice via environment variables or a config file? That sounds a bit messy, but could help expose functionality without having to plumb everything through the gstreamer interfaces.


From: Olivier Crête <olivier.crete at collabora.com>
Date: Friday, October 16, 2020 at 6:07 AM
To: Juan Navarro <juan.navarro at gmx.es>, Stuart Marshall <stuart at seelye.net>, nice at lists.freedesktop.org <nice at lists.freedesktop.org>
Subject: Re: [libnice] Force an external address (srflx) candidate?

I think there are 2 things we could do.

1. We can add a new API like:

This API would let libnice know about such forwarded addresses. We can
then expose it to the peer as a host candidate with the external
address. And internally libnice could use it as a normal host

If you know for sure that the machine is not behind an unexpected NAT
(ie, it's a server). Then you would not longer need to set a STUN or
TURN server on that machine and you should be able to only have host
candidates so the gathering should be instant.

2. We already have nice_agent_add_local_address() for the application
to select internal addresses to use. As you know, if this API is not
use, we just gather the addresses of all interfaces. I wonder if it
wouldn't be a good idea to have a property to restrict the automatic
gathering to only the default interface. That will reduce the number of
candidates and it should make operations faster.


On Thu, 2020-10-15 at 11:30 +0200, Juan Navarro wrote:
> Thanks for your comments; however I believe this would indeed fall into
> the category of feature request, because after looking at all the docs
> and even checking a bit of the code, it's not apparent to me that this
> possibility is offered.
> On 14/10/20 23:22, Stuart Marshall wrote:
> > Juan, to further answer your question: we’re using libnice for our
> > server. However, I had to upgrade the libnice to a private build from
> > the tip of libnice master. The default libnice on Ubuntu 18.04 had a
> > bunch of bugs that prevented ICE negotiation from working well. The
> > latest libnice seems to work well (albeit a bit slowly), but you may
> > not be able to use the standard ones that come with your distro. I
> > haven’t checked the version of libnice in Ubuntu 20.04. I think it was
> > updated, but not sure if it has all the recent(ish) bugfixes.
> >
> Yeah we also build our own binaries, to stay on top of latest fixes, to
> generate GStreamer bindings for our fork of GStreamer, but also to add
> the "G_DISABLE_ASSERT" flag, which disables assertions in runtime
> (otherwise when libnice find a bug and goes to a wrong state, it will
> make the whole process crash; I get it's a good method for testing and
> finding bugs, but not for production where a crash is the last thing you
> want to happen)
> _______________________________________________
> nice mailing list
> nice at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nice
Olivier Crête
olivier.crete at collabora.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/nice/attachments/20201018/60f111ab/attachment.htm>

More information about the nice mailing list