<div dir="ltr"><div><div>Well, after I remove -Werror and -Wno-suggest-attribute=format from LIBNICE_CFLAGS,<br></div>`make` works!<br><br></div>Later I'll report the result back. :P<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-11 15:24 GMT+08:00 Jack Wang <span dir="ltr"><<a href="mailto:antirazin@gmail.com" target="_blank">antirazin@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hello Philip,<br><br></div>When I try to do `make` after I configured master version of libnice,<br></div>error occurred:<br><br>[jack@localhost libnice]$ make<br>make  all-recursive<br>make[1]: Entering directory `/home/jack/Desktop/libnice'<br>Making all in stun<br>make[2]: Entering directory `/home/jack/Desktop/libnice/stun'<br>Making all in .<br>make[3]: Entering directory `/home/jack/Desktop/libnice/stun'<br>  CC     stunagent.lo<br>  CC     stunmessage.lo<br>stunmessage.c: In function 'stun_message_append_addr':<br>stunmessage.c:437:41: error: cast increases required alignment of target type [-Werror=cast-align]<br>stunmessage.c:447:42: error: cast increases required alignment of target type [-Werror=cast-align]<br>stunmessage.c: At top level:<br>cc1: error: unrecognized command line option "-Wno-suggest-attribute=format" [-Werror]<br>cc1: all warnings being treated as errors<br><br>make[3]: *** [stunmessage.lo] Error 1<br>make[3]: Leaving directory `/home/jack/Desktop/libnice/stun'<br>make[2]: *** [all-recursive] Error 1<br>make[2]: Leaving directory `/home/jack/Desktop/libnice/stun'<br>make[1]: *** [all-recursive] Error 1<br>make[1]: Leaving directory `/home/jack/Desktop/libnice'<br>make: *** [all] Error 2<br><br></div>however, it never occurred in 0.1.13,<br></div>any suggestion for this?? <br></div>btw,the gcc used is ARM structure<br><br><br>Thanks.<br><div><div><div><div><br></div></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-01-11 5:21 GMT+08:00 Philip Withnall <span dir="ltr"><<a href="mailto:philip@tecnocode.co.uk" target="_blank">philip@tecnocode.co.uk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
It seems like you have several problems here.<br>
<span><br>
On Fri, 2016-01-08 at 14:14 +0800, Jack Wang wrote:<br>
> I have to print debug logs in syslog,<br>
> can you teach me how to achieve this?<br>
<br>
</span>In your terminal:<br>
<br>
export G_MESSAGES_DEBUG=all<br>
export NICE_DEBUG=all<br>
<br>
then run your program. This will print the full libnice debug logs to<br>
the terminal.<br>
<span><br>
> In a normal way, the state flow should be gathering -> connecting -><br>
> connected -> ready,<br>
> sometimes may be gathering -> connecting -> failed -> connected -><br>
> ready,<br>
> however, it also can be gathering -> connecting -> failed, <br>
> which will never be changed to connected state :(<br>
><br>
> I use the callback like the one in sample code (ex: sdp-example.c),<br>
> when the state changed,<br>
> libnice will signal the callback so that I can know the state in my<br>
> application.<br>
><br>
> I used version of 0.1.13,<br>
> and I will try the master later to see what happened . <br>
<br>
</span>I would suggest trying with master. There have been a couple of fixes<br>
since 0.1.13 to do with state handling and signalling.<br>
<span><br>
> I'm also wondering if the bug is related to network environment.<br>
> If the two ICE endpoints were at the same LAN, the connectivity<br>
> checks never fails. <br>
> (well.... actually I can't promise this is always right, the reason<br>
> why I suppose this because I called over 30 times and it's always OK)<br>
> But it failed more frequent (below 10 times or less) when two<br>
> endpoints were at different network areas.<br>
<br>
</span>Almost everything to do with libnice behavioural differences is to do<br>
with network environment! Note that ICE negotiation is not guaranteed<br>
to succeed in some network environments (for example, between two peers<br>
which are each behind a symmetric NAT).<br>
<br>
Do you have a TURN relay set up?<br>
<span><br>
> Btw, I use an array , which is always reused in next call , to store<br>
> ICE agents for several media channels,<br>
> so I didn't clear the agent with the g_object_unref in the end like<br>
> in examples since I will get an assertion in nice_agent_new when I<br>
> make a new call,<br>
> I just set the agent to NULL when call hangs up.<br>
><br>
> Is this a proper method? or may cause some side effects?<br>
<br>
</span>If you are setting the NiceAgent pointer to NULL without calling<br>
g_object_unref() first, you are leaking the memory from the NiceAgent,<br>
plus all the resources (including network ports) which it’s using. This<br>
might be contributing to the ICE failures you are seeing, if there are<br>
no more forwardable ports left for the new NiceAgent to use.<br>
<br>
If you are getting an assertion when calling nice_agent_new() after<br>
unreffing the old instance, that indicates a bug somewhere – probably<br>
somewhere else in your code – which needs investigating.<br>
<span><font color="#888888"><br>
Philip<br>
</font></span><div><div><br>
> 2016-01-05 6:05 GMT+08:00 Philip Withnall <<a href="mailto:philip@tecnocode.co.uk" target="_blank">philip@tecnocode.co.uk</a>>:<br>
> > Can you please provide a debug log from libnice for this? It’s hard<br>
> > to<br>
> > work out what the problem is otherwise.<br>
> ><br>
> > Does the component state change to NICE_COMPONENT_STATE_FAILED? If<br>
> > you<br>
> > wait, does it later change to NICE_COMPONENT_STATE_READY or<br>
> > *_CONNECTED? What are you waiting for to know when the connection<br>
> > is<br>
> > ready?<br>
> ><br>
> > What version of libnice is this with? 0.1.13, or master? Can you<br>
> > try<br>
> > with master?<br>
> ><br>
> > Philip<br>
> ><br>
> > On Thu, 2015-12-24 at 21:40 +0800, Jack Wang wrote:<br>
> > > I also test by using the random ports , which is used originally<br>
> > in<br>
> > > libnice,<br>
> > > and found it also fails sometimes, <br>
> > > however,  it still can work in some later calls.<br>
> > ><br>
> > > Keep tracking and testing....:P<br>
> > ><br>
> > > 2015-12-24 21:20 GMT+08:00 Jack Wang <<a href="mailto:antirazin@gmail.com" target="_blank">antirazin@gmail.com</a>>:<br>
> > > > Hi, everyone<br>
> > > ><br>
> > > > For several media channels (ex: audio,video etc.),<br>
> > > > I create ICE agents for each of them,<br>
> > > > and each channel I used a fixed port which is a fixed RTP port.<br>
> > > ><br>
> > > > Then after I did a SIP call to exchange the ICE SDP with the<br>
> > > > callee,<br>
> > > > I found the one who sent the offer often failed on negotiation<br>
> > on<br>
> > > > some channels (not the same ones every time), <br>
> > > > while the answer one is always OK.<br>
> > > > And if failed on the first time, it will always fail in the<br>
> > > > following calls.<br>
> > > ><br>
> > > > The Offer one is behind a symmetric NAT, and the Answer one is<br>
> > on<br>
> > > > WAN.<br>
> > > > I trace the log and found the failed(for negotiation) ones<br>
> > always<br>
> > > > discover the prflx candidate very late, and cannot be READY<br>
> > state<br>
> > > > in the end.<br>
> > > ><br>
> > > > I cannot figure out why this happens,<br>
> > > > does it is related to the NAT policy for port forwarding??<br>
> > > ><br>
> > > ><br>
> > > > Thanks in advance :)<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > _______________________________________________<br>
> > > nice mailing list<br>
> > > <a href="mailto:nice@lists.freedesktop.org" target="_blank">nice@lists.freedesktop.org</a><br>
> > > <a href="http://lists.freedesktop.org/mailman/listinfo/nice" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br>
> > _______________________________________________<br>
> > nice mailing list<br>
> > <a href="mailto:nice@lists.freedesktop.org" target="_blank">nice@lists.freedesktop.org</a><br>
> > <a href="http://lists.freedesktop.org/mailman/listinfo/nice" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br>
> > </div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>