Phones keep ringing in Hunt Group

[1QuickQuestion]

I searched and found similar posts but all seemed to be outdated so that's why I am creating a new thread.

We are using IP Office VM Pro 6.1

I have 4 receptionists at different offices. If an incoming call is unanswered at one office before 3 rings, the call is forwarded to a hunt group to include all receptionists.

This process was implemented for over a month ago and since then there have been a handful of times where that same incoming call will ring back over and over. If you try to pick up the call, no one is there and the phone keeps on ringing. The ring is a full ring either, more like a half ring where it sounds like the caller hung up, but the half rings are non-stop.

The only solution I've been able to relay is to unplug the phone at all of the receptionists desk when this is happening. It's random and not specific to a receptionist.

Has anyone experienced this? On our Xima Chronicall log, it shows the incoming call one after another and the receiving party is the hunt group.

Thanks in advanced.

 

[SCNIPOffice]

This sounds very similar to an issue I experienced:

http://tek-tips.com/viewthread.cfm?qid=1606326

You mentioned four offices--are the offices in an small community network? If so, mesh or star configuration? While less than ideal, switching to a star configuration for us made this issue go away. I haven't been brave enough to try again since R6 though and now we're on R8.

 

[intrigrant]

I think this is related to the external lines and the SCN lines do not have unique incoming/outgoing IDs.
The the IP Office does not know when a ringing line is abandoned by the external caller.
Using unique line IDs is mandatory within a SCN.

If it ain't dutch it ain't much

 

[1QuickQuestion]

Thank you for the responses. I guess it happened again Friday when I left for the day and one receptionist was able to stop the ringing by unplugging her phone.

SCNIPOffice, we are all in SCN and I believe it's star. I've seen the layout and how the offices are all connected if that's what star means.

intrigrant, the lines do not have unique DIDs. All calls come into the main office and go out to the offices VoIP. Depending on which office number the caller calls directs them to a specific AA using VM Pro Client. Once the call is directed to that office's receptionist, if she does not answer it within 3 rings, the call is forwarded to the receptionist hunt group. <-After writing that statement I realized DIDs may not be the case.

I have another hunt group forwarding similar to the receptionists but for accounting dept. Same idea and setup and they have not experienced this problem. The only difference is that accounting dept is in the main office where the phone system resides and call forwarding is not being sent across the state...hmm

 

[1QuickQuestion]

Well I switched the ring mode from Collective Call Waiting to Collective. I thought the first would be good because call waiting can be displayed still. But if the receptionist is busy, the call should go to the hunt group anyways sooner without the receptionist being disturbed.

Lets see if that function fixes it.

 

[SCNIPOffice]

You'd need to look in manager to see how the SCN was setup. In a star configuration, there's only one path between any two IP office devices. In most cases, this will look like a device serving as the hub, with spokes going out to each IP office.

IP office B, C, and D all have only one path to A which has paths to all three. A call from B to C goes through A.

In a mesh configuration, multiple routes exist between each SCN member. That means there's likely a direct path for each IP office. So, every IP office connects to the other three directly.

Changing the group type from Collective Call Waiting to Collective shouldn't make a difference--the half ring that is constantly ringing and can't be picked up was, in our case, the system presenting the call over and over across the SCN to all extensions creating a sort of "echo" that would not stop--there was no way to actually answer the call. You could see it in monitor and system status happening. We had a large number of extensions on the affected hunt group, though, so we never tried unplugging an extension to see if that would stop it. We would just reboot one of the IP offices and that would resolve it.

SCN mesh routing was new in R6. The point is to create a network that doesn't depend on one particular IP office being available for the entire system to work. Could not resolve the issue and again have not tried in R8 to see if it has been fixed. I know in R7 it still existed as an issue for us.

It would not happen if all members of a hunt group were local to one IP office, which sounds eerily similar to what you're describing.

I'd check the line configurations inbetween each SCN and see if there's multiple setup for a mesh configuration or if it's star. If it's mesh, change to star and the issue will go away.

 

[1QuickQuestion]

Oh ok, our system is mesh definitely.

This issue just started when I created the hunt group (1 reception from each office) and that is the only ones effected.

This system was setup before I started so I'll have to find out the reasons for mesh vs star. Can you tell me some benefits from using mesh vs star? And how can I check to see what "version" my system is (R6, R7, R8)?

 

[SCNIPOffice]

Mesh, in theory, is more tolerable of any one system going down because there's no one point of failure for the whole system. However, with IP Office, if you're using Voicemail Pro, then the location and redundancy of your Voicemail Pro system comes into the equation as well depending on how you're using Voicemail Pro. Mesh, however, seems to be bug ridden when using hunt groups and there seems to be no fix or workaround for this particular issue. Great to hear that someone other than me has reproduced it though!

If you are extensively using Voicemail Pro as an auto attendant or to do some interesting call flow things, then availability of the Voicemail Pro machine and the associated IP office may be crucial to everything working. You can setup a redundant Voicemail Pro (without any additional licensing) at the same site, different machine OR have another licensed Voicemail Pro machine somewhere else in your organization.

In our case, VM pro is essential and only at one location, so we've got a single point of failure with our main location with or without a star configuration. You just have to figure out what's important to you--mesh vs star and whether or not there's a workaround for what you're trying to do. I've never tried it with anything other than collective, but I wonder if you'd have better luck using a sequential ring group and relatively short no answer timers. In theory, you'd have only one extension ringing at a time so I wonder if that would impact this.

For us, I never found an exact pattern that would cause it to happen--only that it didn't happen on every call, but would undoubtedly happen at some point causing havoc on all associated extensions--in our case, about 20 across multiple offices.

Check the manager help files for more information on mesh vs. star.

 

[1QuickQuestion]

Thanks for your help and knowledge, SCNIPOffice. I emaailed our install tech since we still have 1yr technical support available but I have not heard back from him. I'll ask him these questions and see if there's another work around with what I want accomplished.

 

[1QuickQuestion]

So far it has not happened again since changing the ring mode. No other troubles have been reported since making this change either.

 

[1QuickQuestion]

Well I thought this has passed, but it hasn't. This occurs at least once a week.

Has anyone experienced this problem and find any solution?

Recap: We're a mesh SCN and the only phones effected are the phones in the huntgroup. We have 4 offices involved in the huntgroup with 1 extension at each office. If a call does not get answered the call is forwarded to the huntgroup where the original targeted caller is also a member of that group. The problem is that when another extension answers the call, the system puts a "phantom" call through the huntgroup and only does a half ring and hangs up but rings back immediately. Basically, no one is on the other end of the call and all phones in the huntgroup ring and it's unstoppable.

Solution: I've told the few that are in this huntgroup to unplug their phones and let it sit unplugged for a little while and then plug it back in hoping that the phantom call drops. My new solution if phones are unable to get unplugged is to reboot their office's phone system.

If anyone can help or give recommendations on how the system should be set up, I'm all ears. Thanks in advance.

 

[intrigrant]

Analog lines I presume? That is the cause of all evil, try to enable disconnect clear and if the provider don't have that make sure the busy tone is recognized by IP Office.

A simple mind delivers great solutions

 

[1QuickQuestion]

Thanks for the reply intrigrant. I'm not sure where to enable disconnect clear. I assume it's analog lines. All calls coming into the offices are analog, right?