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

From: Linden deCarmo <[email-masked]>
Date: Thu, 1 Jun 2000 10:42:13 -0400

Yes, we've considered this, BUT, in your scenario, how does A (or in
reality, the proxy) distinguish between a conventional hold and an on-hook
hold?

The reason the distinction is important is this:

If B goes onhook during the prescribed time period, A should be billed.
If B doesn't go onhook, A should be billed up to the onhook, but not during
the "suspend" period.
If B places A on hold, A should be billed for the time on hold.

Will your proposal satisify these requirements?  If so, could you explain
how?

Thanks.

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

> -----Original Message-----
> From:	Dean Willis [SMTP:[email-masked]]
> Sent:	Wednesday, May 31, 2000 7:07 PM
> To:	Linden deCarmo
> Cc:	[email-masked]
> Subject:	Re: [SIP] Suspend a session??
> 
> 
> Have you considered building an auto-hold on switch-hook with a timer
> that initaies a BYE into your UA? My first thought is that the suggested
> behavior is a UA problem, not a proxy problem. Unless it is a flaw in
> the billing model . . .
> 
> B calls A.
> B places receiver on-hook.
> B sends reINVITE-to-HOLD to A.
> B starts timer.
> Timer expires.
> B sends BYE to A.
> 
> The only issue I see here is that B might vanish during the hold-period
> and fail to send the BYE. This is a risk with call-hold in general, and
> I believe there has been a proposal to use a configurable hold-timer in
> end devices to recover from it.
> 
> --
> Dean
> 
> Linden deCarmo wrote:
> > 
> > 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

---

From: "Glenn Morrow" <[email-masked]>
Date: Thu, 1 Jun 2000 10:38:18 -0500

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. 

> From:	Linden deCarmo [SMTP:[email-masked]]
> Sent:	Wednesday, May 31, 2000 1:54 PM
> To:	[email-masked]
> Subject:	[SIP] Suspend a session??
> 
> session needs to be suspended (not just placed on hold), and I'm not sure
> 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
> We're looking for a mechanism for party B to communicate with either party
> A

---

From: "Glenn Morrow" <[email-masked]>
Date: Thu, 1 Jun 2000 12:31:01 -0500

Perhaps we could timestamp the BYE?

> Sent:	Thursday, June 01, 2000 12:09 PM
> To:	Morrow, Glenn [RICH2:C301:EXCH]; [email-masked]
> Subject:	RE: [SIP] Suspend a session??
> 
> 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
> 
> > From:	Glenn Morrow [SMTP:[email-masked]]
> > Sent:	Thursday, June 01, 2000 11:38 AM
> > Subject:	RE: [SIP] Suspend a session??
> > 
> > determines the correct functionilty that the real end-device/user wishes
> > to achieve, it should signal proxies and far-end stations. For instance
> a
> > 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.
> > 
> > 
> > 	Right now, SIP smoothly handles one party putting another party on
> > hold via 
> > <http://lists.bell-labs.com/mailman/listinfo/sip> 
> > 
> 
>

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 5 Jun 2000 14:39:52 -0500

From earlier posts it appears that these topics are still a bit too "taboo"
for discussion on the list.  There are many ways the functionality in
question can be accomplished. Perhaps we should leave it at that?

> Sent:	Monday, June 05, 2000 1:02 PM
> To:	'Dean Willis'
> Cc:	Morrow, Glenn [RICH2:C301:EXCH]; [email-masked]
> 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
> 
> > Sent:	Sunday, June 04, 2000 2:42 AM
> > To:	Linden deCarmo
> > Cc:	'Glenn Morrow'; [email-masked]
> > 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:
> > > 
> > > Timer expires (time 30 seconds). UA realizes session expires so it
> > issues a
> > > BYE.
> > > 
> > > > It seems to me that this should be handled by the UA itself. Once
> the
> > UA
> > > > 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
> > > > physical off-hook stimulus to determine when to actually send a BYE
> or
> > > > not.
> > > >
> > > >       Right now, SIP smoothly handles one party putting another
> party
> > on
> > > > hold via
> > 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.
> 
>