[OpenSIPS-Devel] Accounting enhancement proposal

[Liviu Chircu]

Hi Dan,

A very interesting proposal - too bad it arrived 4 days before the beta 
release, so the discussion will likely have to wait until 3.1.  Below 
are my comments to some of your key ideas:

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

What do you mean by "fully automatic"?  Because the so-called "where to 
take the values from" sources were often a bunch of AVPs, which you 
would inevitably spread all over the script, almost identically to the 
way $acc_extra() is used now. However, with the freedom that AVPs gave 
you came an additional problem, which the current $acc_extra() system 
eliminates:

         +----+----+----+
LEG #5: | x5 | ?? | ?? |
         +----+----+----+
LEG #4: | x4 | y4 | ?? |
         +----+----+----+
LEG #3: | x3 | y3 | z3 |
+----+----+----+
LEG #2: | x2 | y2 | z2 |
+----+----+----+
LEG #1: | x1 | y1 | z1 |
+----+----+----+
AVP   AVP  AVP
#1    #2   #3

Notice how, in more complex accounting scenarios involving multiple legs 
(e.g. call forwarding, VoIP-VoIP hairpinned calls, etc.), you had to 
precisely manage the size of each AVP, taking EXTRA care to NOT 
mistakenly push too many values into it after both GW #1 and GW #2 
failed and the call terminated via GW #3. Desynchronizing the old AVP 
accounting fields (see diagram above, where AVP #1 has too many values 
pushed into it, so legs #5 and #4 are not recorded) was a nightmare, 
leading to missing accounting records and lots of pain.  $acc_extra() 
fixes this problem, making life easier for script writers, since they 
don't have to micro-manage AVPs as they had to before.

> However as it is now, accounting is scheduled for later, while filling in extra values needs to happen on the spot.
Not true at all.  You can fill in all $acc_extra values on BYE 
processing, provided that you can still extract all data that is 
required by the record.
> 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.
As I said above, very little has changed.  The AVPs were set all over 
the place just as before.  Maybe if you had something like $fU, $tU, $si 
and $rU as preset accounting fields, indeed -- you needn't have 
explicitly set them in the script anymore.  But I doubt setting 
$acc_extra() 4 times is as worse as the old "de-synchronized accounting 
legs due to inconsistent AVP stack sizes" problem.
> 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.

Making the accounting take place in a singular place at script level 
sounds like an excellent idea to me.  The only problem we need to solve 
is to make sure script writers have all the data they need at that 
point.  What if they require some metadata that they can only derive 
through a custom INVITE header?  The INVITE is well gone now, and they 
didn't do any special handling for it (e.g. store it as a $dlg_val), so 
what to do next?

Best regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com