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

Very odd Hunt Group issue

Status
Not open for further replies.
Nov 30, 2007
15
US
Greetings all.

I am having a very odd issue at the moment with a circular hunt group that jumps via two locations.

We have 3 locations with a primary and secondary 3300 controller. The hunt group consists of 4 users in location A and 4 users in location B. Lets say that the hunt group contains the following users:

Extension
101 – Location A
201 – Location B
102 – Location A
202 – Location B
103 – Location A
203 – Location B
104 – Location A
204 – Location B


If I create a hunt group with just the users at location A it works fine from all 3 locations. If I begin to add users from site B we experience the following symptoms:

1) On some calls answered from a user at location A they can’t hear the person calling in, but the person calling in can hear the person at site A.

2) No calls at location B are ever dialed when somebody dials the hunt group. The hunt group will cycle through ONLY the location A numbers.

3) Once we hit a location A user that is experiencing symptom 1 the hunt group will continually attempt to dial that extension. So if the hunt group hits 101 and 101 can’t hear the incoming caller EVERY hunt group call that follows will attempt to hit 101.

Obviously there are correct routes between all our controllers and every extension can be dialed without issue directly from another location or from an external call.
 
You don't mention setting up the necessary config in the remote directory for creating networked hunt groups.

Am I safe in assuming you have actually done so?

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
I believe that everything is configured correctly based on the Mitel help documentation for setting up a networked hunt group but I am still experiencing the same issues as indicated in my original post.
 
This is really annoying the hell out of me. Anybody have any other ideas?
 
Please confirm that SDS is enabled on both systems.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
I may have misled you, but I'm not sure.

For Resilient Hunt groups, SDS must be enabled to syncronize the groups.

I believe the same is true for Networked hunt groups but I can't find supporting documentation.

Still looking.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
It's important to confirm that these sites are clustered as the Networked Hunt Groups make use of the Remote Directory field which is used in a cluster

Can you confirm?
 
Hi wishitwascisco

One other thing to try is create speedials for the DN's on remote controllers in the local controller (where the hunt group is located) and put the speedial numbers into the Hunt group assignment (only needed for the ones on other controllers)

Remember reading this somewhere about for Networked Hunt Groups the remote numbers can only be PDN's or Speedials

Let me know if this works

Matt
 
Found the DOCs.

SDS is not required for Networked hunt groups (only resilient hunt groups)

Key Points
- Software must be rel 7.0 or later
- Trunking with Qsig not supported
- Only DPNSS trunks supported (T1/E1,Xnet or IP)
- Hunt group must be Voice type
- Remote Directory numbers must NOT be resilient with local host
- Remote Directory Numbers must have entries in the remote directory form
- The hunt group Pilot must be unique to both systems and accessible from both (input as remote directory number on remote host.)
- RAD's not supported

Do you meet the requirements above?


*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top