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

Fri Jan 9 02:44:46 PST 2015

Hi,

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.

Thanks!
Lorenzo

2015-01-02 12:58 GMT+01:00 Lorenzo Miniero <lminiero at gmail.com>:

> 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:
>
> http://pastebin.com/5CUWpZ5M
>
> Let me know what else I can do to help you understand what's going wrong,
> and if it may be my fault somewhere.
>
> Thanks,
> Lorenzo
>
> 2015-01-02 11:53 GMT+01:00 Lorenzo Miniero <lminiero at gmail.com>:
>
>> 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/20150109/2d602d64/attachment.html>