Auto-Attendant announces there has been a System Error! and hangs up!


Hello All. I had a support case where the answer was right in front of me but I didn’t initially put my hand right on the problem. Actually there is two incidents and the customer was the same. Let me share both stories with you.

The first issue was an auto-Attendant who failed to use voice to interface with a user. Instead It screams out System error! In fact the error simply said there was a system error and hung up. It was very nasty and there was no definitive help in the event log or anywhere else.

The work around plan to fix this was to simply upgrade the Exchange CU and the .NET Framework version. As it turns out, even that would not have helped this situation.

So if your environment is just one Gateway, one Dial Plan, one Auto attendant and one Hunt group, there is a good chance you wont have this problem. However, that may also be the perfect situation for the problem. The issue looks like the product of recreating the Dial plan multiple times. Below is a good result. But what if the results were the same for three lines in a row? If you only have one dial plan, this would be something to be alarmed about!


Not so much the picture above, but the one below:

So with multiple hunt groups per dial plan, the search behavior changes and you may get an un documented failure. Not so much because its a problem failure, but

because, often times, documentation is written in terms of what some application will do, not what it wont do. So word to the wise, check your hunt hunt groups.

I saw the problem when you have multiple hunt groups and only one dial plan. I know there is also only one Dial Plan. But I think you can see how a seach outside of the local dial plan could render a problem.

When you run the get-UMHuntGroup command, You will see the Hunt group displayed, one for every Dial plan. This is an area where you may have old hunt groups pile up for dial plans you created and deleted.

Its fine to have old hunt groups, but if they have the same name, there could be a system error.

The system error occurs, If you have a ghost Hunt group object and:

the name of the hunt group matches the one your using for your production dial plan. and you have the “in the entire organization” checked in the address book and operator access setting in the auto attendant setting.


Changing the radio button to this dial plan only, protects the Auto Attendant for issues with other hunt groups, or dial plans. This is a lesson learned for me! My default setting is not this dial plan only! Such an easy thing to miss!

This seems more like a corner case then a call driver, but I have to mention it, as I am sure we will see it again! Have a great roman holiday!




Warning: Firmware update may not apply the configuration properly after update from Audiocodes 6.8 to 7.0 on Mediant 1000 and Mediant 4000



Good Day all. I found a situation today, which may be of concern to the Unified Communication crowd. I had a customer apply some of his experience with Audiocodes Devices, to find a problem which may be a function of the AudioCodes devices, or the update process, or both.

When applying the update to both the 1000 and 4000 machines there was an error which showed the gateway as not being able to communicate. In effect, the error showed on the 1000, but was clearable. The update to the 4000 took the voice network, for Lync and a third party, integrated voice company, down completely.

The only way to restore voice communication was to Recreate the Proxy set table for the various gateways they had in place.



This was not difficult to do, but how would you know? It was by my customers keen sense and experience that let him to the proxy set table. Instead of saying “OK”, it had a straight line. As in the figure above; you simply need to screen shot your settings, and delete and recreate the proxy set for that device.

what looks like is happening is the update is not applying the settings or configuration back to the device, after the update. There could be more issues, over this update. Be aware of this.

To conclude, this is not an official known issue. it is just an observation we saw today. It may be something you may be interested in if your upgrading your AudioCodes to version 7.0

I hope this is helpful to someone.