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

From: "Gross, Gerhard" <[email-masked]>
Date: Mon, 4 Jun 2001 07:36:58 -0700

Farhan,

Your second issue can be addressed by having the SIP
proxy server communicate with a AAA/policy server.
An overview and msg interaction is discussed in:

http://www.ietf.org/internet-drafts/draft-gross-cops-sip-01.txt
http://www.ietf.org/internet-drafts/draft-gross-sipaq-01.txt

Note that this model allows for selective billing of
appropriate services. For example, part of the
session may proceed using best effort transmission and
another part may proceed using high priority (RSVP, diffserv).
The AAA/policy svr is a PDP (or communicates with a PDP)
for the network nodes providing high priority forwarding
and therefore has knowledge of BW reserved, seconds
the service was provided, etc.

Gery

> -----Original Message-----
> From: Ashhar Farhan [mailto:[email-masked]]
> Sent: Monday, June 04, 2001 12:28 AM
> To: [email-masked]
> Subject: [SIP] Authentication and billing through 
> proxy/re-direct server
> 
> 
> 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.
> 

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Jun 2001 02:03:20 -0400

> Sent: Monday, June 04, 2001 3:28 AM

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.

> update the caller's own 'call meter'.

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

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Jun 2001 17:04:16 -0400

> Sent: Monday, June 11, 2001 9:50 AM
> Subject: RE: [SIP] Authentication and billing through proxy/re-direct
> server
> 
> 
> 
> >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.

The last step is where you have gone wrong. What you are interested in, I
think, is a system where the user has credentials for service at a proxy.
That proxy sits as the entry point to the domain. Once the user has
authenticated itself to the proxy, it should be able to also connect to a
gateway (or some other element), within the domain, but only if it
successfully authenticated itself to the proxy.

Doing that is easy. Its a matter of transitive trust. The user authenticates
itself to the proxy. The proxy maintaints persistent TLS connections to the
gateways or other servers within the domain. The proxy only allows
authenticated requests in, and the gateway only accepts requests over the
TLS connection with the proxy. The proxy and gateway both have policies that
only accept TLS connections from entities that authenticate themselves with
a specific name. 

In this way, you only bother with the user authentication once, and then the
rest is based on secure associations.

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

Well, you wouldn't use a redirect server in this network, then. Thats why I
am saying its a matter of network design.

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

It can do that no matter what. Even if there exists a way to report call
times in SIP messages, this says nothing about what the user might get
charged for.

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

Recording call start and stop times through a proxy has its challenges.
There are many fraud and failure cases where it doesn't work particularly
well. But, thats a separate issue.

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

All the commercial deployments I am aware of have quite a few proxies, for
many reasons, of which billing is just one.

-Jonathan R.
---

---

From: Wai Wu <[email-masked]>
Date: Wed, 20 Jun 2001 10:54:59 -0400

This is how I would like it. Either the BYE or the ACK for the BYE will
contain a Total-Charge header, and each proxy will add up the amount from
the proxy next in the chain, the final charge will end up to the calling
UAC. This might not work if you are billing by bandwidth used since RTP
parket losts either can or cannot be billed within a network.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, June 20, 2001 6:02 AM
To: 'Jay Batson'; Ashhar Farhan; [email-masked]
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
er

Just for grins, what would you expect the charging to look like when the
terminating end is on a different network from the originating end, but they
were both sipphones?  Suppose there were three networks (a transit network
as well as the originating and terminating networks)?  Suppose there was
an enterprise network (no internal charging) connected to a public (IP)
network
that charged by the minute?
 
I don't want to start a debate on billing possibilities.  I do think that
you have to
accept that CDRs may have to be generated at a few places in the network.
I myself am not wild about UAs doing CDR generation.  I think proxy servers 
can do that.  The piece of information the PS doesn't have is the exact
connection
time information.  We may want to be able to get that sent on a BYE.  
 
Suppose you just thought of this stuff as statistics.  There are several
interesting
statistics you may wish to gather on a call (lost packets for example).
Sure,
you could make this a management function, but you are then faced with
storage
and other issues associated with a very large number of endpoints.  If you
could
report statistics on a BYE, the PS could then generate the CDR.
 
This may also help a problem we are currently calling "session management".
There
is some work at the Softswitch Consortium on this.  It deals with the
following
practical problem - your customer service center gets the following call "I
was
just talking to my mother and I couldn't hear her".  Okay, what equipment
was used
on that call, and where did it go wrong?  To make that really work EVERY
device
that participates in some way on the call needs to report information on the
call,
and it has to do so proactively.  This is equivalent to a CDR with more
information
(statistics).  Yes, we could get UAs to generate them, but we could also
just pass
up the info on BYE and let the PS save it, massage it, and send it on it's
way.
 
