[OpenSIPS-Devel] Accounting enhancement proposal

Dan Pascu dan at ag-projects.com
Wed Apr 10 05:52:06 EDT 2019


I’d like to make a proposal to improve how we specify the extra fields for accounting.

In the past, the process was fully automatic. There were module parameters for the acc module that specified which were the extra fields and where to take the values from them when accounting happened. Accounting was triggered by setting a flag and later when accounting was actually generated, it would automatically fetch the extra accounting field values and send the accounting request.

After the changes to accounting, now filling in values for these extra fields is a manual process. We have to do it explicitly in the script by assigning values to $acc_extra(field_name). This approach has created some problems that make it more difficult to work with.

A model where specifying fields, declaring where the values for those fields come from and triggering accounting is fully automatic like we had before works just fine. A model where filling in values and triggering accounting is a fully manual process (meaning that do_accounting() produces an accounting record on the spot, not just mark it for later) also works fine. This is because it is very easy to associate producing the accounting record with filling in the extra accounting values.

However as it is now, accounting is scheduled for later, while filling in extra values needs to happen on the spot. This creates the following possibilities:

1. Fill in extra_accounting when calling do_accounting()
   
   This approach has the problem that the values for extra_accounting may not be available at this time

2. Fill in extra_accounting before we call t_relay() (or any other method that might result in accounting being triggered later).

   This approach has the disadvantage that we need to duplicate filling in values for extra_accounting in many places (depending how much the script logic is branching and how many places we call t_relay or similar methods). An improved alternative would be to create a helper route that only fills in $acc_extra() and call that route before every t_relay or similar method.

3. Fill in the values that do not change in extra_accounting when we call do_accounting() and fill the dynamic ones every time they change. This has the disadvantage that the code to fill the values for extra_accounting is spread out all over the config script and is difficult to follow.

Since the problem was created by dissociating the accounting record creation from the filling of extra field values, the fix should come from re-associating the two processes.

In order to fix this problem that makes filling in values for the extra accounting suboptimal, I propose we change the way it works the following way:

We create a new route type let’s call it accounting_route (or if possible we reuse the event routes by adding an accounting event). The idea is that this accounting_route (or the event route with the accounting event) is called right before the accounting record is generated. Inside this route we can then manually fill in the values for the extra accounting, right before accounting happens, making sure the values are up to date. By doing this we can synchronise the process of generating the accounting record with filling in extra accounting field values, like we had before, thus eliminating the problem. This route will act like a callback that is called right when accounting is generated and gives us the opportunity to fill in the needed values.

Something like:

accounting_route {
   $acc_extra(username) = $Au;
   $acc_extra(billing_party) = $avp(billing_party);
   ...
}

Additionally it might be useful to declare routes per accounting destination like:

accounting_route[aaa] {
   $acc_extra(User-Name) = $Au;
   $acc_extra(Billing-Party) = $avp(billing_party);
   ...
}

accounting_route[db] {
   $acc_extra(username_column) = $Au;
   ...
}

With the event route it would be similar, we’d just define accounting, aaa-accounting, db-accounting, … events




More information about the Devel mailing list