Call Forwarding Issue

[WishItWasCisco]

Another weird problem.

I am trying to setup some call forwarding for certain key users at the company. We have 3 locations and have a receptionist at locations A and B. All forwarding was configured via call routing first/second alternative.

User at site A or B is configured as follows:

Option 1 … receptionist site B
Option 2 … Voicemail

Receptionist site B is configured as follows:

Option 1 … receptionist site A
Option 2 … Voicemail

Receptionist site A is configured as follows:

Option 1 … Voicemail
Option 2 … Voicemail

I have configured call routing so that the call comes in to a user, if the user is busy/no answer it forwards to the receptionist at site B. If the receptionist at site B does not answer it goes to the original receiver’s voicemail. If the receptionist at site B is either busy or DND it goes to the receptionist at site A. If the receptionist at site A is busy or does not answer it goes to the original receiver’s voicemail.

This appears to be working as intended and we are receiving the desired results.

Now the interesting part… If I try to do the same exact setup for a user at site A it doesn’t work quite right. The user at site A will forward to the receptionist at site B as planned. If site B does not answer it is forwarded to the original receiver’s voice mail. If the receptionist at site B is Busy/DND it will forward to the receptionist at site A.

It seems to work fine up until this point. If the receptionist at site A is busy/DND the call will forward to the voice mail of the original receiver. If the receptionist at site A just doesn’t answer the call it will go into a generic system voicemail.

Am I making this too complicated? Is there an easier way to accomplish this goal? Why is the incoming call losing its VM ID info in the last scenario?

Thanks

 

[kwbMitel]

Too complicated, yes. But legitimate question none the less.

I would setup a test that the final destination is a display phone with the same COS as the VM.

Observe what is displayed in each scenario.

Something will be different in the one that fails.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[nytalkin]

Assuming this is a network reroute make sure there are enough network hops programmed to allow the call to go back to voicemail.

30 years and it's still true.....NO GOOD DEED GOES UNPUNISHED!

 

[WishItWasCisco]

There are 5 hops programmed under system configuration. We are going from A to B to A to VM. It shouldn't be more than 4 hops on any of the scenarios. I am assuming hop count starts from the time it leaves the originating call?

 

[WishItWasCisco]

Any other suggestions?

 

[kwbMitel]

Did you try to test as I suggested above.

If so, what was displayed in each case?

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[becca1jane]

Just to make sure I understand - are you saying that the incoming call is following the station routing first, and then following the routing for the receptionist - and that the receptionist only has re-routing set, not forwarding or DND?
Is this a networked v/m? If so is it located at site A or site B? It sounds like you are losing the station's ID, and are only getting a trunk ID - therefore v/m is answering with a generic greeting. Station ID may only be carried for 2 re-routes (1st and 2nd.)

 

[kwbMitel]

Becca1jane:I believe you are speculating that the station ID is lost after 1 or 2 hops. Your statement sounds more certain.

WishItWasCisco: It is very important to find out what is displayed differently for each scenario. I know of several instances where integration fails due to programming methods. What is displayed will lead to better answers.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[rado40]

is it possible to change the call forward timer for cos of reseptionist 1 or to chnage option1 for operator A to nothing???

 

[becca1jane]

kwbMitel - you are correct about me speculating - I should have emphasized the word "MAY" only be carried for 2 hops. I also wonder if the call originated in v/m and was transferred to the initial ext? If so the recall timer could be pulling the call back to the generic greeting if the transfer wasn't supervised. As rado40 mentioned this could be a timing issue - call re-rte, sys re-rte, cfwd, etc.

 

[WishItWasCisco]

It is not a networked voice mail system, VM only resides at site A. Everything is done through call routing first and second options.

kwbmitel... I will test this again using a dummy display phone and see what happens. I do now that it is losing its VM header information on the second cross network hop.

 

[WishItWasCisco]

Ok, it definately loses its VM header info on the second cross network hop back to site A.