[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