Subject: RE: [Sip] The fate of session timer?

From: [email-masked]
Date: Tue, 12 Nov 2002 13:14:22 +0200

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:[email-masked]]
> Sent: Tuesday, November 12, 2002 10:07 AM
> To: [email-masked]
> 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:[email-masked]] 
> Sent: Tuesday, November 12, 2002 4:54 AM
> To: [email-masked]
> 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
> [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
> _______________________________________________
> 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
> 
_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Nov 2002 08:24:00 -0500

[email-masked] wrote:
 > 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.

No. Require/Proxy-REquire in a response is only allowed if the request 
contained a Supported header in the INVITE.

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

This specification predates our requirements for requirements. So, no, 
there are none. I don't think we need to do a formal requirements 
process here. However, I think it is useful to have an email discussion 
of the basic requirements that underlie the current draft, to see which 
ones we can rule out, as it seems people seem amenable to considering a 
simplification:

REQ 1: There shall be a way for a proxy or UA to request that a session 
timer be executed for a dialog.

REQ 2: There shall be a way for the session timer to take place so long 
as EITHER the UAC or UAS supports it.

REQ 3: There shall be a way for each element - proxy,UAC, UAS, to 
specify their desired value for the session timer.

REQ 4: There shall be a way for each element to specify their minimum 
allowed value for the session tiemr.

REQ 5: The final session timer shall be:

          MAX(MIN(desired timers),MAX(min timers))

REQ 6: It shall be possible to renegotiate the use of session timer, and 
its value, at any time during a dialog.

REQ 7: Session timer shall be immune to DoS attacks introduced by a 
rogue UAC, UAS, or proxy.

REQ 8: It shall be possible for the UAC in the initial INVITE to suggest 
itself for performing the refreshes.

I think that captures most of it. Some of these requirements, like 6, 
fall out of general SIP properties, and we would be hard pressed to 
eliminate them.

Its also possible to get simplification through redesign while still 
meeting the requirements. For example, it occurs to me that we could 
potentially send the refreshes directly from the client to the 
"interested" proxies. This is more overhead for the client if there is 
more than one interested proxy, but means that proxies which don't care 
about session timer don't suffer from additional message volume, which 
is a drawback of the current solution.

By doing that, all of the negotiation becomes two-way, between a UA and 
a proxy, rather than N-way, and is thus much simplified.

Such a solution would require a proxy requesting session timer to have a 
  globally routable URI.

Yet another solution is to define a specific "heartbeat" media stream 
type, which periodically genreates a keepalive. In that sense, its 
similar to RTCP, but not RTP specific. AN intermediary can get itself 
onto this heartbeat stream by being a b2bua that mucks with SDP, or 
using a mechanism like the session policy which I have formerly proposed:
http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-00.txt

There may be other general solutions to this too.

-Jonathan R.

---

From: "Arunachalam Venkatraman" <[email-masked]>
Date: Tue, 12 Nov 2002 10:59:26 -0600

Jonathan
I believe your statement below about the rule for adding a Require header
into a response should be documented in section 20.32 of the RFC3261.
Regards
Venkat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Jonathan
Rosenberg
Sent: Tuesday, November 12, 2002 7:24 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Sip] The fate of session timer?

-Jonathan R.

---

From: "Arunachalam Venkatraman" <[email-masked]>
Date: Wed, 13 Nov 2002 10:59:16 -0600

Jonathan

-----Original Message-----

-Jonathan R.