20 Aug
2006
20 Aug
'06
2:23 p.m.
We've had similar problems and ended up getting our CDRs from our local
PSTN gateways. This works until we begin peering with carriers via IP
(which is soon). The gateway records are much more accurate.
One thing I've wondered about but did not have time to check is whether
some of the accounting entries are generated by SER? Let me explain. Our
accounting script looked for invite and bye records with matching
call-id tags. In some cases a bye or an invite was missing. In other
cases there were duplicates of one record or another. We enabled
accounting for cancel messages and found some problems were due to
hangups (invite/cancel instead of invite/bye).
When a call goes to our Asterisk voicemail server the r-uri is
re-written and the message t_relay'ed. I suspect some of our mismatched
records were due to these calls not being identified properly. I don't
have concrete data for this point but I think either the invite to the
voicemail server had a different call-id tag or the corresponding bye
never made it back from Asterisk.
We also had problems with multiple message from the phones themselves. I
think this is due to an older version of SIP code on the phone.
Hopefully some of these thoughts help,
Steve
Jiri Kuthan wrote:
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,
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.
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).
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.
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).
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:
<http://lists.iptel.org/pipermail/serdev/2003-August/000602.html>http://lists.iptel.org/pipermail/serdev/2003-August/000602.html
thats usrloc specific, unrelated to accounting.
<http://lists.iptel.org/pipermail/serusers/2005-February/015102.html>http://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, 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.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers