MiCC 8 DNIS

[Ceaserx]

I have a clustered 3300 system with redundant ivr ports between two gateway controllers, when sending a call to the redundant IVR port numbers the call does not pass the correct DNIS information along. Instead I get the CEID followed by die IVR port number, instead of first passing the hunt group number. I have made sure all the DNIS numbers with or without the CEID digits are in the IVR workflow. The issue is that i am getting the ivr port number as DNIS instead of the hunt group. Any suggestions?

 

[augustD2]

If you are using a MiVoice Business running MCD 8.0, please see article RE1944 in our Knowledge Management System regarding a known defect in DNIS linking. A relink fix is available for MCD 8.0 and PR1, or you can upgrade to MCD 8.0 PR2

Title
Preserving Original DNIS in Mitai is broken
Description
Summary

When the Shared System Option for Present Original DNIS is enabled, the option is broken and is no longer to preserve the Original DNIS in the Mitai Event on the conditions of routing via IP trunk/Cluster network.

If applicable, Mitai applications such as MiCC may not integrate properly using this option.


Affected Mitel Communications Director Version and conditions
MiVB 8.0 (14.0.0.90) and MiVB 8.0 PR1 ( 14.0.0.91)
All MiVB platforms in cluster AND Mitai application with the integration of preserving the Original DNIS across cluster.
Solution
Mitigation Plan
Download the Control Relink CC-44.0.0.87_SP1 from MOL and follow the instructions to apply.

Long term Solution
The official fix is scheduled to release in MIVB 8.0 PR2 or higher.

 

[Ceaserx]

Thanks for the heads up, but this is Mivoice Business 7.0 Sp1 PR2

 

[boycey9]

Had a similar situation previously and the number comes through to the IVR as redirect digits instead of DNIS so had to have a duplicate call flow with a redirect option instead. If you check the port logs you will see if this is the case from the entry that will be somthing like [REDIRECT xxxx] instead of [DNIS xxxx]

 

[Billz66]

I had exactly the same issue recently

i just added CEID DN to the DNIS rule in the ivr

- was checking for hunt group 6100

when call arrived via local trunks all ok
when call came across IP trunks was seen as 91026100

so i added 91026100 to the dnis match list and it worked

If I never did anything I'd never done before , I'd never do anything.....

 

[kwbMitel]

Just adding a couple of thoughts on troubleshooting methods from the perspective of you not having good advice already.

On the host system running the IVR, try dialing a local DN using the CEID + the Local DN and see if you have the same issue. This eliminates the IP trunk component of the issue

On the Host System add absorb X digits to match the digit length of of your CEID digits if you are using IP Trunk Programming and make call from remote system. Caution - if you are sharing the Trunk Attribute form this can have a wider impact but safe one.

If you are using Direct IP method, on the remote system absorb X (CEID Length) Digits in the ARS Digit Modification form. and make call from remote system. Similar caution but if you are sharing your mod digit form

This might help what component of the call is causing the fault.


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

 

[Ceaserx]

Thanks for all of the input/ideas. Have covered all your suggestions and still no luck. Will dig deeper next week and let you know if we get a fix

 

[kwbMitel]

My workarounds should have at least removed the problem if not successful in isolating.

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

 

[Ceaserx]

got the setting and it works.

Under shared system options
"present original DNIS"


Thanks for all your suggestions and help.