Brian

-----Original Message-----
From: Jay Batson [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 5:59 PM
To: Ashhar Farhan; [email-masked]
Subject: Re: [SIP] Authentication and billing through proxy/re-direct server

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.

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 <http://bol.rediff.com/> 

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

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 20 Jun 2001 11:07:31 -0500

On the other hand, it may make a lot of sense for UAs to generate CDRs if it
is a gateway (especially if it is a gateway to an expensive PSTN where you
need to track charges accurately which I don't think will be possible if it
is based on SIP signalling).

It seems to me that they'd be network level CDRs using proxy servers, and
"local" ones that can be useful when somebody has figured our how to abuse
the system, or to calculate "real" charges from the PSTN.

> From:	Rosen, Brian [SMTP:[email-masked]]
> Sent:	Wednesday, June 20, 2001 06:02
> serv er
> This may also help a problem we are currently calling "session
> management".  There
> practical problem - your customer service center gets the following call
> "I was
> that participates in some way on the call needs to report information on
> the call,
> 	There is another possibility that "real commercial systems" might
> use (in fact, are likely to use...):
> 	
> Neither the proxy nor the originating (IP-network-resident) UA need to
> know / do anything....
> 	
> 	-jb
> 	
> 		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.
> 		
> 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:
> atleast the next couple of years. to support billing, accurate times of
> call start and end are important.
> 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]
> 		
> 		
> 		
> 		<http://bol.rediff.com/>
> 	<mailto:[email-masked]>
> 	781-938-5306 (office)
> 	
> 	
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 20 Jun 2001 12:29:43 -0400

<moved to [email-masked]>
Don't have a problem with UAs generating CDRs, and gateways are one place
where you might want to do that.  That would be a device implementation 
decision, and would not subject to standardization.  If we wanted to have a
UA 
send statistics somewhere, that would have protocol implications.
 
Brian

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Wednesday, June 20, 2001 12:08 PM
To: [email-masked]'
Cc: 'Rosen, Brian'
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
er

	-----Original Message----- 
From:   Rosen, Brian [SMTP:[email-masked]] 
Sent:   Wednesday, June 20, 2001 06:02 
To:     'Jay Batson'; Ashhar Farhan; [email-masked] 
Subject:        RE: [SIP] Authentication and billing through proxy/re-direct
serv er 

	Just for grins, what would you expect the charging to look like when
the 
terminating end is on a different network from the originating end, but they

  

Brian 

	-----Original Message-----
