[libnice] libnice not negotiating well with itself
olivier.crete at collabora.com
Mon May 18 17:37:13 UTC 2020
There shouldn't be a problem updating it from under the application,
we're careful not to break ABI. That said, instead of replacing just
the file, it's probably a best idea to just steal the whole .deb from
the latest Ubuntu and re-build that against the older one if you want
to upgrade it.
Ubuntu 20.04 is going to have 0.1.16
On Fri, 2020-04-10 at 04:11 +0000, Stuart Marshall wrote:
> I found the issue. It was fixed in this commit in June 2017:
> It appears that Ubuntu 18.04 is still using Libnice 0.1.14, which was
> cut about two months before this fix got into master.
> In my previous attempts noted below I had updated one of my two
> libnice clients to 0.1.16, but not both. As luck would have it, I
> needed the fix on the side that I had not upgraded.
> After a bunch of reading the code and the logs I tracked down the bug
> and then figured out that Fabrice had fixed it long ago. I’m happy to
> see it was fixed.
> Upgrading the Libnice on both sides of my setup seems to result in
> successful negotiation.
> A couple follow up questions
> If libnice.so.10.7.0 is already on a machine and I install
> libnice.so.10.9.0 to the common /usr/lib directory and relink
> libnice.so.10 to
> point to the libnice.so.10.9.0, will that do some horrible damage to
> the installation of the libnice10 deb package? I’m inclined to go
> ahead and upgrade the libnice on customer machines if the old one is
> present, but it makes me a bit uncomfortable.Do you guys know if
> ubuntu 20.04 (releasing soon) is going to get a more recent libnice
> than 0.1.14? Seems like the world would benefit from
> the bugfixes.
> From: nice <nice-bounces at lists.freedesktop.org> on behalf of Stuart
> Marshall <stuart at seelye.net>
> Date: Thursday, April 2, 2020 at 7:05 AM
> To: "nice at lists.freedesktop.org" <nice at lists.freedesktop.org>
> Subject: [libnice] libnice not negotiating well with itself
> I’ve got two libnice instances that aren’t successfully negotiating
> with each other. I’d appreciate any suggestions on how to fix this.
> Logs are attached.
> Process 1 is a native Linux amd64 exe using gstreamer. It’s trying to
> establish a webrtc connection to a server from behind a NAT firewall.
> This exe is using GStreamer 1.16. It’s running on Ubuntu
> 18.04. I’ve tried using the default 1.14 libnice as well as a
> privately compiled libnice 1.16. The security group is configured to
> allow all UDP to come in.
> Process 2 is a Java app running on Ubuntu 18.04 on EC2. It’s also
> using GStreamer 1.16. It is using the default libnice 1.14 on the
> Both processes leverage a stun server that I’m running. I’ve tried it
> with the public Google stun server with the same results.
> I can see the two libnices exchange stun messages on viable addresses
> and ports. One appears to connect component 1 and the other connects
> component 2. Neither connects both. I’m quite puzzled
> about why this is failing.
> I have not done a packet capture yet, nor have I walked through the
> libnice code. I could do both, but would love to get a solution that
> would save me that effort. Hope somebody on the list can
> _______________________________________________nice mailing
> listnice at lists.freedesktop.org
olivier.crete at collabora.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nice