I was wondering if you anyone has run into this particular situation with a UC320 before. The auto attendant works perfectly as long as the caller is on a land line. If they call in from a cell phone then the system completely ignores all button presses. I’ve tested it with three different cell phones and every time the system acts as if no choices are being made. Is there a way to make the system responsive to cell phones? I can make the same call with a land line and navigate the AA menus perfectly. We are running the latest version of the firmware and using AT&T analog lines for input to the system.
There are some tips for isolating faults like this in the Troubleshooting Guide. Based on your input, I would suggest seeing if you can isolate the issue to certain lines and then making sure that you run the impedance matching tool to properly set the impedance on those lines. If you've already done that and it doesn't resolve the issue, try increasing the Rx gain on the suspect FXO lines in small increments and test to see if you can eliminate the problem. If none if these ideas help, you might need to open a case with the Small Business Support Center.
I had a similar issue, only in mine, landlines from certain Lucent systems had the issues. But it seems like the corrections listed did help. The impedance test does take some time (about 7 minutes per line,) but is functional. And be careful with the gain; increase it very slowly. Too much recieve gain boost, and calls will sound horrible. Good luck!
Before the latest firmware, we only had this problem on calls from a particular carrier. Since the latest firmware, we have had to completely disable the Auto Attendant while we troubleshoot. I have adjusted the line matching and am currently increasing the receive gain. Thus far no luck. We have no DTMF recognition at this time.
That's certainly not what I was hoping to hear. I did the impedance matching and it may have helped just a bit. I still had to press the button on my phone 3 times before it would actually accept the input. I'll try adjusting the gain a bit but it really sounds like Cisco has a gremlin at work. This is a mighty frustrating problem for sure. Thanks to everyone for the input.
I also noticed much poorer DTMS detection after the update. Before the update, I didn't even go through changes to the FXO ports, it just worked. I thought it was just my imagination. Hopefully Cisco can do some more testing and root out any DTMS issues. One has to figure it's tricky, with all the different types of line and sources (PBX, Cell, POTS, VOIP, SIP, etc.)
Kris / Mike / Dave,
I would encourage you to please open a TAC case on this so that action can be taken immediately if there is a problem with our software.
We are having the same issue on 2 different systems. I have run the impedence testing, and made the recommended settings. With those recommended settings, we see that cell phone users can't type an extension. Prior to making the recommended settings (and if I put them back to default), the system accepts the numbers, but typically won't transfer to an extension and gives the caller a fast busy signal.
On my personal phones, I can call each of the two offices with my home line (I use Charter telephone) and I get the problem above. On my AT&T Windows 7 HTC phone, I can type the extensions and get through.
The upcoming 2.1 release will have some adjustments to the firmware to help with DTMF detection for AA. Have you tried increasing the gain settings by +3dB on the receive side in the meantime?
I have tried going through the impedence matching, and when it is set to unknown (in both of the two units I have at two locations), the dtmf works, but transfers to a fast busy signal.
After the impedence matching and setting to the recommendations is when the dtmf issues occur. In both cases I have changed the gain by +3 (no luck), so +6 (no luck) and then +9 (on my customers' unit, and this removed all the static he was getting and he said the volume was now perfect), but no luck on the dtmf...
I'm setting the gain only on the receive side, not the transmit...
Can you give us a solid arrival time for 2.1? My boss is getting very annoyed by the AA not working, and he's about ready to scrap the entire project. This is beyond critical at this point.
We're looking at offering a "Plan B" sometime next week, which is taking the 2.0.9(3) software version and adding a few key bugfixes while the engineering team finishes their work on 2.1 release. Watch for an update on this forum next week.
Patch seems to work. I notice that the issue of always having to restart the Configuration Utility is also resolved.
We're a bit miffed that it took two months from the time the problem was first reported, but thrilled that a resolution was finally made available. We were literaly days from ripping it out entirely -- not to mention actually selling it to someone else.
2.0.13(2) Limited Deployment has just been made available. This firmware release should address the issue. Please see:
I installed the update today, and it seems to be working. I have a few more incoming systems to test on, but the update seems to be doing the trick. The only issue I have is when logging in to the unit, it pops up an update warning, trying to get me to install 2.0.9 again. A bit annoying, but by no means a deal breaker. I'll update again in the morning. But so far, so good. Kudos to you and your team.
Sent from Cisco Technical Support iPad App