cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8531
Views
10
Helpful
34
Replies

Spa504g crashes - registration/drop issue

I have had an intermittent issue where users attempt to answer a  call, but the device(spa504g) freezes and the lcd gets stuck  "Answering". The  phone becomes unresponsive to any button presses; even  after considerable  patience. The call is eventually dropped, and if we're lucky the customer calls back. The only solution is to unplug the power  and repower the  device.

On the server side, the phone often remains registered  for sometime even  showing that it is still on a call. I think after  about 15 minutes the  registration drops. So if I attempt to repower the  phone before it  unregisters, it will seem to register fine but will  not actually ring on  any inbound calls. Most of the time I've resorted  to restarting services on the server which effectively brings the system  down, even if only for a minute.

I'm using 3cx phone system. Our server is collocated so all extensions are remote. Aside from this, we have no other issues

We have 5 end points at this location all SPA504g with  7.5.4 firmware. We have low call volume and I'm usually the first guy  to take calls 90% of the time. But I have swapped out phones and confirm  that it has happened on more than one device, even on previous  firmwares.

I can't reproduce the issue. It has happened about 5  times this week, but hadn't happened in over a couple of months prior to  this week.

I have experienced the issue ever since we went live with the system. So basically since everything was new out of the box.

I have created a support ticket with 3cx, providing syslogs for the phones, logs from the phone system, and wireshark pcap on the server. They say there is no problem on the server and that it is probably a phone/networking issue.

1 Accepted Solution

Accepted Solutions

Looks like v7.5.5 is still the latest firmware, but if you shoot me a message via my website below, I'll be happy to share the test firmware Cisco built for my SPA508G phones which has resolved the issue for my clients.

www.TechAdvantage.co

 

EDIT:  I've also attached the test firmware to this reply; unzip it first then apply to your phones (you'll probably need to use TFTP).

View solution in original post

34 Replies 34

nseto
Level 6
Level 6

Hi, you mentioned not able to reproduce but that you have logs and wireshark.  Can you send me those 2 items and the time of when the crash occured in the log/wireshark?  Send to nseto at cisco.com.  Thanks.

Thank you very much. I just emailed you all of the details and logs.

I just began am running wireshark 24/7 right now via

dumpcap -ni 1 -w e:\pcaps\some_log_files.pcap -b duration:1200 -b files:5

So in case the pcap I provided is not sufficient, I will capture the event again. Also because the issue occured twice on a different endpoint Friday and today.

Andrew Bucklin
Level 1
Level 1

My client is having the same issue with their SPA508G phones on various firmware versions, even with the latest 7.5.5.

Any suggestions?

So far nothing. When I first reported this, I was on 7.5.4 firmware but I am on 7.5.5 it has happend on all firmwares going back to 7.5.2b I think. Basically as long as I've had the phones (the only IP phoens I've ever owned). I don't have any other to compare to.

I Basically had to capture packets on my server 24/7 and capture packets on my LAN 24/7 too. On the server I could capture using wireshark commandline as I mentioned above. But on the lanside I can only start and stop.

