Mitel 5000 ARS not working

[sespletzer]

I have a problem where our Mitel 5000 ARS stopped working. When trying to dial out from a phone using ARS, it says that it is an invalid/unknown extension. The system does not recognize PP040 as a valid extension for ARS.

[dwayneg]

That's unusual. typically the ext for ARS is 92000.  You can check by peeking at SYSTEM/DEVICES AND FEATURE CODES/FEATURE CODES, check ARS code.  If it's 92000, dial that from a phone and see if you hear ARS dial tone.  Then work back from there to figure out how PP040 got into your ASSOCIATED EXTENSIONS field instead of 92000.

[DND ON]

PP040 is used when programming Forward Information via On Line Monitor. The ARS feature code 92000 needs to be entered as outgoing in Associated Extensions.

[sespletzer]

92000 is set as the ARS code. When I dial 92000, I get "Invalid Extension Missing Number" message on the phone. I have confirmed that 92000 is set as the Outgoing extension in Associate Extensions.

[dwayneg]

I guess you checked to make sure OUTGOING feature code is still 8 (not changed to 9 by  someone).  Lets try making outbound call another way.  Make sure ARS ONLY is NOT on for any extensions in TOLL RESTRICTION.  Then dial a TG pilot ext (probably 92001)...do not press outgoing first.  If that works you can replace 92000 as outgoing ext in ASSOCIATED EXT to get phones up and running for now.  Then I'd try changing ARS feature code to something else and testing.  If it works, you can change back to 92000.  Sometimes a bit in programming gets messed up, usually changing it will fix it.

[sespletzer]

I have 92001 set now for the Outgoing Ext on all extensions now to get outbound calls working. no matter what i change the feature code to for ARS, it says invalid extension when you dial it.

[dwayneg]

Maybe ARS is broken?  Inspect your local FACILITIES GROUP (under SYSTEM/NUMBERING PLAN), make sure it shows 92001 as TRUNK GROUP and dial rules make sense.  Make sure local ROUTE GROUP shows LOCAL as FACILITIES GROUP.

[sespletzer]

Ok looking back through the database change logs, it looks like someone tried to add a CO Trunk group with an extension of PP040 and then removed it on the day the issue started. That person is no longer with the company so i am not sure why they would have tried to add a CO trunk group. My guess is that is why ARS is not working, regardless of what feature code we assign (92000, 92004, etc...)... is there a way to re-associate extension PP040 with ARS, there isn't a backup of the DB prior to the change so we can't restore a previous DB

[dwayneg]

I think you're on the wrong track.  PP040 would suggest that instead of creating a trunk GROUP, they were fooling with a trunk EXTENSION LIST.  The pilot number for a trunk group would be a 920XX number.  I'd look at SYSTEM/NUMBERING PLAN/FACILITY GROUPS, find LOCAL and view the TRUNK GROUPS/NODES field.  Based on the fact that dialing 92001 works (you can make a call), I'd expect to find 92001 (or other 920XX groups) in that field...anything else, it won't work.  Try that, then dial 92000 followed by a local number.  If that works fix your other facility groups for LD etc.  Then users should be able to use ARS when you change their OUTGOING back to 92000.

[DND ON]

I would back up the database and run it through DB Tester.

[sespletzer]

The problem is when i dial 92000 i get 'invalid extension' i have verified the feature code for ARS is set to 92000. i have tried changing it to a different number (92004, 92005) and i get the same result. I have checked to make sure the Route and facility groups are configured correctly ( we have 9 other 5000 systems that are all configured the same). i attached the database change log to see if anyone can tell what might have gone wrong

[Tech Electronics]

sespletzer,

I was hoping that you would have come up with an answer by now, but since you haven't then there are only two options left for you to get this resolved.

1. Re-key the database since you don't have a backup.
2. Post your database to allow other users to verify it. This may still require a re-key of the database.

I believe that you are getting hung up on the PP040 aspect when looking at the OLM. The system uses certain "extensions" in the background similar to the way the numbering plan is setup. We have little to no control over those, but it seems that PP040 is still being used for Manual Forwards as it should be. As for why someone was trying to create a CO Trunk Group with PP040 that would be a mystery as they would have had to turn on OLM in order to assign that as the extension of a CO Trunk Group; this would be an intentional corruption of the database which will most likely not show up on a DB Test.

Thanks,

TE

[sespletzer]

I was able to locate a backup today, but it was a reporting backup done through the system admin and diagnostics software. from a few months ago before the problem started. Can I use that to restore the DB.

[Tech Electronics]

sespletzer,

I guess you probably haven't been working on these systems long enough to know there used to be a report function within Database Programming which has since been moved over to the System Administration and Diagnostics Reporting Tab. These are just reports and not the actual database so there is nothing to reload from it.

Sorry,

TE

[sespletzer]

I have been working on the 5000s since 2006 during the InterTel  days So I am aware of the reporting from days of old. I just have never been faced with a problem like this and was seeking assistance. When you run reports in the new system admin and diagnostics you are running them against a "report backup" which is a copy of the database. The report backup is a Mitel database file so I assume I can restore from it
 just wanted to get confirmation before I tried the restore.

I stopped supporting our PBXs  last year when we hired someone to take over [the same person that screwed this up] so he didn't do a good job of keeping up with the backups

I will go ahead with trying the DB restore from the Report Backup file and see how it goes.