Mitel 5000 incoming to outgoing DID routing

[kwbMitel]

I've done this before without issues.

Something is enabled (or disabled) on this system that is preventing routing to an external number on an inbound call.

SW Version - rel 6.0.10.77
trunks are PRI

Setup
Phantom setup with Forward to Cell
Inbound DID terminated to Phantom Fails
Internal call to phantom succeeds
Inbound call to CRA with timeout to phantom fails
Dynamic Extension to Cell fails
Using the PRI line monitor we can see the trunk being seized for outbound but drops right away.

Cell number is LD from the system
Sounds like a restriction somewhere but I can't find it.

Any thoughts?

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

 

[Hovus]

Check Numbering Plans > Area Flags.

Normally for 10 digit dialing should read Yes, Yes, No, No, No.

Otherwise, could be that the phantom isn't forwarded properly. Did you forward from OLM or through the feature code? Definitely easier to program a phantom's forward destination through a phone than it is through the DB.

I have dreamed a dream, but now that dream has gone from me.

 

[kwbMitel]

The phantom is forwarded correctly as it works when called from an internal set.

The number can be dialed directly which makes the Area Flag settings unlikely.

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

 

[Hovus]

Ah, didn't see the middle "success". If you can send me the DB, I can take a look. I'm also curious. Was thinking maybe Outgoing Access on CO Trunk Groups, but if internal to phantom routes it fine, then that can't be it.

I have dreamed a dream, but now that dream has gone from me.

 

[sarond]

Does it work if you program the phantom as a dynamic extension with the cell?

 

[kwbMitel]

Our working theory at the moment is that the Telco is rejecting the call based on caller ID

We have turned off the option to propogate the Caller ID with no success.

We are engaging the Telco for troubleshooting as it appears to be them causing the issue.

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