CALL NOT FOLLOWING COVER PATH

[SBL110]

I've got an interesting problem with a call not following a cover path. Here's the cliff notes version:

Call to VDN A sends call to Vector A then after filtering for holiday, time-of-day, etc. will route call to station A with cover "Y" unconditionally.

If station A doesn't answer, or is in SAC, call follows coverage path for station A to VDN B. VDN B sends call to Vector B which collects 1 digit after announcement.

Call is routed to station B with cover "Y" unconditionally if caller chooses option 1. Call rings on station B, but does not follow cover path of station B.

When I do a list trace on station B, I never see the call ring through, yet the station is physically ringing. If I do a trace on station A, it appears that the cover path for this station is still in control. Calling station B or VDN B directly allows the cover path for station B to be followed.

I'm stumped. I realize that this is a somewhat unconventional way of routing calls, but the department doesn't want to deal with logging in/out as an ACD agent. Routing the call between vectors A and B was pretty much the only way to solve the problem.

I have a Visio diagram showing all of the details if anyone is interested. Also, I'm running CM 2.2 software load R012x.02.0.111.4.

Many thanks in advance for any ideas, comments or suggestions.

Scott

 

[TykeUK]

As far as i remember calls can only be subjected to call forwarding once. Therefore the second stations coverage will not apply.

 

[rejackson]

This could be interesting if someone has a solution. In my experience all references to cover path use the cover of the number that originally received the call.

 

[huffer]

Indeed, after the first coverage path the call will not go through another coverage path. And because a VDN is a final coverage point in a coverage path, adding another coverage point in the first won't help eighter.

Perhaps the following approach can be helpful: in the first vector route-to station A, assign no coverage point to the coverage path of station A. When station A is in SAC the system tries to route through the coverage path but this will fail. This means the route-to step in the vector fails en and vectrol control continues at the next step... now you can route to VDN B... Not sure this will work in current CM versions but I'm sure I have build this on one of the Definity Releases.

 

[des0906]

I'm not sure how feasible it would be for this application, but we've got a similiar situation at my office. It pre-supposes the use of digital phones.

It's an operations center without agent login id's. We route from a vector after checking TOD/Holiday to a station that is a Line Only type with an X port. Multiple other phones have bridged appearances of that LO station. The coverage path on that LO station goes to a voice-mail box after 8 rings. Six phones ring in conjunction when a call comes in on that LO station. I suppose you could bounce to another VDN/Vector instead of voicemail, and start over with another LO station from there.....

An issue with this is determining the number of buttons each user is willing to hand over for the line appearances. If you are short on buttons, this might not be feasible.

G3r\Octel VMX 300
"Sanity is a goal, not a guarentee"

 

[SBL110]

Thank you to everyone's replies. I also got the official word from Avaya that you can't cover to a cover path. I had submitted the question about this problem to Avaya and to this forum at the same time. I had an answer from the forum within hours, Avaya took two days.

The response from des0906 got me to thinking and I came up with a work around using the Intuity system. It's got a slight flaw, but it works. Here are the details if anyone is interested ...

Based on my original description, I'm taking the voice mail account for station A and making it an auto attendant. I'm changing the timeout to zero and transferring the call to VDN B. This breaks the chain of call forwarding. The flaw is that when the Intuity does the transfer, it says: "please wait" then sends the call to VDN B. Not a big deal, but might throw some folks off.

When I choose option 1 from VDN B, it routes the call to station B and follows the cover path for station B. Problem solved, or is it?

We're scheduled to upgrade to Modular Messaging in a couple of months, so the obvious question is: will MM be able to perform the auto attendant transfer like the Intuity does? If not, then this work around is short lived.

Does Modular Messaging function like the Intuity, or is it an entirely different beast? Again, thank you to everyone who responded.

Scott