<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> I found the issue. It was fixed in this commit in June 2017:<o:p></o:p> <a href="https://gitlab.freedesktop.org/libnice/libnice/-/commit/58d061df8f5425dc1add9c6030a2f891ebda4616">https://gitlab.freedesktop.org/libnice/libnice/-/commit/58d061df8f5425dc1add9c6030a2f891ebda4616</a><o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> 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.<o:p></o:p> 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.<o:p></o:p> Upgrading the Libnice on both sides of my setup seems to result in successful negotiation.<o:p></o:p> <o:p> </o:p> A couple follow up questions<o:p></o:p> <ol style="margin-top:0in" start="1" type="1"> <li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">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.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">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.<o:p></o:p></li></ol> <o:p> </o:p> Stuart<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"> From: nice <nice-bounces@lists.freedesktop.org> on behalf of Stuart Marshall <stuart@seelye.net> Date: Thursday, April 2, 2020 at 7:05 AM To: "nice@lists.freedesktop.org" <nice@lists.freedesktop.org> Subject: [libnice] libnice not negotiating well with itself<o:p></o:p> </div> <div> <o:p> </o:p> </div> 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.<o:p></o:p> <o:p></o:p> 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.<o:p></o:p> <o:p></o:p> 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 system.<o:p></o:p> <o:p></o:p> Both processes leverage a stun server that I’m running. I’ve tried it with the public Google stun server with the same results.<o:p></o:p> <o:p></o:p> 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.<o:p></o:p> <o:p></o:p> 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 help.<o:p></o:p> <o:p></o:p> Thanks,<o:p></o:p> <o:p></o:p> Stuart<o:p></o:p> <o:p></o:p> <o:p></o:p> <o:p></o:p> </div> </body> </html>