[libnice] State stuck to 'connected' and no nominated pair

[Philip Withnall]

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:
http://cgit.freedesktop.org/libnice/libnice/commit/?id=fcb1b84fd81f7db7dfe25bad824cb7fcfb254469
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/nice/attachments/20141227/f4c90054/attachment.sig>