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

Daniel-Constantin Mierla miconda at gmail.com
Wed Feb 2 14:03:23 CET 2011


Hello,

On 2/2/11 12:52 PM, Timo Reimann wrote:
> Hey Daniel,
>
>
> On 01.02.2011 21:15, Daniel-Constantin Mierla wrote:
>> 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.
> 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.

well, some of the avps are transaction persistent, but there are also 
global avps which are available as long as kamailio runs. None of these 
should be used, I gave avp just as generic PV example. The idea was to 
make new PV available with the data stored by dlg module.

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

It is not about where the data is store, it is about how acc accesses 
that data. I would like to avoid acc module being aware of dialog module 
internals. In the future might be different call tracking extensions, I 
don't want to change acc each time.

That's why we have PVs, if I want to record something from XYZ module, 
acc is not going to be changed and understand what xyz stores 
internally, but XYZ should export some PVs for that.

For example, if I want to record something from a HTABLE, there is 
nothing to do in acc, just specify $sht(x=>mykey) to some of acc parameters.

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

But then acc has to know the dialog internals, what the getter function 
will return and how to access those structures. PV framework is exactly 
the same, but available for all components/modules, no need to develop 
specif ones each time.

With your solution, dialog module has to know acc api to call the 
recording function, and acc has to know dialog module to know its 
exported structures. This is cross dependency imo.


>>> 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
> Missed that one. Will take a look at it.
>
>
>>> 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.
> See my comment above for why binding PVs to CDR fields does not seem
> appropriate in this case.

I still don't see your point.

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

What will happen if a new call tracking module will be available, should 
acc be changed again?


>> 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.
What stops tracking these replies in the cfg?

Anyhow, I think you divert from the initial goal. If you just break the 
message in pieces and reply on each word will lose the meaning of the 
entire content. I presented my plans above and below I added acc_cdr() 
that seems to suit your needs.

>   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.
The hash table module (htable) keeps the data in shared memory. It is a 
generic container, so you can store anything there. dialog module is 
just an automatic call tracker, handling sip messages passing through 
kamailio. Most of that can be done from config file. Internally, dialog 
module has also a hash table. Also, I can track active calls using a db 
table (in memory or not for speed), with a timer process (rtimer module) 
to handle missing BYEs, and so there could be other options to track 
dialogs. My point here is that acc should be independent of all these 
potential options available now or added in the future.

You additions to dialog module can export the new stored data inside 
dialog via some PV, e.g.,

$dlgacc(caller), $dlgacc(callee), $dlgacc(duration), a.s.o.

dialog module will call acc_cdr() when the call ended, making sure the 
PVs are properly available at that time.

Cheers,
Daniel

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




More information about the sr-users mailing list