<div dir="ltr"><div><div><div>Hello Philip,<br><br></div>After I tested with the latest libnice from master branch,<br></div>I found that when the caller (Offer) begin negotiation with the callee (Answer),<br></div><div>the caller program then crash due to assertion fail from libnice.<br><br></div><div>And I found the assertion code is add from the commit below:<br><a href="http://cgit.freedesktop.org/libnice/libnice/commit/?id=2eaa8b3277f4f39515ff5dc7b512a44fd79e7275" target="_blank">http://cgit.freedesktop.org/libnice/libnice/commit/?id=2eaa8b3277f4f39515ff5dc7b512a44fd79e7275</a><br><br></div><div>For understanding what the old state and new state are at that time,<br></div><div>I printed them and got <br><br></div><div>old-state = FAILED<br></div><div>new-state = CONNECTED<br><br></div><div>all the assertion failed so the application terminated.<br><br></div><div>However, if I do ICE with only audio or video channel, that is, with only one ICE thread, it works~!<br></div><div>so maybe my threads have some improper codes that cause interference with the others,<br></div><div>I'll keep tracking!<br><br></div><div>And now I haven't used the relay candidate yet,<br></div><div>after current version of the application becomes more stable,<br></div><div>I'll also test with it.<br><br></div><div>I think ICE can deal with the case that both endpoint are in different symmetric NATs , doesn't it?<br></div><div><br></div><div>Furthermore, <br></div><div>I want to print the debug logs in syslog file , not on the terminal screen.<br></div><div>below are the steps, but doesn't work.<br><br></div><div>1. modify the nice_debug() function<br><br>void nice_debug (const char *fmt, ...)<br>{<br> va_list ap;<br> if (debug_enabled) {<br> va_start (ap, fmt);<br> vsyslog(LOG_DEBUG, fmt, ap);<br>// g_logv (G_LOG_DOMAIN, G_LOG_LEVEL_DEBUG, fmt, ap);<br> va_end (ap);<br> }<br>}<br></div><div><div><div><div><div><div><br></div><div>2. in the execution environment, set:<br> export G_MESSAGES_DEBUG=all<br> export NICE_DEBUG=all</div><div>3. run the program<br><br></div><div>Is there anything wrong with my steps??<br><br><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-11 17:29 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You can do that without source code modifications by passing --enable-<br> compile-warnings=maximum to the configure script. The default is --<br> enable-compile-warnings=error, which enables -Werror.<br> <span><font color="#888888"><br> Philip<br> </font></span><div><div><br> On Mon, 2016-01-11 at 16:30 +0800, Jack Wang wrote:<br> > Well, after I remove -Werror and -Wno-suggest-attribute=format from<br> > LIBNICE_CFLAGS,<br> > `make` works!<br> ><br> > Later I'll report the result back. :P<br> ><br> > 2016-01-11 15:24 GMT+08:00 Jack Wang <<a href="mailto:antirazin@gmail.com" target="_blank">antirazin@gmail.com</a>>:<br> > > Hello Philip,<br> > ><br> > > When I try to do `make` after I configured master version of<br> > > libnice,<br> > > 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<br> > > target type [-Werror=cast-align]<br> > > stunmessage.c:447:42: error: cast increases required alignment of<br> > > target type [-Werror=cast-align]<br> > > stunmessage.c: At top level:<br> > > cc1: error: unrecognized command line option "-Wno-suggest-<br> > > 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> > > however, it never occurred in 0.1.13,<br> > > any suggestion for this?? <br> > > btw,the gcc used is ARM structure<br> > ><br> > ><br> > > Thanks.<br> > ><br> > ><br> > > 2016-01-11 5:21 GMT+08:00 Philip Withnall <<a href="mailto:philip@tecnocode.co.uk" target="_blank">philip@tecnocode.co.uk</a>>:<br> > > > Hi,<br> > > ><br> > > > It seems like you have several problems here.<br> > > ><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> > > > 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<br> > > > logs to<br> > > > the terminal.<br> > > ><br> > > > > In a normal way, the state flow should be gathering -><br> > > > connecting -><br> > > > > connected -> ready,<br> > > > > sometimes may be gathering -> connecting -> failed -> connected<br> > > > -><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-<br> > > > example.c),<br> > > > > when the state changed,<br> > > > > libnice will signal the callback so that I can know the state<br> > > > 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> > > > I would suggest trying with master. There have been a couple of<br> > > > fixes<br> > > > since 0.1.13 to do with state handling and signalling.<br> > > ><br> > > > > I'm also wondering if the bug is related to network<br> > > > 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<br> > > > reason<br> > > > > why I suppose this because I called over 30 times and it's<br> > > > always OK)<br> > > > > But it failed more frequent (below 10 times or less) when two<br> > > > > endpoints were at different network areas.<br> > > ><br> > > > Almost everything to do with libnice behavioural differences is<br> > > > to do<br> > > > with network environment! Note that ICE negotiation is not<br> > > > guaranteed<br> > > > to succeed in some network environments (for example, between two<br> > > > peers<br> > > > which are each behind a symmetric NAT).<br> > > ><br> > > > Do you have a TURN relay set up?<br> > > ><br> > > > > Btw, I use an array , which is always reused in next call , to<br> > > > store<br> > > > > ICE agents for several media channels,<br> > > > > so I didn't clear the agent with the g_object_unref in the end<br> > > > like<br> > > > > in examples since I will get an assertion in nice_agent_new<br> > > > 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> > > > If you are setting the NiceAgent pointer to NULL without calling<br> > > > g_object_unref() first, you are leaking the memory from the<br> > > > NiceAgent,<br> > > > plus all the resources (including network ports) which it’s<br> > > > using. This<br> > > > might be contributing to the ICE failures you are seeing, if<br> > > > 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()<br> > > > after<br> > > > unreffing the old instance, that indicates a bug somewhere –<br> > > > probably<br> > > > somewhere else in your code – which needs investigating.<br> > > ><br> > > > Philip<br> > > ><br> > > > > 2016-01-05 6:05 GMT+08:00 Philip Withnall <<a href="mailto:philip@tecnocode.co" target="_blank">philip@tecnocode.co</a>.<br> > > > uk>:<br> > > > > > Can you please provide a debug log from libnice for this?<br> > > > It’s hard<br> > > > > > to<br> > > > > > work out what the problem is otherwise.<br> > > > > ><br> > > > > > Does the component state change to<br> > > > 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<br> > > > connection<br> > > > > > is<br> > > > > > ready?<br> > > > > ><br> > > > > > What version of libnice is this with? 0.1.13, or master? Can<br> > > > 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<br> > > > 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<br> > > > port.<br> > > > > > > ><br> > > > > > > > Then after I did a SIP call to exchange the ICE SDP with<br> > > > the<br> > > > > > > > callee,<br> > > > > > > > I found the one who sent the offer often failed on<br> > > > 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<br> > > > the<br> > > > > > > > following calls.<br> > > > > > > ><br> > > > > > > > The Offer one is behind a symmetric NAT, and the Answer<br> > > > one is<br> > > > > > on<br> > > > > > > > WAN.<br> > > > > > > > I trace the log and found the failed(for negotiation)<br> > > > ones<br> > > > > > always<br> > > > > > > > discover the prflx candidate very late, and cannot be<br> > > > 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<br> > > > 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> > > > > ><br> > > ><br> > > </div></div></blockquote></div><br></div></div></div></div></div></div></div></div>