Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Mitel 3300 VM not answering on incoming trunks 1

Status
Not open for further replies.

usaguy

Programmer
Nov 28, 2011
37
US
Hi,

We are using incoming SIP trunks and if a call is transferred directly to an ext the VM does not answer.

It does however answer if you call the Ext Directly.

I assume this must be a routing issue but I cant seem to find where.

Any ideas?
 
COS option use called party extension

NO GOOD DEED GOES UNPUNISHED!
 
I don't see a COS option "use called party extension" am I missing something.

PS. Thanks for all the help.
 
Are you using forwarding or routing on the extension to get to voicemail?

If Forwarding, have you enabled external forwarding?

If routing, Are all call types / trunks set to route?

Forwarding overrides routing, Locate Feature Extension XXXX

**********************************************
What's most important is that you realise ... There is no spoon.
 
Hi,

Firstly THANKS @kwbMitel for all the assistance

All External forwarding on the COS for the devices, ring group and trunk are set to allow external forwarding.

It seems that when the source of the call is external the call will not route to VM.

Any other ideas?
 
Could you post all the of the following:

Locate Feature Extension XXXX (for a phone that is not working)

Call Rerouting First Alternative (page 1)

Call rerouting assignment (for a phone that is not working)

Also, could you check the COS of the VM ports and make sure that Public Trunk Y/N is NOT set to Yes.

Also, Are all device types using the same interconnection number?

Also, is the voicemail connected to the same system as the SIP trunks?



**********************************************
What's most important is that you realise ... There is no spoon.
 
Quick question, in the Call Rerouting First Alternative Form should the directory Number be set? If so to what? I cannot use the VM hunt group number (it gives an error).
 
IP Device ID: 1
Circuit Location : 1 3 1 1 1
Extension : 5001
Active Features :
Call Forward End Chaining
Phone Lock: UnLocked
Service Level: Full
MAC Address : 08:00:0F:5E:F8:79

- that Public Trunk Y/N is set to No
- Device types ARE using the same interconnection number
- The voicemail connected to the same system as the SIP trunks
 
 http://www.mediafire.com/?e99yww1kd1udhkx,j4heajqzh4g563r
Yes there should be a DN set in the first alternative form. (But not on the first/default entry)

For your internal routing to be working today. There must be either routing in place or forwarding. There isn't any forwarding active on the station above although I'm not sure what the Call Forward End Chaining might affect things. (Not at all I suspect)

The station above should have a value set for its first alternative routing in the Call rerouting assignment form.
- What is this value?
- In the 1st alt form, what is the DN programmed for this value
- In the first Alt form are any rerouting methods turned off?

Is there any value set for 2nd alternative?

**********************************************
What's most important is that you realise ... There is no spoon.
 
OK, think I have it.

The first alternative is set to 2.

2 does not have a DN set in the First Alternatives Forms. When I try set the DN to 8200 (The VM hunt group) I get the error: "The Directory Number is not allowed"

What am I missing?

PS @kwbMitel THANKS AGAIN for all your help.
 
There are 2 things wrong with your response that I'm having difficulty with.

1 - That the calls route to VM on no answer/busy for internal calls. Without routing or forwarding, this should not be possible. You're not telling me something important.

2 - There should be no issue with putting the VM hunt group pilot in the DN field of rerouting. Again you're not telling me something that I need to know.

What does the system tell you when you type:

Locate number 8200

In your original call flow you state: "if a call is transferred directly to an ext the VM does not answer"

What device is doing the transfer???

**********************************************
What's most important is that you realise ... There is no spoon.
 
1. Nope I have checked and double checked, no forwarding and Rerouting.
2. It seems that I cannot add any DN to the rerouting form??? Each time I get "The directory number is not allowed”.

Locate Number 8200 shows it as a Hunt Group.

What device is doing the transfer??? - Call from Ext SIP trunk to AA, user dials the Ext number and is transferred to the ext.

Any ideas?
 
Ok, well in that case the mystery has gotten a lot bigger.

My imagination is not able to corrolate the info.

If the DN is valid (Hunt group Qualifies) then there should be no issue adding it.

With no forwarding on the sets and no DN in the routing form, I have no idea how the calls are getting to VM at all.

I'm either missing something so obvious that I'm blind to its absence or this issue is waaaaay out there.

Supernova - Loopylou - we need you!

**********************************************
What's most important is that you realise ... There is no spoon.
 
Would it be worthwhile to see what is programmed in the "Call Forwarding Profile" Form?
 
That solves some of the mystery...

The ext has 2 entries, 1 for no answer internal and 1 for no answer external, both pointing to the VM Hunt group and both enabled.

Explains why internal calls are going to VM, but External calls still do not get forwarded.
 
Please confirm:

The station that you used for the Locate Feature Extension listed above on 1 Dec 11 15:16 (5001) has [highlight]active[/highlight] forwarding when viewed in the Call Forward Profile Form?

**********************************************
What's most important is that you realise ... There is no spoon.
 
Hi,

it turned out to be something really stupid, the First alternatives options needed to be set to "This" to accept a DN without giving the error.

Now transfers to VM are happening 100%.

Thanks for all your help.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top