[libnice] sometimes connectivity checks fail...

Jack Wang antirazin at gmail.com
Thu Jan 7 22:14:38 PST 2016


Hello Philip,


I have to print debug logs in syslog,
can you teach me how to achieve this?

In a normal way, the state flow should be gathering -> connecting ->
connected -> ready,
sometimes may be gathering -> connecting -> failed -> connected -> ready,
however, it also can be gathering -> connecting -> failed,
which will never be changed to connected state :(

I use the callback like the one in sample code (ex: sdp-example.c),
when the state changed,
libnice will signal the callback so that I can know the state in my
application.

I used version of 0.1.13,
and I will try the master later to see what happened .

I'm also wondering if the bug is related to network environment.
If the two ICE endpoints were at the same LAN, the connectivity checks
never fails.
(well.... actually I can't promise this is always right, the reason why I
suppose this because I called over 30 times and it's always OK)
But it failed more frequent (below 10 times or less) when two endpoints
were at different network areas.

Btw, I use an array , which is always reused in next call , to store ICE
agents for several media channels,
so I didn't clear the agent with the g_object_unref in the end like in
examples since I will get an assertion in nice_agent_new when I make a new
call,
I just set the agent to NULL when call hangs up.

Is this a proper method? or may cause some side effects?





2016-01-05 6:05 GMT+08:00 Philip Withnall <philip at tecnocode.co.uk>:

> Can you please provide a debug log from libnice for this? It’s hard to
> work out what the problem is otherwise.
>
> Does the component state change to NICE_COMPONENT_STATE_FAILED? If you
> wait, does it later change to NICE_COMPONENT_STATE_READY or
> *_CONNECTED? What are you waiting for to know when the connection is
> ready?
>
> What version of libnice is this with? 0.1.13, or master? Can you try
> with master?
>
> Philip
>
> On Thu, 2015-12-24 at 21:40 +0800, Jack Wang wrote:
> > I also test by using the random ports , which is used originally in
> > libnice,
> > and found it also fails sometimes,
> > however,  it still can work in some later calls.
> >
> > Keep tracking and testing....:P
> >
> > 2015-12-24 21:20 GMT+08:00 Jack Wang <antirazin at gmail.com>:
> > > Hi, everyone
> > >
> > > For several media channels (ex: audio,video etc.),
> > > I create ICE agents for each of them,
> > > and each channel I used a fixed port which is a fixed RTP port.
> > >
> > > Then after I did a SIP call to exchange the ICE SDP with the
> > > callee,
> > > I found the one who sent the offer often failed on negotiation on
> > > some channels (not the same ones every time),
> > > while the answer one is always OK.
> > > And if failed on the first time, it will always fail in the
> > > following calls.
> > >
> > > The Offer one is behind a symmetric NAT, and the Answer one is on
> > > WAN.
> > > I trace the log and found the failed(for negotiation) ones always
> > > discover the prflx candidate very late, and cannot be READY state
> > > in the end.
> > >
> > > I cannot figure out why this happens,
> > > does it is related to the NAT policy for port forwarding??
> > >
> > >
> > > Thanks in advance :)
> > >
> > >
> > >
> > _______________________________________________
> > nice mailing list
> > nice at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/nice
> _______________________________________________
> nice mailing list
> nice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nice
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20160108/55bbba51/attachment.html>


More information about the nice mailing list