From: Jay Batson [ mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Tuesday, June 19, 2001 5:59 PM
To: Ashhar Farhan; [email-masked]
Subject: Re: [SIP] Authentication and billing through proxy/re-direct server

-jb

	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 second issue:

- [email-masked]

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

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

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 20 Jun 2001 13:03:04 -0400

Agreed.

> Sent:	Wednesday, June 20, 2001 09:30
> To:	Audet, Francois [SC2:4K02:EXCH]; [email-masked]'
> Cc:	Rosen, Brian
> decision, and would not subject to standardization.  If we wanted to have
> a UA

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 20 Jun 2001 20:33:02 +0200

At 03:01 PM 6/20/2001, Rosen, Brian wrote:
[...]
>can do that.  The piece of information the PS doesn't have is the exact connection
>time information.  

My opinion on network configuration is that CDR/AAA functionality 
is best hooked to the same place where the particular AAA-fizied 
service is actually provided. 

If we speak about PSTN call termination service, I think gateways 
would be a better place to hook AAA than proxies. A particular advantage 
of gateways (i.e., UAs from SIP perspective) doing the AAA job is it 
works even if subsequent SIP requests take a different path and do not
hit the same proxy. It sounds better to me than attempts to force 
routes by RR or B2B.

If transport services were hooked to AAA systems somehow (e.g., premium 
PSTN termination service incl. RSVP), it would be probably also easier 
to do the AAA job in gateways rather than in SIP proxies.

Note that having gateways done the AAA job from SIP perspective does not 
necessarily imply that the entire AAA functionality resides in gateways. 
More likely, it would be outsourced to a AAA server.

Jiri

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 20 Jun 2001 17:13:33 -0400

<moved to [email-masked]>

I don't want to cast this in terms of billing == too narrow.
I want to be able to get information about a call out of
all of the devices in a call, including the proxies and the
UAs, and that includes the gateways.  The information I want to
get is statistics about the call.

I CAN do this with another interface; Radius for example, or SNMP.
I suspect it might be better, for UAs at least, to send this
call-related info up the chain to a proxy server.  If I don't,
then I force EVERY device in my network to have to implement this
other interface, whatever it is.

If it is done by some other interface, or it is done locally in the
UA, then we don't have any work in the sip WG.  If we DO want to
be able to pass statistics up, then we might need something in sip.

I would specifically point out that doing some things in gateways
limits network design.  What if the call doesn't have one end on
a gateway?  It IS reasonable to do some things in UAs, but then it
has to work reasonably in all UAs.

Brian

> From: Jiri Kuthan [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 2:33 PM
> To: Rosen, Brian; 'Jay Batson'; Ashhar Farhan; [email-masked]

_______________________________________________
Sip mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sip

---

From: "Ashhar Farhan" <[email-masked]>
Date: 21 Jun 2001 06:49:47 -0000

jdrosen wrote -
>> I think people know my opinion on standardizing all the services on might offer... horrible idea. 
then you should oppose the very idea of sdp, and even sip.
- [email-masked]

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

---

From: "Ashhar Farhan" <[email-masked]>
Date: 21 Jun 2001 14:13:22 -0000

i work on another proprietory telephony protocol -the lightweight telephony protocol that is sort of a cut-down binary equivalent of the sip. we have third party authentication scheme in-built into that protocol.

the we do in ltp is this:
1) an INVITE request arrives at a redirect server.
2) the redirect server checks for authnetication (by a challenge for an md5 response).
3) redirect server then, signs the invite message with the current nonce, userid and password of the gateway but returns the invite response back to the caller.
4) the caller now forwards this invite message to the gateway.
5) upon succseful propagation of this call, the gateway issues a NOTIFY message to the redirect server signalling a call start.
6) at the end of the call, another NOTIFY message is sent from the gateway to the server.
7) the gateway periodically sends NOTIFY messages to the server to keep the server informed of the gateway's availability and state. If a notification doesnt arrive for sufficient length of time (60 seconds), the gateway is thought to be offline.

the key points are:
1) the md5 digest is generated only over select headers so that they are replicated as in the message to the gateway.
2) the redirect server itself remains stateless.
3) NOTIFY messages are signed with md5 digest using the gateway's own password, userid.
4) we use NOTIFY to update the state of the gateway as opposed to REGISTER because REGISTER doesnt support any further state propagation. (gateway busy/idle/etc.)
5) if a gateway fails to successfully send a NOTIFY message to the server, it drops the current call (if any) and waits for the gateway <-> server connection to resume before accepting any further calls.

ps. i have lost the mail to re-register myself on [email-masked], i will be glad if someone can send me the web url where i can subscribe to the new list.

