[libnice] State stuck to 'connected' and no nominated pair
Philip Withnall
philip at tecnocode.co.uk
Thu Jan 22 07:31:29 PST 2015
Hi Lorenzo,
Sorry for the slow reply. I did take a look at the trace a little while
ago, but I couldn’t figure out what was going on. I’m afraid the best
advice I can give is for you to use gdb to trace through libnice’s
handling of the candidate pairs, and work out why it’s nominating pairs
but then never selecting them.
One other approach you can try is to examine the packet logs in
Wireshark, and make sure that all the transmitted STUN checks get the
responses you expect them to, given the network configuration.
Sorry I can’t be more helpful, but this is a difficult problem to fix
without being able to reproduce it!
Philip
On Fri, 2015-01-09 at 11:44 +0100, Lorenzo Miniero wrote:
> 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 --------------
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/20150122/99f2b6df/attachment.sig>
More information about the nice
mailing list