<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-04-10 22:28 GMT+02:00 Olivier Crête <span dir="ltr"><<a href="mailto:olivier.crete@collabora.com" target="_blank">olivier.crete@collabora.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Hi,</div><div><br></div><div>That is really interesting,</div><span class=""><div><br></div><div>On Mon, 2017-04-10 at 18:42 +0200, Lorenzo Miniero wrote:</div></span><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">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></span><span class=""><blockquote type="cite"><div dir="ltr"><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</p></div></blockquote></span></div></div></div></blockquote><div><br></div><span class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote type="cite"><div dir="ltr"><p>conncheck: Separate valid and succeded states</p></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div></div></div></blockquote><div><br></div></span><span class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>He then tried a patch another user referenced on our issue page, and it worked instead: <a href="https://phabricator.freedesktop.org/D735" target="_blank">https://phabricator.<wbr>freedesktop.org/D735</a></div></div></div></div></blockquote><div><br></div></span><div>I've been looking at this patch a couple times and the reason I didn't merge it is that I don't understand what it tries to accomplish.</div><div><br></div><div>But now I think I figured it out. It seems that libnice sets the "nominated" flag on all the pairs when it creates them as a controlling agent, which seems wrong. I think it should set the flag only when it gets a reply... And this is why propagating the flag fixes it in some cases, but I think we need to go over the whole conncheck code and make it set the nominated flag at the right time (after the reply is received!).</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></blockquote><div><br></div><div><br></div><div>Hi Olivier,</div><div><br></div><div>thanks for the quick reply!<br><br>I think you're indeed on the right path, as we did some more checks and we did experience a different behaviour depending on who was offering, which in turn means a different role when it comes to ICE (in Janus, the answerer has the controlling role).</div><div><br></div><div>In case it can help shed some more light, we verified that when Janus is on a public address, we never encounter any issue, no matter whether the user is behind a regular NAT, a symmetric one or public themselves. If Janus itself is behind a NAT, instead, and so we configure it with a STUN server, then the issues we mentioned arise. We made some more tests with Janus behind a NAT, and with a user behind a NAT himself, the EchoTest demo (where Janus answers, and so is the ICE controller) doesn't work, while the Streaming demo (Janus offers, user is ICE controller) does, which seems to confirm your theory on the role's importance.</div><div><br></div><div>Hope this helps,</div><div>Lorenzo</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span class="HOEnZb"><font color="#888888"><div></div><div><span><pre><pre>-- <br></pre>Olivier Crête
<a href="mailto:olivier.crete@collabora.com" target="_blank">olivier.crete@collabora.com</a>
</pre></span></div></font></span></div></blockquote></div><br></div></div>