Hotel/motel blocking calls between extensions


I’ve already agreed with you TWICE that the dial plan is an easier and better way to accomplish the same thing.

However, unless you pay for EPM, this would require configuration that it outside the FreePBX GUI.

The OP indicated that he wanted to accomplish this from within the GUI, which I understood to mean FreePBX’s GUI. He was told that it couldn’t be done, which is wrong. It can be done. It just gets very complicated, especially if you’re right and he wants the rooms to be able to dial the feature codes themselves and if the system has others that use the “from-trunk” context.

(Bigunk) #23

My word…what have I started? Here’s the simple, with a couple more details for clarity (I hope). No corporate, no rules. Small fleabag place with no pool or anything. 21 rooms + 3 SIP phones in the office + one roaming analog cordless. Nothing really special. Client wants the rooms to call only the office and 911, and when 911 is called, the office phones (and maybe the roaming cordless) will get called so they know which room dialed. Customer wants guests to set wakeup calls on their own (feature code), along with being able to set them up from the office.There will be two analog trunks. No SIP trunk at all at this time. This client is old-school and was running things on an old Mitel that flamed out. Mitel is the defacto standard for Hotel/Motel. That’s pretty much it. And the reason I want to do it via GUI and I don’t understand doing it via CLI. I was a CLI guy at one time, but asterisk CLI is beyond me at this time in my life.


The easiest way to do it would be using the Dial Plan, which would normally be configured on your FXS Gateways, and not from within FreePBX’s GUI (unless you’re using EPM - which is a commerical module).

However, since you have no SIP trunks, the “from-trunk” context combined with inbound routes would do exactly what you need as well and meet your request to have everything done from the FreePBX GUI.

If the only feature code that extensions needs is Wake-up calls, you can allow that via the inbound route as well. You’ll also need to be sure to create an inbound route for 911 calls that links to dialing 911 on the FXO gateway.

As to the “what have I started,” it seems that certain people who post here don’t like it when their answers turn out to be mistaken.

(Bigunk) #25

Please, let’s not have war in this forum. I would like to think we’re on the same side, and sniping at each other would tend to detract from our mission. I’m a 37+ year phone guy who comes from the old-school world, and FreePBX has been part of my offerings for only about 4 years, so I have plenty to learn.


(look into the “custom contexts” opensource module, it makes all the contexts granular)

(Bigunk) #28

But are contexts generally CLI? I’m not afraid of it. I just don’t understand it right now. I figure I’ll start getting into it soon enough, because it seems the capabilities can really expand the system function. Of course, it’s probably a double-edged sword. One wrong move…

And I come here seeking knowledge from people who are clearly smarter than me, with the idea that I’ll eventually be able to give advice to newcomers.


Did the PMS module meet your needs? Or, did any of the three other suggested approaches work? If so, please mark the appropriate one as the Solution and we’ll let the mods close the thread.

If you are still looking for advice, please let us know why none of the methods mentioned are suitable and tell us what kind of gateway or FXS module you are using.


No, contexts are elemental concepts in Asterisk to allow access to included peers and groups,

(Bigunk) #31

After talking with Sangoma, it looks like the PMS Pro will be exactly what I need. I could buy it for my office machine to play with, but once I figure out how to use it, it’ll be disabled.


Limiting outbound calling in the dial plan is the easiest way to do what you want, and it doesn’t require any CLI. It’s usually done via the web gui of the FXS gateway, so it avoids the CLI.

The method that I recommended would also work. The statements by other posters that it is impossible are incorrect for the reasons that I’ve stated, though my solution does present limitations and risks if you are using SIP trunks.

Custom contexts are generally CLI, though there may be an open source module that lets you type the CLI commands into a web-page. You’ll still have learn how to write Asterisk code. It’s not hard once you read through the *.conf files and learn how to do it.

Please do not feel pressured to accept a solution and terminate the discussion early. If you have more questions, you’ll probably get quick (and possibly even contradictory answers) now.

(Bigunk) #33

