Call forwarding and voicemail

[pakojones]

Hi,

I have a 3300 MXe with software 10.0.1.22 with some extensions configured with voicemail, on Call Rerouting Asignment I have a first alternative to the voicemail extension, this is working fine. Now I need to enable call forwarding on one phone for all calls, but when I configure it on the phone, it only works from internal numbers, if I call from outside it automatically forwards the call to the voicemail system instead the extension I configured to forward to. Is there any way to solve this?

TIA.

Jesus.

 

[BrantN]

What is your call rerouting assignment do you have it also set to go to voicemail? How are you setting the forward set side or system side? Is it forward always, busy, or na?

 

[pakojones]

Hi BrantN,

Yes, the call rerouting assignment is set to go to voicemail, and I am setting the forward on set side.

Thanks.

Jesus.

 

[YnotPhone]

The set when call forwarded - only forwards the original DN (extension) of the set, not all the line appearances that are on the set.

If you need to change the call answering location: Night Service will need to be the service to change.

 

[kwbMitel]

Forwarding on the 3300 needs to be set independantly for internal and external.

My assumption based on your posts is that you have set the internal forwarding only. The external call would follow the Call Rerouting in this case.

Use the Maintenance command: Locate Feate Extension XXXX

This will tell you what forwarding types have been enabled.

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

 

[BrantN]

Yes that is correct when you set it set side are you setting internal or external?

 

[pakojones]

Hi,

kwbMitel, no, I set the forward as always on the phone, if this helps, the phone is a Mitel 5312.

IP Device ID: 633
Circuit Location : 1 3 6 8 1
Extension :4871
Active
Features :
Call Forward Always : 4811
Phone Lock: UnLocked
MAC Address : 08:00:0F:42:C1:A1

Primary Element : LEID 1 - Routing Digits : 3991 *
Secondary Element: CEID 2 - Routing Digits : 3992

 

[pakojones]

Hi again,

I'll try to explain better.
The extension with the problem is 4871, the controller has two PRI with 150 DDI, to get the correct extension the controller absorb the first 6 numbers and insert '4'. If I call to the extension from i.e. 4801 it works fine, but if I call from PSTN to XXXXXX871, inmediatly goes to voicemail, without any ring.

 

[kwbMitel]

The phone is forwarded always to 4811, Why?

When you call internally you say 4871 rings? This would seem unlikely unless 4811 is an invalid destination.

What features if any are active on 4811 (loc fea ext 4811)

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

 

[pakojones]

kwbMitel, the user on 4811 needs sometimes to forward all calls to 4811 which is a valid destination (another 5312)

When the forward always is active, internal calls rings on 4811 as it is supposed to work, but when the call is from PSTN, it immediately goes to voicemail.

The help says that the call forwarding has preference to call rerouting (not always alternative, but first and second does), but in this case is not working.

I have not access to the controller now, but I'm pretty sure that 4811 has no feature active.

Thanks.

 

[kwbMitel]

We're starting to get in the territory of too many variables to properly advise you.

I can think of several scenarios where the observed behaviour would occur while the phone is forwarded to 4811. These depend on the status of 4811 (busy or not) and the status of certain COS options (CFFM follows rerouting if destination busy)

You either need to remove the forwarding and test

Or

You need to test every possible combination of 4811 being busy or not during test calls.

Report back with your findings either way.

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