[libnice] sometimes connectivity checks fail...

[Philip Withnall]

Hi,

It seems like you have several problems here.

On Fri, 2016-01-08 at 14:14 +0800, Jack Wang wrote:
> I have to print debug logs in syslog,
> can you teach me how to achieve this?

In your terminal:

export G_MESSAGES_DEBUG=all
export NICE_DEBUG=all

then run your program. This will print the full libnice debug logs to
the terminal.

> 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 would suggest trying with master. There have been a couple of fixes
since 0.1.13 to do with state handling and signalling.

> 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.

Almost everything to do with libnice behavioural differences is to do
with network environment! Note that ICE negotiation is not guaranteed
to succeed in some network environments (for example, between two peers
which are each behind a symmetric NAT).

Do you have a TURN relay set up?

> 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?

If you are setting the NiceAgent pointer to NULL without calling
g_object_unref() first, you are leaking the memory from the NiceAgent,
plus all the resources (including network ports) which it’s using. This
might be contributing to the ICE failures you are seeing, if there are
no more forwardable ports left for the new NiceAgent to use.

If you are getting an assertion when calling nice_agent_new() after
unreffing the old instance, that indicates a bug somewhere – probably
somewhere else in your code – which needs investigating.

Philip

> 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 --------------
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/20160110/3ac993da/attachment.sig>