[libnice] sometimes connectivity checks fail...
Jack Wang
antirazin at gmail.com
Mon Jan 11 00:30:22 PST 2016
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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20160111/43fcc307/attachment-0001.html>
More information about the nice
mailing list