Hi Cisco Team,
I have a case that was just opened on the subject heading (SR619518489) and have decided to spear head the issue with that and the forums as this has pretty much brought the business to its knees
Phones: SPA-525G2 & SPA-508G
Connected: Via Power Pack and Ethernet no PoE Switch is used, and 1X Phone is using an Ethernet Over Power adapter as Wireless was very unstable and causing major issues.
Firmware: 2.1.2 (1)
First Issue: Can see calls coming in on the FXO line, debugs show that it is alerting phones but phones do not ring.
The issue has happened out of nowhere, reboots sometimes restore the system back but only partially meaning that one phone will accept incoming calls for a short period of time and then it just stops doing so on its own. Everything has been tried to try and get it back up and working short of resetting it to factory defaults, which is being reserved as last resort option, I would prefer to find out what caused this before I take that type of drastic measure still not knowing if that would even resolve the issue anyway.
Second Issue: Calling VM, you get prompt to enter password and then nothing but dead air, and if you talk the phone starts to squeal its A** off and the echo/feedback is out of this world, and there is no further engagement by the VM...
The problem here almost seems as though the VM is no longer responding to DTMF tones, after a while the lady kicks in and just says goodbye with no explanation as to what was the issue, it also does this on all phones.
The odd thing about this whole thing is that the calls will route to VM, and you can leave a VM on the system and it will show up on the SPA-525G2 as a deposit but you cannot access it at all, and Force-Night-Service also works so the system can route the incoming calls still but just not to the phones, and the phones lack communications between each other and also from the outside world.
This is a desperate situation as this is a surgery and they cannot take incoming calls, it is causing me all sorts of grief and I don't know if it is related to it being on the latest firmware or not.
Please launch the UC320W Configuration Utility then go to Services -> Feedback -> SBSC Report. Put in
619518489 into the SR field and submit. This will send the device's config file and attach it to the case.
Next, check the IP addresses on the phones, in particular the phone using the Ethernet over Power. Need to make sure the phone is on the Voice VLAN 10.x.x.x by default. If it isn't you may have to make the switch port that is connected to the Ethernet over power an access port on VLAN 100. Note: That phone won't be able to have a PC connected behind it.
What firmware version were they running before this?
Thanks for that, didn't know the service feedback worked that way and quite impressed about that function actually
I have checked your suggestion actually as this was another thing that played on my mind, the phones are registering in that subnet and even in CDP neighbors it is showing up in that subnet as well.
I truly am stumped and feel a little lost as I am so used to diagnosing on the UC-500, these systems are much more simplified that it actually makes you feel a little helpless in trying to work out issues.. If that makes sense
I am curious though as to how you can force the VLAN membership on a LAN port? I have checked every settings in the left hand side navigation menu and couldn't find it, is there something I am missing? I would like to try it to eliminate this as being a potential issue, even though the issue is happening to all phones not just the one using the EoP adapter.
That would depend on the kind of switch you are using. If you are using 300 series switches, you could veryify the VLAN assignments using Smart Design documentation:
Look for Using Small Business 300 series switch in here:
As the product evolves so will the available tool set. As for forcing a port to a VLAN, sorry, I wasn't clear. This needs to be done on an external switch. There isn't a way to do this on the built-in UC320W switchports currently.
We're looking at the feedback information you submitted.
Thank you for pointing that out The phones are using Power Packs and just connect into the UC-320W Switch Port as there are only two phones for the surgery.
We have now scheduled a cable technician to go out tomorrow and run entirely new cabling to all the phones, using Wireless on the 525G2 was a bad idea and then going to an Ethernet over Power adapter was clutching at straws I think.
I will let Ray Long know of our actions and ask him to put the case# in suspended mode until the cabling is completed and testing of the system is done, I don't want to waste support resources for something that could be fixed by stopping the whole work around nonsense with the cabling.
Thank you for all the help...
Hi Cisco Team,
I have been trying to call through to the support team all morning, I am unable to get through to anyone as I just get dead air as soon as I complete the process of going through the prompts.
Is there a problem with the UC Call center? And do they take calls from Australia on Monday's our time?
The situation with this client is getting worse, even after we re-did the cabling onsite, I am still unable to get phones to alert on incoming calls, it just goes to voice mail after about 15 rings (30 second timer).
I don't know if the system is stuffed or what is going on, I have restored the system using 3 other backups from different dates, and still no joy.
Just for the benefit of the wider audience, there has indeed been a problem today with the SBSC IVR and it is being looked at as I write this. In the meantime, we are working with David directly to try and resolve the customer problem.
MEH!!! Silly Monday I have dubbed today, what can go wrong has gone wrong
Thanks for all your help Dave, much appreciated.
Hi Cisco Team,
To provide an update to this issue, after going out and inspecting the physical infrastructure it has been determined that there was an issue with the cabling that was recently rolled out, once replaced there seems to be stability with the service and call routing is working to all phones.
Networking 101 "Check The Physical Layer" seems to have fallen through the cracks on this one and ended up being the last thing to check, I am highly doubtful that the issue resides with the physical hardware but more so with the cables feeding each device, which is now undergoing a more in-depth investigation.
The client has reported no further issues in the last 48 hours.