Subject: [MMUSIC] ICE issue 3: default timers

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Jul 2005 11:13:31 -0400

The current ICE algorithm has two timers in it. Those are:

Tu: amount of time to wait for active candidate to be validated, before 
doing a reinvite to activate a different one. Default: 3s

Tg: once the active candidate has been validated, amount of time to wait 
for the ice exchanges to complete before the final re-invite. Default: 50s

I've been asked: why is Tg so large? The reason is to deal with the case 
where both sides are behind port-restricted nat. Once the answerer sends 
the answer, the answer has to be delivered (say, in a 200 OK), and the 
offerer needs to get its stun requests through the nat to create a 
permission. If SIP packets are lost, this could take as long as the 
maximum sip transaction timeout, which is already like 32s. Add some 
time for the stun transaction to see packet losses, and you end up near 
50s.

Now, it can be argued that this is just simply too long, and that no one 
wants a change in media handling 50s into a call. So, what is the rgith 
way to set this timer?

Firstly, the issue relates to issue (1), and how the ICE algorithm works 
overall. If we go with my suggestion, you'll do an initial re-invite 
once the first connectivity check succeeds, so Tu wouldnt be needed 
anymore. The endpoint won't do any other new connectivity checks. 
However, ones that launched previously may have not yet completed, and 
may produce a higher priority candidate. Do we allow yet another update, 
and how long do we tell the endpoint to wait before doing the update? 
There is a desire to avoid a sequence of one-ontop-of-the-other 
reinvites as stun transactions complete around the same time.

A meta-question is whether we even need to mandate behavior here. Any 
solution will work from an interop perspective since its just a standard 
re-invite. However, I'd like to have guidance on the best practice here.

I'd suggest that, after the stun connectivity check succeeds and a 
re-invite is done, the endpoint wait about 2 seconds for any checks on 
higher priority candidates to complete. If they do, then one and only 
re-invite happen. This is basically setting Tg to 2s. What about my 
concerns about SIP transaction timeouts? They become irrelevant, 
interestingly. With ICE, and offer/answer exchange MUST complete for the 
checks to succeed; the offer and answer contain pieces of the stun 
username and passwords. So, NO CHECKS will work until the exchange is 
done. Thus, once a single STUn check succeeds, we know the offer answer 
exchange has completed. Thus, Tg represents time after the exchange has 
completed to wiat for stun transactions to complete, and we can set that 
to a lower number.

Comments?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic