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

Day/Night Greetings 1

Status
Not open for further replies.

Pheadrus

ISP
Jun 11, 2012
11
US
Mitel 3300 CX II Running 6.0 to AVST CX-e Voicemail.

During the day 3700 (main number) points to 4402 (random call processor AA options box) That is working fine. Night mode (Night1 or Night 2) Still plays the day greeting though routing is set up to go to a different CXe box - 4403

Routing:
3700 is a System Speed Call pointing at 4402
4402 Call forward allways Day:2 (mail) Night1:4 (4403) Night2:4 (4403)
4403 Call forward allways Day:2 Night1:2 Night2:2
4403 is a Nametag Hunt Group on the 3300 as requested by Mitel which should change the digits that the CXe system is receiving, but it is not.

If I take the CFA off of 4403 (change it to 1) During Night1 I get a busy signal (I don't remember what the phone says) Which is to be expected, so, the 3300 is forwarding internally correctly, but is not changing the digits that are going to the AVST system during the night.

AVST is not directly connected to this controller, its hunt group is on the primary controller in another location, if that makes any difference. All controllers in the cluster go to main then to cxe for VM, this is the only other site other than main running this type of AA.

So, why is the CXe still receiving 4402 during night mode, and how can I correct this?
 
The why is easy. Mitel is designed to retain the first called number for VM intergration. This is so that when you call extension A, and that extension is forwarded numerous places, when it goes to VM MB A answers.

**********************************************
What's most important is that you realise ... There is no spoon.
 
Sorry, didn't mean to submit above.

How to fix it is a little more difficult. Basically, you have to break integration.

The simplest method is to use nametag huntgroups. This method has some caveats however and I have no idea how that might work with a non-mitel VM

Using ACD paths would be my best bet and there is a convenient FAQ for that.

faq1329-6743

**********************************************
What's most important is that you realise ... There is no spoon.
 
Awesome! I have been working on this on and off for three days, this makes so much sense. Obviously I will need to build and test it, but I will let you know how it goes. Thank you!
 
Attempted to follow the FAQ. Call is still doing the same thing when routing through ACD to a dummy number.

The question that I have can be simplified.
The Controller is crossing an IPX trunk to get over to the Main controller that has the VM system hanging off of it.
All calls that hit the Main controller from this branch (and possibly all of them)are coming in as the origional dialed number - So, if I have 3700 built as a hunt group, passing it through the ACD system is not changing its ID over to the main controller.
Is there a setting that I should change for this IPX trunk that will allow for those redirects between controllers?

Thanks again for helping to look into this issue.
 
Well, it did work correctly this morning using the ACD system.

The issue was that we were attempting to test internally, which caused the VM system to do something odd.
Testing from the outside worked perfectly.

Thanks again for the help!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top