RE: [Sip] The fate of session timer?

["Chandan Rajah" <chandan.rajah@wipro.com>]

I think it is important to change the actual scope of the session timer.
If at all there is to be a session timer, it better do something
worthwhile. Though, re-INVITEs could be a way of going about achieving
this, deciding on the inter re-INVITE time is critical and can not be
defaulted. Maybe, at this point it would be a good idea to rethink the
entire mechanism and evaluate other prospective mechanism that could
replace the current session timer.


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] 
Sent: Tuesday, November 12, 2002 4:54 AM
To: sip@ietf.org
Subject: [Sip] The fate of session timer?

Folks,

As you may have noticed, I submitted an update to the session timer 
specification. This is an old, old spec that has been around for quite 
some time. It receives only minimal attention these days. The general 
comments on the list are generally 'too complex' and 'too hard to 
understand'. Some of that is wording, which I will continue to work. The

bigger problem, I think, is that its not at all clear what problem this 
draft is REALLY solving.

I assert that session timer is really useful for one thing, which is to 
provide a means to cleanup old session state in UAs and proxies. 
Normally, you'd set a timer (on the order of 5 hours or something) to 
discard any state thats still around. However, since a call may actually

last that long, you want a way to reliably know when you can flush the 
state.

Session timer is NOT useful for determining call durations for billing 
purposes.

Session timer is NOT useful for quickly determining that a UA has 
failed, in order to recover. It operates too slowly for that.

So, given this somewhat-marginal value, the complexity seems startingly 
high. I have begun to wonder whether that is the reason for the troubles

this specification is having. So, I see a few options:

1. No one cares about this spec. Discard it entirely.

2. Continue as it is, fix up some wording, and submit. Probably no one 
implements it since it provides little value at high cost.

3. Change the scope. Eliminate or simplify negotiation of the timer by 
defining a suitably long minimum. Eliminate or simplify choosing who 
refreshes by requiring that the UAC support the timer. And so on. The 
result would be a much simpler spec.

4. others?


Please provide comments, particularly if you are actively using this 
specification for some real problem.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip