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

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

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

---

From: Dave Walker <[email-masked]>
Date: Thu, 01 Jun 2000 15:45:26 -0400

I think that the solution was pointed out earlier in this thread.
The problem seems to be that you want to charge for the existence of
a signalling connection.  

If billing was based on packets, you would simply put the remote UA 
on hold.  You want to put the remote UA on hold anyway because that 
may lessen the chances of additional billing.  

I feel what you want to do is to issue a re-INVITE to go on hold, 
then somehow issue some "STOP BILLING" request to entities in the 
signalling path that may be accumulating billing data.  That kind of 
request would be subject to abuse of course.

But couldn't that billing entity simply look at the successful hold
to decide to suspend billing (or bill at some reduced rate)?  The 
next signalling that would normally come through is a BYE or another
INVITE which stops or will resume normal billing.

Then I'll argue that if your UA is getting excessively charged for
sessions that are on hold (i.e. generating zero media), then it's
time to find a new service provider.

Regards,

Dave Walker
SS8 Networks
Ottawa, Canada

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 02 Jun 2000 01:33:08 -0400

> The problem seems to be that you want to charge for the existence of

Actually, the problem is that you are trying to bill for services you
are not actually providing. Unless there is either transport level
services, or gateway services, billing anything by the minute is going
to be a tough proposition. Providing a mechanism that allows the user to
stop billing actually makes the job of getting around billing really
easy.

Now, if you were providing QoS, I would argue that "hold" would not also
be accompanied by a release of QoS resources, where perhaps "suspend"
would. In this case, releasing of QoS resources would signal to stop
billing by the minute. But, thats all within the transport
infrastructure, not SIP.

> request would be subject to abuse of course.

Exactly.

> to decide to suspend billing (or bill at some reduced rate)? 

Not really; this is also subject to abuse. I'll just put you on hold
within SIP, but both near and far end have "updated" SIP terminals which
actually ignore the hold message anyway, and continue to send media.
Free phone calls. Cool.

-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

---

From: Dean Willis <[email-masked]>
Date: Sun, 04 Jun 2000 01:41:32 -0500

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 04 Jun 2000 23:06:23 -0400

> "billing proxy" could use to determine an appropriate action.

May as well use a new method, and call it FREECALL ;)

Seriously, though, developing extensions with known monstorously large
security holes doesn't help anyone. If a new method were defined, people
will think that it is generally useful and apply it in cases where a
trust relationship between the UA and proxy does not exist. Counting on
friednly UAs is like counting on people not to send spam or generate
viruses....

-Jonathan R.