Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Extensions can't be routed from automated attendant--temporarily 1

Status
Not open for further replies.

damascus9

Vendor
Jul 2, 2007
61
US
Hi All, I experienced a problem last week that was quickly resolved but I need to document a root cause for my client. The issue was callers could not dial extensions from Voicemail Pro autoattendants. I was driving while this was reported to me so I don't know if DTMF tones weren't recognized or if the calls actually transferred but audio simply was lost. Calls from extension to extension across SCN trunks were not affected. Customer is on Server Edition 10.1 with Centralized Voicemail. Right before this happened I was making a lot of routine changes on multiple control units, adding and deleting users, but that's it. After I restarted the IP Office and Voicemail Pro services in Server Edition normal operation returned immediately. I checked System Status and Server Edition syslog messages but didn't find any relevant error messages.

Anyone experience this before? I feel it may be a touch-tone recognition issue because intermittently I can't complete calls when dialing extensions from this client's autoattendant when calling from my desk phone, but calling from my cell phone works; but this would seem to be an issue from my own phone system, not the client's.

Thanks, input and shared experiences is greatly appreciated.
 
Yes we have had the same issue.
But to answer your question it is mandatory to know:
which versions and types of install
We had this issue on a IPO500v2 on R10.1 with a ugh, UCM running VM and One-X Portal, SIP trunks only.
It started on R9.1 but after a upgrade with several ServicePacks and finally to R10.1 it was not solved.
The problem is no DTMF send to VM, not on internal or extenal calls.
And only one customer with this issue.

No solustion from Avaya so I solved it using a rude method: a forced restart of the VM Pro service every 24 hours on the UCM.
As it is inux I wrote a new Crontab rule on the UCM to restart the service every night at 02:00 hours and the problem never came back.

Crontab explained :
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top