<html> <head> <style></style></head> <body class='hmmessage'><div dir='ltr'>Olivier, I can not "just send the candidates" as l don't have yet. The issue I have is that libnice can take 3 second to gather Local candidates if one network interface has no internet access. This is too slow which affects communication setup with remote VoIP clients. Tom > From: olivier.crete@collabora.com > To: chentom60@hotmail.com; felixschlitter@gmail.com; nice@lists.freedesktop.org > Date: Wed, 4 Nov 2015 18:20:36 -0500 > Subject: Re: [libnice] why it takes so long (3 second) to get Local candidates? > > Hi, > > You should be able to just send the candidates earlier and ignore the > signal if you think the timeout is too long. > > Olivier > > On Wed, 2015-11-04 at 07:00 -0800, Tom Chen wrote: > > Olivier: > > > > I enabled glib debugging and see there are lots of retransmission > > timeout as there is a network interface that is connected to intranet > > and can not access external STUN server: > > > > (process:4472): libnice-stun-DEBUG: STUN transaction retransmitted > > (timeout 396ms). > > (process:4472): libnice-stun-DEBUG: STUN transaction retransmitted > > (timeout 397ms). > > (process:4472): libnice-stun-DEBUG: STUN transaction retransmitted > > (timeout 793ms). > > (process:4472): libnice-stun-DEBUG: STUN transaction retransmitted > > (timeout 1589ms). > > . . . . . > > > > I am wondering if there is a way to shorten or limit the re > > transmission? 3 second can be too long for voip phone communication > > setup as the remote client may close the session if it does not > > receive response soon enough. > > > > Tom > > > > > From: olivier.crete@collabora.com > > > To: chentom60@hotmail.com; felixschlitter@gmail.com; nice@lists.fre > > edesktop.org > > > Date: Fri, 30 Oct 2015 16:18:21 -0400 > > > Subject: Re: [libnice] why it takes so long (3 second) to get Local > > candidates? > > > > > > Hi, > > > > > > There is a signal for new candidates also that will give you the > > > candidates as they are discovered. > > > > > > Olivier > > > > > > On Thu, 2015-10-15 at 11:23 -0700, Tom Chen wrote: > > > > Olivier, > > > > > > > > The delay is in waiting for candidates gathering done signal not > > in > > > > waiting for component state changed. If i don't wait for the > > > > candidates gathering done signal, then the > > > > nice_agent_get_local_candidates( ) will always return Null, thus > > no > > > > candidate. > > > > > > > > Tom > > > > > > > > > From: olivier.crete@collabora.com > > > > > To: felixschlitter@gmail.com; nice@lists.freedesktop.org > > > > > Date: Thu, 15 Oct 2015 12:01:43 +0100 > > > > > Subject: Re: [libnice] why it takes so long (3 second) to get > > Local > > > > candidates? > > > > > > > > > > Hello, > > > > > > > > > > libnice will do a STUN query from every local interface, in > > case > > > > you > > > > > have a multi-homed device, so if some of them are not Internet > > > > > connected, then it waits for all of them to timeout. You can > > just > > > > > ignore the state change and start sending candidates earlier if > > the > > > > > delay is unacceptable for your application. > > > > > > > > > > Olivier > > > > > > > > > > On Thu, 2015-10-15 at 18:25 +1300, Felix Schlitter wrote: > > > > > > I found that it can take a long time if I leave libnice to > > figure > > > > out > > > > > > my local interfaces. If I tell which local address I want to > > use, > > > > > > it's a lot faster. But that may have been because it tried to > > use > > > > a > > > > > > local interface that had no internet connection. Maybe see if > > > > > > `nice_agent_add_local_address` does anything for you. > > > > > > > > > > > > On Thu, Oct 15, 2015 at 6:01 PM, tom chen <chentom60@hotmail. > > com> > > > > > > wrote: > > > > > > > Hello, > > > > > > > > > > > > > > I am using an external public STUN server, > > > > > > > stun.l.google.com(74.125.194.127), port: 19302, to try > > > > > > > /examples/simple-example.c. > > > > > > > > > > > > > > simple-example can get its public IP as expected from this > > STUN > > > > > > > server, so the public STUN server really works. However, I > > > > notice > > > > > > > that, somehow, it takes around 3 second to get local > > candidate > > > > > > > list. Any idea why so long? Then I installed a local STUN > > > > server in > > > > > > > our intranet, still has same delay. I am wondering if there > > is > > > > > > > anything waiting for some events during the gathering but > > > > always > > > > > > > timeout? > > > > > > > > > > > > > > Tom > > > > > > > > > > > > > > tao@ubuntu:~/workspace/libnice-0.1.13/examples$ ./simple- > > > > example 1 > > > > > > > 74.125.194.127 19302 > > > > > > > Copy this line to remote client: > > > > > > > > > > > > > > vPRk owHFru8Z6Dx8hj9TKel7Zl > > > > > > > 1,2013266431,fe80::20c:29ff:fe34:d0c8,42411,host > > > > > > > 2,1019216383,fe80::20c:29ff:fe34:d0c8,0,host > > > > > > > 3,1015022079,fe80::20c:29ff:fe34:d0c8,50240,host > > > > > > > 4,2013266431,fe80::20c:29ff:fe34:d0be,51731,host > > > > > > > 5,1019216383,fe80::20c:29ff:fe34:d0be,0,host > > > > > > > 6,1015022079,fe80::20c:29ff:fe34:d0be,43916,host > > > > > > > 7,2013266431,fe80::20c:29ff:fe34:d0b4,35004,host > > > > > > > 8,1019216383,fe80::20c:29ff:fe34:d0b4,0,host > > > > > > > 9,1015022079,fe80::20c:29ff:fe34:d0b4,51142,host > > > > > > > 10,2013266431,192.168.0.60,33635,host > > > > > > > 11,1019216383,192.168.0.60,0,host > > > > > > > 12,1015022079,192.168.0.60,51301,host > > > > > > > 13,2013266431,172.16.1.129,41734,host > > > > > > > 14,1019216383,172.16.1.129,0,host > > > > > > > 15,1015022079,172.16.1.129,46629,host > > > > > > > 16,2013266431,10.113.54.60,41481,host > > > > > > > 17,1019216383,10.113.54.60,0,host > > > > > > > 18,1015022079,10.113.54.60,33328,host > > > > > > > 19,1677722111,204.96.168.3,41481,srflx ç Public IP > > > > > > > candidates > > > > > > > 20,847249919,204.96.168.3,0,srflx > > > > > > > 21,843055615,204.96.168.3,33328,srflx > > > > > > > > > > > > > > Enter remote data (single line, no wrapping): > > > > > > > > ^C > > > > > > > > > > > > > > > > > > > > > > > > > > > > Statement Of Confidentiality: > > > > > > > > > > > > > > This electronic message transmission, and all attachments, > > > > contains > > > > > > > information from Extron Electronics which is confidential > > and > > > > > > > privileged. The information is for the exclusive viewing or > > use > > > > of > > > > > > > the intended recipient. If you are not the intended > > recipient, > > > > be > > > > > > > aware that any disclosure, copying, distribution or use of > > the > > > > > > > contents of this information is prohibited. If you have > > > > received > > > > > > > this electronic transmission in error, please notify the > > sender > > > > > > > immediately by a "reply to sender only" message and destroy > > all > > > > > > > electronic and hard copies of the communication, including > > > > > > > attachments. > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nice mailing list > > > > > > > nice@lists.freedesktop.org > > > > > > > http://lists.freedesktop.org/mailman/listinfo/nice > > > > > > > > > > > > > _______________________________________________ > > > > > > nice mailing list > > > > > > nice@lists.freedesktop.org > > > > > > http://lists.freedesktop.org/mailman/listinfo/nice > > > > > -- > > > > > Olivier Crête > > > > > olivier.crete@collabora.com > > > > > > > > > > > > > > > _______________________________________________ > > > > > nice mailing list > > > > > nice@lists.freedesktop.org > > > > > http://lists.freedesktop.org/mailman/listinfo/nice > > > -- > > > Olivier Crête > > > olivier.crete@collabora.com > > > > > > > > > _______________________________________________ > > > nice mailing list > > > nice@lists.freedesktop.org > > > http://lists.freedesktop.org/mailman/listinfo/nice > -- > Olivier Crête > olivier.crete@collabora.com > > > _______________________________________________ > nice mailing list > nice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nice </div></body> </html>