[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] The fate of session timer?
As I see it, what we are specifying here is a keepalive mechanism for sessions. The value of the keepalive can have a default.
UACs don't have to send any new header in an initial INVITE, but proxies and UASs requiring session keepalive can inform the UAC of such requirement by including a (proxy-)Require-header in the response?? The default values can be used.
In this way, each entity can take of cleaning up its own stale sessions. No need for UAC to tell every other entity when it plans on ending the session, it can just send a BYE.
Btw, do we have requirements for this, or should we write one?
Regards,
Hisham
> -----Original Message-----
> From: ext Chandan Rajah [mailto:chandan.rajah@wipro.com]
> Sent: Tuesday, November 12, 2002 10:07 AM
> To: sip@ietf.org
> Subject: RE: [Sip] The fate of session timer?
>
>
> 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
>
_______________________________________________
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