Our oldest UC320W user has a new issue driving them bonkers.
If you dial an extension from another extension, it rings, but there is no audio.
Incoming calls seem to work okay, we can call them, the AA answers and routes the call fine, and all audio sounds great.
Outgoing calls from any extension seem to work okay.
Internal users can dial the AA and be routed to an extension, but no audio.
Internal users can get their voice mail I believe via the handset.
Latest firmware. No changes to the config at all in ages.
Client rebooted the UC through the web interface. No change.
Our guy is there now... If you dial an internal extension from an extension in the building, the called party's phone rings.... But they do not hear you.
You can hear yourself echoed back though.
Are all the phones getting the correct IP addresses from the Voice VLAN (10.1.x.x) by default? You can view this by checking the Network status on the phone menu.
I think we'll need to get someone to take a look at the SIP messaging to see what is going on. A call into the Small Business Support Center can help guide you through the specifics, but if you can connect a USB memory stick to the UC320W, perform a TCP dump capture on the LAN side (best if you can plug the phones directly into the UC320 if you can).
We've tried just two phones and just the UC, and the exact same thing is going on....
Guess we can't do anything without a contract, and the client is just totally discouraged. =(
Cisco sent us a new UC320W (well a refurb) and we still have the same problem.
We have been on the phone for an hour or so today trying to diagnose this issue.
Here's the latest information that we have:
UC320W with nothing attached to it except two phones on it's LAN ports and the Charter Cable modem on the WAN ports (no switch, no anything), when you dial the other extension, you hear yourself, but you don't hear the other side, and they don't hear you.
After 15 seconds, the call is disconnected.
Calls to/from the outside, work perfectly.
To make this more interesting.... If we disconnect the Charter Modem, all is well....
We're still on the phone with tech support now.
Yes, we are using a SIP trunking provider -
No, we do not have a firewall in front of that UC320
Will post the resolution when we have one!
Just an update:
Cisco has escalated this issue, but still, it is unresolved.
No internal calling working at this client...
They are being as patient as they can be, but as you can imagine, a church that gets a lot of calls cannot possibly hold out forever... They cannot announce who they are transferring... Guess blind transfer works...
Our escalation team is working on your issue. The support engineer will need to collect the detailed syslogs.
Thanks for your patience!
Issue still not resolved....
Have tried the following now:
NORMAL system configuration with UC320 behind Charter Cable modem, switch, multiple phones, computers, servers all on the network - problem exists
JUST two phones and UC320W, connected to Charter cable modem - problem exists
JUST two phones and UC320W, disconnected from Charter Cable modem - NO problem
NORMAL system configuration with UC320 but WITHOUT Charter Cable modem, switch, multiple phones, computers, servers all on the network - NO problem
NORMAL system configuration with UC320 behind Charter Cable modem, switch, multiple phones, computers, servers all on the network but COAX CABLE disconnected from Charter Modem - NO problem
Remove SIP trunking provider from config - problem exists
Soooooooo, whenever the UC320W has an internet connection - this problem exists.
I am beginning to feel there is some kind of data stream (DoS?) coming in that is causing that to happen.
Charter Cable engineers do not show any kind of odd traffic though. We have their technicians on site now.
Charter Cable technicians replaced the modem with a new one.... Checked their equipment and all is good.
Still no joy.
Still no joy...
Today I am sending a tech out to place a cheap router in front of the UC320W, to isolate the UC from the internet in an attempt to see if this is some magic packet coming in over the WAN and crippling the UC.
We won't route anything to the UC in our test.
This has gone on for so long, the client is not amused. At all.