<div dir="ltr">Hi,<div><br></div><div>sorry to bump, but is there any light you can shed on this? I'm still wondering whether it's a bug or something I did wrong, but if it's the latter I'd appreciate some hints on what this could be.</div><div><br></div><div>Thanks!</div><div>Lorenzo</div><div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-02 12:58 GMT+01:00 Lorenzo Miniero <span dir="ltr"><<a href="mailto:lminiero@gmail.com" target="_blank">lminiero@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">As promised, the same debug info on 0.1.8.1 instead. The same issue is happening there as well, everything fine with Chrome instead:<div><br></div><div><a href="http://pastebin.com/5CUWpZ5M" target="_blank">http://pastebin.com/5CUWpZ5M</a><br></div><div><br></div><div>Let me know what else I can do to help you understand what's going wrong, and if it may be my fault somewhere.</div><div><br></div><div>Thanks,</div><div>Lorenzo</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-01-02 11:53 GMT+01:00 Lorenzo Miniero <span dir="ltr"><<a href="mailto:lminiero@gmail.com" target="_blank">lminiero@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Philip,<div><br></div><div>sorry if this took so long but I've just managed to get back working on the code.</div><div><br></div><div>I've captured a log using the environment variables you asked for using libnice-0.1.4:</div><div><br></div><div><a href="http://pastebin.com/Rv48zi2k" target="_blank">http://pastebin.com/Rv48zi2k</a><br></div><div><br></div><div>Later today I'll do the same with <a href="http://0.1.8.1" target="_blank">0.1.8.1</a>: I wanted to start with this since, as far as I know, I need to update the code to get it working with 0.1.8.1 due to some deprecated callbacks (or am I mistaken?). Besides, having a view of what's happening in this version as well may help us identify the actual issue beforehand.</div><div><br></div><div>This dump refers to a simple echo test call to our gateway, which negotiates audio, video and data channels (3 streams) with rtcp-muxing (so one component per stream) using Firefox stable. The offer is coming from the browser, the gateway answers. I tried to clean the log as much as possible with respect to the possibly overly verbose output my own gateway adds, and just kept the parts of it that could be relevant to the libnice debugging: the libnice debugging, instead, is all there and unmodified. Just for the sake of completeness, the server hosting the gateway is on Amazon: this means that it has a 1-1 NAT mapping, and so, while the gathering is done on a private address (10.0.0.239) it is then modified when reporting it back to the browser replacing it with its public address counterpart (missing in the log). This works because the 1-1 mapping Amazon does keeps the port mapping as well.</div><div><br></div><div>As you can see from the log, there are multiple checks that succeed (the failed ones are related to the private addresses being trickled by the browser) but no one ever gets nominated. Looking at the log, I can see that apparently some pairs are indeed nominated for each stream:</div><div><br></div><div><div>(process:4945): libnice-DEBUG: Agent 0x7f1ee800b9e0 : marking pair 0x7f1ef4016000 (1:1) as nominated</div><div>(process:4945): libnice-DEBUG: Agent 0x7f1ee800b9e0 : marking pair 0x7f1ef4026110 (2:1) as nominated<br></div><div>(process:4945): libnice-DEBUG: Agent 0x7f1ee800b9e0 : marking pair 0x7f1ee80a6e60 (3:1) as nominated</div></div><div><br></div><div>but for some reason the nominated count is always 0 anyway in the timer-tick debug lines. All those pairs are "discovered", and from what I can understand, if we look at 0x7f1ef4016000, for instance, this seems to be happening because libnice receives a connectivity check from the public address of the browser before it is notified of the related trickle candidate: this happens because the browser already notified its private, host trickle candidate which is mapped to the server reflective address it will get from STUN later, and is already sending checks from there; libnice will of course receive it from the related public address and consider it a new candidate it was not aware of. Not sure if what's causing the issue is actually receiving the info on the candidate only later: it may be that, when my application adds the new (already discovered) candidate to libnice, it "resets" its nominated status and there are no following connectivity checks to "renew" this (which is why maybe with Chrome it works instead? Chrome sends CC on a regular basis even during the call), but I may be wrong.   </div><div><br></div><div>Anyway, whatever the cause, eventually, I gave up and closed the session in the browser, which destroyed the agent in the gateway.</div><div><br></div><div>Let me know if you need additional info from me, I'll keep you posted on 0.1.8.1 debugging as well.</div><span><font color="#888888"><div><br></div><div>Lorenzo</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2014-12-27 13:01 GMT+01:00 Lorenzo Miniero <span dir="ltr"><<a href="mailto:lminiero@gmail.com" target="_blank">lminiero@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Thanks for the response. I'm currently abroad with no pc so I'll only be able to test this when I get back. I'll keep you posted,</p>
<p dir="ltr">Lorenzo</p>
<div class="gmail_quote">Il 27/dic/2014 10:59 "Philip Withnall" <<a href="mailto:philip@tecnocode.co.uk" target="_blank">philip@tecnocode.co.uk</a>> ha scritto:<div><div><br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On Tue, 2014-12-23 at 17:49 +0100, Lorenzo Miniero wrote:<br>
<br>
<br>
> I'm encountering some issues using libnice within my open source<br>
> WebRTC gateway. It mostly works great, but lately I've had some weird<br>
> issues that I can't seem to be abe to figure out. First of all,<br>
> apologies if this may have been addressed in the past already, but I<br>
> couldn't find any related discussion in the archive. I'm using libnice<br>
> 0.1.4 as it's the one available on most distributions I tried it on<br>
> (ubuntu, fedora), so not sure if this may be a bug fixed in the<br>
> meanwhilw, but I looked at the changesets and I couldn't find anything<br>
> related there either.<br>
<br>
I would strongly suggest trying to reproduce this with 0.1.8.1. There<br>
were a number of fixes relating to connection checking which made it<br>
into 0.1.8.<br>
<br>
> As to what I'm getting, when I'm using it with Firefox stable, which<br>
> does not bundle media (that is, in WebRTC terms, there are different<br>
> ICE components for audio and video, while when bundling instead you<br>
> have a single ICE component for all of them, RTCP too if you're<br>
> rtcp-muxing), I'm often in a situation where the ICE state gets to<br>
> 'connected' but it does not move from there. I never get the<br>
> 'new-selected-pair' callback, which means that, although there should<br>
> be at least a working pair (the 'connected' suggests so), none of them<br>
> ever gets nominated/selected. I can confirm, looking at Wireshark,<br>
> that connectivity checks work in both directions, and in fact from the<br>
> browsers perspective the ICE setup has been completed (candidate pair<br>
> nominated and selected), but libnice doesn't seem to think so and so<br>
> nothing works anymore. The state never gets to 'failed' after that, it<br>
> just stays 'connected' until I have to assume it's over and I destroy<br>
> the agent.<br>
<br>
It might be fixed by this:<br>
<a href="http://cgit.freedesktop.org/libnice/libnice/commit/?id=fcb1b84fd81f7db7dfe25bad824cb7fcfb254469" target="_blank">http://cgit.freedesktop.org/libnice/libnice/commit/?id=fcb1b84fd81f7db7dfe25bad824cb7fcfb254469</a><br>
or one of the other 0.1.8 fixes.<br>
<br>
*snip*<br>
> What may be the issue, and in particular, what may lead to a case<br>
> where no pair is ever nominated no matter what? Shouldn't the first<br>
> pair that gets you a 'connected' state be selected right away, to be<br>
> replaced by a different pair later on if its priority is higher, or is<br>
> this not the behaviour to expect?<br>
<br>
If it is still reproducible with 0.1.8, please send us a debug log<br>
gathered with NICE_DEBUG=all G_MESSAGES_DEBUG=all, otherwise it will be<br>
impossible to debug the problem.<br>
<br>
Thanks,<br>
Philip<br>
<br>
</blockquote></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div>