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

Fri Jan 2 02:53:56 PST 2015

Hi Philip,

sorry if this took so long but I've just managed to get back working on the
code.

I've captured a log using the environment variables you asked for using
libnice-0.1.4:

http://pastebin.com/Rv48zi2k

Later today I'll do the same with 0.1.8.1: 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.

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.

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:

(process:4945): libnice-DEBUG: Agent 0x7f1ee800b9e0 : marking pair
0x7f1ef4016000 (1:1) as nominated
(process:4945): libnice-DEBUG: Agent 0x7f1ee800b9e0 : marking pair
0x7f1ef4026110 (2:1) as nominated
(process:4945): libnice-DEBUG: Agent 0x7f1ee800b9e0 : marking pair
0x7f1ee80a6e60 (3:1) as nominated

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.

Anyway, whatever the cause, eventually, I gave up and closed the session in
the browser, which destroyed the agent in the gateway.

Let me know if you need additional info from me, I'll keep you posted on
0.1.8.1 debugging as well.

Lorenzo

2014-12-27 13:01 GMT+01:00 Lorenzo Miniero <lminiero at gmail.com>:

> 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
> Il 27/dic/2014 10:59 "Philip Withnall" <philip at tecnocode.co.uk> ha
> scritto:
>
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20150102/295e2db8/attachment.html>