Hey, I’ve recently discovered FreePBX has a free community-made version of the paid extension Endpoint Manager (Endpointman), I’ve tried installing this because the FreePBX wiki still mentions it. After trying to in
stall it FreePBX immediately throws an error. How could I fix this? And if not supported anymore is there any free alternative? I chose FreePBX because I didn’t want to pay for 3CX although FreePBX isn’t really “Free”. After all, the modules like this are paid which sucks. Could anyone help?
To quote the home page:
" Freedom to Communicate
The “Free” in FreePBX stands for Freedom. That’s because FreePBX, the world’s most popular open source IP PBX, gives users the tools to build a phone system tailored to their needs."
I believe you are referring to OSS Endpoint Manager. That project has been put down by the original developer and picked up a handful of times by others, but at this point takes some effort to get somewhat operational. I don’t strongly recommend using it.
If you insist, these links may help you on that journey:
https://nerdvittles.com/introducing-oss-endpoint-manager-for-freepbx-16-incredible-pbx-2027/
https://nerdvittles.com/oss-end-point-manager-returns-for-incredible-pbx-2020/
If you haven’t settled on a phone brand, I would actually recommend looking at ClearlyIP phones, they include a great provisioning module, and also offer some amazing features. To just name one of the many features I love, you can set BLF keys that auto update upon extension name updates (Has saved me hours).
1 Like
There is a developer @vsc55 that is doing some work to bring it to 17. I believe he is doing it in his free time so I don’t know the status or timeline. That said there are way$$ to motivate developers lol. I would keep an eye on
2 Likes
That’s a new one. The last one I knew about was the billsimon one mentioned in the earlier link but it was only brought current with FreePBX 16 and PHP 7x Given the age of commits on Javier’s one he might have cleaned up the php code for php 8
Even the commercial endpointman is not very good unless you are using a very very tiny selection of phones, because Sangoma has a pay-to-play approach to it, thus the only VoIP phone vendors who are willing to pay Sangoma to get their stuff into the commercial endpointman are the ones like Yealink who don’t have enough of a reputation to sell PBXes. I have several dozen different models of phones in my test box and only a few are provisionable by the commercial endpointman.
I would strongly advise you to learn how to use a text editor, tftp/http server, and templates to provision manually. That’s how I provision my Cisco and Polycom phones. It is actually just as fast as doing it via a GUI in fact, probably faster. All I do is plug in a phone I want to provision, tail /var/log/syslog to get the name of the provisioning file the phone is requesting, then make a temp copy of the provisioning file and modify the extension # and password, then move the temp file to the filename the phone is bugging the tftp server for and voila, within a minute the phone is setup.
There is this “mystique” about provisioning phones as if the GUI is covering up one of the great mysteries of the universe and us mere mortals could never understand how to do it. However the reality is that the GUI is nothing more than a crutch.
If you were running an IT department with 20 people and you were provisioning a couple phones a day, you MIGHT justify the GUI but then I’d ask why are you running an IT department that large and not assigning a specific person to provision phones, and why do you even have an IT tech working for you at all who is afraid of the command line, and a text editor?
The number one rule in being a sysadmin is to perfect your solitaire game. Anything that can be automated or done by a script indtead of a human should be.
I would argue if you have someone editing text files for every move/add/change your doing it wrong. There are several endpoint management solutions out there and manual editing is one of them. If you only use one brand of phone you can create your own automatons to sync all the files yourself. The original commercial endpoint manager code started off as a Provisioner for Aastra phones in the Schmooze days because that is what was needed. It wasn’t started as a commercial product. Anyone with minimal skills can do something similar. When you have to add brands, models, etc and make it more complex that is when it requires full time maintenance. Sangoma at one point had a single developer that worked full time on just endpoint manager. I think that has gone away but it isn’t a passive task. By the way Vsc55 is the developer that made ossendpointman compatible with FreePBX 15. I would say next to the original author he may know the most about the code.
1 Like
And you would be incredibly wrong. Now, if you amended that argument to prepend the phrase “in certain environments” then you wouldn’t. But as a “rule”, ah no.
If you and I have a race on provisioning phones, I using my command line and vi text editor and you using your GUI, and I can complete the job 10 seconds faster than you - EVEN IF I do it with more keystrokes - then you lose, simple as that. I’ll get more Solitare time.
And if I can control the environment I can optimize it to use a phone that is easy to provision that way - then there’s not a snowball’s chance in hell you will be able to write a GUI provisioner that will be faster than I am.
Of course, if the goal here is to have the fastest phone provisioning possible then you design the phone and the system so that it’s user provisioned. That is, when the new user sits down they pick up the handset, dial a code, then has a conversation with an AI that ends up setting their properly spelt name, informs them of their extension #, DID, sets up passwords on their mailbox and tells them how to remotely access the phone system and their voicemail. I don’t know if any of the major “cloud” extension providers (Vonage, etc.) are doing that but I’m sure it’s only a matter of time.
There is an assumption out there among users that a GUI is always automatically faster. This is an assumption that was pushed by computer software vendors when personal computer software transitioned from command line to GUI back in the 80’s and 90’s. There is a huge long history to this and reasons it happened that had a lot to do with shifting the US workforce of 50 million or so office workers from typewriters to computers who had no generational or upbringing experience with computers. The mythos is that Evil Bill Gates “stole” poor sweet Steve Job’s Apple interface but that’s just fun and games for computer wannabes.
The professionals that study user interface design understand the issue and it is far more complicated. In some environments and for some tasks a GUI is faster but for other environments and tasks it is slower. This is why Microsoft is continuing to expand PowerShell
Back in the very early 90’s I worked as a payables clerk in a large software company. We used glass terminals on an IBM AS/400. At that time I got to the point that I could input a check run of approximately 300 invoices in 1 hour using the AS/400 terminal. That’s 1 invoice every 12 seconds. When they finally one day decided to replace our terminals with PCs running 400 terminal emulation my input speed dropped and the same checkrun input now took 2 hours. I knew immediately it was because of the keyboard and that was when I got introduced to the whole “clicky mechanical keyboard” thing. My speed got better but it never reached it’s prior amount. If at the time I had realized mechanical clicky keyboards existed for PCs and pushed for my keyboard to be replaced I would have gotten back to where I was before. (I have since rectified this as I now do have a collection of mechanical keyboards that I use in some environments. I have also tested different keyboards for speed and while my typing speed is highest on the standard bucking spring keyboards it’s higher on the low profile keycaps common on laptops than the “mush” garage keycaps on most cheap PC keyboards - my typing speed ranges from 40-60wpm depending on accuracy with 96% accuracy at the low end and less at the higher end)
Years later when I opened my consultancy I like so many people doing that was using Quickbooks. Now I was taking 2 hours to input roughly 20 invoices. I do NOT believe that there’s an A/P clerk anywhere left that has the kind of speed input that us clerks routinely would achieve back in the 80’s/90’s although some approach that - when using enterprise accounting software that…drumroll…uses properly designed Windows Forms desktop software that does not require the operator to take their fingers off the keyboard and use the mouse, to go from screen to screen and invoice to invoice.
PhD’s out there study this stuff. Data input in computing has been studied quite a bit. Phone provisioning is essentially that - you are inputting data into a form. If you can design the input so that the operator can do it 100% by not taking fingers from the keyboard AND you use repetitive forms where the same keystrokes are used to move around the form - then once the operator gets experience and skill they will kick the ass of a GUI user every single time. This is because mice do not have rest positions and reference points that can be found without looking at the screen.
Not exactly but close since different phone models in the same brand can vary in configurations so it can’t quite be made that simple but yes, this is why in large deployments they prefer to only use a handful of different phone models. For example, I use Cisco 8845’s and 7821’s in my employer’s enterprise for this reason even though my phone guy provisions via GUI (and probably types 10wpm if that, lol) even though the Cisco UCM supports many dozens of phone models. And my department is not that large and as such my “phone guy” isn’t really a phone guy, just a regular IT tech who prefers not to run all over the place and so prefers stuff like phone provisioning where you don’t have to do that. (I have other techs who do prefer running around gossiping with users who don’t prefer stuff like phone provisioning, so they get to crawl around under desks.)
GUI’s have their place but the OP is obviously one of the IT people doing this for the learning experience stuff which is why I advised him to really learn how the stuff works under the hood. If he was managing a staff I would advise differently. IT staff talent in a large part really determines your choice of tech. If you have staff who are flakes, you probably aren’t paying enough and you are just screwing yourself or you are just a poor manager. But if you are managing right and paying right your going to have staff that stay around for a while and you really need to suss out their talents and abilities. There’s good IT techs out there who I’d never trust with command line provisioning and would need the GUI training wheels slowing them down, and there’s good IT techs out there I’d trust with CL provisioning who would get extremely frustrated with the GUI limiting them.
I’m not sure what you are referring to exactly when you keep saying GUI since you really didn’t clarify it. Phones have GUIs that allow you to provision them, is that the GUI you are referring to when you say GUI? Or are you referring to a GUI like the EPM (commercial or OSS)? Because those GUIs are two completely different things.
The phone’s GUI will have limitations. Not ever feature will be able to be managed or configured via the phone’s GUI. It requires provisioning files as per their documentation. A GUI like the EPM is a completely different beast because it was created by someone to do more than what the phone’s web GUI allows.
I wrote my own for the stuff that we do with the phones and gateways. Right now I have a hotel that has three 48port gateways and a handful of Yealink phones. I bet me copying a base template for my Yealinks, making some minor updates and associating the six phone MACs to the template is still faster than editing six different files by hand. Because now I can either use DHCP Option 66 to drive the phones to their new configs or I can just pop into the phone and enter the provisioning URL, user and pass.
Believe me, having a template for 48 port gateways that can pull all the account details (name/user/pass, etc) from our backend systems when the config file is generated beats having to use vi or any text editor to edit 48 different accounts with name/user/pass.
Oh and as someone who has worked at VoIP providers and CLECs for the last three decades…no one wants to hand edit phone config files on a day to day basis because it’s rather time consuming.
The title of the thread is “OSS EPM” and that for sure is a GUI provisioner.
With enterprise phone provisioning (ie: provisioning large numbers of phones) decentralized provisioning (that is, the provisioning data is stored in the phone) is completely impractical. For starters if the phone dies you would have to have a backup of how it was provisioned. I am referring to centralized phone provisioning. Even phones that do have GUIs will respond to provisioning files in most cases. The two test phones I have that don’t are clearly intended for very small setups and both companies that made them ended those product lines years ago.
But that’s exactly the same process I’m taking about. For example take the Polycoms, when they boot they pull down a single provisioning default file that contains the same thing your base template does - basically everything that is common between all phones, then they pull down a separate file that is tied to their MAC which contains only the different things - basically the extension and password. That is, the same minor updates you are referring to. The Cisco phones work the same way.
That isn’t how OSS EPM works which is what started this discussion but there’s zero barrier to doing it the same way if you wanted to with the Ciscos or Polycoms - but that’s not a GUI solution either. That’s a fully automated single point of data entry provisioning system
I also detailed an example on how that could be done for a CLEC and that it would be superior to the GUI or manual provisioning system for a large number of phones like at a VoIP provider.
Can you clarify this a bit? Having the provisioning server details in the phone isn’t impractical. It’s basically three or four pieces of information. URL, method, username and pass. It is impractical to have that in the phone?
I do have a backup, it’s the config file that exists on the provisioning server. So I can factory default a phone and throw the provisioning server details in it either manually or via DHCP options for the phone to pull the new config.
You are assuming you understand how my system works, it doesn’t work like that. Each phone has its own config because each phone could be programmed differently. I’ve had offices where all the phones where pretty much the same but some phones had certain features and others didn’t. I’ve had it where every user had BLF’s for all the other users in the office (minus themselves in the list) so that means each phone for each user is unique because they all have one thing in them that is different. Along with some having parking lot BLFs and some don’t. Some might have a special dial out key that presents a specific callerID when they use it to call out.
The user provisioned thing where the AI sets it up? How would their handset talk to the AI? It would need to dial into the phone system to have this conversation. How would the phone be able to call into the phone system if it hasn’t been provisioned yet? Also, the MAC address details aren’t sent during this initial phone calls, so how would the system know what to do with the device?
[quote=“BlazeStudios, post:10, topic:100644”]
Can you clarify this a bit? Having the provisioning server details in the phone isn’t impractical. It’s basically three or four pieces of information. URL, method, username and pass. It is impractical to have that in the phone?
[/quote]
Yes in many environments no in others.
It is not impractical if for example you have 1,000 phones all exactly the same button layouts and same models the only difference being the phone number/extension number on each phone. An example might be a hotel or hospital with a standardized extension layout with 90% of the phones one model and 10% of the phones office/executive/etc phones that are different layouts/models. In that case you might use a provisioning server with central phone provisioning for the 100 phones in offices/execs and a your-on-your-own decentralized storage for the 900 extensions scattered like leaves on the trees through the rest of the hospital. However the IT people servicing the 900 extensions will have to have some mechanism to avoid a collission (assigning the same provisioning info to 2 different phones) or you will have embarassing things like someone calling a lobby phone and an instrument in an exam room rings in the middle of an exam.
It is not impractical if you are running for example a public VoIP phone switch that supports BYOD/BYOP (Bring your own device/bring your own phone) and you have some customers who maybe have groups of phones with multiple phone numbers on some, BLF on some, etc. some customers with single phone, etc. In that case you will be having the customers responsible for their own provisioning and you won’t supply a provisioning server at all. Since each customer does not know the provisioning details for other customers there won’t be collissions however, customers with multiple extensions can shoot themselves in the foot by colliding their own phones.
But I think it’s impractical on a large enterprise even if you have all the same phones because you will have some departments doing different things with extensions in their department. The techs servicing this would have to carry around a book with all phone configs or something. It’s just easier to centralize it.
In Real Life it’s also impractical for example for the Comcast ISP who supplies cable modems with POTS ports - their hardware on boot pulls from a central modem provisioning server so if a customer modem fails one of their techs carries out a new modem and calls in a MAC address swap to the central office who just changes the MAC address in the central provisioning server.
For something like that you do an automatic provisioning, I have seen this in action with the Comcast gear. You can literally go to a customer who has a Comcast cable modem with POTS ports. You plug in a phone, pick it up off-hook and after a moment you hear dialtone, you talk though the script. When done your account is updated and now the phone can make calls. Obviously their hardware senses the off-hook condition, sends a provisioning request to the central office, the central provisioning server provisions a temporary extension to a sign-up IVR, then that system does the complete provisioning with new phone number assignment and so on.
You could duplicate this on a public BYOD VoIP provider with a phone that supports http provisioning. The VoIP provider has on their website instructions for the new customer to modify DHCP params in their SOHO router to point to the provisioning server. Customer does this, plugs in their VoIP phone, that starts issuing repeated provisioning requests with MAC to the server, server provisions a temporary phone number for any new provisioning request, customer phone provisions, customer makes any call to any number and that is routed to the IVR that gets the credit card info, charges the card, sets up the account, sets up new provisioning data and tells customer to power cycle phone. Could be completely automated via AI. You might also need to severely restrict it to certain phone models that use known filenames for provisioning files although parsing the MAC address will get you the manufacturer of the phone at least so that can help.
So a preconfigured device, configured for your services such as voice. Kind of sounds like the service was already setup and that was a wizard to finalize it. Done that in the past too in various ways.
I will just say the logic you have presented has never been used at any company I’ve been with including the CLEC where we were shipping out 100’s of phones almost daily.
The service was probably already setup but it was not “tied” to the customer account for sure since this is for new residential customers who were only paying for Comcast cable Internet already and not voice. It added voice to their account. I have no idea of whether the turn up provisioned the back end number and routing and all that or if that was already done and the turn up just connected those to that particular customer account. I can think of several ways to do this.
As for nobody did this before I can also think of several other reasons.
First of all AI is changing a lot of stuff these days and enabling automation in user interface in ways that were not practical previously. Eventually Microsoft Windows will be able to parse out:
“Computer do that thing with the files we did last time not that other thing”
LOL
But more importantly I would say the reason my logic has never been used was not because it would not work. It is almost certainly because it is much more profitable for a CLEC to browbeat a customer into discarding a perfectly good working VoIP telephone and dropping a C-note on a brand new piece of junk phone and plugging that into a $20 a month phone line, vs having the customer take their perfectly good working telephone from one CLEC to another for a $20 a month phone line.
As proof of this I will point out in the US the federal government had to pass a law forcing telephone companies to allow number portability. And that many years earlier the Carterphone decision was used to force the Bell Telephone company to allow people to take their perfectly good working telephone from one phone company to another and plug it in.
The modern telephone companies today may have changed their names, changed the protocols, but still the Telco industry has a very strong Dark Side of the Force thing going when it comes to vendor lock in tricks on customers. And we all know that otherwise FreePBX wouldn’t have the name “Free” in it.
Something as trivial as the “de-facto standard” in VoIP telephony provisioning being the filename comprised of characters indicating make/model/mac done in the very beginning of VoIP telephones instead of just mac, would have easily permitted a BYOP for customers taking VoIP desk telephones from one CLEC to another.
Maybe it’s time for another Carterphone decision on VoIP telephones? It’s easy to see the CLECS and telephone set vendors would fight that tooth and nail. The name of the game is get things to be 99% compatible with that vital 1% incompatible so as to prevent products becoming commodity items and the politicians, consumers, and courts are too tech-ignorant to realise this means their costs for tech and far higher than otherwise.
I may benefit personally from this but I’m not going to lie to people and tell them it’s for their own consumer good.
Note that setting aside the public company political aspects of this, it might be a scheme usable on something like a large college campus where you used non-IT staff like Facilites people to shuttle around phones. Obviously you would have control over make/model of phone so you could incorporate canned templates in your provisioning server.
In every provider I’ve been at, even the CLEC, we allowed BYOD. However, BYOD meant you were on your own for configuring the device. If you did BYOD and it was a supported brand/model, we were happy to add it to our provisioning system so we could manage the settings on the device.
BYOD was something that residential customers did the most but had businesses do it as well. However, this is all in the context of hosted services and during a time when most places had TDM based PBXes and non SIP phones. So they converted to hosted and needed phones. Even when they converted to a SIP PBX, they still needed phones.
The CLEC did a lot of work with the universities in the state. So when U of M moved to us…we didn’t make them replace existing phones. That would have been silly.
Well an update:
I installed the latest
GitHub - vsc55/freepbx_endpointman
In my FreePBX 17 system by doing the following:
- SSH into the command line, su to root
- cd /var/www/html/admin/modules
- wget https://github.com/vsc55/freepbx_endpointman/archive/refs/heads/release/17.0-dev.zip
- unzip *.zip
- mv freepbx_endpointman-release-17.0-dev endpointman
- fwconsole ma install endpointman
- fwconsole reload
- chmod -R g+w _ep_phone_modules
- chmod -R g+w endpointman
- chown -R asterisk _ep_phone_modules
- chgrp -R asterisk _ep_phone_modules
After that, I logged to FreePBX, clicked Settings, scrolled down to the OSS Endpoint Manager screen, clicked that, and on the right side of the screen is the flyout, click that, click Settings in Endpoint Manager, and go from there.
it will download install and uninstall packages from either it’s default https://raw.githubusercontent.com/billsimon/provisioner/packaging/ or from the package server at https://ossepm.incrediblepbx.com/
Click Package Manager under the Brands and you can go in and download and install phone packages.
I did not attempt to actually provision any phones with it. It’s clear that it does need some time to figure out since some of the phone brands you can install (polycom) it installs firmware for, while others (cisco) it does not. It might be useful for a site that needs a phone provisioning GUI and has few phones.
I also wasn’t able to get the package import/export to work. I WAS able to import an OLD package from the Wayback machine but it blew up with Ajax errors so clearly anyone wanting to create their own packages for phones that aren’t already in the Provisioner URLs above is going to have to start with the docs off the Wayback machine here:
https://web.archive.org/web/20110314061313/http://www.provisioner.net/adding_new_phones
Then look at a sample out of the wayback machine, and then look at a more modern entry for a phone model that’s in the provisioning servers above to see what changes would need to be made.
1 Like
Hello everyone.
@tmittelstaedt I do not recommend that you use the dev branch, it is under development and still has a long way to go, and with the changes I am making I am sure I will break something somewhere else.
I am doing a complete code review since this module comes from very old versions of freepbx and there is a lot of obsolete code and functions that no longer work.
Incidentally, I am giving it a facelift in terms of layout.
I’m doing this in my free time and it may take a while to finish.
For now I leave some screenshot:
2 Likes
Hey, thanks for your efforts on this! The wget command I listed pulled from the release branch not the dev branch. I was cheered to see that more current Cisco phone provisioning packages were present. My post was mainly because there are some people who want an open source provisioner module and this is a way to let them know that OSS EPM is still alive under FreePBX 17. There are now around 5 or more older versions of OSS EPM including what seems to be a private fork of the billsimmons one that is being hosted by the incredible pbx for FPBX16, and it is very confusing for a newbie who does not know the history of this module, and easy to end up installing one that is incompatible with their version of FreePBX.
Any of these GUI provisioners really should be proofed for the environment they are installed into by carefully comparing their XML output against a tested XML phone provisioning file for phones that you actually have deployed at your site. The only ones that really should be regarded as authoritative sources of phone provisioning files are the phone-manufacturer paid for ones, and the only FreePBX ones I know of now are the ClearlyIP one for it’s phones, EPM for Sangomas’s phones and the phone-vendor paid certification entries in EPM (which I think is mainly Yealink) For every other phone (snom, astra, Cisco, etc.) the outputs of both OSS EPM and the commercial EPM need to be carefully examined and tested with actual phones before being trusted in production.
I realize for a newbie to FreePBX I am basically putting them in a chicken-and-egg situation, they don’t know how to manually provision so they want to depend on EPM or OSS EPM for provisioning files, and I’m saying they have to test output with manually-created provisioning files, which if they can create such files from scratch they don’t need EPM or OSS EPM. But, XML is easy to understand and after spending time looking at XML provisioning file examples for your phone model it’s not that hard to get the hang of what the provisioning file is supposed to look like.