Calls ringing extensions not in hunt group 2

[MightyMrMatt]

Client has IP Office 9.0.12 on a PBX with a PRI. External calls come in to AAs which then route the calls to the appropriate HGs. However, some of the calls are ringing extensions that are not in the hunt group. The calls show up for extensions in other hunt groups. So if someone calls office A, they get the AA for office A, press an option on the menu, then it send them to the HG for office A, but for some reason, it is actually ringing an extension at office B.

There is no forwarding on the extensions for office A's HG and all I see in the call logs are that the calls are going to the correct HG. Any ideas what I might be missing?

 

[IPGuru]

you either have the AA programmed incorrectly or the group you are transferring to programmed incorrectly.

Cant say much more as my crystal balls are broken. Probably best to call your maintainer


Do things on the cheap & it will cost you dear

 

[janni78]

What you're missing is a Monitor trace =)

"Trying is the first step to failure..." - Homer

 

[MightyMrMatt]

I am the maintainer.

The AAs are set correctly with the HG for the correct office. Group contains only the extensions from that office.

I guess I could try to monitor trace it, but it's an intermittent issue, maybe 5% of total call volume.

 

[IPGuru]

you definitely need to capture traces of when the issue happens
I would recommend both a system monitor trace & a System status capture

this issue will be either a programming error (but that would be consistent & not intermittent) or a user error, does the client use pickup, this can be the cause of getting the wrong call.


Do things on the cheap & it will cost you dear

 

[MightyMrMatt]

System status tells me nothing. I can watch the calls go to the correct HG, but it's ringing an extension not in the HG. I'll try a system monitor, see if I can get lucky enough to capture one.

 

[snowman50]

what voice mail type are you using..Embedded ?

how many voicemail ports do you have..are they congested

do you have a fallback on the ICR route to another hunt group or extn..
is it always the same extn or are these users in a hunt group that receives the call.

could be the call cant get to a voicemail port and drops to the Fallback destination..

all worth looking at..

 

[MightyMrMatt]

Using VMPro, but there are no congestion errors on the PBX (24 VM channels). There are no fallbacks set up in the ICR, just the HGs.

 

[gkittelson]

I'm sure you checked this, but what about forwarding on one or more of the extensions in the hunt group? Perhaps that's why it's random depending on the status of the phone it's being forwarded from?

 

[snowman50]

Set up a short code to test the module to see if the same thing happens..

With out screen shots or more details off how your AA s set up it will be hard to tell what is happening.

Does it happen immediately or is there a delay before it goes to the wrong extn .

Is there queue timers set to route call to another group or user.i

Is there an option for the caller to dial the extension directly.

What happens if they don't press an option.? where does the call go

 

[MightyMrMatt]

Forwarding was my first thought, but there is no forwarding on the extensions in office A.

AA setup is pretty simple. Press option 1 or 2 to go to office A's HG. The HG has a queue with one extension and overflows to another HG with a queue with 4 extensions in the same office. The calls that ring to other offices can happen in either queue and happen collectively with the extensions in the queue. If the user doesn't press an option, the menu repeats up to 3 times, then disconnects the caller.

 

[IPGuru]

There are no fallbacks set up in the ICR, just the HGs.

Not related to your current issue but potentially poor programming practice - hat happens to calls if/when the VM Pro fails?

If the user doesn't press an option, the menu repeats up to 3 times, then disconnects the caller.

More bad practice - what happens if the cust receives a call fro a potential customer who does not have a DTMF telephone (They do still exist)? customers should realy be disuaded from this practice (known as Voicemail Gaol) whenever possible.

fundamentaly with your current issue, either the incorrect phones are in the overflow groups or the caller is coming in on a different route to the one you think it is

you need full traces of a failed call to have any chance of identifying this


Do things on the cheap & it will cost you dear

 

[MightyMrMatt]

So after all of this, the cause of all of this trouble was the end users using Call Pickup and not owning up to it. Sheesh! Thanks for your help everyone!

 

[joe2938]

IPGURU called it earlier in the post!

 

[MightyMrMatt]

Yup. Should have known...

 

[IPGuru]

So the fix is to reprogram the pickup option to a call pickup members so that the users can only pickup the correct calls.

Either with a dedicated button on the handset or by creating user short codes to override the default *30 if that is what they are using


Do things on the cheap & it will cost you dear

 

[MightyMrMatt]

Thanks IPGuru! I've done exactly that. I appreciate your help!

 

[IPGuru]

a star (on the post that identified the problem) would be nice


Do things on the cheap & it will cost you dear

 

[MightyMrMatt]

Yeah, I starred the wrong one. Extra star for you!