And that, right there, is where I lose my way. Peers and stuff like that aren’t in my brain yet. If you have an easy way to insert said knowledge between my ears, I’d entertain the attempt. Giving me tons’s of docs will simple put me to sleep.


Until you pick an FXS Gateway, it would be impossible to give you step by step directions on how to do it via the Dial Plan method. Every gateway has its own unique method of programming the dial plan. Pick one and then ask, and I’m sure that someone will help you to do it.

The manufacturer of your FXS may also have a tech support line that will help you do it.

Did you understand that method that I proposed, or do you need further guidance on how to do it?


Though not free, IMO the commercial module has a big advantage of putting the logic in an obvious place, which may make it easier on your successor(s). If this system lasts as long as their SX-50, you won’t be the last to work on it. Also, it comes with support if needed.


Hehe, but to do what you want, you will need your brain to encompass needed concepts, this is the normal context for an extension:=

include => from-internal-additional-custom
include => app-cf-toggle
include => app-cf-busy-prompting-on
include => app-cf-busy-on
include => app-cf-busy-off-any
include => app-cf-busy-off
include => app-cf-off
include => app-cf-off-any
include => app-cf-unavailable-prompt-on
include => app-cf-unavailable-on
include => app-cf-unavailable-off
include => app-cf-on
include => app-cf-prompting-on
include => ext-cf-hints
include => app-callwaiting-cwoff
include => app-callwaiting-cwon
include => ext-meetme
include => app-dictate-record
include => app-dictate-send
include => app-dnd-off
include => app-dnd-on
include => app-dnd-toggle
include => ext-dnd-hints
include => app-fax
include => app-fmf-toggle
include => ext-findmefollow
include => fmgrps
include => app-hotelwakeup
include => app-calltrace
include => app-echo-test
include => app-speakextennum
include => app-speakingclock
include => ext-intercom-users
include => park-hints
include => app-parking
include => app-pbdirectory
include => ext-queues
include => app-recordings
include => ext-group
include => grps
include => app-speeddial
include => vmblast-grp
include => app-dialvm
include => app-vmmain
include => app-blacklist
include => app-contactmanager-sd
include => app-userlogonoff
include => ext-local-confirm
include => findmefollow-ringallv2
include => app-pickup
include => app-chanspy
include => ext-test
include => ext-local
include => outbound-allroutes
exten => h,1,Hangup

and this the from-pstn context

; from-pstn:
; Entry context for calls from the outside world to hit FreePBX
include => from-pstn-custom             ; create this context in extensions_custom.conf to include customizations
include => ext-did
include => ext-did-post-custom
include => from-did-direct
include => ext-did-catchall             ; THIS MUST COME AFTER ext-did

from asterisk’s cli you can

dialplan show @your-context
dialplan show @ext-local

etc. . . .

so building a context that includes all the ones you want but explicitly excludes ext-local would likely achieve what you want.


Since it seems like you still might be lost, let me give you a bit more detail.

Every SIP device (phone and FXS Gateways (aka Analog Terminal Adaptor)) has a dial plan. The “dial plan” tells the device which phone numbers the device is allowed to dial, which phone numbers the device is not allowed to dial, and how quickly to send the call out and how long to wait for the user to dial another number before deciding that he’s done dialing. These settings are made at the level of the hardware, and have nothing to do with FreePBX or Asterisk. When a call doesn’t match the dial plan, the call is never sent from the device to the FreePBX/Asterisk server.

So, for example, all dial plans in North American (or places using NANPA) should allow the dialer to call 911, and should immediately send the call out without waiting for additional digits after the final “1” has been dialed. The Dial Plan allowed would generally be written “911,” but can sometimes also be written as “911S0” or “911T” depending upon the syntax used by the company that makes the device.

For trusted users in a corporate environment, you might also allow calling 411, 611, 811, etc. Sometimes, you’ll just write the plan as “X11” or “N11” to allow all of those calls with a single rule. X usually refers to 0-9, while N usually refers to 2-9, but that depends upon the device. So, N11 would allow the device to call 211, 311, 411, 511 . . . 911, etc. Sometimes, devices use lower case “x” instead of upper case “X.”

