Incoming Call route to Hunt Group 2

[pbxman]

Hi everyone -

At the end of my rope here.
Incoming call route to a DID 123-456-7051 bypasses VMPro and Queues as if there are no time-checks or modules configured whatsoever.
Incoming call route to DID 123-456-7000 reaches VMPro and gets voicemail according to business hours, like I want.

The Hunt groups, incoming call route destination (VMmenu7051) and (Vmmenu7000) both have fallback destinations to the respective hunt group extensions, and 7000 works but 7051 will NOT reach VMmenu7051 no matter what I do.
In IPOffice Manager, these hunt groups are configured identically (pointing to the VMmenugrp first, then correct fallback group), same line groups as well.

Why does dialing the 123-456-7051 ignore VMPro completely? It just queues directly to the hunt group and bypasses all time checks, etc. I cant find anything different between the 7000 config and the 7051 config in VMPro modules.
Yes, the server has been rebooted also. 7051 works just fine if calling 7000 first (the main auto-attendant VMenu) but not if you call 7051 directly via DID, even though VMPro is set to the exact same config.

Hope that makes sense and someone knows what it going on. This makes no sense to me..
How do I confirm dialing 123-456-7051 reaches VMPro first before going into any hunt group/queue according to business hours?

Thanks!


pbxman
Systems Administrator

Please let Tek-Tips members know their posts were helpful.

 

[intrigrant]

Use sysmonitor to lag both calls and search for the differences, leave the filter at default but only enable shortcodes in the Call filter.

 

[holdmusic34]

First off- don't do it. If I can't then neither can you.

Break it down in to little pieces so the problem is easier to digest.
Change the destination of 7051 to a test extension and label the call testtest.
Works ok?
Good now you know you can throw it at a VM:<module>

Throw it at the working VM:<module>
Working ok? good!

Now throw it at the second 7051 module.
not working?

Try and access the module directly with a short code.
Within each step of the module place a recording such as: 'checking day or night mode''it is day mode' checking public holiday mode' it is/ is not a public holiday'
They're like breadcrumbs or check points through your module. You may find the system thinks it's a public holiday when you mean for it to be a working day. In that case swap your actions around.
This will help you find where it's going wrong. After it you get it working, delete the technician help recordings. This is what I do.

Poopy bubbles!

 

[pbxman]

IPOManager ignores any setting I choose for Incoming Call Route destination. It's like it doesn't even look at it, however if i go to the voicemail tab and turn on voicemail and set a low time threshhold, it goes to VM.

All I want is 123-456-7051 to hit VMPro, but I cant seem to steer it there. It only works properly when dialing 123-456-7000 (main auto attendant in VMPro) and it's fine.

The 123-456-7000 just queues immediately no matter what I set.
I'm going bonkers!

I'm a definity guy so this may be something stupid - i've been using system status to see "active calls" but it only tells me the main module it hits and not the full trace?
For the 123-456-7000 it shows me VM:menuMainDay (which is correct)
For the 123-456-7051 is shows the hunt group extension and "queueing" no matter what I toggle.

Gah!?

pbxman
Systems Administrator

Please let Tek-Tips members know their posts were helpful.

 

[holdmusic34]

Your digits in your incoming call route could be wrong. Sometimes for an indial I may need all 10 digits of a full national number, sometimes I need to drop the leading number.

Also in your Line> PRI settings, remove the national prefix.

National Prefix Default = 0
This indicates the digits to be prefixed to a incoming national call. When a number is presented from ISDN as a "national number" this prefix is added. For example 1923000000 is converted to 01923000000.


Poopy bubbles!

 

[IPGuru]

Are yoou using SIP trunks?
have you correctly configured the sip trunk to use ICR for call routing?

system monitor will probably still be needed for fine detail debuging

A Maintenance contract is essential, not a Luxury.
Do things on the cheap & it will cost you dear

 

[pbxman]

Woooo! Holdmusic34 ftw!
Incoming call route was it. The IPO manager is full of hundreds of entries for all 10 digits for our DIDs and alllll the way at the bottom there was an entry for just the last 4 digits of 7000 and 7051! Sure enough, 7000 was set for VM:menuMainDay and 7051 was set to go to the hunt group instead (incorrectly all along).
Changed it to the correct VM: destination and it worked like a charm.
Thanks again you saved my sanity!

pbxman
Systems Administrator

Please let Tek-Tips members know their posts were helpful.