[libnice] sometimes connectivity checks fail...

Mon Jan 11 01:29:37 PST 2016

You can do that without source code modifications by passing --enable-
compile-warnings=maximum to the configure script. The default is --
enable-compile-warnings=error, which enables -Werror.

Philip

On Mon, 2016-01-11 at 16:30 +0800, Jack Wang wrote:
> Well, after I remove -Werror and -Wno-suggest-attribute=format from
> LIBNICE_CFLAGS,
> `make` works!
> 
> Later I'll report the result back. :P
> 
> 2016-01-11 15:24 GMT+08:00 Jack Wang <antirazin at gmail.com>:
> > Hello Philip,
> > 
> > When I try to do `make` after I configured master version of
> > libnice,
> > error occurred:
> > 
> > [jack at localhost libnice]$ make
> > make  all-recursive
> > make[1]: Entering directory `/home/jack/Desktop/libnice'
> > Making all in stun
> > make[2]: Entering directory `/home/jack/Desktop/libnice/stun'
> > Making all in .
> > make[3]: Entering directory `/home/jack/Desktop/libnice/stun'
> >   CC     stunagent.lo
> >   CC     stunmessage.lo
> > stunmessage.c: In function 'stun_message_append_addr':
> > stunmessage.c:437:41: error: cast increases required alignment of
> > target type [-Werror=cast-align]
> > stunmessage.c:447:42: error: cast increases required alignment of
> > target type [-Werror=cast-align]
> > stunmessage.c: At top level:
> > cc1: error: unrecognized command line option "-Wno-suggest-
> > attribute=format" [-Werror]
> > cc1: all warnings being treated as errors
> > 
> > make[3]: *** [stunmessage.lo] Error 1
> > make[3]: Leaving directory `/home/jack/Desktop/libnice/stun'
> > make[2]: *** [all-recursive] Error 1
> > make[2]: Leaving directory `/home/jack/Desktop/libnice/stun'
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory `/home/jack/Desktop/libnice'
> > make: *** [all] Error 2
> > 
> > however, it never occurred in 0.1.13,
> > any suggestion for this?? 
> > btw,the gcc used is ARM structure
> > 
> > 
> > Thanks.
> > 
> > 
> > 2016-01-11 5:21 GMT+08:00 Philip Withnall <philip at tecnocode.co.uk>:
> > > 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/20160111/865e8efd/attachment.sig>