Subject: RE: [Sip] updating session timer

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 4 Jun 2002 17:44:56 -0400

I also vote for allow in UPDATE, and no more.

But, please, we seem to be able to find something to tweak no matter
how long we bake things.  This one is overdone, let's get it out now.

Brian

> -----Original Message-----
> From: David R. Oran [mailto:[email-masked]]
> Sent: Tuesday, June 04, 2002 4: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