Subject: RE: [Sip] updating session timer

From: [email-masked]
Date: Wed, 5 Jun 2002 10:58:53 +0300

We have to separate dialogs from sessions.

To my mind, we are talking about Session Timer, not dialog timer. Requests like SUBSCRIBE/NOTIFY can appear within a dialog but should not affect the "session" timer.

UPDATE updates a session, not a dialog.

/Hisham

> -----Original Message-----
> From: ext Dean Willis [mailto:[email-masked]]
> Sent: Wednesday, June 05, 2002 3:44 AM
> To: 'Padhye, Chinmay'; [email-masked]
> Cc: 'David R. Oran'; 'Jonathan Rosenberg'
> Subject: RE: [Sip] updating session timer
> 
> 
> 
> I think I agree with Chinmay here. One of the big beefs with
> session-timer is the number of additional messages required
> (INVITE-OK-ACK) just to refresh it. If every request-response on the
> dialog resets the count-down timer, then we have very little 
> overhead. 
> 
> --
> Dean
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Padhye, Chinmay
> > Sent: Tuesday, June 04, 2002 4:06 PM
> > To: [email-masked]
> > Cc: 'David R. Oran'; Jonathan Rosenberg
> > Subject: RE: [Sip] updating session timer
> > 
> > 
> > Hello,
> > 
> > 	I feel any method sent/received on an existing dialog 
> > should reset the session timer for that dialog.
> > 
> > 	Its OK for UPDATE to change the session timer related 
> > roles, timer values, etc.
> > 
> > Regards,
> > 
> > Chinmay
> > 
> > -----Original Message-----
> > From: David R. Oran [mailto:[email-masked]]
> > Sent: Tuesday, June 04, 2002 1:36 PM
> > To: Jonathan Rosenberg; [email-masked]
> > Subject: Re: [Sip] updating session timer
> > 
> > 
> > It certainly makes sense to have UPDATE refresh the session 
> > timer. Other 
> > than that I don't see much benefit in tweaking the design, 
> > unless we just 
> > want to say that any method refreshes the timer. That makes 
> the spec 
> > future-proof for new methods, which might be a good thing, or 
> > a bad thing 
> > depending on some clairvoyance I don't have.
> > 
> > I vote for the minimal disruption: add UPDATE as a method 
> > which refreshes 
> > the timer and leave the rest alone.
> > 
> > Dave.
> > 
> > --On Tuesday, June 04, 2002 3:17 PM -0400 Jonathan Rosenberg 
> > <[email-masked]> wrote:
> > 
> > > Folks,
> > >
> > > I am in the process of doing an update to session timer. 
> This draft 
> > > got "shelved" while we were finishing up bis and the rest 
> > of the pile 
> > > of drafts for 3gpp. As such, its being updated to now 
> reference bis 
> > > rather than rfc2543. One of the things I am doing in this 
> > process is 
> > > assessing whether anything new impacts design decisions we 
> > made in the 
> > > original draft.
> > >
> > > One of the things we assumed in session timer was that 
> all session 
> > > refreshes were with re-invite. The principal reason for 
> > that was that 
> > > we wanted the refreshes to have a soft-state property, so that a 
> > > refresh could itself cause the recovery of call and session 
> > state at a 
> > > failed-and-rebooted UA (or a backup).
> > >
> > > The notion of such soft-state recovery of sessions was 
> > something that 
> > > we discussed at length for bis (bug #207), and ultimately 
> > decided not 
> > > to go with. In the case of bis, the particular issue was 
> > that if you 
> > > have a media stream failure, should you send a re-INVITE in 
> > order to 
> > > re-establish the call with a backup? This would allow 
> > relatively fast 
> > > recovery. However, we didn't do this because it had 
> > numerous problems, 
> > > which I won't repeat. There was also limited interest in such 
> > > recovery. Now, the point of this is that we discarded support for 
> > > rapid recovery of call state and sessions from bis. Session timer 
> > > would provide much slower recovery, arguably, so slow as 
> to not be 
> > > useful. Since we already discarded the much-more-useful approach, 
> > > there seems little value in supporting the much-less-useful 
> > approach.
> > >
> > > Another thing that has changed with bis is the existence 
> of another 
> > > method which is a pretty reasonable mechanism for refreshing the 
> > > session timer - UPDATE. An UPDATE without an offer at all seems a 
> > > perfect mechanism for updating a session timer.
> > >
> > > So, I would propose we re-visit this design decision, and 
> > at the very 
> > > least, allow for session timer refreshes to occur in UPDATE 
> > as well as 
> > > INVITE. The other alternative is to allow session timer 
> > refreshes in 
> > > any method. This would allow normally ocurring SIP messages 
> > within the 
> > > dialog (if any) to cause refreshes, and if you had 
> nothing to send, 
> > > you would use UPDATE. The overall benefit here is reduced 
> overhead 
> > > (2-way exchange with UPDATE instead of three-way with 
> > INVITE). I see 
> > > no reason why we shouldn't allow for session timer updates in any 
> > > method.
> > >
> > > Another issue possibly worth revisiting is the decision to allow 
> > > session timer to work as long as only one of the two UA 
> in a dialog 
> > > support it. In order to enable that, there is some complex proxy 
> > > behavior, and generally more complex UA behavior. With more 
> > experience 
> > > behind us (although I must say I am not aware of any UA 
> > > implementations of this draft), do people still believe this is a 
> > > reasonable assumption? I'm inclined not to change it, since 
> > I really 
> > > prefer not to revisit every design decision unless there is good 
> > > reason (i.e., bis has changed an assumption).
> > >
> > > Comments welcome.
> > >
> > > Thanks,
> > > Jonathan R.
> > >
> > >
> > >
> > >
> > > --
> > > Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> > > Chief Scientist                         First Floor
> > > dynamicsoft                             East Hanover, NJ 07936
> > > [email-masked]                 FAX: (973) 952-5050
> > > http://www.jdrosen.net                  PH:  (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
> > 
> > 
> > 
> > -----------------------------------------------------------
> > David R. Oran                   Phone/Fax: +1 978 264 2048
> > Cisco Systems                   VoIP: +1 408 571 4576
> > 7 Ladyslipper Lane              Email: [email-masked]
> > Acton, MA 01720
> > 
> > 
> > _______________________________________________
> > 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
> 

_______________________________________________
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: Thu, 06 Jun 2002 15:15:50 -0400

This is a good point. I think there was consensus on at least allowing 
UPDATE to update the session timer. On other methods, things were mixed. 
However, I am inclined to leave it at just UPDATE, partly for the 
(arguably philosophical) reason below.

I will make the change and be submitting an update shortly.

-Jonathan R.

[email-masked] wrote:
> To my mind, we are talking about Session Timer, not dialog timer.
> Requests like SUBSCRIBE/NOTIFY can appear within a dialog but should not
> affect the "session" timer.
>