Subject: RE: [Sip] Some thoughts about sip-reconstitute-state and session timers.

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Thu, 7 Feb 2002 22:03:18 -0800

Hi:

Thanks for the reply! In response to item 2, consider the following:

A B2B UA (or a 3pcc kind of application that is enabling click to call
services). Or an example would be say a calling card type service. User
calls in. He/she is prompted for his PIN and card id. Once authenticated,
he/she is requested to dial the number that needs to be contacted. The IVR
app places a new call, and bridges the two. It now waits for hang up from
one side and then prompts user to dial next number or terminates both calls
if his/her calling card is exhausted. In this scenario, the B2B UA is really
assisting in setting up a dialog between 2 end points. Once the dialog is
established, the application is not in the media path. It sends out peridic
reINVITES to keep both these call legs active/detect any far end crashes. A
BYE from one side triggers a disconnect to the other. 

The thought I had in mind is to allow calls set up by applications such as
this to reconstitute states and provide a mechanism for such applications to
recover from crashes, implementing session timers would terminate these
calls although from an end user perspective neither of their phones never
really crashed? 

Venkatesh

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 9:30 PM
To: Venkatesh Venkataramanan
Cc: [email-masked]'
Subject: Re: [Sip] Some thoughts about sip-reconstitute-state and
session timers.

Venkatesh Venkataramanan wrote:

> I was wondering if we could enhance sip-session-timer-08.txt to make the
> UA
> that is waiting for 'session refreshes' to send a re-INVITE before it
> tears
> the call down by sending a BYE on session-timer expiry (rather a few
> seconds
> before the expiry). This would assist such applications to reconstitute
> state of sessions as well if they persist exactly the same information
> that
> is indicated in the sip-reconstitute-state draft and keep such dialogs
> active.

Well, I don't see anything wrong with doing that per se, but there are
two issues:

1. session-timer has already gone to IESG, so it is a bit late for
addition of features to the draft,

2. Its not clear to me what the scope of applicability of this would be.
Specifically, the amount of time it takes to discover failures with
session timer is really, really long. More than likely if you
application crashed for 20m before that was reconstitiuted by session
timer, its been gone too long to be useful. Session timer is really
meant as a state cleanup mechanism, i.e., a long term garbage collector,
not for failure recovery. The ICMP approach in the reconstitute draft is
very rapid because it uses the media stream.

-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