Subject: RE: [Sip] updating session timer

From: "Padhye, Chinmay" <[email-masked]>
Date: Tue, 4 Jun 2002 14:06:24 -0700

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

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 4 Jun 2002 19:43:59 -0500

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

> 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
> 
> > 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.
> >
> > 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 
> > 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 
> > 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.
> >
> > 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.
> >
> > 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.
> >
> >
> >
> >
> > --
> > Use [email-masked] for questions on 
> current sip Use 
> > [email-masked] for new developments on the application of sip
> 
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
> 
>