2 Feb
2011
2 Feb
'11
10:52 p.m.
Hey Daniel,
On 01.02.2011 21:15, Daniel-Constantin Mierla wrote:
If I get you right, by cross reference/dependency you mean that A
requires B and vice versa, i.e., cyclic dependency. I do not intend to
let that happen.
Instead, the acc module would use getter functions attached to the
dialog interface (which is what I mean by "acc module will make sure").
dialog would never touch the acc module or even know about the fact that
the acc module is using it.
Missed that one. Will take a look at it.
See my comment above for why binding PVs to CDR fields does not seem
appropriate in this case.
Of course, I would want to take advantage of acc's existing backend
connectors. There's no need to re-invent the wheel, acc will still be
responsible for writing out CDRs; the difference is that a few
additional calls to a well-defined dialog interface will be used in
order to collect the data that constitute the CDR.
On 2/1/11 8:18 PM, Timo Reimann wrote:
I initially thought about having a cdr_extra parameter similar to
log_extra. However, I see a problem with AVPs which live in single
transactions to work with dialogs that span multiple transactions.
Say you want to have a CDR field that contains combined or concatenated
data from multiple transactions, e.g., all Kamailio flags set in the
INVITE, ACK, and BYE transaction. How could that be accomplished with a
log_extra-like module parameter? At what times would AVP be parsed?
IMHO, you will need to keep such data per dialog which is why I came up
with the idea of storing CDR-specific data in the dialog.
[...]
Apart from this very minimum CDR content, however, one can think of a
number of CDR fields that cannot be filled easily. For instance, caller
identity isn't always contained in the From header (think of CLIR calls)
but need to be determined from other headers depending on the type of
call, possibly even involving a database lookup.
From header URI is not accounted
automatically, you can specify any
variable that can contain caller id as you need (e.g., it can be an AVP
that you previously set for in config) -- see *_extra parameters of acc
module. That's why
I'd like to
provide a way to pass additional, CDR-specific data from the
configuration file to the dialog structure associated with the call.
When the dialog is about to terminate, the extended acc module would
make sure that the added CDR data associated to the dialog is included
in the CDR.
Not sure what you mean here with "acc module will make sure ...", but I
hope is not going to be cross reference/dependency, so that acc has to
walk through dlg structures. In order to
accomplish this, the dialog module would need to be extended
such that dialog-specific data may be stored for the duration of a
dialog (which is not possible to this day AFAICS).
Carsen committed some code in this regard in his IMS branch, as I could
see from commit log, check:
http://lists.sip-router.org/pipermail/sr-dev/2011-January/010197.html Regarding the
acc module, a couple of new features need to be
implemented: First, the introduction of another module parameter called
something like "cdr_fields" that comprises the set of key names
designated for CDR inclusion. Hence, a line like
modparam("acc", "cdr_fields", "caller, callee, foo,
bar")
The db_extra has the format of 'key=variable', where the 'key' is the db
column name and the 'variable' is the name of PV holding the value to be
stored. I think the format is better than just providing the names of
the dialog keys. Third, the CDR
is persisted to either log file, database, or both.
If this new thing is not going to support what acc module API has for
backends (radius is missing), then will not make sense to tie the two.
dialog module can do its accounting alone. Regarding db accounting:
- I have in my todo list the plan to enhance acc to export a functions
like acc_start() and acc_stop(), with the goal of storing the initial
record for start of the call (acc_start() for INVITE) then at the end of
the call (BYE) acc_stop() will just set extra details (end time,
duration, etc)
- practically then dialog module can call acc_start() and acc_stop() via
some inter-module api. The benefit is that even sip server crashes
suddently, there is an acc start event to indicate a call
Regarding server crashes/restarts, instead of persisting events ASAP via
acc module I would recommend using dialog's existing feature to store
dialog data in a database. That way, every piece of CDR-specific data
stored in dialogs in my approach will be saved automatically (as
governed by dialog module configuration), and there will be no need to
produce partial CDRs in the first place.
- such functionality is independent of dlg module or
any new call
tracking extension in the future, also writing full CDR can be achieved
from config file by tracking INVITE and BYE, calling
acc_start()/acc_stop() from cfg
Tracking INVITE and BYE messages from the config file may not be enough
if you want to create CDRs for failed calls too, e.g., 408/487. They may
not be relevant for billing but having them in a CDR database may still
be desired.
Does your approach allow automatic CDR generation, or will you need to
call these acc_* functions explicitly? I'd prefer to have automatic CDR
persisting, similar to how transaction-based accounting in the current
acc module works.
Therefore if I would do it:
- enhance acc module to export via cfg exports and inter-module api
three functions:
- acc_start() - write the initial call record at start
- acc_stop() - update the call record at stop, based on a matching
condition specified as parameter
- acc_cdr() - write a full CDR
Data to be written in db (or other backend) is going to be taken from
PVs, independent of who (cfg, dialog, or other module) is calling the
function, specified in a similar form like db_extra.
First two functions will work for db only. Third can work also without
dialog, e.g., I can store the start of a call, a.s.o. in hash table and
get it at BYE time to build the full cdr.
Where would you maintain that hash table containing the call start time
and similar data if you do not seek to use the dialog module? Such data
seems to be naturally associated to a dialog, so my impression is that
it should be kept there too, i.e., in the dialog module.
Cheers,
--Timo