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

From: David Oliver <[email-masked]>
Date: Fri, 15 Nov 2002 12:20:36 -0600

Keith,

I believe there is no requirement that a proxy MUST perform a cleanup after
a period of time. It's just a good idea for proxies to abandon dialogs that
appear to be "dead". By abandonment I mean discarding state of a dialog
after a successfully OKed INVITE and before a BYE. Timer C handles timeouts
between INVITE and OK.

It seems that determining a dialog to be dead by a proxy in SIP is only
reasonably determined by inactivity. Changing the term "timer" to "timeout"
in the requirements should reflect this.

It is a practical requirement that User Agent changes are minimal (including
no change for common situations), to allow for interworking with existing
"hard" devices, and to recognize that the benefits primarily accrue to
proxies. In particular, a UA that does not support extended dialogs (e.g.
answering machine, pager, IM application) should be implicitly conformant.

In general, it would seem unlikely that user agent implementations are
likely to negotiate a shorter timeout. Exceptions would include mobile
devices, where lost calls are common.

Currently implemented proxies are likely to perform ad hoc abandonment of
timed out dialogs to prevent possible overload (even if this requires human
intervention, up to and including a reboot). A minimally conformant proxy
could be possibly be implemented by simply changing the parameters of an
existing timer to use the default timeout. Ignoring a UA-requested timeout
would merely keep resources allocated for slightly longer than necessary.

Although it would be possible for a proxy to specify a timeout period, this
would only be useful where many dialogs "die", and would only work where at
least one UA is fully conformant. I am not certain if this has much utility.

Based on these musings, these look like possible requirements:

1)  A stateful proxy MUST NOT abandon a dialog until a timeout period has
elapsed since the last observed SIP activity. A proxy MAY abandon any dialog
after the timeout period.
2)  The default timeout period MUST be such that non-conformant UAs are
rarely affected.
3)  A UA shall be implicitly conformant if its dialogs terminate normally in
less than the default timeout period.
3)  Either (or both) the UAC or UAS MAY request a changed timeout period.
Any requesting UA is responsible for ensuring the dialog is refreshed at its
requested period.

Best Regards,

David C. Oliver
SecureLogix Inc.
+1 210 402 9669
[email-masked]

-----Original Message-----
From: Drage, Keith (Keith) [mailto:[email-masked]]
Sent: Wednesday, November 13, 2002 7:01 PM
To: Jonathan Rosenberg; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip] The fate of session timer?

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] 

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Sun, 17 Nov 2002 20:52:06 +0200

Jonathan,

I have just noticed that a method PING has been added to RTSP to test
the aliveness of the other end point. It may be good to align our
session timer with that work...

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 17 Nov 2002 22:57:38 +0200

Hi,

After reading all the messages (and having written half of them
myself...) I would say we should split the whole discussion into four
different parts:

1. What is the functional purpose of the session-timer?

Can we agree that we only use if for cleaning of call state, or does
someone still want to use if for state recover, "heartbeat",
charing,....?

2. What method do we use for the re-fresh?

re-INVITE, UPDATE, PING, INFO, insert-your-favorite-SIP-method, etc...

My personal opinion is that the refresh should not be treated as an
offer/answer transaction, assuming the functional requirement doesn't
require it.

3. How do the nodes do the timer negoatiation?

This is was most of my mails on the issue have been about...

I have presented my concerns about the current mechanism, and presented
an alternative. I know, however, that it has been discussed before, so I
am aware there may be issues I haven't thought about.

4. What are different nodes supposed to do if they don't receive
refreshes?

Cleaning up call state, send BYE, etc etc...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Nov 2002 02:38:48 -0500

Ah, yet another case of deviation between RTSP and SIP, all for no 
reason. Grr.

So, are you saying you propose that we adopt a new PING method for doing 
this in SIP?

-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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 18 Nov 2002 14:51:35 +0200

Jonathan,

> Ah, yet another case of deviation between RTSP and SIP, all for no

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

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-rfc2326bis-02.txt

Thanks,

Gonzalo