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 SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Reroute to Menu Node

Status
Not open for further replies.

cdpak

Vendor
Feb 17, 2009
105
0
0
US
MCD 3300 5.0
My current scenario is a incoming call to XXX-2273, which is Phantom DN Multicall which rings on 3 Exts. then after 20 sec reroutes 1st alt to its VM box which has appearances on the 3 Exts. Now the customer would like to this scenario to work during the day, but now at night be able to have xxx-2273 go to a menu where #1 would be the 2273 VMbox and #2 would be an External Number. When I try to reroute 2273 Night1 to the Menu Node 4121 (a phantom DN)which is rerouted to the VM Hunt Grp, the call goes straight to 2273's VMBox. I assume this is because the Mitel just sees 2273 being routed to VM and thus routes it to it VMbox. Am I just missing something or do I need to completely change how xxx-2273 is being handled? Also in trying to get #1 option to go to 2273 VMbox would I just be setting up a loop?

Problem 2, This Mitel is being used by two entities. Each have their own PRI. It appears in my testing that when #2 option of the Menu Node 4121 is pressed. The outgoing call goes out over the other entity's PRI, which is the 1st PRI on the Mitel. How would one force the call over the 2nd PRI used by this customer?

Thanks you in advanced. I have learned alot from this site.

















32
 
Issue 1:
Correct. As 2273 was the number of origin, it will go to it's mailbox. To get around this you can use nametag huntgroups to override this an send to another extension. Typically you can prefix the nametag HG with a *
Eg: *4121 in your case and forward it to VM which will send it to the correct mailbox.

Issue 2:
I imagine you are using tenanting to separate the entities? The VM ports are likely members of Tenant 1 and using their trunks.
If you reconfigure voicemail so half the ports are T1 and half are T2, you can send this to the T2 VM group and it should dial out through to correct trunks.

If you are not using tenanting on the system and just separating trunk access with CoR, Interconnects or the like, you can do the same as above and just allocate the VM ports the second CoR or Interconnect.

Hope that helps.
 
Thanks Jemson, Your suggestion for Issue 2 was correct. I changed the tenanting and the calls go out over the 2nd PRI.
I am not grasping what you saying for issue 1. From what I read the name tag for a Hunt Grp is just what is listed in the Telephone Directory. 4121 is call routed to the VM Hunt grp 4100. So I am confused where I would put *4121 and if I would change where 2273 is routed to at Night1. For a test I took an Ext that had no VMBox. Call rerouted that to 4121. But I got the Canned AA message"If you are using a touch tone phone...." I was able to dial 4121 and got the Menu and and was able to dial out.
 
Issue 1: I do not recommend using Nametag huntgroups to force integration unless the endpoint is the final destination. There are issues with calls routing back out afterwards
There are other ways to accomplish this but they can be more complicated.
One simple solution would be to use the personal directory of 2273 but that method would require that it operates 24/7

Issue 2 - simplest solution would be to create a separate ARS access code that accesses only PRI #2. That way you do not need to partition your VM

**********************************************
What's most important is that you realise ... There is no spoon.
 
Thanks All, I did partition the VM ports. And ended up just using the main AA for the XXX-2273. Created a VM box to catch 2273 messages. Two Greetings one for day that does not announce the #2 option and the After hours that does.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top