Confused on dial patterns in trunks and routes

Ok, I’m a bit confused. We have the basics setup for our trunks and routes but I think i’m missing one step.

A number that is local to us we dial the area code and number, long distance we add the one. I have just signed up with a sip provider for long distance calls that are not reachable by my dundi cloud.

This all works, however if I dial a local number and add the 1 to the number it goes out my sip provider.

In my Zap trunk under dial rules I have area code + local number 555+5551234. I used the lookup to populate.

In my local outbound route I have NXXNXXXXXX and NXXXXXX . And it dials out Zap/G0.

In my long distance or sip trunk i have

These are the area codes that i cannot reach with my dundi cloud.

In my long distance route i have 1NXXNXXXXXX . And it checks dundi, then sip then local Zap for dialing out.

So basically my question is what do I put where so that if a user mistakenly adds the 1 to a local number it won’t go out my sip provider.

hope it this wans’t to confusing as it is really confusing to me. This is the only part that I cannot seem to get my head around.



Rob, I hope that I’m not confused here but 1NXXXXXX should get the local zap dialing. If they put the one in front of a seven digit number as your plan is now don’t they get an error message? My system just gives a fast busy to let the user know they must dial it another way.


When constructing a dialplan and trunk routing, Place the specific ones at the top and the more general ones after that in the order you’d like them checked.

So for your local numbers you can use
and/or if you want to do it by the area codes

Then for those that don’t dial right do (yes you’ll have to list all the area codes)

That way if they dial it with a 1 by accident the 1| will strip it off

Ok, this is starting to make sense. But Do I put the the 1|555nXXXXX in the out bound route or the trunk.?

Can the trunks be blank for dial rules and everything just governed by the outbound routes and then use trunk order?



it is sort of up to you but… Trunks can use | (remove/subtract) and + (add) in patterns so you can add and subtract things while outbound routes can only use | to subtract things. The other thing to keep in mind is that if you send it to a trunk it should at that point be able to handle it no matter what or the call will not complete as the outbound route that picked that trunk has taken it and it will not then pick another route.

For your second question yes. that is how we have it except for one trunk that has a single addition rule.

Good Morning Rob,

I follow Fred’s strategy of making the most specific outbound routes first and follow with the general ones. My first route is always emergency, the match pattern is 911 and it is routed to the appropriate trunk for those calls.

In your case, my second route would be for your internal Dundi cloud. If your extensions numbers in your cloud are all 2XXX, that is what I would match there.

My next route would be your local calls. I would list each NXX exchange individually here. I would list them 3 times, once as NXXXXXX, once as NXXNXXXXXX and finally as 1|NXXNXXXXXX. I have a tool on my website to help facilitate this, One of my local exchanges here is 828494XXXX. In my outbound route for local calls it is listed as:


If my area allowed 7 digit dialing it would be:


In your Zaptel (local) trunks Dial rules you would add the area code back in if your area requires 10 digit dialing, like this:


Then your next route would be long distance with a match pattern of:


The first listed trunk here should be your Dundi trunk and then your SIP trunk as second. In the dial rules for both of them put:


which prepends the 1 to 10 digit numbers.

These routes are processed from the top down, so order is important. Once you have a match in a route, the call will be processed by that route and will not check any further down the list of routes. So by listing all of your local exchanges on your box, the user can dial a local number anyway they want, and FreePBX will modify the dialed number and dial it the proper way. Now your users can dial a local number anyway they want and it will be modified by FreePBX and sent out a Zap channels. All other calls will be processed by your long distance route which will try Dundi first.

In your case, any number that is handled by your Dundi cloud should be treated as a long distance call and let the foreign phone server modify the number for dialing when it gets there.

Thanks John & Fred, that clears it up for me.

I follow the instructions, tried every way i could think of to dial a local number and all of them went through the zap trunk as they should. I then dialed a long distance number in every way I could with and without the 1 and those that could go out the dundi cloud did and those that could not would dial out the sip LD carrier.

Perfect, just what I wanted.

Thanks again for the help.


There is a page that is on the AussieVoIP site (old FreePBX documentation site) that for some reason never got copied over to this site, that I thought might help your understanding of this topic. So I copied it over tonight, and you can find it here:

The article is actually probably a couple years old, but it appears to still be applicable today.