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

From: "Ashhar Farhan" <[email-masked]>
Date: 4 Jun 2001 07:28:07 -0000

in a typical next gen telco setup, the billing is centralised and their Point of presence are basically SIP servers that gateway to PSTN cloud.

the INVITE gets redirected/proxied from the central server and the is resend to the gateway (a sip server).
here, we have an issue of user authentication. the user has to be authenticated by the redirect/proxy server. the authentication (as per the SIP recommendations) should be md5 digest. 
the scheme would be that the redirect/proxy should generate a digest over the redirected INVITE request using the nonce and password of the intended server.

billing systems are usually needed to be centralised (esp. in those next gen telcos where the servers are operated by franchises). this is a commercial requirement of SIP operations.

the 2543.bis does not explicitly talk of the redirect/proxies authenticating requests for the gateways.

the second issue:
the call minutes are the accepted billing mechanism for atleast the next couple of years. to support billing, accurate times of call start and end are important.
the call times maybe at variance between the client and the server due to a the RTT nature of messaging itself. In that case, it will be advisable, from a caller perspective to know when exactly did the call get disconnected (a second's delay can roll the call over to the next minute) and how long did the call last - as per server's record. Although MESSAGE can be used for this, i would rather believe that a more intrinsic method must be available to support this that can update the caller's own 'call meter'.

- [email-masked]

_____________________________________________________
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: Jay Batson <[email-masked]>
Date: Tue, 19 Jun 2001 17:59:06 -0400

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....

-jb

At 03:28 AM 6/4/01, Ashhar Farhan wrote:
>in a typical next gen telco setup, the billing is centralised and their 
>Point of presence are basically SIP servers that gateway to PSTN cloud.
>
>here, we have an issue of user authentication. the user has to be 
>authenticated by the redirect/proxy server. the authentication (as per the 
>SIP recommendations) should be md5 digest.
>the scheme would be that the redirect/proxy should generate a digest over 
>the redirected INVITE request using the nonce and password of the intended 
>server.
>
>billing systems are usually needed to be centralised (esp. in those next 
>gen telcos where the servers are operated by franchises). this is a 
>commercial requirement of SIP operations.
>
>the 2543.bis does not explicitly talk of the redirect/proxies 
>authenticating requests for the gateways.
>
>the second issue:
>the call minutes are the accepted billing mechanism for atleast the next 
>couple of years. to support billing, accurate times of call start and end 
>are important.
>the call times maybe at variance between the client and the server due to 
>a the RTT nature of messaging itself. In that case, it will be advisable, 
>from a caller perspective to know when exactly did the call get 
>disconnected (a second's delay can roll the call over to the next minute) 
>and how long did the call last - as per server's record. Although MESSAGE 
>can be used for this, i would rather believe that a more intrinsic method 
>must be available to support this that can update the caller's own 'call 
>meter'.
>
>- [email-masked]
>
>
>

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