Subject: Re: Re: [SIP] Authentication and billing through proxy/re-direct server

From: "Ashhar Farhan" <[email-masked]>
Date: 20 Jun 2001 03:29:31 -0000

jb wrote -

>>There is another possibility that "real commercial systems" might use (in fact, are likely to use...):
>>
>>- Charge only for PSTN gateway transit.
>>- Sessions that stay on the IP net (only) are built into a base bandwidth/connectivity fee.

>>In this case, CDRs generated by the gateway will provide sufficient information about PSTN connectivity to create billing info, wouldn't they?  Neither the proxy nor the originating (IP-network-resident) UA need 
to know / do anything....

I completely agree that it is PSTN transit that will be charged in for the next couple of years. the issue is who will authenticate CDRs generated by a gateway? if we are talking of a network of PSTN gateways and a central settlement system, we need a way of acknowledging the call timings and QoS at both ends to bill the call.
for instance:
1) how does a gateway know whether the caller is credit worthy? if we require a separate TLS style connection to the proxy for billing purpose, it is actually simpler to just make the proxy hold the state information and pass setup and cleardown messages over the same pipe.

2)we do not require TLS pipe between the UA and the proxy to authenticate itself. i dont see why we should require a TLS session between the gateway and the proxy to authenticate the incoming callers.

i am problematizing the issue of third party authentication for callers. this is a commercial issue with calling card vendors, meta-network operators (like itxc), or resellers (like yahoo, msn, icq resold net2phone).

- [email-masked]

_____________________________________________________
Buy Lagaan & Yaadein music for 30% less.
Avail this special offer at http://shopping.rediff.com/shopping/music/offerrediffmailer.htm 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 19 Jun 2001 21:37:52 -0700

> i am problematizing the issue of third party authentication for callers. this is a commercial issue with calling card vendors, meta-network operators (like itxc), or resellers (like yahoo, msn, icq…

I suppose I may be missing something obvious here, but this is exactly what the AAA
WG has been working on solving for quite some time now.

PatC

---

From: Jay Batson <[email-masked]>
Date: Wed, 20 Jun 2001 10:50:07 -0400

I'm not as technically deep as others in this, but here's a response.... 
(routed back through the "new" mailing list at IETF for SIP):

At 11:29 PM 6/19/01, Ashhar Farhan wrote:
>1) how does a gateway know whether the caller is credit worthy? if we 
>require a separate TLS style connection to the proxy for billing purpose, 
>it is actually simpler to just make the proxy hold the state information 
>and pass setup and cleardown messages over the same pipe.
>
>2)we do not require TLS pipe between the UA and the proxy to authenticate 
>itself. i dont see why we should require a TLS session between the gateway 
>and the proxy to authenticate the incoming callers.

The gateway doesn't want to know, the proxy should.  Via network design 
(vs. protocol design) you can make the gateway only accept INVITEs from an 
authenticated Proxy.  The proxy doesn't need to maintain state to 
authenticate if the caller is credit worthy on a session-by-session basis 
-- it can simply deny a registration to any UA it doesn't want to serve 
(e.g. a customer that isn't credit worthy.)  No registration, no INVITE 
gets through to the gateway.  TLS is irrelevant.

-------------
PingMe!
Jay Batson
CEO
Pingtel Corp.
mailto:[email-masked]
781-938-5306 (office)

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 21 Jun 2001 13:38:50 -0500

Actually, we can go one step further and eliminate the requirement for registration.

A proxy fronting a gateway could conceivably check the credit on a per-INVITE basis. Auethnticated INVITES with adequate credit would be passed to the gateway for call completion. This is transaction stateful in the proxy(not CALL stateful), but this isn't a particularly bad thing -- the proxy is going to want to be transaction stateful so that it can feed back a provisional response and slow down the retransmit timers anyhow.

Despitewhat the mobile phone people think, reception of a SIP REGISTER message by a proxy is NOT a requirement to be able to process INVITES. You MAY have to REGISTER to receive a call -- you SHOULD NOT have to register to make a call.

Now, of one were to implement call metering in the gateway, one could go so far as to send a gateway-specific header indicating the available credit. It's more common to front-end a prepaid gateway with a B2BUA prepaid app, which is easy to build on an app server. That may be the only legitimate use of a signaling-only back-to-back user agent. 

--
Dean

--
Dean
  ----- Original Message ----- 
  From: Jay Batson 
  To: Ashhar Farhan ; [email-masked] 
  Sent: Wednesday, June 20, 2001 9:50 AM
  Subject: Re: Re: [SIP] Authentication and billing through proxy/re-direct server

  I'm not as technically deep as others in this, but here's a response.... (routed back through the "new" mailing list at IETF for SIP):

  The gateway doesn't want to know, the proxy should.  Via network design (vs. protocol design) you can make the gateway only accept INVITEs from an authenticated Proxy.  The proxy doesn't need to maintain state to authenticate if the caller is credit worthy on a session-by-session basis -- it can simply deny a registration to any UA it doesn't want to serve (e.g. a customer that isn't credit worthy.)  No registration, no INVITE gets through to the gateway.  TLS is irrelevant.

  -------------
  PingMe!
  Jay Batson
  CEO
  Pingtel Corp.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 21 Jun 2001 15:15:08 -0400

At 01:38 PM 6/21/2001 -0500, Dean Willis wrote:
>A proxy fronting a gateway could conceivably check the credit on a 
>per-INVITE basis. Auethnticated INVITES with adequate credit would be 
>passed to the gateway for call completion. This is transaction stateful in 
>the proxy(not CALL stateful), but this isn't a particularly bad thing -- 
>the proxy is going to want to be transaction stateful so that it can feed 
>back a provisional response and slow down the retransmit timers anyhow.
>
>Despitewhat the mobile phone people think, reception of a SIP REGISTER 
>message by a proxy is NOT a requirement to be able to process INVITES. You 
>MAY have to REGISTER to receive a call -- you SHOULD NOT have to register 
>to make a call.

So long as you are willing to provide your radio network for free, that's 
fine.  But I would bet that most operators that paid millions to get 
airwave licenses would like to recoup their costs at a minimum.  You must 
be sure that you can settle with the home network in order to get 
paid.  Mobile operators see the location aspects of register also 
intertwined with the authorization/billing aspects.

Mike

>
>Now, of one were to implement call metering in the gateway, one could go 
>so far as to send a gateway-specific header indicating the available 
>credit. It's more common to front-end a prepaid gateway with a B2BUA 
>prepaid app, which is easy to build on an app server. That may be the only 
>legitimate use of a signaling-only back-to-back user agent.
>
>--
>Dean
>
>--
>Dean
>From: <mailto:[email-masked]>Jay Batson
>To: <mailto:[email-masked]>Ashhar Farhan ; 
><mailto:[email-masked]>[email-masked]
>>itself. i dont see why we should require a TLS session between the 
>>gateway and the proxy to authenticate the incoming callers.

_______________________________________________
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