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
_______________________________________________
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
