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

From: "Ashhar Farhan" <[email-masked]>
Date: 11 Jun 2001 13:50:05 -0000

>I'm uncertain if there is a question here somewhere. >Perhaps you are asking whether the spec should say
>something about proxies authenticating users on
>the behalf of gateways? 
>THis is a network design issue, outside the scope of
a specification.

it is not clear that this is issue entirely within the network design. if a proxy authenticates an INVITE from a caller to a gateway, the following arise:
1. the caller does not have the password for the gateway.
2. the gateway does not have the password for the caller.
3. the caller sends the INVITE to the proxy, the proxy issues a challenge.
4. the caller resends the INVITE with an incremented C Seq and this time includes a response to generated over the INVITE message using the caller's own userid, password, nonce and the INVITE message.
5. the proxy checks that INVITE contains correct respones to its previous challenge and the proxy has to forward the INVITE to the gateway.
6. the INVITE to the gateway will be challenged and responded to by the proxy using gateway's own userid, password and message content.

This behaviour is only possible in the proxy mode and it is not possible in redirect mode where the INVITE travels directly to the gateway server. That is because, the client will not be able to generate the correct response to the gateway's challenge. It can be accomodated if there is a mechanism to return a authentication response to the client from the redirect server such that this authentication response is forwarded to the gateway server.

>Many billing systems today allow users to go to a web page to see how longthe call lasted. 
> I see no reason to include such information in SIP
messages.

while the billing accounting system will take care of many more things, it is important that the client and the server, both agree about the call duration. if the client issues a BYE but the gateway can, inspite of having dropped the call, mis-report the call time and overcharge the caller. 

this can be ascertained if BYE and ACK are both routed through the proxy to record the definite start and end times of a call. 

in a sense, i am suggesting that proxy behaviour maybe the only possible architecture for commericial deployments.

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com

_______________________________________________
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: Wai Wu <[email-masked]>
Date: Wed, 20 Jun 2001 11:23:14 -0400

-----Original Message-----
From: Jay Batson [mailto:[email-masked]]
Sent: Wednesday, June 20, 2001 10:50 AM
To: Ashhar Farhan; [email-masked]
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):

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.

[Wai Wu] Now the gateway has to implement only to process INVITEs from THAT
proxy. On a side note, the proxy has to allow caller to register just to
make internal calls. 

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