Subject: [Sip] updating session timer

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 04 Jun 2002 15:17:40 -0400

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

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 04 Jun 2002 16:36:25 -0400

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.

> design decision unless there is good reason (i.e., bis has changed an

-----------------------------------------------------------
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

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 05 Jun 2002 06:21:27 -0400

I always thought that in addition to INVITE/UPDATE we should have had a 
"side-effect free" mechanism for refreshing timers; some request method 
whose response cannot change media characteristics. Allowing any request 
to refresh timers should do the trick, so I'm for that one.

Anders