Hunt Group interfering with intercept handling for unassigned DN

[ACIMitel]

Confusing situation to a new user.

We rely on using the Intercept Handler - Unassigned DN option to route DNIS calls to an ACD queue. All worked fine until we tried to port a new batch of numbers. When ported the new numbers did not work - all others work fine. New number 7 digit range - 252-1001 through 252-1099. Since they are undefined, they should drop through to the Unassigned DN via the intercept handler - BUT it appears that a hunt group (2521) stops this and presents the caller with error message - Cannot be completed as dialed. Re naming/numbering the Hunt group solved the problem - Why? What am I missing? 3300 Version 40.1.2.10_SP1

 

[kwbMitel]

if you are receiving all 7 digits then yes, you have a conflict and as such the DN being dialed is not unassigned. When the 5th digit is dialed it cannot go back and instead will present reorder.

The best method to resolve this is to actually define the numbers and not rely on the intercept handler.

You can easily define a 7 digit speed call matching the inbound digits and then define the actual digits as the destination. This is much more reliable and flexible.

You will still have a conflict however. The hunt group will not ring until your conflict timer has expired when you dial 2521.

You can either renumber the hunt group or you can absorb and insert digits on your trunk group to make the number(s) unique.

E.g. Absorb 3 digits and insert 2** will make every inbound number 2**-XXXX. you would then define 2**XXXX as the speed dial as described before.

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

 

[ACIMitel]

Thanks for the explanation - We have thousands of DNIS numbers pointed to the incoming Digital Trunks (more than room for in the speed dial tables) Thus the Mitel installers designed the use of Unassigned DN interrupts. I guess we can use a combination of speed dial for small groups and number avoidance for long strings (like the 252-1000 through 1999) above. Not a good situation to be in at this time. Any other suggestions? Would a second interrupt handler have worked in the situation above? Which one? Again THANKS!!
OH - We use DNIS Name Tagging to associate the caller with the right account/location so when it works it works quite well in our situation.

 

[kwbMitel]

More than room for in the speedcall tables?

This would mean more than 3000?
(by default the system is limited to 1000 but this can be easily changed)

As for a different intercept handler, you might try "Directory Number Out of Service" but I wouldn't hold my breath.

If you have less than 3000 numbers I would still be recommending using speedcalls. With form imports it would only take a few minutes to program all of the numbers and import them.


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

 

[dryaquaman]

Try this:
Create a speed dial number of "2521*". Point to anything else - perhaps your intercept number.
This should actually use the conflict to your advantage.

There will be a delay when people dial 2521. However, when your DIDs route in, since the 5th digit won't be a '*', it turns it into an invalid DN like you're used to .

Dry Aquaman

http://www.university-music-on-hold.com

 

[ACIMitel]

Thanks for all of the responses - We have chosen a combination of the suggestions above - And yes we do have near 3000 numbers pointed here. Does anyone know if the size of speed call tables can be changed from 1000 back to 3000 without a reboot of the controller?

 

[kwbMitel]

A change of dimensions will always require a reboot. The system will actually give you a pop-up to inform you of such when you make the change.

A good source of extra memory space is lowering the default value for account codes which by default is 11,000 I believe.

Good Luck

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