Subject: RE: [SIP] Authentication and billing through proxy/re-direct ser ver

From: David Schwartz <[email-masked]>
Date: Tue, 26 Jun 2001 16:35:40 +0300

Hi Jonathan.

I think all would agree that the ideal place for call control is in the
Voice Gateway. It is already stateful and it is the only element as you said
that has a true picture of which calls are connected and which are not. The
problem faced too often, however, is that a particular company doesn't want
to terminate traffic yet they want to bill for the service. Another scenario
might be if a call passes through more than one network before termination.
In that case each network owner might want to charge for use of his/her
network. There must a mechanism within these networks to detect call
completion.

With that said, I think your point about synchronization is a good one and I
can think of a few ways to solve it. 

The best way I believe would be for the call controller to SUBSCRIBE to the
gateway for a BYE event notification. In this way, the call controller would
not terminate any traffic when receiving a BYE but rather when receiving a
NOTIFY with the BYE event specified. All information necessary for the
Account Stop would then be contained in the body of the NOTIFY message. I
prefer this method since it allows the call controller to remains
essentially stateless. The problem is that at last count most GW
manufacturers have yet to fully implement SUBSCRIBE/NOTIFY on their
gateways.

An alternate approach might be to have the call controller set a session
timer between it and the gateway. The time interval can be as much as a
minute since most companies charge on a per minute basis. In this scenario
if indeed the Max-Forwards was set to end at the call controller, the call
controller would close the session thereby ceasing to send the re-INVITE
with the updated session time so the voice gateway would defacto close the
session. The reason I like this event less is because it forces the call
controller to be call stateful.

There are a few other mechanisms I can think of but I think these two will
suffice.

David Schwartz

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Thu, June 21, 2001 6:51 PM
To: David Schwartz; 'Jiri Kuthan'; 'Rosen, Brian'; 'Jay Batson'; 'Ashhar
Farhan'; [email-masked]'
Subject: RE: [SIP] Authentication and billing through proxy/re-direct
ser v er

> -----Original Message-----
> From: David Schwartz [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 9:30 AM
> To: 'Jiri Kuthan'; 'Rosen, Brian'; 'Jay Batson'; 'Ashhar Farhan';
> [email-masked]'
> Subject: RE: [SIP] Authentication and billing through proxy/re-direct
> ser v er
> 
> Here to it is important to look at the pros and cons in doing 
> this in an
> internal proxy Vs. using the gateway. The big con in using 
> the proxy is that
> it causes another statefull element in the network and since 
> the VG must be
> statefull anyway why have another statefull element. In 
> addition when it
> comes to the call stop (CDR creation) there is some 
> information that might
> be needed about the user (e.g. internal username) that may 
> only be available
> from the call start response. So the typical solution is to 
> use the VG. The
> con with using the VG is that you must own the VG. If you 
> wish to terminate
> on someone elses network it can be tricky retrieving the CDR's. 
> 
> One possible stateless solution might be to use the proxy for 
> call start and
> call stop. The Record-Route header is used to ensure that the 
> proxy sees the
> BYE message. Any proxy that gets an invite generates a call start (on
> receiving the 200 OK) which writes to some file that a 
> particular callID has
> started a call at this particular time, and any proxy getting a BYE
> generates a call stop which writes to a file (potentialy on a 
> different
> machine) that a particular callID has stopped a call at a 
> different time.
> There is no state that needs to be saved. Instead, a different process
> constantly moniters these files and correlates the call 
> starts with the call
> stops. This seperate process is the one that generates the 
> CDR's. This also
> reduces the load on the VG's enabling them to focus on the 
> call setup and
> teardown.

Using a proxy to generate minutes of usage is very hard. Ultimately, the
gateway knows the call call duration, as it is the arbiter of whether the
call is still in progress with the PSTN. For proxy-based duration to work,
you need to be able to prove that the proxy is always in continuous
synchronization (in terms of call state) with the gateway, within a
reasonable time lag. So, can you prove that an attacker cannot force the
proxy and gateway to go out of sync? I know of several attacks that are
possible in order to convince the proxy that the call is down, but the
gateway that the call is up (Max-Forwards values which cause the BYE to pass
the proxy but fail at the gateway, for example). This results in free
service. Someone more creative than I might come up with a few more.

-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

_______________________________________________
Sip mailing list  http://www.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: Michael Thomas <[email-masked]>
Date: Tue, 26 Jun 2001 09:04:28 -0700 (PDT)

David Schwartz writes:
 > to terminate traffic yet they want to bill for the service.

   There are lots of things people want; I'll note that not
   only did I not get a California lottery ticket, I also
   didn't win the $141M.

   The real question here is whether you can trust the gateway
   or not, regardless of who operates it. This is mainly a
   business question. If the risk is tolerable, than generating
   CDR's on that UA, sending NOTIFY's, etc, etc, are all fine
   ways of generating accounting records. If they aren't, then,
   well, I didn't win the lottery either.

>  Another scenario

   If you're trying to account for RTP traffic,
   then what you want is RSVP/COPS, not SIP.

	     Mike