specific number will not dial

[jherlitz]

I was given a number that if you dial it from our phone system it states the number you dialed is no longer in service or has been disconnected.  However if you call it from a cell phone it works fine.

Other numbers with that prefix work, it isn't long distance.  What suggestions to help troubleshoot this issue?

Thank you,

[acejavelin]

Is this a new prefix? It is possible your carrier (telephone company) doesn't have it programmed yet... Since you are getting an audible recording, that indicates the call is leaving the system and going to your telephone company. If the problem was within your phone system you would get a message like INVALID or NOT ALLOWED in the display (or just an intercept tone).

I would contact your carrier and give them a call example... date, time, number dialed from XXX-XXXX line or XXX-XXXX DID number, and the recording you got. The issue is likely on their end.

[jherlitz]

thank you for your reply.  It is not a new prefix, been around.  Other numbers to that prefix work just fine.  I am just getting this reported so not sure if it worked before and now it is not, or if it is a new number they are calling.  But yeah, other numbers with the same prefix work just fine.  Just this one.

[VinceWhirlwind]

I've had a similar issue.
Our users were getting a "number unavailable" when ringing a specific number, but when ringing the same number from their mobile phones, it rang fine.
 
Based on that information, I assumed I had an ARS problem - this was a cluster of MCDs so there were internal IP trunks involved for least-cost routing). Checked ARS, everything looked fine. Put in new routes so calls to that number were not sent over the IP trunks but went straight out to the carrier locally. Same result.
So then I googled for similar numbers that were identical right down to the last two digits. One was a private home, one was a business.
The first dialled fine & I got ring tone. The second rang fine and was answered by some kind of ACD.
So I decided there probably wasn't anything wrong with the phone system after all and ARS was working fine.
I ran an EDT trace on the trunks. Made a call to the suspect number and saw a "congestion" message.
 
So the conclusion was that calls from one carrier were getting a congestion message from the remote end, while calls from a second carrier were not getting that issue.
 
Eventually managed to talk to lvl3 support at the carrier to get him to run a trace and he saw what was happening: the remote end was answering the call with a D channel renegotiation message. It just so happened this carrier didn't support that.

[ralph]

I've had very similar things to what VinceWhirlwind describes.
Here's what I do in this situation:
1) Verify the ARS is routing the calls the same way for similar working calls.  If it is then it's going to be a carrier issue.
Sometimes it's easier to route around the problem via ARS to a different trunk group.  (I've had issues routing around a problem.  If I route around the problem, then the customer believes it's our problem and blames the PBX.  Perception is reality. For this reason I rarely route around it unless the customer clearly understands it's not our issue.  I've actually let a customer go without service for a day because he said "The Mitel Sucks" when I had already proved it out to be a carrier issue.  When the carrier fixes it then there's no choice but to accept that it wasn't a PBX issue.)

2) Have the number reported to the carrier and have them either fix it or tell the customer what the issue it.

Ralph

[VinceWhirlwind]

I'll second that - if you make a problem apparently go away by implementing a work-around bodge, the carrier will never fix the root cause and the customer will believe it was your issue in the first place.

[petr.necas]

Yep, "Mitel doesn't work" or "Phones are broken" :-) I've been hearing this since our first installation.

If it is a SIP trunk I would do some tracing using the SIP TCPDUMP ON command and then contact the carrier if the call is going out correctly. I can help with troubleshooting if you capture the SIP trunk communication.