<div dir="ltr"><div><div><div><div><div>Hello Philip, </div>When I try to do `make` after I configured master version of libnice, </div>error occurred: [jack@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 </div>however, it never occurred in 0.1.13, </div>any suggestion for this?? </div>btw,the gcc used is ARM structure Thanks. <div><div><div><div> </div></div></div></div></div><div class="gmail_extra"> <div class="gmail_quote">2016-01-11 5:21 GMT+08:00 Philip Withnall <<a href="mailto:philip@tecnocode.co.uk" target="_blank">philip@tecnocode.co.uk</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <div class="HOEnZb"><div class="h5"> > 2016-01-05 6:05 GMT+08:00 Philip Withnall <<a href="mailto:philip@tecnocode.co.uk">philip@tecnocode.co.uk</a>>: > > 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 <<a href="mailto:antirazin@gmail.com">antirazin@gmail.com</a>>: > > > > 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 > > > <a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a> > > > <a href="http://lists.freedesktop.org/mailman/listinfo/nice" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a> > > _______________________________________________ > > nice mailing list > > <a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a> > > <a href="http://lists.freedesktop.org/mailman/listinfo/nice" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a> > > </div></div></blockquote></div> </div>