- [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Jun 2001 13:00:48 -0400

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 10:40 AM
> To: Jonathan Rosenberg
> Cc: 'Rosen, Brian'; 'Jiri Kuthan'; Ashhar Farhan; [email-masked]'
> Subject: Re: [SIP] Authentication and billing through proxy/re-direct
> serv er
> 
> 
> > Its very likely that more complex services will require 
> usage information
> > from elements beyond just the gateways (although call 
> duration is only
> > reliably obtained from gateways, as people have observed). But, my
> > observation is that this is why billing mediation companies 
> exist; to
> > collect information from multiple elements, and aggregate 
> them together to
> > provide a coherent view of the service being offered.
> > 
> The corellation and agrgregation approach normally precludes 
> the entire
> range of real-time billing services.  This spectrum of 
> real-time billing
> services include popular services like pre-paid service 
> (checking remaining
> balance mid-call), and simple traditional services like time 
> and charges.
> 
> Anybody can come up with a cool service, but being able to 
> order, provision
> and bill it becomes easier with the availalbility of a full 
> range of ordering,
> provisioning and billing mechanisms.  Ruling out the protocol elements
> necessary to support a real time billing mechanism because 
> you "don't like it"
> or because you think it is the responsibilty of something 
> other than call
> control is IMHO irresponsible.

I am not trying to rule out services. I very much appreicate the importance
and complexity of provisioning and billing systems, as much of the time of
my "real" job is spent worrying about such things. I am trying to argue that
construction of new services (with or without real time billing) do not
require the propagation of reporting information in SIP. Prepaid calling,
for example, can (and has) been constructed with existing SIP, and requires
no propagation of call duration, or other usage reporting, within SIP.

The burden is on those who want the information to be present to construct a
specific proposal, and to argue concisely why existing protocol capabilities
or architectures are not sufficient, and these new functions are needed.

-Jonathan R.
---

---

From: "Ashhar Farhan" <[email-masked]>
Date: 21 Jun 2001 17:27:50 -0000

davids wrote -
>> What is the lifetime of your nonce? What if someone is sniffing the
packets and sends a different request to the VG with your authentication
information?

the nonce is regenerated every 3 minutes.

if the information is changed, the digest will change. the digest is over gateway's userid, password, nonce and certain headers of the invite (as generated by the caller).

>> How is the redirect server identified? via Record-Route (I don't think so
since the user is going directly to the VG) or is it preconfigured in the
VG? If the latter, what if the redirect server goes down? is there some sort
of hot backup mechanism?

if the redirect server goes down, the gateway should stop responding to INVITEs. yes, the redirect server is preconfigured at the VG.

>> What if the VG goes down? are all the current calls with their CDR
information lost?

the vg does not start the next call unless the record of the previous call is recorded by the server and confirmed back with a 200 response.

- [email-masked]

---

From: Wai Wu <[email-masked]>
Date: Fri, 22 Jun 2001 09:52:13 -0400

this is very impolite

-----Original Message-----
From: Ashhar Farhan [mailto:[email-masked]]
Sent: Wednesday, June 20, 2001 11:50 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [SIP] Authentication and billing through proxy/re-direct
serv er

jdrosen wrote -

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

---

From: "Ashhar Farhan" <[email-masked]>
Date: 22 Jun 2001 17:49:51 -0000

>this is very impolite

let me clarify,
i have high regard for everything that rosenberg says and writes. infact, i owe him a great debt for having putting me on track regarding the 3-way handshake, which on his recommendation i modified into a 4 way handshake for our own telephony protocol (substituting invite/ack by two separate ring and answer requests).
i am was only trying to drive home the point that rosenberg was facing a self-contradiction when he opposes standardisation of services which are an important element of a telephony protocol (the discussions on this thread amply bear this out).
i offer my unconditional apologies if i have offended him.

- [email-masked]

------------- Original Message --------------
Wai Wu <[email-masked]> wrote:
To:"'Ashhar Farhan'" <[email-masked]>, [email-masked],
       [email-masked], [email-masked], [email-masked]
From:Wai Wu <[email-masked]>
Date:Fri, 22 Jun 2001 09:52:13 -0400
Subject:RE: [SIP] Authentication and billing through proxy/re-direct serv
 er

-----Original Message-----
From: Ashhar Farhan [mailto:[email-masked]]
Sent: Wednesday, June 20, 2001 11:50 PM
To: [email-masked]; [email-masked];

jdrosen wrote -

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 02:54:59 -0400

> From: Gross, Gerhard [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 4:41 PM
> To: [email-masked]'; Jonathan Rosenberg
> A solution to *ONE PIECE* of the AAA problem discussed
> in this thread is addressed by slapping a PEP (policy
> enforcement point) layer on top of the SIP proxy
> and using a AAA/policy server in the domain as
> the PDP (policy decision point). The COPS extension
> for SIP and usage instructions are specified in
> http://www.ietf.org/internet-drafts/draft-gross-cops-sip-01.txt.

Adding a layer of AAA does not help at all with the problems in this thread.
Those problems have to do with a proxy not having the same information on
call state as a gateway that actually provides service. Since the PDP knows
what the proxy knows, if the proxy can't know, how can the PDP? It can't.

-Jonathan R.
---

---

From: "Ashhar Farhan" <[email-masked]>
Date: 26 Jun 2001 07:47:02 -0000

i guess, that the issue of differing call-states
means that either the proxy or the gateway is right. therefore, logically, and arbitarirly, one has to be
accepted as having the right state.

now, if we accept that the gateway is right, and assume that given the current mechanism of a NOTIFY message already in place, it will make sense if the a NOTIFY message is generated from the gateway. NOTIFY message
as received at the proxy can be challenged for an MD5 based authentication and also forward to the INVITEr for statistical purpose.

as i see it, the rosenberg draft on NOTIFY usage is enough for the purpose being currently discussed. it is obvious that SIP cannot evolve an algorithm to arbitrate
between teh gateway and the proxy on differing call-states. SIP will have to assume that one of them is right. whichever entity is right, should communicate it's state to the misinformed entity via a NOTIFYcation.

- [email-masked]

---

From: "Gross, Gerhard" <[email-masked]>
Date: Wed, 27 Jun 2001 08:40:17 -0700

OK, I wasn't clear. The thread has _recently_ focused on recording
session times. Previous msgs in this thread covered other things,
such as:

[Jonathan Rosenberg wrote]
> Its very likely that more complex services will require usage information
> from elements beyond just the gateways (although call duration is only
> observation is that this is why billing mediation companies exist; to
> collect information from multiple elements, and aggregate them together to

and

[David Schwartz wrote]
> I for one would not want anyone getting to my gateway (even to be
rejected)
> who is not authenticated. By authentication I mean "Who are you" and not
"Do
> you have enough money to make this call". So instead I put up an
> authenticating proxy at the border of my network to filter out those that
I
> shouldn't be speaking with.

It is these items I address with the PEP-PDP usage scenario. For
example, another service that requires usage info from elements
that supply it is QoS. As mentioned in other drafts, the
AAA/policy server may act as a PDP for
devices that provide QoS, as well as acting as a PDP for SIP
usage (local policy management). If the PDP is made a trusted
entity in a domain through some neutral party trust relationship
(billing mediation company, clearinghouse), it can be one focal point
of some session info collection before subsequent aggregation at the
clearinghouse. It is likely not the only necessary focal point,
just one of them. Session times coming from a gateway type device
may have to go to another focal point.

Service providers will likely want to provide their own accounting
services for internal bookeeping/auditing. If the gateway is owned by
a different entity, and will charge the service provider for its
usage, the service provider will want to double check its own
records against those claimed by the entity owning the gateway.
For this reason, collecting session timing information independent
of the gateway can be useful, even if they are not completely accurate.

To address the issue raised by David Schwartz above, the AAA/pol svr
PDP can act as an authentication/authorization (A1 and A2) proxy
for SIP. If a call must go through an internally owned gateway,
the provider may configure the PDP to require strict A1 and A2
before media is transmitted.

[Gerhard Gross wrote]

> > http://www.ietf.org/internet-drafts/draft-gross-cops-sip-01.txt.

[Jonathan Rosenberg wrote]

---

From: "Gross, Gerhard" <[email-masked]>
Date: Wed, 27 Jun 2001 08:52:32 -0700

Again, my comments weren't specifically directed at solving
the problem of recording absolute session times.

Gery

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 8:21 AM
> To: Gross, Gerhard
> Cc: [email-masked]'; Jonathan Rosenberg; 'Rosen, Brian'; 'Jiri
> Kuthan'; Ashhar Farhan; [email-masked]'
> As Jonathan points out, this is trivially defrauded.
> 
> The rule is simple: if you don't see the begin/end
> of the actual media stream (either directly or
> through some router that controls, say, QoS
> resources), or whatever other kind of session you
> might be basing session duration based billing on,
> then you are just whistling in the dark. Moving
> the call statefulness to a PDP only obfuscates
> which box got defrauded.
> 
> 	  Mike
> 
> Gross, Gerhard writes:
>  > The PDP is made aware of INVITES, responses, ACKs,
>  > BYEs, etc. through the PEP. So the PDP can tabulate
>  > call event and timing statistics. These can be used
>  > for whatever accounting (and subsequent charging and
>  > billing) models that happen to be deployed. The
>  > AAA/policy server is owned and maintained by the
>  > service provider and is therefore protected and trusted.
>  > 
>  > Call statefulness is handled by COPS and the PDP, not
>  > by the SIP proxy. The PDP (AAA server) may interact
>  > with a clearing house (broker, billing mediation company,
>  > etc.) for inter-domain AAA purposes as people see fit.
>  > As far as I know, there is no reason this can not be real
>  > time so that "real-time billing services" can be used.
>  > 
>  > The additional benefit of providing local policy management
>  > of SIP usage is also there.
>  > 
>  > This does not directly address the issue of byte counts
>  > per session in case billing were dependent on that.
>  > Having the UA deliver CDRs when the call is over seems
>  > like asking for fraud since the UA is generally not
>  > owned by the service provider. How can it be trusted
>  > to report accurate CDRs?
>  > 
>  > As others have said, the burden of collecting
>  > other call/session statistics (e.g. byte count)
>  > should fall on the entity providing the service
>  > who wants to get paid for it. That entity may,
>  > for example, deploy some monitoring module at
>  > its egress points.
>  > 
>  >