Mitel digital system, call forwarding issues.

[dgilson]

We have a customere who has a MitelSX200 Digital G1004 with T1 trunks. The trunks were recently converted from a direct T1 from Telco to a DSX connection on an Adtran router IA circuit. Since then, calls outside calls that are answered or initiated at the console or any other phone and are transferred to a phone at the site that forward to voice mail on a no answer condition get the wrong recording from the voice mail. Outside calls that forward due to busy or no answer get the right recording. Telephones are forwarded to a speed dial entry that provides the proper DTMF integration to the voice mail. Another speed dial entry is set up to retrieve messages and it is this recording that forwarded no answer calls get. Direct calls from one extension to another that forward on no answer DO get the correct recording; it is just transferred outsided calls. I have checked all COS, call re-routing, dial in trunk programming and can't find why the calls forward using the wrong speed dial entry. I know it's an old system but any help would be appreciated.

 

[kwbMitel]

Could you post the exact digit strings of the speedcalls?

Also, does the ARS between sites utilize Analog Networking Options?

**********************************************
What's most important is that you realise ... There is no spoon.

 

[dgilson]

Abbreviated Dial access code is *. Message retrieval: *005 = 799*91*6*9; Play greeting and leave message: *999 = 799*91*6*9. What is being sent to the VM during forwarding on a no answer call is 1XXX; on a busy, 0XXX. If I change the entry in 005 to be the same as the one in 999 the calls route correctly so somewhere the RNA outside call forwards to 005 instead of 999. I have found nothing in the Mitel system programming where I can set that value. One other thing, this condition happens on BLIND xfers. If you stay on the line during the tranfer, voice mail answeres correctly and then you can release the call.

 

[kwbMitel]

I think you slipped on your Copy and Paste. I see no differenc between *005 and *999.

*005 = 799*91*6*9
*999 = 799*91*6*9 but I think you meant 799*9[highlight]0[/highlight]*6*9

Am I correct in assuming that the 1 and 0 are conditional Greeting flags?

What type of voicemail are we looking at here?

I also don't remember the SX200 being able to set NA to a separate destination than Busy. Please confirm that this is what you are doing.

Sorry for all of the questions. G1004 goes back a ways and I haven't touched anything close to that old in about 15 years.





**********************************************
What's most important is that you realise ... There is no spoon.

 

[dgilson]

My bad, *005 = 799*91*6*9; *999 = 799*90*6*9. Voice mail is an InnLine; looks like the same integration as an Innovation. I also don't remember, nor can I find, anywhere that you can set a different destination based on call forward type or based on the call coming from a blind xfr trunk. The forwards work correctly, busy or NA if it's an internal call.

 

[kwbMitel]

You've changed 005 and noticed a difference in the behaviour of the call.

Have you tried changing the 999 speedcall to prove that it is in use when you test?

My memory says that it is not possible to split the forwarding. Although, as I write that statement I had a flash of a memory regarding a COS option and follow external forwarding.

Change the 999 speedcall and prove that it is in use while I look into the cos option.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[dgilson]

I didn't actually try changing the *999; I'll give that a go just for grins. The 1004 generic did allow splittng call forwarding for internal vs. external calls. That COS option is off in the COS's for the rooms, admin sets, console and trunks. I didn't find anything in the descriptor that could explain it either.

Thanks for checking.

 

[kwbMitel]

In your COS options, do you have an option 709?

What happens if a Call is made directly from a console to a station? Does it act like a regular phone or does it act like the transferred call issue?

**********************************************
What's most important is that you realise ... There is no spoon.

 

[dgilson]

According to the docs, 709 is not an option in G1004. A call directly made from the console to a phone that then forwards NA to VM gets the correct greeting. It only appears to happen on a transferred trunk call, although I did not try setting up a call from an ext to an ext and then tranferring that.

 

[kwbMitel]

At your software load, the Console is treated as an External Device. If the issue were due to External vs. Internal it would have shown up there.

We need to definitively prove your premise that *999 is in use for some calls before going any further. As suggested earlier, modify *999 and test again.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[dgilson]

I modified *999 to 799*91*6*9; xfred NA calls still got the path associated w/ *5, please enter security code. However now xfr to vm on busy got please enter security code also so the change to *999 caused that. Put *999 back to 799*90*6*9. This software is to old to use the speed dial index option 265 in COS so that's not where it's picking up the *5. Thanks

 

[dgilson]

This issue has been solved. It turns out that the call forwarding to voice mail was following the path specified in form 19 for DID calls into this tenant. The DID calls that weren't being routed specifically were going to an extension that was forwarded B/NA to the speed dial entry that routed callers to retrieve messages.

 

[kwbMitel]

That should have occurred to me, sorry. Now the forwarding makes sense. I just don't work with the 200 model much anymore.

**********************************************
What's most important is that you realise ... There is no spoon.