Transfer Ring Time Out

[SFSRJSTW]

I have an odd question. I have two coverage paths setup...105 and 106. The only difference between the two is the number of rings. 5 vs 6. The coverage path information is below. When a call is transfered to an extension with coverage path 106, rather than covering to voice mail after 6 rings, it directs the call to the Operator. Can anyone explain why this happens? Is this something I can change? h99 is our Audix hunt group.

Coverage Path Number: 105
Hunt after Coverage? n
Next Path Number: Linkage

COVERAGE CRITERIA

Station/Group Status Inside Call Outside Call
Active? n n
Busy? y y
Don't Answer? y y Number of Rings: 5
All? n n
DND/SAC/Goto Cover? y y

COVERAGE POINTS

Terminate to Coverage Pts. with Bridged Appearances? n

Point1: h99 Rng: Point2: Point3:
Point4: Point5: Point6:


Thanks

 

[Zen216]

please post coverage path 106, since that is the one not working...

 

[SFSRJSTW]

Coverage Path Number: 106
Hunt after Coverage? n
Next Path Number: Linkage

COVERAGE CRITERIA

Station/Group Status Inside Call Outside Call
Active? n n
Busy? y y
Don't Answer? y y Number of Rings: 6
All? n n
DND/SAC/Goto Cover? y y

COVERAGE POINTS

Terminate to Coverage Pts. with Bridged Appearances? n

Point1: h99 Rng: Point2: Point3:
Point4: Point5: Point6:

 

[Zen216]

do the agents/stations that use coverage path 106, have mailboxes on the vm system?
try changing one of the stations that use cov p 105 to use 106 and see if the problem happens...
I really don't know, just throwing ideas out there..

 

[SFSRJSTW]

All the extensions involved have functional voice mail boxes on the Audix system. If I take an extension that has coverage path 105, and transfer to it, it will cover to VM after 5 rings like it should. If I take that same extrension and change the coverage path to 106, it will route me to the switchboard after 6 rings instead of voice mail. Is there a setting somewhere that says after x rings of no answer, route to the switchboard maybe?

 

[h5n1]

create another coverage path using 'add coverage n' should be your next one....ie 107, program it just like coverage path 106 and see if 107 works after 6 rings....if it does do a remove coverage 106 and just use 107. could be a corrupted entry in the coverage table i had that once....

 

[SFSRJSTW]

I created a new coverage path, 109, and set it up identical to 106, and I get the same behavior. Seems to happen with any coverage path with more than 5 rings in it.