Hotel/motel blocking calls between extensions


(Bigunk) #1

I have a small motel situation. Client wants all 21 rooms to be able to dial to the office phones only, but not from one room to another. She wants the office to be able to dial anyone, of course. It gets better. There will be feature phones in the office only, and all the rooms will have whatever cheap analog phone the owner can find, so everything needs to be done via feature codes in the rooms. This, along with a good wakeup call, are all she wants, Hopefully there’s a way to do this through the GUI. I’m not the CLI guy that I once was.


(Preston McNair, ClearlyIP CRO) #2

It doesn’t block calls between extensions, but you probably want to take a look at the Sangoma Property Manager Add-on: https://wiki.freepbx.org/display/FPG/Sangoma+Property+Manager

That with a Vega 3000 for your analog lines should get you most of the way.


(Bigunk) #3

Hey Preston,

Yeah, but that extension-extension blocking is really important to this client. This is a fleabag motel, so my guess is they want to eliminate room-to-room due to drug deals and garbage like that. Could this be done with the Class-of-service module?


(Lorne Gaetz) #4

No. There is no supported way to do this with the GUI.


(Tom Ray) #5

You set the dial patterns in the FXS gateways that are allowed to be accepted from the phones. It’s how I do it with all my hotels.


(Jared Busch) #6

A basic custom context can do it.

[from-room-phone]
exten => 0,1,Goto(from-internal,${EXTEN},1) ; assuming they press 0 for the front desk
exten => 123,1,Goto(from-internal,${EXTEN},1) ; some other extension (e.g. housekeeping=123)
exten => 911,1,Goto(from-internal,${EXTEN},1) ; emergency dialing
exten => _[*0-9]!,1,Playback(ss-noservice) ; block everything
exten => h,1,Hangup()

Then you put that context in the advanced tab of all the room extensions.


(Jared Busch) #7

This is also a good coice.


#8

If you’re doing this on the cheap, take a look at


You can set the dial plan in the device to block calls as desired. If she won’t be allowing guests to dial outside, either, you could even set it up so taking a guest phone off hook would ring the office – no dialing needed or permitted.

If outside calling will be permitted, will you be setting up a billing system? Or, provide ‘free’ calls to a restricted area (local or domestic)?

Does she want guests to set up their own wake-up calls?


(Bigunk) #9

Okay, so if I have rooms 101-121, plus the office at 122-124, I would put the dial patterns of each extension into the gateway as a reject from 101-121, then either have an allow or a not-on-the-reject-list for the office extensions?


#10

From guest rooms, you would probably block anything beginning with 1, but allow 0, which would be a ring group or queue that would ring the office phones.


(Bigunk) #11

Guess what? It looks like the PMS does allow for room-to-room blocking. I’m playing with it now. It’s under the features tab in the general settings in the PMS module.


#12

There is a very easy way to do this from within the GUI.

For each extension that you want to “block,” change the context in the extension settings to “from-trunk”.

Once you make that change, the extensions will be treated as if they are external callers who are calling into your system. They will only be able to dial numbers that are defined in the “Inbound Routes” module. You’ll want to create an inbound route for each allowed number that they can dial, even if it’s an extension number. You’ll also want to create an inbound route for 911 and have that route to actual 911 (which you can set up in the Misc Destinations Module) so that they can dial 911 from their rooms. You could further secure that by having it route to a special number, such as 1911, which would get picked up by an outbound route, modified to 911, and limited only to the phones with caller IDs matching the extension numbers of your rooms.

They’ll also be able to dial any DID that you have programmed for the system, but that shouldn’t really be an issue since those DIDs probably go to the same place that your allowed extension numbers will go to, i.e., the front desk, etc. If your worried about it, you can also impose further restrictions on their ability to dial using the dial plan on each phone or FXS.

The assigned context only impacts the calls that they place. You’ll still be able to call them from your phones using their extension numbers.

Theoretically, this would allow your VOIP service providers to dial those allowed extension numbers (defined as inbound routes) but they would have no reason to ever deliver calls to those numbers, and even if they did, they would just be able to dial the same people that you’re allowing your hotel guests to dial.

Alternatively, as noted, you could create a custom context, assign it to the phones, etc.


#14

Whether or not this is a “horrible” idea depends upon what you’re trying to accomplish. The OP specifically asked for a way to do it via the GUI. The method that I proposed WOULD accomplish what he wanted via the GUI. If it “makes no sense” to you, then you might want to spend a bit more time learning about how FreePBX and Asterisk work.

The only impact that it has on dialing is that the impacted extensions will lose their ability to dial as if they were internal. But, that may be what the OP wants. By making this change, the rooms will be treated as external callers. They won’t be able to dial other extensions, feature codes, ring groups, etc. If that’s what the OP wants, then this won’t “break” anything.

It does create a small risk that your other devices in the same context will use somehow dial those extensions that you do create in the inbound routes, but it seems very unlikely that would happen and even if it did, they would just be reaching the very limited subset of destinations that you were allowing to your guests anyway. You could alleviate that risk by putting the “blocked” extensions on a separate PBX altogether, and by tying that PBX to the main hotel PBX. Then the only devices using the “from-trunk” context would be the restrict hotel room extensions. The OP specifically asked for a way to block dialing other extensions from the GUI, and this proposal will accomplish what he asked for.

