<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-02-27 22:30 GMT+01:00 Chad Phillips <span dir="ltr"><<a href="mailto:chad@apartmentlines.com" target="_blank">chad@apartmentlines.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><p>I’m using this WebRTC gateway: <a href="https://janus.conf.meetecho.com/" target="_blank">https://janus.conf.<wbr>meetecho.com/</a></p><p>I cannot get latest libnice master to work with this project — ICE hangs in the ‘connecting' state</p><p>Some git bisect work got me to the problem commit:</p>
<p>1ab9d7c104978ea1904aaaad708c1c<wbr>8c23c77592 is the first bad commit<br>
commit 1ab9d7c104978ea1904aaaad708c1c<wbr>8c23c77592<br>
Author: Olivier Crête <a href="mailto:olivier.crete@collabora.com" target="_blank">olivier.crete@collabora.com</a><br>
Date:   Thu May 26 16:05:36 2016 -0400</p>
<pre><code>conncheck: Separate valid and succeded states

RFC 5245 specifies that when a mapped-address differs from the address
from the request was sent, the mapped-address is used to select the
valid pair, but the source address of the check is used to select the
pair that succeeded, so they are not the same.</code></pre><pre><code><span style="font-family:arial,sans-serif">If I roll back this commit, then Janus will work with libnice master, ICE connections complete fine.</span><br></code></pre><pre><font face="arial, sans-serif">The Janus lead dev looked at that commit, and couldn’t figure out exactly what it does, or why it would break ICE connectivity when used with the Janus libnice support code.</font></pre><pre><font face="arial, sans-serif">I was hoping you could shed some light on:</font></pre><pre><font face="arial, sans-serif"> - What the added ‘valid’ flag does</font></pre><pre><font face="arial, sans-serif"> - Where adjustments might be necessary in libnice support code as a result of this change</font></pre><pre><font face="arial, sans-serif">Thanks,</font></pre><pre><font face="arial, sans-serif">Chad</font></pre></div></blockquote><div><br></div><div><br></div><div>Hi all,</div><div><br></div><div>chiming in as I only now had some time to look into this.</div><div><br></div><div><br></div><div>Apparently what Chad found out is indeed partly true, and Janus sometimes doesn't seem able to get a valid connectivity out of libnice. I mean partly because we did some a few different tests, and while connectivity did indeed NOT work when talking to a remote Janus, everything was working correctly with Janus on our LAN or doing tests on a local machine.</div><div><br></div><div>One of my colleagues tried tracing what happens with the newly released libnice 0.1.14 when it breaks and apparently, although there are valid candidates, and we do see some "marking pair...as nominated" lines in the debug, the nominated count always remains 0. Not sure if that's the cause, but the result is that the ICE state never leaves the "connecting" state, and so never gets to "connected".</div><div><br></div><div>He then tried a patch another user referenced on our issue page, and it worked instead: <a href="https://phabricator.freedesktop.org/D735">https://phabricator.freedesktop.org/D735</a></div><div>Considering that patch only modifies a single line in priv_add_peer_reflexive_pair, by basically setting the nominated property of the new prflx candidate to the parent's rather than FALSE, I guess this patch does indeed fix a problem with prflx candidates, which in our particular case we do need (we're behind a symmetric NAT and prflx always works for us, no need to do TURN if Janus is publicly reachable). Not sure whether Chad has a different NAT configuration and yet the same problem: if srflx should work for him, for instance, but it doesn't and the prflx issue is breaking it for him, it may be an indication we're doing something wrong with the management of remote candidates (but why did it work so far then?).</div><div><br></div><div>Not sure if the fact we trickle has any relevance here. In fact, we don't wait for the connection to be ready, but only for a valid selected pair to consider connectivity to be available. More precisely, in Janus we wait for the "new-selected-pair-full" callback to fire to decide we can start the DTLS exchange and then do media: with that commit, though, ICE actually never "connects" for us, and so that callback is never fired.</div><div><br></div><div>As Chad said, I couldn't figure out why any of the changes in the commit he identified via git bisect should cause any trouble:</div><div><a href="https://github.com/libnice/libnice/commit/1ab9d7c104978ea1904aaaad708c1c8c23c77592">https://github.com/libnice/libnice/commit/1ab9d7c104978ea1904aaaad708c1c8c23c77592</a><br></div><div>I guess that in general the separation between "valid" and "succeeded" can lead to some checks being done differently, especially for the prflx case mentioned above, and so never leading to a success in the Janus case. That said, I'm far from an expert when it comes to libnice internals, and so I'm just speculating here.</div><div><br></div><div>Do you have any idea on what may be the issue? Any suggestion on where I should look to figure out if it can be solved without resorting to the patch above? (which seems to have been abandoned in the meanwhile).</div><div><br></div><div><br></div><div>Thanks in advance!<br>Lorenzo</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>______________________________<wbr>_________________<br>
nice mailing list<br>
<a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/nice" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/nice</a><br>
<br></blockquote></div><br></div></div>