call fwd vs call reroute

[Mitelpassion]

Hi,

In my couple of years on this product I've always thought that call fwd (fac from phone) will override any system rerouting configured. Helpfiles confirm this.

However when I call reroute first alternative and call forward at the same time the call forward destination rings and then after that the call reroute destination starts ringing after the timer expires it seems.

Surely this isn't right?? Is anyone aware of this as an issue or is this design intent?

thanks in advance

 

[TheMitelGuy]

I believe that is as per design.

 

[MitelInMyBlood]

If you program both First and Second system reroutes then the second reroute will always be taken by the call regardless of any FAC user-forwarding. Watch your timers in Class of Svc. that they do not conflict with the system rerouting timer in system options assignment. If the CFNA timer in CLOS equals or exceeds the SYSTEM reroute timer in system options, guess which one wins the battle?

 

[Mitelpassion]

HI Mitelinmyblood,

Thanks for the info. my problem though is when I program only call reroute first alternative. I've always been under the impression that the fac for call forward always overrides ANY system rerouting.

Like I said the helpfiles confirm this. Mitelguy however seems to think that it's design intent. I suppose there are arguments for and against design intent in this instance. I've logged the call with 3rd line. Will c what they come back with.

Thanks for the responses

 

[kwbMitel]

MitelPassion, What are the exact circumstances?

I had a scenario recently where it appeared that the reroute was engaging when in actual fact it was a recall.

Scenario:
Incoming call answered by VM Autoatt
Caller dials Zero
Switchboard transfers call to Desk Phone
Desk phone Call forwarded to Cell
Call rings 4 times then reverts to internal VM (Not cell VM)

Because the VM was the first answering position in the above scenario, The call would recall based on the recall timer (17sec default) to the VM. Thru Mitel MAgic, it somehow retains the desktop ID and integrates with that VM.

To make it even more strange, if the switchboard retained the call a couple of seconds before releasing the call would drop into the Cell VM instead of recalling.

Solution was to extend the recall timer.

Suffice it to say that it took a long time to identify what was going on above. My first thought was that the re-reouting was still engaging even after the forward which is what brings it to mind for your issue.



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

 

[MitelInMyBlood]

kbMitel - We've run into very similar situations but it wasn't the recall timer biting us (tho in your scenario I could understand how it could occur). In our situation we have some users who want the call to CFA to their cell but drop back into their office VM while others want it to drop into their cell VM. We found that if we have call rerouting both 1st and 2nd alternates set to go to internal VM that the externally CFA'd call will revert back to the office VM system (Octel). On the other hand, if we kill call rerouting and have the user handle it strictly with FAC that the external CFA'd call will land in the cell VM. Whatever floats your boat is what I always say.

Thx for the memory hook on the recall timer. I had completely forgotten about that.

 

[Mitelpassion]

mmmm...I seem to be in the company of some very intelligent gentleman here.

thanks for that. I never though of recall timer. will give that a go.

MIMB, user wants to have it go to external voicemail (BRI integrated) automatically but sometimes call forward the phone to go to his cell. When this is the case he wants the cell vm to answer.

Scenario:

call comes in from trunk on extension. extension is cfwda to cell. cell rings, but when call forward no answer timer expires, it follows call rerouting 1st Alt and lands up in the system voicemail.

I've logged a call with 3rd line to understand if it's design intent or not. I will though test your theories.

again thanks for that