<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7650.28">
<TITLE>Re: [Serusers] SER / Missing call records</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText9042 dir=ltr>
<DIV dir=ltr><FONT size=2>I'll go ahead and start going through our config files
again to see if anything jumps out at me. We've also got an R&D box I can
throw the config on and test changes. <FONT size=2>I will
also see about creating a generic version of our config file that I could
post without any sensitive data in it.</FONT>
<DIV dir=ltr><FONT size=2></FONT> </DIV></FONT></DIV>
<DIV dir=ltr><FONT size=2>I've gone through the syslogs over a dozen times
looking for anything database related already with no luck.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>I figured the FIFO might be a long shot, but we're to
that point of looking for long shots.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>Thanks again Jiri for the response.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>Cheers,</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2> - Darren</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>At 17:08 18/08/2006, Darren Sessions
wrote:<BR>>Content-Type:
multipart/alternative;<BR>>
boundary="----_=_NextPart_001_01C6C2D8.5D25DDC8"<BR>>Content-class:
urn:content-classes:message<BR>><BR>>All,<BR>><BR>>We’re
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 server’s 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.<BR>><BR>>We first noticed this problem when
our underlying vendor’s 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-id’s IP addresses).<BR>><BR>>We’re 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.<BR>><BR>>We’re 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).<BR>><BR>>We’ve scoured the mailing lists and change
logs for any hint of an issue similar to ours without any results. The closest
we’ve been able to come that’s anywhere near along the lines of our issue in any
way that made any sense were these posts:<BR>><BR>><<A
href="http://lists.iptel.org/pipermail/serdev/2003-August/000602.html">http://lists.iptel.org/pipermail/serdev/2003-August/000602.html</A>><A
href="http://lists.iptel.org/pipermail/serdev/2003-August/000602.html">http://lists.iptel.org/pipermail/serdev/2003-August/000602.html</A><BR><BR>thats
usrloc specific, unrelated to accounting.<BR><BR>><BR>><<A
href="http://lists.iptel.org/pipermail/serusers/2005-February/015102.html">http://lists.iptel.org/pipermail/serusers/2005-February/015102.html</A>><A
href="http://lists.iptel.org/pipermail/serusers/2005-February/015102.html">http://lists.iptel.org/pipermail/serusers/2005-February/015102.html</A><BR><BR>This
may be related, even though it is hard to say what the problem cause
might<BR>have been.<BR><BR>I don't know your script and use case, but I would
probably begin to suspect<BR>the script whether it correctly identifies all
transactions in question to be<BR>accounted. Maybe, if you don't net do it, it
may be reasonable to account all<BR>SIP transactions passing your
server.<BR><BR>Second next thing I would do is to look at syslog. I remember
that under some<BR>stressful mysql conditions, some INSERTs really got lost,
which was properly<BR>logged in SER's logfiles/.<BR><BR>><BR>>At this
point, we’re 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.<BR><BR>That has
hardly to do with FIFO.<BR><BR>-jiri<BR><BR>><BR>>Any help would be
greatly appreciated.<BR>><BR>>Thanks,<BR>><BR>>-
Darren<BR>><BR>><BR>><BR>><BR>><BR>><BR>>Fifo
settings:<BR>><BR>>fifo="/tmp/ser_fifo"<BR>>fifo_db_url="mysql://xxx:xxx@xxx/serdb"<BR>><BR>><BR>><BR>>Here
are our module specific parameters:<BR>><BR>># -- timers
--<BR>>modparam("tm", "wt_timer", 10)<BR>>modparam("tm", "retr_timer1p1",
2)<BR>><BR>># -- usrloc params --<BR>>modparam("usrloc", "db_mode",
2)<BR>><BR>># -- database URL
--<BR>>modparam("usrloc|acc|auth_db|group","db_url","mysql://xxx:xxx@xxx/serdb")<BR>><BR>>#
-- auth params --<BR>>modparam("auth_db", "calculate_ha1",
yes)<BR>>modparam("auth_db", "password_column",
"password")<BR>>modparam("auth","secret","xxx")<BR>><BR>># -- rr params
--<BR>>modparam("rr", "enable_full_lr", 1)<BR>><BR>># -- Nathelper
--<BR>>modparam("registrar", "nat_flag", 6)<BR>>modparam("nathelper",
"natping_interval", 10)<BR>>modparam("nathelper", "ping_nated_only",
1)<BR>>modparam("nathelper", "rtpproxy_disable", 1)<BR>><BR>># -- acc
params --<BR>>modparam("acc", "db_flag",
3)<BR>><BR>><BR>><BR>><BR>><BR>>_______________________________________________<BR>>Serusers
mailing list<BR>>Serusers@lists.iptel.org<BR>><A
href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</A><BR><BR>--<BR>Jiri
Kuthan <A
href="http://iptel.org/~jiri/">http://iptel.org/~jiri/</A><BR><BR></DIV></FONT></DIV>
</BODY>
</HTML>