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

From: "Arnoud van Wijk (ELN)" <[email-masked]>
Date: Fri, 22 Jun 2001 10:10:19 +0200

Yup. And that is now exactly my problem with Charging and Billing.
The signalling and the bearer traverse different nodes/servers and pathways. So, SIP is currently unreliable to obtain exact call duration.

But if some people get a great idea how to solve this problem and it requires a new SIP header. Will those people get Lynched? :-)

Just my 2 cents

Greetz

Arnoud

_______________________________________________________________
ERICSSON EUROLABS NETHERLANDS BV
Arnoud van Wijk
Innovation Unit
Research & Development (ELN/V)
Fax: +31-161 247569
_______________________________________________________________

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: donderdag 21 jun 2001 18:51
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
[email-masked]
http://www.ietf.org/mailman/listinfo/sip

_______________________________________________
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 10:24:37 -0700 (PDT)

Arnoud van Wijk (ELN) writes:
 > The signalling and the bearer traverse different nodes/servers and
>  pathways. So, SIP is currently unreliable to obtain exact call
> duration.

  This isn't a SIP problem, per se; it's an inherent information
  problem where a potentially untrusted device(s) is the only
  thing in possession of the necessary information for which it
  has high incentive to withhold/lie. The reason that this doesn't
  come up in the PSTN is because the things beyond the trust 
  boundary of the provider aren't the sole keepers of that
  information. 

 > But if some people get a great idea how to solve this problem and it requires a new SIP header. Will those people get Lynched? :-)

   If such a thing were possible, it might be entertained. I've
   yet to see any proposal that doesn't have a fatal flaw.

	  Mike