[Nice] libnice candidate gathering delay?

[Tom Kaminski]

>>>> I have a quick question: When using libnice with a STUN server, I get
>>>> all the candidate almost immediately, but then there is a long delay
>>>> before the agent reports the candidate gathering done state.  Can you
>>>> explain why this is the case and suggest any way to eliminate this
>>>> delay or reduce it?  I'm using libnice 0.10.  FYI,I also managed to
>>>> compile libnice 0.11 (in visual studio) with some minor tweaks to the
>>>> code.
>>>>
>>>> Tom

>>> Hi,
>>> The delay is about 8 seconds, as suggested by some RFC. The delay is the time
>>> needed for the UDP packet retransmissions to be made and until it finally times
>>> out. The cause can be either that :
>>> 1 - the STUN server doesn't respond
>>> 2 - the STUN server doesn't respond on a specific interface.
>>> If the STUN server is down or something, it will retransmit the STUN request
>>> until it times out (8 seconds). If the server is working and you are still
>>> getting this delay, it might be because you have multiple interfaces and one of
>>> them is unable to reach the STUN server. Maybe you have vmware installed or
>>> something like that which created a new locally-bound (169.xx.xx.xx) interface.
>>> If you don't think that's the issue, then a NICE_DEBUG=all log would help in
>>> determining what's taking so long.
>>>
>>> Youness.
>>>
>>>

>> Thanks for the quick response!
>>
>> You were right, I had an OpenVPN connection that created an additional
>> interface.  After disabling this, the delay disappeared!  Now I am a
>> little concerned about this happening for other users that may have a
>> second interface that doesn't respond to STUN requests.  It is
>> possible to somehow improve libnice to detect for this to ignore this
>> second interface?  Perhaps a "quick" mode that declares that candidate
>> gathering is done when at least one response is detected from a STUN
>> server.  Then if a candidate pair can't be found, then restart the
>> candidate gathering in "full" mode.  What do you think?
>>
>> Tom
>>

>
> I'm not sure that's a great idea (or even possible). The delay you would get by
> doing this would be even greater.. also, not every implementation supports an
> ICE restart, maybe on SIP/XMPP, you can a renegociation of candidates, but it's
> not guaranteed that it will work. Also you can't really know in advance which
> interface will work or not.. assuming you had that openVPN connection working
> and you wanted to do a call with someone behind the VPN (a colleague at the
> office), then it would have only worked through that VPN connection, so it can't
> just be discarded...
> The thing is that you could force libnice to use a specific interface. There's
> the nice_agent_add_address API (iirc), so you could maybe check which interface
> is being used by your application to connect to SIP/whatever, so you know which
> interface is working and tell libnice to only use that one.. but like I said in
> the previous example, it might not work in some use cases.
>
> p.s.: why didn't you email the libnice mailing list, maybe others would have
> been interested in this discussion... if you have no problems with that, reply
> to the list.
>
> Youness.

I assume you mean the nice_agent_add_local_address() function.  I took
a look at the source code to see how libnice decides which interfaces
to use for local candidate addresses as well as querying for STUN
responses.  Currently, libnice doesn't support generating a local
candidate address for an interface without also querying that same
interface for STUN responses.  I think it would be beneficial to
explicitly specify this by a third parameter in the
nice_agent_add_local_address().

eg. nice_agent_add_local_address(agent,address,A_LOCAL);
nice_agent_add_local_address(agent,address2,A_LOCAL | A_STUN);

If this was supported, then it would be possible to only use STUN on
interfaces that my application known is valid (as you mentioned),
without compromising the local candidate addresses on each interface.

Tom