[SR-Users] Proposal to extend acc/dialog modules in order to log CDRs

[Timo Reimann]

Hi all,

I'd like to bring forward a proposal for creating CDRs (Call Data
Records) from Kamailio by means of extending both acc and dialog
modules. Feedback is very welcome.

So far, CDR generation requires post-processing of log entries created
by the (transaction-based) acc module or some other means. Looking at
OpenSIPS (which is already capable of producing CDRs), my idea is to
copy the basic notion of tracking dialogs for to-be-accounted calls and
log a proper CDR on termination. Creating basic CDRs including start
time, end time, and call duration can be accomplished quite easily this way.

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. 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. This way, users may define CDR fields to their personal
needs from the configuration file in a flexible manner.

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). A new setter function
attached to the dialog interface (struct dlg_binds) could accept a
simple key/value pair for storage purposes. Exporting this function to
the configuration file and accompanying it with a corresponding getter
function will ensure that dialog-specific data may be written and read
generically. Thus, improvements to the dialog module may be leveraged
not just for CDR-accounting purposes.

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")

would require Kamailio configurators to store dialog-specific values for
the keys "caller", "callee", "foo", and "bar", respectively, during call
processing. The values will be fed to the dialog structure employing the
new dialog store function explained above.

Second, when the acc module is in CDR mode, dialogs shall be tracked
from creation to termination using dialog callbacks. On termination of a
dialog, values from keys referenced in the "cdr_fields" parameter will
be fetched from the terminating dialog structure and associated with the
new, fresh CDR.

Third, the CDR is persisted to either log file, database, or both.

Note that my approach would not touch the existing acc module
functionality: CDR mode is supposed to be working in addition to
transaction-based accounting as people will likely want to keep
transaction logs for debugging or similar needs. A flag would enable and
disable CDR generation at will. I have not fully investigated
re-usability possibilities but believe that acc's persistence functions
may be taken advantage of by the new CDR-producing parts as well.

That's it with regards to the basic mode of operation. I am also
thinking of having a few other features, such as using a switch to set
the call start time to the moment the ACK or OK is seen instead of the
INVITE (because users shouldn't be billed for call setup times).


Looking forward to seeing your feedback on this proposal.


Cheers,

--Timo