[Nice] NiceAgent emits "candidate-gathering-done" before gathering is finished with UPnP

[Youness Alaoui]

On 07/11/2010 11:41 AM, Olivier Crête wrote:
> On Sun, 2010-07-11 at 10:51 +0200, Jakub Adam wrote:
>> Candidates with foundation 2 are discovered via UPnP. According to libnice documentation
>> i would expect that "candidate-gathering-done" emits when all attempts to gather
>> candidates has finished.
>>
>> Is this behavior intentional?
>>
>> This affects only candidate discovery with UPnP, when I set STUN server IP and port,
>> libnice acts normally and both server reflexive candidates are gathered before the
>> gathering done signal is emitted.
> 
> This is kind of a bug I guess. The idea is that you will almost always
> have a stun server and talking to a stun server (over the Internet) will
> take a lot longer than UPnP. We don't want to wait for UPnP since in
> many cases it isn't on the network. Since you don't have a STUN server,
> the gathering done is almost immediate and you'll miss the second UPnP
> candidate.
> 

Actually, the issue is a bit different.. and I should probably document it at
some point.
The problem with UPnP is that each router will act differently.. I've done quite
a few tests, and I've noticed that most of the time, with a correct router,
you'll get your answer (port mapping) in less 50ms.. sometimes it will take up
to 100ms, so by default, I've set the upnp-timeout to double that amount :
200ms. However, I've also found quite a few routers that do not answer right
away but instead, they answer periodically or something, and it could take up to
5 seconds to get the answer. What this causes is that if we wait for the upnp
response, we might delay our candidate gathering by many seconds (which
translates for the user to a "long time before the call is made after I clicked
the button"), which is unacceptable.
The solution was to not wait that long for UPnP because in most cases the router
will answer under 100ms (it's on the same network), and if we wait longer, then
for all the non-upnp-enabled routers, it will add a huge delay before the
candidate gathering is done (which could be interpreted by other people as being
a bug).
However, once the upnp-timeout is elapsed, libnice will send the
candidate-gathering-done signal, the upnp port mapping stays active in case we
receive the response later, at which point, it really doesn't matter since you
should pretty much *always* have a STUN server when you use ICE. The result is
that you will get your external IP from the STUN server, and just in case STUN
wasn't able to punch a hole through your router, then the UPnP port mapping will
kick in and will open that port for you in the router, which will end up being
the same for you anyways (what I mean is that in theory, the UPnP candidate will
be the same as the STUN candidate, if STUN fails, then UPnP will back it up,
even if it comes in late).
Anyways, if you're not happy with the 200ms timeout I've set, you can always
change it, the NiceAgent has a "upnp-timeout" property that you can set.
Have a look here :

http://nice.freedesktop.org/libnice/NiceAgent.html#NiceAgent--upnp-timeout
"The maximum amount of time to wait for UPnP discovery to finish before
signaling the "candidate-gathering-done" signal"

I hope this helps,
Youness.

> 
> 
> 
> _______________________________________________
> Nice mailing list
> Nice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nice


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/nice/attachments/20100712/9c05db6f/attachment.pgp>