Subject: [Sip] The fate of session timer?

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Nov 2002 18:24:27 -0500

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
[email-masked]                     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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 12 Nov 2002 16:05:58 +0100

At 12:24 AM 11/12/2002, Jonathan Rosenberg wrote:
[...]
>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. 

I think a reasonable example of its use is firewall-control proxies
(unless they are considered a broken idea anyway). The SIP session 
timer mechanism can be used to propagate SIP "keep-alive" messages 
from UAs via proxy servers down to the firewalls (translated to some
MIDCOM keep-alives). In this way, the firewall-control proxies do not 
have to be session-stateful to keep firewall pinholes alive. Keeping 
them up is then UA responsibility. 

Simplification of the negotiation mechanisms seems like a good thing to me.

-Jiri

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 12 Nov 2002 22:34:14 -0500

The functionality provided by the draft 
is needed.

I vote to perform yet another WGLC on 
the draft.  More vendors will implement 
or upgrade implementations once the draft
actually becomes an RFC.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 13 Nov 2002 08:44:05 -0800

Hi,

I likewise consider the existing mechanism a good approach for firewall 
control.  For all of the applications that I would use, I need 
intermediaries to be able to request a timer, and I want the ability to 
use the mechanism when only one side supports it.  For that reason, I 
don't think we will get much less complicated. I think we should 
clarify the language and publish it.

thanks,
-rohan

On Tuesday, November 12, 2002, at 07:05 AM, Jiri Kuthan wrote:

>> 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.
>

---

From: "Cullen Jennings" <[email-masked]>
Date: Thu, 14 Nov 2002 19:33:07 -0800

We all hope that SIP will allow us to build innovative application. Many of
these application will be realized in proxies in the network. SIP has
several ways, using various tags, for these applications to save all their
state out in the UAs. From a reliability and scalability point of view this
puts the state in exactly the right place - it is fate shared with the UAs
in the call.

Session timers allows the applications to cause the various timers that the
application needs to be executed on the UAs. This is brilliant - it fate
shares the timers with the right thing and solves some problems that have
always been tricky in doing high reliability applications.

I think we should close the open issues in this draft and get it to RFC.

Cullen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: Monday, November 11, 2002 3:24 PM
> To: [email-masked]
> Subject: [Sip] The fate of session timer?
>
>
> Folks,
>