Jump to content

Call Log / CDR stopped


Cahnite
 Share

Recommended Posts

Snom ONE mini running v4.5.0.1090 Epsilon Geminids. All working fine for months. Last week, had some local power issues, and since last reboot, our Call Log [..dom_callog.htm] is 'frozen' at a date from when system shut down. No recent calls show up -- the file is not updating. Also, each night we send CDR via e-mail and it shows '0 calls', despite many calls being made, etc.

 

We noted in the error log last week some crazy initial times when the system first came up, e.g. year 2106 etc. Time soon re-synced to NTP but wonder if timestamps from one of those reboots corrupted a CDR file? Don't know how to check and/or restart the call log function.

 

Suggestions?

Link to comment
Share on other sites

Appears to *not* be full. See:

 

Please use the information shown on this web page when you request help from the support team.

Version: 4.5.0.1090 Epsilon Geminids (snom ONE mini)

Created on: Jun 19 2012 09:49:49

License Status: snom ONE free

License Duration: Permanent

Additional license information: Extensions: 9/10 Accounts: 23/30 Upgrade: 01 01 2013

Working Directory: /usr/local/snomONE

MAC Addresses: 0004134419F4

DNS Servers: 192.168.0.1

CDRs: Duration(1d): trunk = 218, extension = 43, ivr = 234

Calls: Total 46/34, Active 0/0 Calls

SIP packet statistics: Tx: 55667 Rx: 71135

Emails: Successful sent: 14 Unsuccessful attempts: 0

Available file system space: 27%

Uptime: 2013/2/4 09:50:06 (uptime: 2 days 17:04:07) (41668 42869-0) WAV cache: 2

Number of HTTP sessions: Sessions: PAC=0, HTTP=1; Threads: SIP=1, HTTP=1

Domain Statistics: Total Domains: 1, Total Accounts: 23

Link to comment
Share on other sites

Okay, that is kind of good news.

 

I assume the problem is that the PBX is in the year 2106, in other words: in the 70s. So you see only the "recent" CDR. Can you login to the SSH level and enter this: date -s 2/4/2013. If that changes the behavior, the problem is somewhere int the startup when it tries to get the time.

Link to comment
Share on other sites

Tried that and it echoed correct date when done, but seems to have set the time to 00:00, which is not useful (!). Just did an ntpdate pool.ntp.org, and date and time *appear* correct. But still the problem remains: call log not updating. It's like that process halted or something.

Link to comment
Share on other sites

Okay, that is kind of good news.

 

I assume the problem is that the PBX is in the year 2106, in other words: in the 70s. So you see only the "recent" CDR. Can you login to the SSH level and enter this: date -s 2/4/2013. If that changes the behavior, the problem is somewhere int the startup when it tries to get the time.

 

Date/time appear correct. Q: Is there something we might try? Ideas?

Link to comment
Share on other sites

So the log messages on the PBX are also in the year 2013? It might take a couple of calls until the CDR are getting back in line.

Right. Yes, the log messages are showing correct time, and, they keep flowing. The 'call log' (CDR) however, is just stuck. Not updating. It's been that way for over a week now. Strange. Anything we can check/kick-start?

Link to comment
Share on other sites

If you look in the file system, is there anything happening in the cdri/cdrt/cdre folders?

Yes. It appears there is. At least, I see files with create dates more recent than the 'frozen' call_log.htm page. Screen shot of content in one of those directories attached, FYI.

 

Now what?

post-26357-0-68524700-1359999635_thumb.jpg

Link to comment
Share on other sites

Looks like in 20 calls the problem will be solved... Those old CDR entries should be disappearing. If you want to force it right now, remove them manually and restart the service (e.g. /etc/init.d/snomone restart).

 

If you restart the whole system, make sure that it gets the time right!

Okay. Hope so. Q: Should I delete all the XML files in each of the three CDR-related directories, then? I noted the ntp host in pbx.xml is set for ntp.snom.com. Should I leave this as is? Is this where the mini "learns" what the real time is? Many thanks for your help.

Link to comment
Share on other sites

Okay. Hope so. Q: Should I delete all the XML files in each of the three CDR-related directories, then? I noted the ntp host in pbx.xml is set for ntp.snom.com. Should I leave this as is? Is this where the mini "learns" what the real time is? Many thanks for your help.

PERFECT. SOLVED. I deleted all the old [numeric].xml files in the three CDR-related directories and issued 'restart' as suggested. System up. Time is correct. Call log/CDR now working again. THANKS.

 

:-)

Link to comment
Share on other sites

ntp.snom.com has the problem that it advertises both IPv4 and IPv6 address. If you mini has no IPv6 access, that might lead to the problem that the NTP will try for a long time the IPv6 address. It would be great if ntp4.snom.com and ntp6.snom.com would be available as well, but it is not. So maybe you just pick something like pool.ntp.org or the time server of your choice.

Link to comment
Share on other sites

ntp.snom.com has the problem that it advertises both IPv4 and IPv6 address. If you mini has no IPv6 access, that might lead to the problem that the NTP will try for a long time the IPv6 address. It would be great if ntp4.snom.com and ntp6.snom.com would be available as well, but it is not. So maybe you just pick something like pool.ntp.org or the time server of your choice.

Ah-hah! THAT could explain some strange delays we experienced in getting correct time the other week. Environment here not IPv6 friendly. We'll plug another NTP server in instead. Thanks again!

 

:-)

Link to comment
Share on other sites

  • 1 year later...
  • 2 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...