Cahnite

Thanks! Yes, I've got intercom to work with the Cisco phones, but unlike with our Snom or Polycom sets, it appears that once a line has its "auto answer" field valued (0-3, apparently) in the Cisco SEP<macID>cnf.xml file, it either answers no calls or all calls as intercom. I.e., does not seem to care about that header's content on a call by call basis. :-(

We have a SoHo and a mini running v 4.5.1 "bug fix" s/w, and just started exploring what Cisco IP phones can/cannot do w the snom ONE system. Not using PnP functionality. (Polycom sets working nicely for years, but life too easy -- time for a challenge, etc.) After a *big* struggle getting current SIP firmware loaded on a re-purposed "skinny" 7965G, and another struggle getting it to actually register, it finally works. Mostly. Q1. Is no 'per call' intercom functionality possible? Q2. Anyone seen a good [recent] write-up on the XML tags/fields for the SEP[mac].cnf.xml file? If so, can you share pls? Q3. Will the BLF modules work (e.g. 7915/7916)? If not for presence status, at least as speed calls/add'l line keys? Appreciate any wisdom from folks with current generation of Cisco sets working with snomONE.

Thanks for quick PM response, guys. Applying the revised/new license allowed device to work on 4.5.1 s/w. Excellent. :-)

So.. found this post: http://forum.snomone.com/index.php?/topic/6448-upgrading-to-v5-from-v45-on-soho/ And see that whoever compiled 4.5.1 "bug fix" branch, elected to use newer libraries. Nice. Followed instructions with both machines and successfully upgraded both to 4.5.1. Admin page comes up. Yay. No phone service. Zero. Both boxes dead in water by the new licensing scheme. And yes, I ran the license through the online 'checker' you set up, and it came back "good to go".

We've got a SoHo, and a mini, both running v4.5.0.1090 Epsilon Geminids. Keen to upgrade to 4.5.1. We have been through the 'manual update' instructions that are still posted on the website, but the 4.5.1.1107 update *fails* to run on either machine. An ldd of the executable shows: root@sheevaplug-debian:/usr/local/snomONE# ldd pbxctrl-mini-4.5.1.1107 ldd: warning: you do not have execution permission for `./pbxctrl-mini-4.5.1.1107' ./pbxctrl-mini-4.5.1.1107: /usr/lib/libstdc++.so.6: version `CXXABI_ARM_1.3.3' not found (required by ./pbxctrl-mini-4.5.1.1107) libpthread.so.0 => /lib/libpthread.so.0 (0x40005000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40023000) librt.so.1 => /lib/librt.so.1 (0x400fe000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4010d000) libc.so.6 => /lib/libc.so.6 (0x40121000) /lib/ld-linux.so.3 (0x2a000000) libm.so.6 => /lib/libm.so.6 (0x40248000) root@sheevaplug-debian:/usr/local/snomONE# What's up with that? Are there library files we need to load? If so, why, which, and from where? Appreciate any/all suggestions!

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! :-)

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. :-)

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.

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?

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?

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

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.

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

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?