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

Fri Jan 2 03:58:53 PST 2015

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/20150102/09a012dc/attachment-0001.html>