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

[Daniel-Constantin Mierla]

Hello,



On 2/1/11 8:18 PM, Timo Reimann wrote:
> [...]
>
> 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.

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

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

Probably it will be merged sometime in the near future.

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

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.

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

I think exporting anything related to dialog via PV and fetching them 
like this will be better from point of view of cross-relationships.

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

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.

> 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.
As general observation, there are some modules (I mainly think about 
presence) that have cross references/dependencies that should be avoided 
normally, and planned to clean it up already. It is not good to have A 
uses/needs B and B uses/needs A

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

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.

Your needs seem to fit in 3, so if you can (wish to) work on that only, 
I will take care of the first two when I can.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://www.asipto.com