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

From: [email-masked]
Date: Tue, 12 Nov 2002 16:19:02 +0200

The current draft fulfils all the requests stated below, but there has been a couple of emails on this thread asking for simplifications to the draft. That's why I asked for requirements.

The simplification might start by examining the need for REQs 3-6.

Also for REQ 1, what is the rationale behind a UAC or proxy requesting session timer to be started on the remote end? Each entity only needs to take care of its own stale sessions (something I tried to propose in my earlier email). Should my UAC care that the remote end has stale sessions? It should just care that the remote end doesn't think my session with it is stale. My suggestion for this was using require-header, but, as pointed out by Jonathan, it is not appropriate (something I over looked).

Regards,
Hisham 

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, November 12, 2002 3:24 PM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sip] The fate of session timer?
> 
> 
> 
> 
> [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.
>  >
>  > Btw, do we have requirements for this, or should we write one?
> 
> 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.

-- 
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Nov 2002 07:40:11 -0500

[email-masked] wrote:
 > The current draft fulfils all the requests stated below, but there
 > has been a couple of emails on this thread asking for simplifications
 > to the draft. That's why I asked for requirements.
 >
 > Also for REQ 1, what is the rationale behind a UAC or proxy
 > requesting session timer to be started on the remote end? Each entity
 > only needs to take care of its own stale sessions (something I tried
 > to propose in my earlier email).

Well, certainly one UA will care that the other UA has crashed. Session 
timer allows a UAC or UAS to get refreshes in order to make that 
determination. As Adam points out, thats not strictly needed; a UA can 
simply send a re-INVITE or UPDATE whenever it wants to perform a 
refresh. Doing it through session timer, however, avoids having both 
sides sending UPDATEs or re-INVITEs to refresh the session, and allows 
for negotiation of a timer.

-Jonathan R.