You’ll also want to allow and send calls out immediately if the user dials 1 + an area code + a phone number. Often, that would be written as “1NXXNXXXXXX,” but again, it depends upon your manufacturer. You could also write it as “1XXXXXXXXXX.” That would work as well, but would allow people to call nonsense numbers like “10550551234.”

Often dial plans use the period (.) for repeated entries. And some manufacturers allow you to add a timeout designator to the end of the dial plan, i.e. “011X.S3” might allow the user to to dial 011 + any digit + to repeat any digit as many times as they want until 3 seconds go by without any dialing whatsoever. This is how you generally allow international calls. You have to use the repeating character (.) because international numbers do not have a uniform length. The number of digits required to call London is different than the number of digits required to call Norway.

To make matters more confusing, some manufacturers have a separate setting as to what to do with calls that don’t match the dial plan. Polycom, for example, allows you to set your devices to allow any call to go through after a timeout even if the they don’t match the dial plan. That settings would ruin your plan, so you’ll want to watch for it. Aatra/Mitel has the ability to allow a non matching number, but does so by adding “xx.” to the end of the dial plan.

But, generally speaking, you could accomplish what you want using the dial plan on the ATA/FXS Gateway, For example, you could make all the room to room extensions start with 2, and all the allowed extensions start with 4, and then set the dial plan to something like:


The above (or something like it), on most devices, will allow the device to only call extensions starting with 4 and that are four digits long, and also to dial 911. Also, make sure that the device won’t send calls that don’t match the dial plan.

And again, you could also just use the method I proposed earlier. That method addresses your issue on FreePBX/Asterisk server side. The custom context method also addresses your issue on the FreePBX/Asterisk server side, and is the more “proper” way of doing so, but requires you to do outside of the GUI.

(Lorne Gaetz) #38

My first reaction when reading the suggestion to put internal extensions in the from-trunk context was, “well that’s interesting”, and I set myself the task of challenging the suggestion with some whatabouts. There must be a reason why I never heard of this, but after a full minute of serious thought I could not see any significant downside, provided you don’t want the room extensions to have access to outbound routes. If an extension in the from-trunk context needs access to the PSTN, you then need to re-create all your outbound routes again as inbound routes, and you lose the native ability for redundant outbound trunking. If, however, you can list all the numbers patterns that room extensions are permitted to dial on say 1 or 2 hands, this could work. I’d still be hesitant to suggest it without serious testing on my part; I feel like I might somehow be overlooking a fundamental flaw.

Not sure if it’s been pointed out already, but the from-trunk context has direct access to from-did-direct, so unless there is an inbound route that supersedes, it will not prevent local ext to ext calls which is the primary goal of the request.


Remember that inbound routes can use pattern matching. Sometimes you have to prefix the pattern with an underscore in order for it to work.

I don’t think that “from-did-direct” means direct dialing of internal extensions. I believe that is used to refer to DIDs linked directly to extensions, but I haven’t read through that context recently.

(Lorne Gaetz) #40

There have been no recent changes, and there is no need to read it. You can very clearly see what will happen by doing this at the asterisk console:

dialplan show 101@from-trunk

where 101 is any local extension. If you have an inbound route for 101 it will be run, otherwise it will go to extension 101.


I went ahead and read it. You’re right: So, to accomplish what I’d want, you’d want to create an inbound route that blocks dialing the extensions that you want to block. Again, you could do that using pattern matching. Assuming that you wanted to block calls to extension in the 2000-2999 range, you’d create an inbound route that matched DID: “_2XXX” and route it to “Terminate Call:Hangup” or even nice recording saying “you’re not allowed to dial that number.”

And since the permitted extensions are already included, you wouldn’t need to do anything else before the rooms could dial the allowed extensions. You’d only need to create an inbound route for 911 and for the feature codes, and an outbound route for 911 that would ensure that the proper CID is set. Though, in the case of calls going out on an FXO, the CID would already be taken care of by the company supplying the POTS lines.


As a complete aside, I appreciate your response and characterization. It is more in keeping with the spirit of FreePBX than the other responses that I received here. :slight_smile: