Proposed Intercom Solution

Hi Developers,

I’ve written some code that, while crude, gives a highly flexible intercom functionality. It allows every extension to select which extensions it is willing to accept intercom calls from, or which to deny intercom calls from – and since it’s based on caller ID, it even gives the option of giving intercom access so certain outside callers.

The paging functionality that’s currently in FreePBX is excellent, but the intercom functionality, I think many believe, is non-existent or half-baked, because the only way to get intercom is through the paging system, requiring people to define all extensions TWICE, a regular version and a paging version.

The only other option is to use *80, which again is clumsy workaround for something that is literally a mainstay on traditional PBX’s. The problem with the *80 workflow also is that it should never be the caller who gets to decide whether a call is on intercom, it should be the RECIPIENT. The *80 workflow has significant privacy and security problems – think if someone *80’s into the bosses office. Absolutely noone should have that kind of access. And it is also incompatible with BLF buttons, because they can’t prefix the *80, thereby denying you the possibility of push-button-intercom. But the alternative shouldn’t be to be forced to disable intercom altogether. I think that *80 is a misunderstanding and not a good approach.

This proposed solution is recipient-centric, where each extension has list of extensions to either ALLOW or DENY intercom calls from.

This code is sort of a hack, in that I’m modifying extensions.conf directly, and calling a php script from the webserver that makes the decision about whether to include the auto-answer headers for Grandstream and Polycom phones for a given call. If you were to include this in FreePBX, it should obviously be database-driven. I would then suggest to re-label the “Paging And Intercom” section to just “Paging”, and add an intercom extension list to each extension’s configuration page, where in addition to the list you have 4 radio-buttons, Deny All, Allow All, Deny List, Allow List. Intercom is a feature of the particular extension, not the system itself, and it therefore belongs on the extension config page.

Anyway, here is the code, and I strongly believe that this intercom behavior ought to be in FreePBX… of course not programmed the way I’ve done it below, but this is just a proof of concept. Try it out and tell me if you don’t just love it.

First of all, in extensions.conf, locate the [macro-dial] macro, locate Sequence number 10, and replace 10 and 11 with this block:

;
; Step 14 and 15 are from original code, only renumbered.
; This segment uses localhost/custom/intercom.php to determine whether to add SIP headers for intercom
;
exten => s,10,Set(DOINTERCOM=${CURL(http://localhost/custom/intercom.php?dest=${ARG3}&src=${CALLERID(num)} )})
exten => s,11,GotoIf($[ “${DOINTERCOM}” != “ALLOW” ] ? 14)
exten => s,12,SIPAddHeader(Call-Info: answer-after=0)
exten => s,13,SIPAddHeader(Alert-info: Ring Answer)
exten => s,14,Dial(${ds}) ; dialparties will set the priority to 10 if $ds is not null
exten => s,15,Set(DIALSTATUS=${IF($["${DIALSTATUS_CW}"!="" ]?${DIALSTATUS_CW}:${DIALSTATUS})})
;
; End of new segment
;

If you’re using a later version of FreePBX than the 2.? this is done with, the whole point is to just squeeze in some action at sequence #10, and then the original code gets executed at #14. You may want to keep the original code, and just insert #10-#13 before it, and renumber, just to stay compatible. Execution starts at #10.

Then there’s a PHP script, which on Elastix is installed in /var/www/html/custom/intercom.php (“custom” is a new directory in the web root).

Here is the script, intercom.php:

<?php // Selective Intercom, 2008 Per Holmes, Public Domain // // This PHP script assists code in extentions.conf in determining whether to send SIP headers // to phones for enabling intercom/auto-answer. This allows each extension to choose // which other extensions it is willing to accept intercom calls from (or which extensions to // deny intercom calls from). Intercom must also be physically enabled on the phone itself. // // If an extension is not listed in the array below, the default is NO INTERCOM. // If ALLOW is selected, ONLY the listed extentions will be allowed to intercom. // If DENY is selected, all extensions will be allowed to intercom, *except* the listed extensions. // To allow all, select DENY with no extension. To deny all, select ALLOW with no extensions. $extensions = array ( // Syntax is: (destination) => array(allow/deny, source1, source2, source3, source4, ...), 201 => array("DENY"), 202 => array("DENY"), 203 => array("DENY"), 204 => array("DENY", 240, 241), 207 => array("ALLOW"), 240 => array("ALLOW"), 950 => array("ALLOW", 210, 211), // Example: 950 allows intercom from 210, 211 951 => array("DENY", 220, 221), // Example: 951 denies intercom from 220, 221 952 => array("DENY"), // Example: 952 allows intercom from everyone by denying noone ); $dest = $_GET['dest']; $src = $_GET['src']; if ($extensions[$dest][0] != "") { $mode=$extensions[$dest][0]; $srccount=1; while ($extensions[$dest][$srccount] != "") { if ($extensions[$dest][$srccount] == $src) { echo $mode; exit; } $srccount++; } // Return opposite result as default if ($mode == "ALLOW") echo "DENY"; else echo "ALLOW"; exit; } if ($src < 1 || $src > 9999) echo "DENY"; // If callerID is >9999, then it's a phone number = outside call = always deny // This is placed last to allow the possibility of a specific phone number // having intercom access to certain extensions. To do that, simply enter the // callerID as an allowed extension. echo "DENY"; ?>

Again, this solution is not the most elegant one – it probably should be an .agi file or something, and this should all be integrated. But it works.

Notice the piece of code at the end that says if ($src > 9999) then DENY. The point is that if the extension number is over 9999, then it’s not in fact an extension, but an outside call. It is placed last, because then you have the option of actually making an extension willing to auto-answer a call from a certain outside caller if you program it into the arrays, but only if. You could use that to call in to hear if a machine is still running or whatever. We for example do a lot of remote printing because we have multiple locations with VPNs back and forth. With our 3Com system, we would routinely call and hear if a printer was running. You don’t have to do this, but the option is free. It’s also set to check if $src < 1, because if the caller ID for some reason was a string, it might resolve as 0.

Anyway, I hope that you’ll give this approach serious consideration, because I believe it gives an intercom functionality that will allow everyone to get what they want, and not be forced to either (1) have intercom across the board, (2) have no intercom, (3) use *80 which has serious privacy issues, is tedious and doesn’t work with BLF, or (4) set up double extensions for everyone to page them. Extension-to-extension intercom is what everyone wants, and you can readily find hundreds of forum postings where people ask how to do it.

I think that this proposed solution is flexible enough, and simple enough, that it’s right for FreePBX. Not the code, good heavens no. The concept.

Best,

Per

perholmes,
First a disclaimer - I read the first half of your post very quickly and I have to run right now but wanted to get something out. You should look at the Paging & Intercom in 2.4 as it has been significantly overhauled. It already has allow/deny functionality for instance. There is also a lot of functionality that it has that is not even exposed in the gui. It does require a feature code to intercom but you will find that most environments do not want intercom to be default and it is very straight forward to program blf buttons or combo buttons where you press interocm button followed by the blf extension of the user you want to call (or just program it in a intercom if you always want to call them that way).
In any event, like I said I have not read the rest of your thread but it is a really good idea to build upon what is the latest vs. the previous release since, as you are aware, Paging and Intercom was in really bad shape in 2.3 an prior.
One last parting thought - which I have no idea if you addressed in your code, is to consider Devices and Users mode of FreePBX. FreePBX can have multiple phones registered to a single user. The new Intercom functionality in 2.4 also work with that scenario. So if you intercom Joe who has two phones, one at his desk and one in the store room, it will intercom both of those phones, effectively into a 3 way duplex page with the caller.
Anyhow - take a look, there may be some good stuff which may go well with other ideas and wishes that you have.

Hi Phillippe,

Thanks for responding so soon. I can see that we’re running 2.3.1.3, which is part of the last Elastix distro. We unfortunately can’t experiment too much with upgrading, because it’s a live system. So I don’t know what’s in 2.4, and I won’t see it until it becomes part of Elastix.

I must comment on the *80 prefix for intercom, because I’m obviously of the opinion that it is tedious and also precludes push-button-intercom, which all of us loved for years, but the most important part is that it’s philosophically wrong. By definition, *80 let’s the CALLER authorize the intercom, whereas it’s the RECIPIENT who truly should have that authority. Under no circumstance should someone be allowed to secretly bug someone else’s room, and the only security precaution the recipient person can take is to disable intercom altogether.

Take a lawyers office. The lawyer will want the secretary and the front desk to have intercom access. For everyone else, the phone should ring normally. His phone would be set up to allow the secretary and the front desk, and disallow everyone else. This is natural.

Or in our case, I have a lot of phones in my house, and also a small company with a couple of employees who each have a couple of phones. I want them to be able to intercom me in my office, but not in my bedroom. Rather than making long lists, my office is set to allow all, but my bedroom is set to deny just the employee extensions and allow everything else. This is again natural.

I don’t think there’s a public preference for having to dial *80. Rather, in the digium forum there is page up and page down of people begging for the normal BLF/intercom functionality. I can find this question asked hundreds of times around the internet.

But I’m so happy I programmed this, and also finding out that programming Asterisk and FreePBX is relatively easy and fun. We now have exactly the behavior that we want, and if it never gets included into FreePBX, that’s all right too. I’m posting it here so that other who want it can have it, and I will keep adding the mod to every subsequent FreePBX upgrade, because it just really, really, really works. There’s a reason that this behavior has been a mainstay on PBXs for decades. Especially in organisations where you have tiers, like a front desk representing a secretary representing a lawyer, because it establishes “trusted relationships” who have push-button access to each other. The lack of this functionality has been a deal-breaker that has kept people from wanting to switch to asterisk. I’ll find you the digium threads, there are installers who have dozens of clients, some very large firms, who won’t switch because they can’t have this workflow.

As it already exists on classic PBX’s, it’s not really my idea, but an idea that I think has proven itself. I therefore hope you’ll consider this for FreePBX. Having to type a code is not preferable to not having to type a code. And intercom is a form of priviledged access, which should never be authorized by the caller, it should be authorized only by the recipient. And the recipient shouldn’t be forced to deny all, just in order to deny some.

Anyway, hope I’m not too pushy. I am astonished at the quality of FreePBX, and a great admirer.

Best,

Per Holmes

P.S. I realize that this approach is device-centric and not user-centric, and perhaps it needs to stay device-centric, just because one would have different preferences for each device.

Per,
go read up on the new intercom, it addresses some of your issues (disable to all, selective white list to some, as one example). You have some reasonable requests in other features you would like but it will be much more productive if you see what is there and then provide ideas against that basis.
As far as Elasitx, I suspect Edgar will have 2.4 out on it before long. I will be releasing 2.4.0 this weekend as it has proven itself out over the last 2 months in a very solid beta cycle with well over 1000 sites testing.

Hi Phillippe,

Could you help me locate the URL where this is discussed?

Thanks!

Per

Hi Phillippe,

Found it on the development site. Some of it is almost the same, and I think it’s great that you’re adding keycodes so that people can control their ALLOW/DENY list directly from the phone. This will give regular folks some control without having to enter the admin interface or have a tech do it. But from my experience, once this is set, it never changes. I think I only changed the configuration on our 3Com system once in several years.

There’s one thing you have on your wishlist, which is a longer beep. Me, personally, I gasped a sigh of relief when I first heard the Grandstream auto-answer with just a 1/4 second beep. On the 3Com, you would get this 2 second beep, and although I’m sure they did it for the exact reason of making the intercom situation known and prevent spying, oh man did it always bother me, for years. I think the responsible thing for you to do is put the beep in there, but for me, personally, my first order of business will be to find that line of code and comment it out.

But as I understand it, you really do have the same solution, which is to have a list under the extension itself, which determines who is allowed or denied. It also appears that you agree that intercom is a device feature more than a user feature, and I couldn’t agree more. When intercom is easy to do, you quickly push the button for ext. 205, “Mike are you there?”, no answer, you push ext. 208, “Mike are you there?”… and there he is. If you routinely need to get Mike and you know he might be in several places, this would be time to set up a Paging Group to ring a group of phones at the same time. In my book, I kind of can’t predict the consequences if intercom becomes a user-thing that might potentially ring many phones, because then you also have many simultaneous talk-back, which I think could become a mess. Therefore, I think intercom needs to be strictly device-centric, which I assume means extension-centric. Communicating with more extensions then requires a paging group. Intercom is thus one-to-one, while Paging is one-to-many.

But I have to say that the absolute biggest deal for me is that the *80 workflow is intolerable for all of us. When you have had push-button-intercom on your PBX, giving it up is like going back to manual transmission and no garage-opener. You can do push-button intercom while you’re juggling a baby, eating a sandwich, you’re too lazy to reach the phone so you extend your arm with a pen, all that stuff. Otherwise, you have to go off-hook, dial *, 8, 0, extension (or the BLF), and suddenly, it’s not an intercom, it’s just a way to get people’s phones to auto-answer so you don’t have to wait for them. On their end, it’s certainly an intercom. On your end, it’s a calculator.

If you have the ability with your current version of FreePBX to quickly hack it to try this auto-answer workflow in conjunction with the BLF buttons, I really urge you to try it, because I think you’ll really like it.

And I must say thanks to you as a developer, because you seem to able to consider other paradigms, and even though you might not agree, you’re at least considering the logic of the argument. It’s very rare to get that sort of consideration, most developers will not in fact consider other paradigms. I think that’s great, and ultimately you’ll make the decision you think is best for FreePBX.

Best,

Per

Per,
you can program blf buttons with the *80 so it is all one button. But anyhow - my suggestion is, once you have become familiar with what is in 2.4, since for better of worse, that is what is going out the door as we don’t make feature changes in current releases typically, then you ca file specific enhancement requests to build on top of, change or provide alternative behavior to what is there.

Hi Phillippe,

Certainly.

Can I ask, if you include *80 in the BLF, does that work? I’m assuming you mean that on for example Grandstream phone, you literally type *80205 as the User ID, and then you’ll both have BLF behavior as well as intercom when you dial? Doesn’t the system get confused about which hint you’re trying to access if the extension is called *80205 rather than 205? I’m assuming that *80205 would become SIP/*80205, an extension which doesn’t exist, and thus the hint wouldn’t work.

Certainly, that would allow you to micro-manage intercom permissions, although it’s still on the sender end, and as I’ve argued, should probably be on the receiver end instead.

I think it’ll probably be a while before I get to see 2.4 because I have to stick with the distros for safety. Please convince Elastix to put it in ASAP :slight_smile:

I must admit that I still don’t have a clear picture of how intercom works in 2.4. If it doesn’t allow you to allow/deny people based on a list (that is edited wherever), and to push-button-intercom directly from the BLF buttons, I would strongly suggest that for some time in the future.

And regardless, thanks for all your hard work.

Best,

Per

well right now if you put *80205 you won’t get blf without manually putting in the hint code, but the feature request is in and it is just a minor loose end that hasn’t been gotten to yet to add it in. If it doesn’t get in this weekend before the release, it’ll be on the short list for an upgrade shortly there after as it should be there and the code is very straight forward.

Excellent!

But have I understood it correctly that 2.4 contains an allow/deny list for each extension, or is it just a global list or a global group who has unselective intercom functionality among themselves?

Thanks,

Per

It maintains white/black lists in the user objects for each user who controls it with a feature code. At this point there is no user portal interface to edit the lists although clearly it is a very doable thing since they are all in the user objects and controlled just like other features such as followme are controlled.

*80nnn: Intercom extension nnn
*54: Enable all extensions to intercom you (except those explicitly denied)
*54nnn: Explicitly allow extension nnn to intercom you (even if others are disabled)
*55: Disable all extensions from intercoming you (except those explicitly allowed)
*55nnn: Explicitly deny extension nnn to intercom you (even if generally enabled)

Well, then it appears that you’ve already implemented almost everything I’m suggesting. I would much prefer to edit this in GUI rather than on the phone, especially because a lot of phones might share the same allow or deny list, so you could copy/paste from extension to extension.

But when you say User, do you mean extension, or is there a hierarchy above extension called User where this is edited? Does this mean the possibility of being intercommed in several places at once? I think that should probably be reserved for paging.

And are you saying that with proper hinting, *80xxx as a BLF will both do direct intercom as well as show extension status?

If all this is the case, then the only thing I would probably consider for the future is to make intercom a decision made by the recipient, not the sender. After all, it makes no difference to the sender if the phone rings or if it goes to intercom – then they just have to shout “are you there” instead of waiting for the ring-tone to do it for them. I would thus suggest to possibly drop the *80 workflow altogether, and let the recipient turn the Intercom functionality on and off, both to control the list, but to also temporarily disable the whole thing. 3Com 3102 Business phones that went with our NBX system actually had a Hands-Free button with an LED that you could turn on and off. Intercom functionality was so integrated that this was built into the hardware layout.

On that note, I can see a trend in the development that looks great, which is to allow different features to be toggled via the same feature code, rather than having an on-code and an off-code. If you were able to map this to a virtual extension, so that pressing the BLF button would both toggle the feature, as well as light up the BLF depending on whether the feature is enabled or not, you would be able to have visual feedback on Intercom On/Off, Call Forwarding On/Off etc. Especially the call forwarding, I’ve seen people everywhere asking for visual feedback on. I never use it, so I don’t care, but I can see the problem of not having visual feedback, because you’re sure to forget, it’s not IF, it’s WHEN.

Toggling with BLF feedback would work excellent for these things. You would simply make a BLF for the virtual extension, 9876, which toggles Intercom. That gives you an Intercom On/Off button. I think that would be rather sweet.

Thanks much,

Per

doing visual feedback in feature codes has been an issue in the past because of the lack of a func_devstate() type functionality which is technically not supported until Asterisk 1.6 although there is a back port for 1.4. However, with XML applications, you can do the visual feedback quite nicely and it is very important.
as far as extensions vs. users: an extension = user + device. But a user can also be logged into or have multiple fixed devices which both represent their same phone. This is a mode of FreePBX that many people don’t even know about:

FreePBX Devices and Users Under the Hood

It’s true that you can do them with XML applications, and I assume you mean things like idle-screen XML on Grandstream or Snom phones. It’s just that nothing would beat having a button that literally toggles and displays its status. However it could be implemented, I think this would be ideal, maybe with fake virtual extensions that are dialed to toggle the feature through BLF, and they could reflect back the feature status as a hint and light up the LED. Things like Intercom or Call Forwarding you wouldn’t want to have to dig into a menu, they need to be served on a silver platter to be truly useful. In my experience, an enormous amount of mistakes happen with Call Forwarding because the setting is forgotten. Intercom you’d realize quickly, so it’s maybe not as important, and it doesn’t prevent you from getting the call. Call Forwarding has the possibility of being dangerous without status feedback.

Best,

Per

Per - XML abilities depend on which phones. You can get your silver platter with some phones such as Aastra, where the XML app is effectively your buttons with LED control, etc. - no different then if you programmed a BLF on a GS or SNOM.

Hi Phillippe,

There’s one last thing which I hope you’d implement regarding intercom. Basically, I’ve programmed my intercom solution so that if intercom is allowed, the headers for auto-aswer are included, but if intercom is NOT allowed, then I instead send a different Alert-Info, for example for distinctive ring. That way, in one go, you get auto-answer for intercom, and for everyone else who’s still local, you can get a distinctive ring for extension-to-extension calling.

This works remarkably well for us, it makes total sense in your user-experience. I’m very surprised at how natural it feels.

Best,

Per

My suggestion would be to review what is in 2.4 as you partially have, and then review your various suggestions and comment and start a section in the wiki as to what evolution and features should go into it from where it is today. This thread will eventually get lost, and since this thread is beyond a simple feature request, it’s usually best done that way. If you look in the dev wiki you will find a thread that already exists for paging which was a bit of a white board scratch pad prior to the current 2.4 version.

Two questions:

Has this feature been added to the current FreePBX?

How would you manually edit the hint code? I’ve searched, but my Google-Fu is failing me.

Thanks!

Philippe Said:

well right now if you put *80205 you won’t get blf without manually putting in the hint code, but the feature request is in and it is just a minor loose end that hasn’t been gotten to yet to add it in. If it doesn’t get in this weekend before the release, it’ll be on the short list for an upgrade shortly there after as it should be there and the code is very straight forward.

Check out this thread which I believe is what per holmes is looking for…

http://www.freepbx.org/forum/freepbx/users/station-to-station-intercom-without-80-preifix-use-your-one-touch-blf-keys-etc

-Andy

Andrew Miffleton
Telecommunications Technician
DFW Business Telephones, Inc.
(972)424-4242 x455
1260 Shiloh Rd.
Plano, TX 75074

On second thought, do NOT use the above code, I found a flaw in it’s design after some testing, but I believe I have found a way around the flaw, I want to do a bit more testing but it’s getting a bit late here and I’m currently taking a class for certification in the Samsung OfficeServ series of phone systems, so i gotta get some sleep, I will post back tomorrow when I’ve had a chance to test the new code and if it looks good I’ll post it up here :slight_smile:

-Andy

Andrew Miffleton
Telecommunications Technician
DFW Business Telephones, Inc.
(972)424-4242 x455
1260 Shiloh Rd.
Plano, TX 75074