Subject: RE: [SIP] Suspend a session??

From: Linden deCarmo <[email-masked]>
Date: Mon, 5 Jun 2000 14:01:33 -0400

Ok, you've forced to to evaluate what I'm really requesting.  If you throw
out my billing/on hook/off hook application, and examine the root
functionality I'd like to see added, it boils down to extended transactional
roll backs.

Basically, for certain methods, it would be convenient if the requesting
entity could request the amount of time a CANCEL could roll back the
transaction.  The recipient of the request would determine if it supported
extended roll backs for the method in question.

If it supported these extended roll backs, it would send a provisional
(18x-type) response to acknowlege the receipt of the request.  After the
specified time period passed, a final response (2xx) could be issued.
Should a CANCEL be received during this intermediate time period, the
request would be cancelled.

If the UA didn't support extended roll backs, it could immediately return a
final response (2xx) so the solution is completely optional and backwards
compatible.

If you apply this solution to my scenario, here's how it would map out:

UA A calls UA B.
B goes on hook. UA B issues BYE (with rollback: 30 seconds) to UA A.
UA A sends provisional response 18x to UA B.
B goes off hook within 30 seconds.  UA B sends CANCEL to UA A and session
continues.

scenario two:

UA A calls UA B.
B goes on hook. UA B issues BYE (with rollback: 30 seconds) to UA A.
UA A sends provisional response 18x to UA B.
B remains on hook for 30 seconds.  UA A sends final 200 OK response to BYE
and session terminates.

I don't think this solution is useful (or relevant) for an INVITE, but I
believe there are applications for it with OPTIONS, INFO, and BYE.

Linden deCarmo
Netspeak Corporation
902 Clint Moore Road
Suite 104
Boca Raton, FL 33487

> -----Original Message-----
> From:	Dean Willis [SMTP:[email-masked]]
> Sent:	Sunday, June 04, 2000 2:42 AM
> To:	Linden deCarmo
> Cc:	'Glenn Morrow'; [email-masked]
> Subject:	Re: [SIP] Suspend a session??
> 
> 
> I suspect I don't like what you're attempting to achieve, but methinks
> the friendly UA could always submit an appropriate INFO method which the
> "billing proxy" could use to determine an appropriate action.
> 
> AS has been pointed out here, it is that UA that is responsible for
> translating user action into appropriate signaling.
> 
> One might also ask WHY and end device would choose to use a "time
> billing proxy" rather than routing around said proxy. There are probably
> some cases involving proxy-moderated firewalls and QoS sessions, but I
> still suspect the fundamental approach is somehow flawed.
> 
> --
> Dean
> 
> Linden deCarmo wrote:
> > 
> > Here's the problem with the UA doing it:
> > 
> > User goes on hook (time 0 ).  UA starts timer.
> > Timer expires (time 30 seconds). UA realizes session expires so it
> issues a
> > BYE.
> > 
> > Since the proxy sees the BYE 30 seconds later, thats when it stops
> billing.
> > I do not believe your solution addresses how the UA signals to the proxy
> > that billing should stop at time 0 rather than time 30.
> > 
> > I realize I can do this with a proprietary method or header, but I'd
> rather
> > not.
> > 
> > Linden deCarmo
> > Netspeak Corporation
> > 902 Clint Moore Road
> > Suite 104
> > Boca Raton, FL 33487
> > 
> > > -----Original Message-----
> > > From: Glenn Morrow [SMTP:[email-masked]]
> > > Sent: Thursday, June 01, 2000 11:38 AM
> > > To:   [email-masked]
> > > Subject:      RE: [SIP] Suspend a session??
> > >
> > > It seems to me that this should be handled by the UA itself. Once the
> UA
> > > determines the correct functionilty that the real end-device/user
> wishes
> > > to achieve, it should signal proxies and far-end stations. For
> instance a
> > > legacy device may which to indicate flash and collect more digits for
> a
> > > 3-way call by the user using the hook as you say.
> > >
> > > This would result in a separate transaction but I believe it doesn't
> > > require something like a  "suspend" method or indication at the SIP
> level.
> > >
> > >
> > > I suggest that the UA itself should handle this with timers, etc..
> based
> > > upon the physical device and human interface it is trying to achieve.
> > >
> > > For the billing issue the UA could simply use a timer started based on
> > > physical off-hook stimulus to determine when to actually send a BYE or
> > > not.
> > >
> > > If this doesn't address your concerns please let me know.
> > >
> > >       -----Original Message-----
> > > From:   Linden deCarmo [SMTP:[email-masked]]
> > > Sent:   Wednesday, May 31, 2000 1:54 PM
> > > To:     [email-masked]
> > > Subject:        [SIP] Suspend a session??
> > >
> > >       Right now, SIP smoothly handles one party putting another party
> on
> > > hold via
> > > a re-INVITE with modified SDP.  However, we have a scenario where the
> > > session needs to be suspended (not just placed on hold), and I'm not
> sure
> > > how this can be done without using proprietary headers.
> > >
> > >       Here are ther details.  If party A calls party B , party B
> should be
> > > able to
> > > hang up without immediately terminating the session.  If party B picks
> up
> > > the phone within some prescribed time window, the session continues.
> > > However, if they don't pick it up within the time window, the session
> > > terminates (via a BYE).
> > >
> > >       We're looking for a mechanism for party B to communicate with
> either
> > > party A
> > > or a proxy server, to inform the distant party that the session has
> been
> > > suspended, and not just placed on hold.  The primary motivator for
> this
> > > notification is billing.  Without notification of suspension, its
> > > impossible
> > > to determine when to safely stop billing.
> > >
> > >       Thanks.
> > >
> > >       Linden deCarmo
> > > Netspeak Corporation
> > > 902 Clint Moore Road
> > > Suite 104
> > > Boca Raton, FL 33487
> > >
> > >
> > >
> > >       _______________________________________________
> > > SIP mailing list
> > > [email-masked]
> > > <http://lists.bell-labs.com/mailman/listinfo/sip>
> > >
> > 
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> Privacy and Confidentiality Notice 
> The information contained in this transmission is intended for the
> above-named 
> recipient(s) only and contains privileged and confidential information.
> If the 
> reader of this message is not an intended recipient, you are strictly
> prohibited 
> from using, copying, distributing, or taking any action in reliance on
> such 
> information. If you have received this communication in error, please
> notify us 
> immediately.

Privacy and Confidentiality Notice 
The information contained in this transmission is intended for the above-named 
recipient(s) only and contains privileged and confidential information.   If the 
reader of this message is not an intended recipient, you are strictly prohibited 
from using, copying, distributing, or taking any action in reliance on such 
information. If you have received this communication in error, please notify us 
immediately.

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 05 Jun 2000 17:21:06 -0400

With the more general formulation, I immediately have the question -
why? If the application is not for this billing thing, what is this
useful for? I don't see why the originating UA could not simply wait the
required time and then issue the request.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com