3300 Intermittent RNA when trying to access Voice Mail

[jaxuser]

I am a relative "newby" to Mitel trouble shooting and have been blessed with some strange issues of late. 3300 ICP MX controller running 6.0.5.7 with embedded VM. Intermittent RNA complaints when users try accessing VM from softkey. 20 ports total; last 5 do not answer when dialed directly so I am thinking that I have some bad ports. I removed them from the hunt group which seems to have appeased the users but, after reading other posts, think I might have caused some additional issues. I will be returning to site tomorrow for further testing.
Any direction would be appreciated. Could this be a bad DSP?

 

[kwbMitel]

Your software is quite old and the issues could be software related.

By removing the last 5 ports I am willing to bet that you have caused issues with your message lamps. Lamps will now be Dialed Message waiting against the final port only (which doesn't answer)

Try a restart of your system, the ports may recover.

If not and you can do without them, put the 5 ports back in the hunt group and create a new COS for them with permanent DND enabled. (just copy the existing COS and add the option)

You will have lots of fun turning off those lamps.

There is a feature access code to turn them off - Message Waiting Dialed - Deactivate (or something like that)

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[jaxuser]

Thank you for the insight. Controller was reset on Saturday to clear up issue of VM not answering and no local dialing; then this came up on Monday. We are talking with customer about upgrading since they are so old but that might take some time with today's economy.

 

[kwbMitel]

What costs other than labour time?

Software is free to download.

Software assurance is active until at least Oct 2010.

If the customer can't pay for a couple of hours to upgrade the system, ask them how much it costs them for it to go down in the middle of the day.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[jaxuser]

They're finding that out right now. Mitel has determined that there is a bad Quad DSP in the system so am awaiting part arrival. Meanwhile, no VM, no Paging. Should get the ok to upgrade this thing once I get it back up and can get a good backup.

 

[IrwinMFletcher]

Paging doesn't require dsp resources, unless of course they are compressed channels, but even then it should default to G711.

 

[kwbMitel]

Irwin, That was bothering me as well. If paging is affected then E2T resources are suspect. (Maybe both?)

Also, DSP problems would set off alarms on the system. None have been mentioned.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[IrwinMFletcher]

kwb, the only way paging involves the dsp is with compression or with echo cancellers (if on a CX for example, or base MXe). Echo cancellers shouldn't be an issue. Thinking about it some more, it could still be a compression issue if the controller wasn't reset. The components the control the call setup wouldn't know that the compression resources are gone, so it would attempt the call compressed and it would fail. That being the case, it's not just paging, but any other compressed E2T call.

There probably won't be an alarm if voicemail is involved. If it sends a request to outpluse a DTMF digit, but the dsp doesn't respond, it will just give up. You will only get dsp alarms if there is a critical failure on the dsp. If it just decides not to 'talk' to someone then it's up to the component (voicemail in this case) to decide if it's a problem or not.

 

[jaxuser]

I apologize for the delayed response but have had my hands full tracking part, etc. Replaced DSP and system went into auto reboot; moved new DSP to new slot per Mitel and system booted and all services working now.
Mitel had looked at the service logs yesterday to determine that the DSP was the issue. Voice mail ports stated idle in ESM but vmPortStatusInfo showed all as "PlayingVoice".
Thank you kwbMitel and IrwinMFletcher for your posts.