Hi Antonio, In general PBXs (Example: Cisco Callmanager, Asterisk) handles extensions and routes to PSTN differently. Example: Extension 1. 4082186571 Extension 2. 4082186572 Route Pattern (SJ Local) 408XXXXXXX There are normally 2 approaches for the problem you describe. a) Context access b) Dial plan priority *Context* a) PBX lets you configure different Classes of Service so you can restrict which user access what. (Example: Restrict International dialing, etc) My experience is that you configure context access to prioritize calls based on the following order: Extensions/Emergency Numbers/Local Numbers/Long Distance/International/Premium As a concrete example: When extension 1 dials extension 2, extension 1 is configured to only access extensions and extension 2 rings as expected. If extension 1 has access to SJ Local in this existing overlap situation you handle priority access based on Class of Service in which PBX logic should allow you to decide what needs to be contacted first: extensions after that route patterns, etc. In this case my advise is to prioritize extensions first and then PSTN...but it may depend in your scenario. *Dialplan* When context is the same, lets say internal and local calls access have the same priority, some PBXs use "Best match pattern" since obviously an extension contains a specific number of digits versus a pattern which contains wildcards, most PBX use this to route to more specific patterns which result in dialing extensions first. Pros of using internal extensions first: 1) Avoid paying PSTN calls for a call intended to an internal number. 2) Prevent routing loops, let say you own 40821865XX block and you have not configured 408218659 and someone dial it, you will be in a routing loop which may impact your PBX and eat up your DID channels. 3) Consider overlapping dialplan when same range exist internally and on the PSTN or second PBX. Your logic may need to be: Check internal (If internal number doesnt exist...check PBX, then PSTN). HTH -Gonzalo On Thu, Jun 4, 2015 at 9:15 AM, Antonio Gómez Soto < antonio.gomez.soto(a)gmail.com&gt; wrote: