Problem with Remote Forwarding

[rwessels]

I have a sales rep that wants to forward calls to his Cell when he is gone. We have a Merlin Legend R7 system with an 007 MLM with an auto-attendant. Through WinSPM, I turned on remote forwarding and trunk to trunk transfer. Dealyed Forwarding is set to zero rings. We have a MLX-20D as the main console phone and a MLX-28D as the backup console phone. Both of these phone have all 6 lines that we use as buttons on the phone. On the sales guys MLX-10D phone (extention 102), I did *33 and the number followed by the # sign. When I dial his extention (102) from an internal phone, it rings twice and then forwards to the cell. When I dial externally, I get the auto attendant and select his extention. Immediately I here the MLX-28D and the MLX-20D start ringing. If unanswered, it goes to a DIFFERENT voice mail than the sales guy (extention 108). Is there any way to make the forwarding function the same way through the auto-attendant as it works for internal extensions?

 

[tdaugirdas]

Why does his call - when transferred by the AA ring on the operator phone and the MLX-28D?? Does the operator phone and the MLX-28D have a "primary cover" button for his specific extension? To get a better idea of what is happening - use WinSPM and print an extention info report for the operator phone, the 28D and his phone. Then cut & paste those reports here.

Tom Daugirdas,
President
STCG, Inc.
stcg.com

 

[merlinman]

Your last 2 voice mail ports need to have TRUNK TO TRUNK transfer permissions, ars restrictions of 3, and set to be UNRESTRICTED, and your lines need to be set for LOOP START RELIABLE DISCONNECT - YES.

That should resolve your problems.

What's happening now is the VM ports can not do a trunk to trunk transfer, nor are they allowed to dial out of the system, so therefore, your call is going somewhere in house.

 

[rwessels]

Thanks guys for the help. I enabled the Trunk to Trunk on the VM and Reliable Disconnect and it works great.

 

[TouchToneTommy]

ALL of the voice mail ports need to be unrestricted and allowed trunk to trunk, as the original call could hit ANY of the VM ports (especially since the VM calling group should be linear in hunt sequence)

 

[merlinman]

Give that a whirl as well, I was thinking that only the last 2 ports did this, but TTT is probably correct in thinking that ALL PORTS can be called on to do this, also.