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

From: Adam Roach <[email-masked]>
Date: Tue, 12 Nov 2002 14:39:08 -0600

Session timer isn't needed for a back to back user agent.

B2BUAs are user agents, plain and simple. If you want to
check liveness on either side, you can send a re-INVITE.

/a

> -----Original Message-----
> From: Stevens, Del [mailto:[email-masked]]
> Sent: Tuesday, November 12, 2002 11:51
> To: [email-masked]'
> Subject: RE: [Sip] The fate of session timer?
> 
> 
> All:
> 
> For us the implementation of session timers has been a customer-driven
> requirement for our B2BUA. I agree that this draft was difficult to
> understand, but it satisfies several requirements for us:
> 
> 1. A simple keep-a-live mechanism (as stated previously). 
> This prevents
> tying up resources in our B2BUA if something happens in the 
> network causing
> a SIP UA (or proxy) to "disappear" after the receipt of 200 
> OK. We have a
> configurable timer value, but the default of 30 minutes (per 
> the draft)
> seems adequate. From a telco perspective, it is important 
> from a billing
> perspective to have some record of a session during failure 
> scenarios. Yes,
> this record is not exact, but telcos (or the like) can 
> generally deal with
> inaccurate cdr records during failures better than no record at all.
> 
> 2. If our B2BUA receives an INVITE from a SIP UA (or proxy) 
> that support
> session timers, the negotiation takes place, allowing a symetrical
> keep-a-live mechanism. If the SIP UA doesn't support session 
> timers, then
> our B2BUA can still use an asymetrical keep-a-live mechanism 
> so our UA can
> ensure the "other" end is still there for each session.
> 
> A nice off-shoot from our implementation of session timers 
> occurs during
> fail-over situation. In this case, the newly active B2BUA can 
> "re-establish"
> updated state information about each in progress session by issuing a
> re-INVITE for the session. The responses reinitializes the 
> session timer
> lists on the "new" ACTIVE machine.
> 
> Even though this is an old draft several sip phone 
> manufacturers support
> session timers. Also, since the implementaton of session timers is not
> universal, we never issue "Require: timer", but let 
> "Supported: timer" and
> "Session-Expires: n" to allow the negotiation to take place.
> 
> If anyone is using digest authentication with session timers 
> this creates
> the need for each re-INVITE to contain an Authorization 
> header or risk being
> challenged (401/407).
> 
> Yes, there is some messaging and processing overhead: 1) session timer
> negotiation + refreshes, and 2) tracking additional timers 
> per session. But
> the safety net provided is a must for some customers. My vote 
> is to keep
> this draft and update as necessary!
> 
> 
> Del Stevens mailto:[email-masked]
> Siemens Network Convergence LLC
> 7800 Congress Ave
> Boca Raton, FL  33487
> 
> 
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, November 11, 2002 6:24 PM
> 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: "Kevin Summers" <[email-masked]>
Date: Wed, 13 Nov 2002 10:55:31 -0600

This is a valuable and useful extension. That it can function
asymmetrically (i.e., only one participant in a session needs to support
session timer) is particularly useful WRT interoperability.

My opinion is that we go with option (2).

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, November 11, 2002 5:24 PM
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.

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

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?

-Jonathan R.

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 14 Nov 2002 01:00:44 -0000

Actually, if we really want to proceed with session timer, then I think putting a requirements draft through SIPPING is an excellent idea. We have had too many discussions in the past of what are we trying to achieve, so I think obtaining consensus as to whether there are requirements and what those requirements are is an excellent idea.

And by the way, 

1)	I see no requirements below on the treatment in response to non-supporting entities, i.e. the compatibility requirements.

2)	Some of these requirements seem to specify the implementation - who says we need a timer in the first place - the base requirement is that we do a cleanup within certain time constraints, yes, but stating "timer" implies we are always going to do this after a determined period of time rather than as and when we feel like it.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> Sent: 12 November 2002 13:24
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sip] The fate of session timer?
> 
> 
> 
> 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.

---

From: "Eric Burger" <[email-masked]>
Date: Sun, 17 Nov 2002 22:53:26 -0500

Prior to the session timer draft, we hacked keep alive mechanisms with application servers.  The session timer draft allows us to have a single mechanism that works for everyone.

Let's get this one done!

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Thursday, November 14, 2002 10:33 PM
> To: Jonathan Rosenberg; [email-masked]
> 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
> 
> 
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Jonathan Rosenberg
> > Sent: Monday, November 11, 2002 3:24 PM
> > To: [email-masked]

---

From: [email-masked]
Date: Mon, 18 Nov 2002 20:05:08 +0200

This sounds like a good idea, but we have to be careful: PING in RTSP is used to check liveliness of the entity. We want to check liveliness of a session. So, if we use PING, we need to allow it only as a request inside dialogs. Otherwise we will run into privacy issues with presence.

Regards,
Hisham

> From: ext Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Monday, November 18, 2002 2:52 PM
> To: Jonathan Rosenberg
> Cc: David Oliver; 'Drage, Keith (Keith)'; Khartabil Hisham
> (NMP/Helsinki); [email-masked]; [email-masked]
> Jonathan,
> Jonathan Rosenberg wrote:
> > 
> > Ah, yet another case of deviation between RTSP and SIP, all for no
> > reason. Grr.
> 
> Yes, that's exactly what I thought yesterday when I discovered it:
> Grrrr!
> 
> > So, are you saying you propose that we adopt a new PING 
> method for doing
> > this in SIP?
> 
> Since the entities involved in session timer have to support session
> timer, it would be alright to use a new method which would be specific
> to this extension. PING would be a good choice.
> 
> In any event, I believe that having RTSP and SIP aligned on this issue
> is a good thing.
> 
> FYI: this is the definition of the PING method in RTSP:
> 
> 10.12 PING
> 
>    This method is a bi-directional mechanism for server or 
> client live-  
>    ness checking. It has no side effects. The issuer of the 
> request MUST 
>    include a session header with the session ID of the 
> session that is   
>    being checked for liveness.                                
>            
> 
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326b
is-02.txt

Thanks,

Gonzalo