So I was at the point of a daily routine, leave work start capture, get to work stop capture, download restart capture (otherwise pcap was going to get well over 1GB

Are you also using 3cx? if so what version, and if not, what system and what version?

I'm running 3cx V10, I know 2 versions behind, but generally aside from this issue not much else goes wrong. A couple other things I dont want to get into but are minor by comparison.

Same here. Our phones started out with 7.5.2b and I've tried every version up to 7.5.5 and they all lock up when attempting to answer a call sometimes.

Yes, I am also using 3CX version 12 with all the latest updates, interestingly enough.  Due to the lack of others experiencing this issue, I would imagine it must have something to do with 3CX, but I don't know where to start looking. Maybe some setting in the provisioing file (I already found one bug in the 3CX provisioning file template regarding ring tone selection and reported it the 3CX some time ago). Also, all of our extensions are remote as well.  Are you doing a direct connect from the phones to the remote 3CX server or are you using the 3CXTunnel?

Maybe a 3cx quirk, but they are adamant it is a cisco problem. They stopped supporting v10 months ago I guess so i can't get support anymore. But I think they might have some issues so I still think they may be partially to blame.

Only one device in my office is using the tunnel and ONLY because of a problem that just started happening... but even with the tunnel that devices doesnt ring in call queues.

So the other phones are all provisioned to connect remotely. Mostly according to their guide for remote extensions. The main difference is that since I have 5 devices in this location and so Stun is DISABLED. If you enable stun, then you have to manually increment the sip port on each device... although I think they have automated this in v11 and v12.

For me it is just as easy to leave stun off. The only downside is that we can't talk to extensions in other remote offices (no 2 way audio). But we dont actually have other locations (just when I work from home/vacation - rare occasssion).

Maybe if you can capture packets on your server and lan, as well as syslog for the phones I can pass your email onto him incase he isn't reading this topic anymore. I'm sure it would be nice to see another user experiencing this and hopefully nail this bug.

No response from 3CX with the ticket I opened with them.  The Cisco rep I chatted with yesterday followed up via e-mail today, which suprised me.

I just started the syslog capture on one of the phones today and am waiting for the client to update me with a timestamp of when the problem occurs so I can look at the phone's logs.

Come to find out, however, my client's problem is actually with placing calls (not receiving calls). When they try to place a call, intermitantly, the phone will lock up with "answering" on the LCD (but I could have sworn they told me in the past it also happened with incoming calls).

In version 12, you can specify the 'Local SIP Port of Phone' and 'Local Audio RTP Ports Start' and 'End' via the extension's phone provisioning tab, which I've manually incremented to ensure no collissions exist.

Hopefully we can nail this down. Maybe it's as simple as a setting that needs to be changed.

Would you do me a favor and have that rep look at ticket ID CSCuh94341

Apparently the person I was working with (Nelson Seto) no longer works with cisco, my last email to them just bounced. Maybe they can contact me and we can collaborate on the ticket.

The problem happened to me twice in a row this morning. I am capturing on both server and endpoint side now in case it happens again. Sadly I was not during the occurences.

3cx wont support me anymore since I'm still on v10 (considering a switch to asterisk). But they were blaming cisco on the issue last time I had a ticket.

My rep has stopped responding. I haven't heard back from him in a couple weeks. I just sent him another e-mail yesterday asking for the ticket to be escallated.

You should try going to the Cisco Live Chat and see if that rep can look up your old ticket.

Let me know if you get anywhere. Maybe one of us will get lucky...

I tried the live chat... thought I was getting somewhere but the email they provided bounced as well... I eventually started emailing the chat rep but then they stopped replying too.

I can't say I've had this issue occur since my last posting, but then again, I'm not exactly hoping for the day either.

I think we might have solved it, at least in our environment.  We tinkered with all of the settings and it appeared as though turning STUN 'off' has stopped the lockups from occuring. We had to edit the 3CX provisiong file since simply turning it off in the phone would only work temporarily until the phone reprovisioned itself which would re-enable STUN.

...So far, so good.  I hope this was the culprit.  We have been operating for almost two weeks now without any lockups on outbound calls...

In our configuration, multiple endpoints in the same office, we had to turn stun off. Otherwise we'd have to manually increment the sip port in all devices as I mentioned above. We've been configured like this for about two years now (I think, time flys by).

The only time I enable stun is if the remote extension is the only one on the lan.

I'll post again if it occurs. I've figured out how to anonymize packet captures so I'll be able to post those too.

Just upgraded to v12 a couple of weeks ago. I'm  considering a vpn between the server an our office vs using the sip  proxy manager.

So I hope that works for you but considering you were using it and I wasn't, but it still happened, I'm thinking probably not.

What was the frequency of this problem occuring for you?

I have a couple offices that have several remote extensions as each office. 3/4 of the offices are fine with the default settings. However one of the offices has this issue. I have incremented the SIP port via the extension tab under the 3CX console but that has not resolved the issue. I have to use STUN because the extensions need to talk to the other extensions in other offices.

Any suggestions? I did notice that it seems to happen when it says "next registration in 0s"

I received a response from Cisco this morning saying they were able to replicate the issue and are putting together a beta firmware update for me to try...

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: