External Phone-Number Matching with Internal Phone-Number

[Ecarttev]

Hello All,

I have user trying to call an external number ex: 7-1-365-2246, 7 is our dial out prefix, and 1 is the US country code.

The issue is that we have an internal extension 2246, and whenever we try to dial this external number we are routed to the internal number.

Has anyone encountered this before?

Thank you. 

[Les Pruden]

It sounds like you have a translation pattern match to possibly keep calls to your DID number range on prem.

In your case is it possible that this number is similar to your DID range? You can run a route plan report and look for a translation pattern starting with 7 and adjust it as needed.

[Roger Kallberg]

This is why in general a 0 or 9 is used as the breakout code for external calls as using other numbers, like 7 in your case has a big chance of overlap with real public numbers on PSTN. Other than that changing your call routing configuration, either internal or external breakout, I see no option for how to solve this in a practical and maintainable manner.

[Dmytro Benda]

This is a strange sequence you try to dial. If I remember it well, in US you dial 1 for long distance calls (i.e to call from one region to another region), right? If so, after 1 typically you have to dial an area code, for example, 9 (or 7 in your case)-1-408 (area code of San Jose)-5551234. But in you case you don't dial an area code. Is that correct? 

My Cisco Unified Communications Blog

[Roger Kallberg]

I agree that it is a strangely formatted dial string. Going back to what the OP wrote about the 1 being country code a proper formatted dial string should according to NANP be 7-011-1-<area code>-365-2246 or +1<area code>3652246 from what I know. This wikipedia article outlines the number plan for USA pretty well. North American Numbering Plan 

[Deepak Kumar R]

@Ecarttev One possible workaround is you can try disabling the "Urgent Priority" checkbox on the translation pattern pointing to your internal extension 2246. As @Les Pruden said you can identify this pattern by searching for 2246 in route plan report with the filter "contains / Ends with".