Subject: Re: [AAA-WG]: Issue 360: Accounting standalone

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Sep 2002 14:38:21 -0700 (PDT)

> All of these AVPs are not mandatory (M bit is not set) but affect the bill
> (e.g SIP-Method, SIP-Media-Info, SIP-From, SIP-To, SIP-Content-Body),
> consequently a billing server capable of generating the bill for the usage
> of SIP services must understand these AVPs or the same accounting
> information in different format (e.g. AVPs translated to CDR ASN.1 coded).

I'd claim that the SIP/AAA specification has mis-classified these AVPs as
non-mandatory. If the backend billing server MUST understand these AVPs,
then the right thing to do is for them to have the "M" bit set as
generated by the Accounting client.

> 1- The billing server does not understand any AVP, it require Call Detail
> Record formatted according to some other format e.g.ASN.1 coding. In this
> case the Diameter accounting server, or some sort of gateway node, must
> understand these AVPs, translate them in CDR (Call Detail Record) ASN.1
> coded and sends the CDR to the billing server.

But if the billing server can't handle the AVPs that are being encoded,
what use is it to the Accounting Server to provide them within the CDRs?
It makes more sense to fix the problem by failing the capabilities negotiation,
than by having the accounting server accept the packets, and
generate CDRs that the billing system can't process.

I am envisaging having the Accounting Server configured with the
application IDs that correspond to applications that the backend billing
server can process. It then exchanges these capabilities in the CER/CEA.
If the Accounting client wants to do an application that isn't supported
in the backend billing server, then the capabilities negotiation will fail
until the Accounting Server is re-configured to handle those new
applications. That seems like the right thing to me.

> 2- The billing server does understand the AVPs. In this case the Diameter
> accounting server does not need to understand these AVPs, it simply store
> the AVPs to the disk and sends them later on to the billing server.

Yes -- and so the accounting server can advertise the applications that
the billing server understands and there is no issue. Note that if the
Accounting Server is written correctly, the applications can just be
selected from a list which can be augmented via a dictionary. That means
there is no need to change code on the Accounting Server in order to
support a new application, as long as no new commands are required.
However, the billing server does need to be upgraded to be able to bill
correctly for the new application.

> In any case the end system that generate the bill, the billing server, must
> understand the service specific accounting information (or AVPs) for those
> services it is supposed to bill for. One clear example is the above
> mentioned draft sipping-aaa-diameter, and it's very difficult to believe
> that you add accounting AVPs that do not affect the bill.

I'd expect that most of the AVPs would affect the bill -- that's why they
were put in the spec. But not all the accounting AVPs that we have defined
fit in that category.

> In conclusion when you define new AVPs that carry information to charge for
> the service x, either the billing server or some sort of gateway node
> (between Acct. Server and BS) must understand these AVPs if you want to be
> able to generate the bill for the usage of service x.

Yes.

> Accordingly I guess I would buy this other argument:
>
> if the application requires new AVPs to be present (ABNF mandatory), but
> does not require the accounting server to understand them (e.g.new AVPs
> don't have "M" bit set), there are no new commands and there are no
> additional mechanisms defined (e.g. application state machine); a new
> application Id is not required and MUST NOT be used.
>
> Br
> Marco

OK. Sounds like we agree.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Sep 2002 09:29:42 -0400

> generated by the Accounting client.

I agree that "M" bit is needed if an accounting server must be able to
process (inside the Diameter protocol) the AVP to support a particular
accounting application (e.g., prepaid).  However, I don't think "M"
bit is needed for a backend billing server to be able to process
billing outside the Diameter protocol, since accounting and billing
are closely related but they are different things.  I think the right
thing to do in this case is that the implementation of an accouning
server must be able to record all AVPs regardless whether "M" bit is
set or not (and regardless of whether it does not support AVPs that do
not have "M" bit set), and pass them to the billing server and let the
billing server choose whatever AVPs needed for creating appropriate
bills.  I think this is natural because the accounting server
basically does not know which information is used by the billing
server.

Yoshihiro Ohba

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 Sep 2002 09:20:00 -0700 (PDT)

> I think the right

However, if the admins of the accounting server do know what the billing
system can handle, then they can configure the accounting server with the
set of application IDs corresponding to those supported services. That
way, they won't accept accounting packets containing unbillable services,
which saves headaches down the line (like not getting paid for authorized
sessions).

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Sep 2002 15:05:56 -0400

> which saves headaches down the line (like not getting paid for authorized

I agree that such optimization is possible if the accounting server
has some knowledge (by configuration) about billing.  But I think this
still does not necessarily mean that the billing server should accept
only AVPs with "M" bit set.

Anyway, I agree with the proposed text for Issue 360.

Yoshihiro Ohba

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 Sep 2002 11:25:59 -0700 (PDT)

> only AVPs with "M" bit set.

I agree. The accounting server should be able to accept new AVPs without
the "M" bit set, since if the Billing Server can't handle them, it is free
to ignore them.

> Anyway, I agree with the proposed text for Issue 360.

Good.