[libnice] why it takes so long (3 second) to get Local candidates?
tom chen
chentom60 at hotmail.com
Wed Nov 4 21:38:50 PST 2015
Hi Olivier,
There are a couple of flags in stun/usages/timer.h that can affect when
candidates gathering is done.
#define STUN_TIMER_DEFAULT_TIMEOUT 600 //initial timeout
#define STUN_TIMER_DEFAULT_MAX_RETRANSMISSIONS 3
Below are some tests showing the relationship between max re-transmission
and total wait time. It seems that I should reduce the MAX_RETRANSMISSION.
But I am also wondering if I simply change MAX_RETRANSMISSIONS from 3 to 2
or 1, could there be some side-effects like some candidate pairs may not
have been tested when timeout happens, ie timeout too fast?
MAX_RETRANSMISSION timeout (second)
5 12.9
4 6.48
3 3.3
2 1.6
1 0.8
The timer.h has a formula to calculate total time,
total_timeout = initial_timeout * (2^(max_retransmissions + 1) - 1);
But the formula does not consider the number of network interfaces available
in the local and remote machine, I am curious why?
Tom
--------------------------------------------------
From: "OlivierCrête" <olivier.crete at collabora.com>
Sent: Wednesday, November 04, 2015 3:20 PM
To: "Tom Chen" <chentom60 at hotmail.com>; <felixschlitter at gmail.com>;
<nice at lists.freedesktop.org>
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 at collabora.com
>> > To: chentom60 at hotmail.com; felixschlitter at gmail.com; nice at 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 at collabora.com
>> > > > To: felixschlitter at gmail.com; nice at 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 at 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 at 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 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
>> > > > --
>> > > > Olivier Crête
>> > > > olivier.crete at collabora.com
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > nice mailing list
>> > > > nice at lists.freedesktop.org
>> > > > http://lists.freedesktop.org/mailman/listinfo/nice
>> > --
>> > Olivier Crête
>> > olivier.crete at collabora.com
>> >
>> >
>> > _______________________________________________
>> > nice mailing list
>> > nice at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/nice
> --
> Olivier Crête
> olivier.crete at collabora.com
>
>
> _______________________________________________
> nice mailing list
> nice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nice
>
More information about the nice
mailing list