At 17:08 18/08/2006, Darren Sessions wrote:
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C2D8.5D25DDC8" Content-class: urn:content-classes:message
All,
Were experiencing a problem with missing call records. There is nothing in the log files that indicate a problem either with SER or our database server and likewise there is nothing in the database servers logs to indicate a problem. System loads are within reason on both servers, network connectivity has been tested and verified, and a through hardware shakedown on both boxes has been completed without any errors.
We first noticed this problem when our underlying vendors bill (based on minutes of course) did not correspond with our own. Upon doing a CDR comparison (based on what was in both the acc and calls tables), we were able to verify that the calls in dispute were indeed ours (based on the sip call-ids IP addresses).
Were processing roughly 1.4 million calls per day on this SER server in question. Out of those calls, 508 calls (give or take a couple hundred) with a total duration of over 5,300 minutes - can not be accounted for in any of the SER database tables.
Were running 0.9.5-pre1 with Suse Enterprise Server 9.0 (2.6.11 Kernel). Server is an HP DL380 with dual 3.2GHz processors with 6GB physical ram (only 1.4GB in use system wide); disk space is not an issue as well (only 10% in use).
Weve scoured the mailing lists and change logs for any hint of an issue similar to ours without any results. The closest weve been able to come thats anywhere near along the lines of our issue in any way that made any sense were these posts:
http://lists.iptel.org/pipermail/serdev/2003-August/000602.htmlhttp://lists.iptel.org/pipermail/serdev/2003-August/000602.html
thats usrloc specific, unrelated to accounting.
http://lists.iptel.org/pipermail/serusers/2005-February/015102.htmlhttp://lists.iptel.org/pipermail/serusers/2005-February/015102.html
This may be related, even though it is hard to say what the problem cause might have been.
I don't know your script and use case, but I would probably begin to suspect the script whether it correctly identifies all transactions in question to be accounted. Maybe, if you don't net do it, it may be reasonable to account all SIP transactions passing your server.
Second next thing I would do is to look at syslog. I remember that under some stressful mysql conditions, some INSERTs really got lost, which was properly logged in SER's logfiles/.
At this point, were not sure if this issue has something to do with the FIFO and SER making bulk dump uploads with call data to the database, or some other issue along those lines or if this is a new issue all together.
That has hardly to do with FIFO.
-jiri
Any help would be greatly appreciated.
Thanks,
- Darren
Fifo settings:
fifo="/tmp/ser_fifo" fifo_db_url="mysql://xxx:xxx@xxx/serdb"
Here are our module specific parameters:
# -- timers -- modparam("tm", "wt_timer", 10) modparam("tm", "retr_timer1p1", 2)
# -- usrloc params -- modparam("usrloc", "db_mode", 2)
# -- database URL -- modparam("usrloc|acc|auth_db|group","db_url","mysql://xxx:xxx@xxx/serdb")
# -- auth params -- modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("auth","secret","xxx")
# -- rr params -- modparam("rr", "enable_full_lr", 1)
# -- Nathelper -- modparam("registrar", "nat_flag", 6) modparam("nathelper", "natping_interval", 10) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "rtpproxy_disable", 1)
# -- acc params -- modparam("acc", "db_flag", 3)
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/