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, Lorenzo <div class="gmail_quote">Il 27/dic/2014 10:59 "Philip Withnall" <<a href="mailto:philip@tecnocode.co.uk">philip@tecnocode.co.uk</a>> ha scritto: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, On Tue, 2014-12-23 at 17:49 +0100, Lorenzo Miniero wrote: > I'm encountering some issues using libnice within my open source > WebRTC gateway. It mostly works great, but lately I've had some weird > issues that I can't seem to be abe to figure out. First of all, > apologies if this may have been addressed in the past already, but I > couldn't find any related discussion in the archive. I'm using libnice > 0.1.4 as it's the one available on most distributions I tried it on > (ubuntu, fedora), so not sure if this may be a bug fixed in the > meanwhilw, but I looked at the changesets and I couldn't find anything > related there either. I would strongly suggest trying to reproduce this with 0.1.8.1. There were a number of fixes relating to connection checking which made it into 0.1.8. > As to what I'm getting, when I'm using it with Firefox stable, which > does not bundle media (that is, in WebRTC terms, there are different > ICE components for audio and video, while when bundling instead you > have a single ICE component for all of them, RTCP too if you're > rtcp-muxing), I'm often in a situation where the ICE state gets to > 'connected' but it does not move from there. I never get the > 'new-selected-pair' callback, which means that, although there should > be at least a working pair (the 'connected' suggests so), none of them > ever gets nominated/selected. I can confirm, looking at Wireshark, > that connectivity checks work in both directions, and in fact from the > browsers perspective the ICE setup has been completed (candidate pair > nominated and selected), but libnice doesn't seem to think so and so > nothing works anymore. The state never gets to 'failed' after that, it > just stays 'connected' until I have to assume it's over and I destroy > the agent. It might be fixed by this: <a href="http://cgit.freedesktop.org/libnice/libnice/commit/?id=fcb1b84fd81f7db7dfe25bad824cb7fcfb254469" target="_blank">http://cgit.freedesktop.org/libnice/libnice/commit/?id=fcb1b84fd81f7db7dfe25bad824cb7fcfb254469</a> or one of the other 0.1.8 fixes. *snip* > What may be the issue, and in particular, what may lead to a case > where no pair is ever nominated no matter what? Shouldn't the first > pair that gets you a 'connected' state be selected right away, to be > replaced by a different pair later on if its priority is higher, or is > this not the behaviour to expect? If it is still reproducible with 0.1.8, please send us a debug log gathered with NICE_DEBUG=all G_MESSAGES_DEBUG=all, otherwise it will be impossible to debug the problem. Thanks, Philip </blockquote></div>