[libnice] sometimes connectivity checks fail...
Jack Wang
antirazin at gmail.com
Sun Jan 10 23:24:36 PST 2016
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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20160111/e58415fc/attachment.html>
More information about the nice
mailing list