External calls transfer to attendant after "x" number of rings.

[MichiganRon]

I had a previous thread on this topic ( thread690-342927 ), but decided to start a new one because I wanted to get all the information in ONE posting. None of the suggestions in the aformentioned posting were successful in solving my problem. I was on the telephone with Avaya software support (tier 1) last week for an hour and they couldn't solve my problem. Their final answer was "that must be the way the system was designed". I disagree. There HAS to be an answer to this problem. I'm sure I'm not the only person that has my system set up like this. I've gotten GREAT help from this forum in the past, so I am puting all the info out there now in the hopes that SOMEONE will have an answer for me. This posting is a bit long winded, so bear with me...

My equipment: Definity G3si r11 & Intuity Audix r6

Breif synopsis: Inside calls to extension 2200 follow proper coverage and transfer to 2200's VM after 8 rings. Outside calls to 2200 cover to the attendant after same number of rings, even though both have the SAME coverage path settings.

The FULL story:

I have an analog POTS line that comes into a trunk card on the PBX. The trunk group sends the calls to extension 2101. 2101 has a coverage path that sends ALL calls to h10, my Audix hunt group. Once in Audix, subscriber 2101 has an automated attendant with the following option:

Button Extension Treatment
1 2200 transfer

When a caller presses "1" at the auto-attendant they ring extension 2200. Extension 2200 has a coverage path with the following settings:

Hunt after Coverage?: n

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

Point1: c4 Point2: h10

Coverage answer group 4 (c4) consist of two telephones in the same office area. As you can see, inside and outside calls have the same coverage treatment. However, while inside calls (calls directly to 2200) follow the correct coverage path into h10 (Audix hunt group), outside calls do not. They cover to the attendant. I performed "list trace station 2200" twice. Here are the results:

Inside call (the one that works):

time data
8:55:54 Calling party station 1295 cid 0x59
8:55:54 Calling Number & Name 1295 Ron
8:55:54 dial 2200
8:55:54 ring station 2200 cid 0x59
8:56:12 no answer station 2200 cid 0x59
8:56:17 coverage-path 225 point 1 cid 0x59
8:56:36 no answer cid 0x59
8:56:36 coverage-path 225 point 2 cid 0x59
8:56:37 active station 1106 cid 0x59
8:56:44 idle station 1295 cid 0x59

Station 1106 is a member of h10, thus the call went Audix.

Outside call (the one that DOESN'T works):

time data
8:53:36 dial 2200
8:53:36 ring station 2200 cid 0x52
8:53:36 transfer station 1102 cid 0x52
8:53:55 no answer station 2200 cid 0x52
8:53:55 coverage-path 225 point 1 cid 0x52
8:54:17 active attendant 1650 cid 0x52
8:54:44 idle attendant 1650 cid 0x52

1650 is the main attendant. Extension 1102 is one of the links between the PBX and Audix (also a member of h10). Is there a clue in the bold line above?

Am I missing any information that might help in solving this problem? If so, let me know and I'll post it. Any help on this problem would be GREATLY appreciated. This is one of those problems that just won't go away and I am at my whit's end!

THANK YOU!
-Ron

P.S. Oh yeah, I forgot to mention two things. If h10 is the FIRST coverage point, the system WORKS! Also, this is not the only extension that has this problem. It seems to occur whenever a station has more than one coverage point.

 

[vectorbob]

Your message is a little long winded and I don't understand some of the interactions described, but it sounds like a classic probem of "Double Coverage". The fact that inside calls directly to 2200 don't have a problem is a clue in that the caller has only covered once. The outside call had to initially cover once to h10 then, inside the AA, transfered to 2200 which had another cover path. This is called "Double Coverage" and is hard to create a work around for.

If you have vectors, add a vdn that routes to a vector that has a step that says [messaging split 10 for extension 2101]
Put this new VDN as the incoming destination for the POTS line. This way you eliminate a cover path.

 

[MichiganRon]

Problem FINALLY solved! While on the phone with Avaya about an unrelated problem, the tech stumbled onto the cause of this problem. On page 2 of "Console Parameters", "Return Call Timeout (sec)" was set to 30. This caused all calls that went unanswered for 30 seconds to go to the attendant. We set it to 90 seconds and fixed the problem!

Great job <insert Avaya tech's name here>!!

-Ron