Subject: [MMUSIC] ICE Issue #14: sending keepalives and ICE states

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Sep 2006 14:41:02 -0400

On the first ICE call, Derek pointed out a bug in the way keepalives 
work. In particular, the ICE spec had assumed keepalives would just 
happen by flushing the states of the check list every 15s (which, after 
the reinvite, will contain only the selected pairs), which causes an ICE 
restart and thus redo checks. The problem with this is in the 'fedex 
case', there won't be a reinvite for a long time.

The fedex case for those not familiar, is an evil nasty early media use 
case. Consider a SIP UA that calls the PSTN, and in particular a 1-800 
number through an ICE-aware PSTN gateway. The PSTN side never actually 
answers the call; early media is used for the IVR prompts. When the user 
finally asks to talk to a person, the call is then accepted. This is 
done to deal with arcane billing issues. Don't get me started.... but 
its a real case.

In such a case, we could wait well more than 15s for that new offer, 
since it can't happen till the call is accepted if PRACK/UPDATE aren't 
used.

So, something different needs to happen.

As I was working through this, it fell out that we've basically 
introduced a notion in ICE-10 (though not made explicit) that the ICE 
processing itself has states. There are three states, in fact:

testing: both sides are performing checks to arrive at a set of pairs 
for each media stream. ICE starts out in this state.

done: we've finished checks, having found a highest priority pair for 
each component of each media straem

finalized: a reinvite has shown up that has placed the selected pairs 
into the m/c-line

If you make these states explicit, it becomes much easier to define 
rules for keepalives and also to describe how you get ICE to redo 
checks. Namely, I'd propose that, in any state, a re-invite without an 
a=remote-candiadtes moves you into the testing state. If, in either the 
testing or done states, you get a reinvite with a=remote-candidates, you 
go to finalized.

OK, so this makes rules for sending keepalives easier:

* testing state: no keepalives are sent
* done state: send keepalives to the highest priority candidate pairs 
for each component of each media stream in the valid list
* finalized state: send keepalives to the m/c-line

My proposal is to formalzie these states and use them to define the 
rules for keepalives and also for sending media (which more or less are 
based on these states, but again, doesnt explicit say it).

OK?

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   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