[SR-Users] Simple Call Accounting

Graham Wooden graham at g-rock.net
Tue Aug 10 04:05:13 CEST 2010


I appreciate yours and Alex's' input and insight.

While I don't have a many to one (proxy to DB), but rather one to one, I
have a few worker scripts from a central reporting box that pulls those
records and anything in the missed_calls and dialog and wraps up any
collation. I don't use anything in ACC...

-graham


On 8/9/10 8:10 AM, "Uriel Rozenbaum" <uriel.rozenbaum at gmail.com> wrote:

> Just as an addendum to Alex's comment, I'm doing the exact same thing
> with MySQL triggers.
> 
> Most strange situations can be worked around using some parameter in
> ACC or DIALOG modules (if working together).
> 
> Our main cause is that we have many proxies and a central DB, so the
> work is performed by only one process that can be measured and
> optimized alone.
> 
> Uriel
> 
> On Sun, Aug 8, 2010 at 11:00 PM, Alex Balashov
> <abalashov at evaristesys.com> wrote:
>> For comparison and contrast:  We handle this in PostgreSQL by having
>> Kamailio write to the 'acc' table, and adding triggers that operate on 'acc'
>> events and populate or update another table, 'cdr', with actual CDRs in the
>> desirable one-row-per-call way.
>> 
>> The advantage to doing it that way versus in route script is that it's
>> transactional in nature;  an error will result in all the cascading queries
>> being rolled back.  It also makes it much easier to insinuate business layer
>> stuff into the cascade, or extend the trigger cascade with additional logic,
>> because PL/PgSQL provides certain features of a general-purpose programming
>> environment that Kamailio does not, given its domain specificity.
>> 
>> It also eliminates unnecessary data interchange between the Kamailio process
>> and the RDBM, given that most of the work is done in the database itself,
>> causing additional latency and being a possible source of data corruption.
>> 
>> In short, it lets us have a relatively clean Kamailio config and deputise
>> all the business layer stuff to the database backend in a very hierarchical,
>> maintainable way.  That way, the Kamailio route script can stick to doing
>> what it does best:  operating on SIP messages.
>> 
>> --
>> Alex Balashov - Principal
>> Evariste Systems LLC
>> 1170 Peachtree Street
>> 12th Floor, Suite 1200
>> Atlanta, GA 30309
>> Tel: +1-678-954-0670
>> Fax: +1-404-961-1892
>> Web: http://www.evaristesys.com/
>> 
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>> 
> 
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users





More information about the sr-users mailing list