12 Aug
2004
12 Aug
'04
2:06 a.m.
At first it seemed like a really good idea then the more I looked at real
world records I realized that to generate a bill for a customer would
require quite bit of work on MySQL's part to match up the INVITE's and the
BYE's and then calc the difference in the times. This causes a bit of a
problem for me because I like my customers to be able to see their CDR
records live. Which really isn't much unless you look at it from a 100,000
user perspective. I would either have to beat up my SQL server every time
they look at their records (or my customer service employees look at them or
even when the biller generates their bill) or run a cron job that runs every
so often to convert the data to a single record with a start time and a
duration and store it in another table. The cron idea isn't too efficient
because of wasting disk space and rewriting a lot of the same data twice.
This then leads me to ask why the SER acc module wasn't setup to generate an
initial start record identical to the INVITE message that it already does
that would be marked as "in progress"? Then when a BYE is received with a
matching Call-ID you find the original INVITE record, change its status to
"done" and populate a duration field. Any ideas why this can't be done
without affecting SER's scalability? :)
Thanks!
----------------------------------------
Michael Shuler, C.E.O.
BitWise Systems, Inc.
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
12 Aug
12 Aug
2:31 a.m.
SER seems to support postgresql as an accounting backend, and postgresql
support "triggers."
This is a synthesis of only a cursory look at the SER source tree and
postgresql docs on triggers, but it looks like you can do the following:
1.) Set up SER to use postgresql as it's accounting backend.
2.) Create an extra table with the fields you would like to see in your
"real world records."
3.) Create trigger to corelate INVITES and BYEs and insert a row into your
"real world records" table every time it notices that a BYE has been
inserted into the transactional accounting table.
This is still extra CPU load that will hurt your scalability but it's
fairly elegant and an experienced PostgreSQL user/admin should be able to
crate it up pretty quickly.
Finally, I'd bet that a 2-way or 4-way opteron-based database server would
hold up to a pretty substantial call volume, even while running that
trigger.
Best regards,
Mike Przybylski
On Thu, 12 Aug 2004, Michael Shuler wrote:
At first it seemed like a really good idea then the
more I looked at real
world records I realized that to generate a bill for a customer would
require quite bit of work on MySQL's part to match up the INVITE's and the
BYE's and then calc the difference in the times. This causes a bit of a
problem for me because I like my customers to be able to see their CDR
records live. Which really isn't much unless you look at it from a 100,000
user perspective. I would either have to beat up my SQL server every time
they look at their records (or my customer service employees look at them or
even when the biller generates their bill) or run a cron job that runs every
so often to convert the data to a single record with a start time and a
duration and store it in another table. The cron idea isn't too efficient
because of wasting disk space and rewriting a lot of the same data twice.
This then leads me to ask why the SER acc module wasn't setup to generate an
initial start record identical to the INVITE message that it already does
that would be marked as "in progress"? Then when a BYE is received with a
matching Call-ID you find the original INVITE record, change its status to
"done" and populate a duration field. Any ideas why this can't be done
without affecting SER's scalability? :)
Thanks!
----------------------------------------
Michael Shuler, C.E.O.
BitWise Systems, Inc.
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
13 Aug
13 Aug
4:30 p.m.
That's actually our design decision. We try to keep the code that is not
necessary for signalling out of SER. Because SER does not use the
accounting information in any way, there is no need to correlate the
rows directly in SER and it is better to do it in other components, like
SERWeb, that are not so critical.
Nothing serious happens if you do not see your accounting data in SERWeb
immediately, but if the database queries so complex that they block SER too
much, then nobody would be able to place a call -- and that can be serious.
Looking up the original INVITE can take a lot of time, especially if the table
is big and the data gets fragmented.
Jan.
On 12-08 01:06, Michael Shuler wrote:
At first it seemed like a really good idea then the
more I looked at real
world records I realized that to generate a bill for a customer would
require quite bit of work on MySQL's part to match up the INVITE's and the
BYE's and then calc the difference in the times. This causes a bit of a
problem for me because I like my customers to be able to see their CDR
records live. Which really isn't much unless you look at it from a 100,000
user perspective. I would either have to beat up my SQL server every time
they look at their records (or my customer service employees look at them or
even when the biller generates their bill) or run a cron job that runs every
so often to convert the data to a single record with a start time and a
duration and store it in another table. The cron idea isn't too efficient
because of wasting disk space and rewriting a lot of the same data twice.
This then leads me to ask why the SER acc module wasn't setup to generate an
initial start record identical to the INVITE message that it already does
that would be marked as "in progress"? Then when a BYE is received with a
matching Call-ID you find the original INVITE record, change its status to
"done" and populate a duration field. Any ideas why this can't be done
without affecting SER's scalability? :)
Thanks!
----------------------------------------
Michael Shuler, C.E.O.
BitWise Systems, Inc.
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7307
days inactive
7308
days old
2 comments
3 participants
participants (3)
-
Jan Janak -
Michael Przybylski -
Michael Shuler