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

From: "Gross, Gerhard" <[email-masked]>
Date: Thu, 21 Jun 2001 13:41:16 -0700

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.

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.

_______________________________________________
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 08:20:30 -0700 (PDT)

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