I have 12 SoundPoint IP 450 handsets connected to 3CX 12, and I am having some issues. Every Monday morning for the past three weeks the phones have hard locked and unregistered themselves from the PBX over a 30 second period. When the handsets go down they are truly crashed- lifting the receiver doesn't turn the backlight on, anything scrolling across the display such as missed calls freezes where it was at when the phone went down, it doesn't respond to pings and the web interface is inaccessible.
As far as I know nothing has changed in terms of configuration. I've looked at the log files on the phones but I think they are being wiped out on reboot so there's only ever information relating to them booting up in the logs - do I need to put a syslog server in place and wait for the problem to happen again (3CX uses IIS to deliver the firmware, provisioning files etc so the phone can't write back to there)? It would also help if I knew how to read the timestamps in the log files - the phone is getting valid time from a local NTP server but the number at the start of each line doesn't seem to match up to a date.
welcome to the Polycom Community.
Has this issue occurred on an earlier software version or only since you upgraded to UCS 4.0.5?
The community's VoIP => FAQ <= contains this post here:
Oct 17, 2011 Question: How can change Logging Levels or use Syslog?
Resolution: Please check => here <=
I suggest you activate Syslog as it seems easy to reproduce and then work with 3CX to bring this to the attention of Polycom support.
Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.
Polycom Global Services
It happened once and then I deployed the software update to see if that fixed anything, which it didn't.
I've got a syslog server running and it's logging at the debug level so hopefully that should reveal what's going on if it happens again.
I have some syslog entries now and a screenshot of what the web UI looks like after this error. At the moment the handset is still registered so I'm assuming it's working its way towards crashing entirely.
The log is normal debug messages:
0126215858|so|5|03|[SoMediaSess:PpsCallStateIdle] Dialog session is not found
and then the following happens:
0004f225c152|0126215926|sys|*|03|0x94f7d7a0 (httpd): memPartAlloc: block too big - 99307 in partition 0x94daae6c. 0004f225c152|0126215926|utilm|4|03|utilBufferDecompress Couldn't realloc 99307 bytes 0004f225c152|0126215926|cfg|4|03|Web|[cfgSaProcessRequestC] Failed to decompress the Website_dictionary_language_en-in.xml language file 0004f225c152|0126215931|sys|*|03|0x94f7d7a0 (httpd): memPartAlloc: block too big - 99307 in partition 0x94daae6c. 0004f225c152|0126215931|utilm|4|03|utilBufferDecompress Couldn't realloc 99307 bytes 0004f225c152|0126215931|cfg|4|03|Web|[cfgSaProcessRequestC] Failed to decompress the Website_dictionary_language_en-in.xml language file 0004f225c152|0126215936|sys|*|03|0x94f4cf50 (httpd): memPartAlloc: block too big - 49653 in partition 0x94daae6c. 0004f225c152|0126215936|utilm|4|03|utilBufferDecompress Couldn't allocate 49653 bytes 0004f225c152|0126215936|cfg|4|03|Web|[cfgSaProcessRequestC] Failed to decompress the Website_dictionary_language_en-in.xml language file 0004f225c152|0126215940|sys|*|03|0x94f64700 (httpd): memPartAlloc: block too big - 99307 in partition 0x94daae6c.
The log files continue like this, I have attached two HTML files with 50 log entries in each.
Edit: This appears unrelated to the crashing handset issue as it's just relating to reading language files out of flash. I managed to remote reboot the handset which restored the web UI, but I'm wondering if this read error is related to the phone eventually locking up?
to troubleshoot this myself would be outside the scope of the Polycom community as a Polycom employee.
We would need you to go ahead and escalate this as initially replied and specified within my signature.
I suggest you check the logs from booting up to check for any errors appearing there.
I stumbled upon your post while searching for more information about my own problem. I have an IP 650 phone that is displaying remarkably similar symptoms to your 450s. I initially thought it was related to the sidecar, but I now believe that it is a software bug -- specifically, a memory leak.
I believe that the fact that you see the language file decompression errors in your phone is coincidental, and that the problem likely has nothing to do with reading the language file from flash. It probably was trying to do just that at the moment these events were logged, but I suspect the problem was not strictly with the reading of the file from flash, but the fact that it was unable to allocate enough memory (RAM) to load the contents of that file into, because the memory leak had by that time caused that much RAM to be unavailable for allocation.
As far as I have been able to tell, the "Dialog session is not found" messages you are getting are also related...we will see streams of those in the logs from the phones that are running with a configuration that includes certain parameters which seem to cause the bug to assert itself, but we will not see those same log entries (nor the "memPartAlloc: block to big" mesages, nor experience phone crashes/hangs/reboots) if we take the implicated parameters out of our configuration files.
In our case, the problem only occurs when we configure some of the line buttons to act as BLFs for other extensions using the attendant.resourceList.x.address parameter. Is it possible that you have one or more of the line buttons programmed as BLFs on your 450 phones as well? If we rip those lines out of the configuration, the problem goes away.
I started another thread about our problem here: http://community.polycom.com/t5/VoIP/SoundPoint-IP-650-lockups/td-p/50317 -- I will be trying to file a bug report with Polycom through our distributor, and I would encourage you to do the same. Until this bug is fixed, we have a ~$250 sidecar on our 650 that is useless to us.
I am having these same problems on 550's and 650s with 3cx version 12 and phone firmware 220.127.116.1153. I am in the process of downgrading a site with over a hundred phones to 18.104.22.16833 to see if this resolves the issue.
as already replied to the original poster this is something that needs to be troubleshoot via your Polycom reseller.
It is of utter importance to get this to our support team so we can troubleshoot such isolated incidents in order to fix any issues in the field.
You would need you to go ahead and escalate this as specified within my signature.
I suggest you check the logs from booting up to check for any errors appearing there.
We were having similar issues with 4.0.2B before we upgraded to 4.0.5 to see if doing so would resolve the issue, and it didn't. So I would be surprised if downgrading worked in your case. One thing I did not do, however, was attempt to collect logs from the phone while it was still running 4.0.2. Now that I know how to collect logs from the phone, I may try to downgrade to 4.0.2 and see if the issue we were facing with that version was the same or not.
I have a case # with Polycom now via my reseller, so we'll see if they can manage to reproduce these crashes in a lab environment. You and Jonny M should also do the same...the more open cases on this issue, the more attention I'm sure it will get!
In the meantime, if you have any BLFs defined on your line keys, try removing the configuration for those BLFs. We have found that doing so causes the crashes to cease.
As I speculated in another post here in this thread, I believe Jonny M and CrashDodson's problem to be related to mine, which I posted about in another thread (linked elsewhere). In my case, I had tracked down the problem to the presence of BLFs configured on my 650 phone; without the BLF configuration, the phone does not crash. My guess was that Jonny M and CrashDodson also were using BLFs but failed to mention it, because they did not yet have any reason to believe that it was at all related to their issue.
Neither Jonny M nor CrashDodson have publicly confirmed my suspicion in this thread, but I did send Jonny M a private message, asking him if he was, in fact, configuring BLFs on his crashing 450 phones. He confirmed for me that, yes, in fact he was. I hope that he does not mind me quoting from his responses:
"Thank you for your message. You just jogged my memory - I thought I hadn't made any configuration changes to my system before the crashing starting but I was only thinking about firmware or network changes. I did add BLF information about a week before the handsets first started having issues. I've removed a couple of handsets from our provisioning server and entered the SIP details manually to see if the problem comes back - as I didn't add any BLF information [this time around] I presume that it won't. And just to add some context to the amount of 'load' being placed on the BLF - there is only one BLF in use on each handset to show the status of a manager in a private office (on the same LAN). The handsets are members of a ring group that maybe receives 20 calls a day. The handset that the BLFs are all pointing at might make 10 calls a day. I would be very surprised if the volume of calls was causing this (as opposed to a bug)."
So now we have confirmation that two people suffering from this issue (myself and Jonny M) have this in common.