You could also achieve this via the dial plan configured on each device, and that would be a much easier way to accomplish the same thing. But, the OP specifically stated that he wanted a way to do it via the GUI.


(Tom Ray) #15

Correct which goes against what the OP stated when they opened the thread. Please see quote below.

While this may (or may not) be a small, independent hotel and may not be subject to outside rules. Hotels are generally controlled by corporate and some have multiple page documents on not only for Guest Room dialing rules but for each type of phone around the hotel. Elevator, Pool, Laundry, Business Centers, etc. etc. each of those could have different dialing rules like “Cannot dial anything. Opening a line/picking up handset sends call directly to front desk operator” or other rules such as that.

Do not conflate restricting room calls with just blocking all internal dialing functions.


#16

Be aware that I made some edits to my initial response to your post while you were replying to it.

First, the OP never said that he wanted the hotel rooms to be able to dial feature codes. He simply said that things would be done using feature codes in the rooms. The hotel operator/manager would still have full access to those feature codes to accomplish things in the rooms, because their extensions would still be in the ordinary context.

Second, any feature codes that you want to allow can be enabled by creating a matching incoming route for that dialing pattern and linking it to the allowed feature code.

Third, your discussion of elevator, pool, laundry, etc., is beyond what the OP asked for.


#17

BTW- this discussion reminds me of another discussion that I had back in 2013. I proposed that people start putting their FreePBX installs in virtual machines. I got a response similar to yours from multiple people who have long since evaporated from these forums, one of whom was then a developer, who said that it was a “horrible idea” and would “break” FreePBX.

Today, using VMs and hosted services is commonplace.


(Tom Ray) #18

That is exactly what the OP is saying. The Guest Room phones need to use feature codes to do things like a Wake Up Call because they won’t have a (as the OP put it) a “featured phone” i.e. a SIP Phone. If there was a SIP phone in the room then you can do things like have softkey’s programmed for 911, Front Desk, Wake Up Calls, etc. to avoid the use of feature codes.

Yes, you could. No one would do that because they would do this properly and limit the phone/extensions ability to dial places vs opening internal functions to any rando that dials in and can mash buttons.

Correct, it was. It was more there to explain to you why your solution is a bad idea and to make sure others looking at this understanding why.

There is also the fact that it is illegal to not have proper 9-1-1 dialing. The room phones must be able to dial 9-1-1 that will go to some place that always answers with a person. It doesn’t have to route directly to a PSAP (which is recommended) but 911 must be routed to a live person 24/7 that can handle the call.

So take that and say Room 100 calls 911, it will hit the Inbound Routes and will say the CallerID is the extension’s callerID (Room 100 <100>) and sure you can send it to the Outbound Route but the Outbound Route looks to override the extension so you would have to validate that it treats this call as an extension due to the callerID and overrides the Outbound CallerID when it calls out to the PSAP. Otherwise the PSAP is going to get a call with the CallerID of Room 100 <100> and it’s not going to get routed properly.

So there are other factors that need to be considered when suggesting something like this because it can screw with how the PBX sees that call and how it applies settings and rules to that call.


#19

OP’s initial post used the passive voice, and it was unclear as to who would be using the feature codes. If he desired feature codes to be available only to the non room phones, my solution would meet his needs perfectly. If he wanted the feature codes available to the rooms, he could create inbound routes for those feature codes. That does create some additional issues that I’ve already discussed and which you raised in the next paragraph (see below).

The only “rando” who could direct calls in to those internal functions would be a service provider who was on that same context. Your service provider would only direct such calls to your PBX if your service provider was a malicious actor. That seems incredibly unlikely, but it certainly is a risk.

As I said before, you could eliminate that risk by putting the restricted extensions on their own PBX without a direct link to a service provider. Instead, you could set up a second PBX for your non-room extensions that has a link to the service provider, and link the two machines via a SIP Trunk on the “from-internal” context. Then, the only person using the “from-trunk” context would be the room phones. There would be no “randos” on the “from-trunk” context.

Admittedly, this does get complex, but it still meets the OP’s requirement that everything be done using the GUI.

The proposal that I gave would allow proper 9-1-1 dialing. It is evident by your next comment that you didn’t understand it.

As I said previously, you could create an inbound route for calls to 911 that actually routes the calls to 911. Your CID concerns can be dealt with via the CID override field in the appropriate outbound route.

Again, the OP wanted a way to do this via the GUI. He was told that it was “impossible.” That’s not true. Depending upon how he wants things to work, it can get very complicated. Using a Dial Plan or a Custom Context is a much easier way to do it, but it is possible to accomplish via the GUI without doing anything else.


(Tom Ray) #20

If writing custom dialplan and doing things outside of the GUI is impossible or not desired. This suggestion fixes all that. Doesn’t matter what context they are using on the PBX when the FXS gateway won’t allow the call to even leave the gateway.


#21

Hey! The OP stated that the PMS module offered a possible solution and has not replied since, so we can assume that it issue is solved.