Create an open api spec that can be used. We need a way to be able to integrate voip with other applications and having an open api spec would be helpful.
Unless I really missed something in the docs and code samples, the existing VoIP.ms API seems to be just a publicly exposed, tweaked version of the administrative toolkit VoIP.ms most likely created for their own internal use to manage client accounts.
Having access to that is great - if you are a big reseller. I have two friends that do resell VoIP.ms services but they both told me they would not likely ever need to use the API. (And, yes, they are superb coders.)
So, the API isn’t really a Telephony interface:
-
There’s no function for grabbing an inbound caller ID.
-
There’s no means of going off hook to pick up or dial out.
In other words, the API lacks basic features required for simple telephony services. (I don’t count remote control over things like altering failover settings, etc.)
I did put in a formal request for a proper Telephony API, but I have no clue where, or if, that will go anywhere.
I’m reasonably certain their system is built on / from decades-old, open-sourced Asterix which would imply at least the potential to build out such an API. Of course, doping so would be a non-trivial task. Without knowing the goals of the CTO at VoIP.ms, I have no clue what kind of budget would be available, if any for a larger project like this.
That said, however, it seems like a missed business opportunity (and said so in my suggested feedback 
) Think of the hundreds of thousands of mom-and-pop shops who are being forced by the likes of AT&T to go to VoIP. (Aside to our dear Canadians @ VoIP.ms: you can thank them for many of us dropping their services like a molten rock and switching over to you all. No, I won’t say what AT&T is now charging for an old-style copper line because I don’t want the readers to p00p rubber Twinkies.)
Most all of these small businesses would love to have a CRM properly integrated with their VoIP services. Without an API here, we who could easily code such gigs cannot do so. There are at least three free and open-sourced CRM packages that have telephony extensions. Although these are Linux-based, they can be run seamlessly within Windows 11 easily using Hyper-V, VMWare, etc. Yes, Outlook can be extended too - but coding Gods help you if you have to use it.
We need a real API - please.
A direct API would be nice indeed. But this is possible for you to do it right now, indirectly, if you want (or rather, need it now).
Using an Asterisk based PBX
I implemented this in a business where I worked many years ago, and they were customers of voip.ms.
- Put up your own Asterisk-based PBX (either a physical machine, or hosted as VM).
- Enable the Asterisk Manager Interface (AMI).
- Use a simple socket connection to send commands to initiate calls from the desired phone extension to the desired destination.
- The user’s phone rings.
- Pick up the call, then the phone call to the destination is made.
- Pros: works with any device, portable to different environments, the moment there is a PBX with an activated AMI.
- Cons: This is not trivial, required work to implement, and testing. Once it works, it’s great, but a big learning curve and time dedicated to implement it.
Nevertheless, you can do it right now with the right resources. You need a couple fields in your app, like user’s phone extension, user name, secret. Then your app can log in to the AMI interface, and send the required Action (like Originate to make a call).
Bonus, once logged in the AMI, you can ask to be sent the events of the PBX so you can parse them and get data on incoming calls for the current user. So your app can display on the screen the linked incoming call details on the screen if the phone number is available and in the database. But this is much work!
Using your current device’s web/REST interface (if available)
Another solution (which I never implemented because this is too specific to each device) is to use the web/REST interface of the device/phone to initiate such calls. Some Yealink, Polycom, Grandstream, and Snom models support a simple HTTP command like http(s)://[login@]phone-ip/api/dial?number=1231231234.
- Pros: simpler project execution, product documentation, maybe available for the devices you are using right now. Easy to make a test.
- Cons: This required special coding for each device (or brands).
But yes, an API would be quite nice. 
I would probably thinker with it myself at home and build some fun stuff.
Kind regards!
I have a specific need for an API spec for an application that is used. They require an openapi spec to be available for integration.
@cpp-llc, if the API spec is on your side to provide, you probably can do it. (I do not know the constraints or parameters of the project, so I am making an assumption here.)
- Implement the PBX on your side.
- Implement a simple REST web service on your side.
- Of course, it will respect the OpenAPI specification.
- Implement the “call” feature you need with the required parameters.
- The web service will then make the “link” between this REST interface of yours, and the PBX that will make the call.
- You will be able to call your own REST API and it will call the PBX to do the rest of the job. It will be a simple URL.
- This is a clean implementation, and gives only one responsibility to your own REST API.
Again, I have no idea of who needs what in your project, and what you require, but this is doable. OpenAPI is just a specification.
You may use an already docker stack ready to be used and make your REST interface in the language you feel the most comfortable with (or use some AI assisted coding for that part—you can review the code generated, etc.).
This is an important undertaking (depending of your comfort and experience), but maybe it is worth it. Only you can decide if this is financaly worth it.
The solution I developed many years ago was integrated inside a CRM module in an ERP software. All our customers that had an Asterisk PBX could use it out of the box. The AMI interface is good everywhere. It was worth it. It took a couple weeks (probably around 2010), with poor documentation, no AI tools, nothing as we have today. So it is doable! Not as easy as if an API was already available though.
Kind regards!
Hi Aleclerc - yes indeed. I’m reasonably familiar with Asterick.
However, a PBX is overkill for many of us. Our office has three voice lines and one FAX line, running on a Polycom, an SPA112, and SPA122 respectively with Zoiper all over the place for backup. (BTW Getting the FAX configs correct and working was a surprising PITA, but only because there are so many parameters, most of which few mere mortals understand. Like: StandOnLeftFootAndWhistleDMTFs= TRUE :P)
So, splicing in a PBX gives a nice, config double whammy.
I compiled Asterick on Windows 11 in a Hyper-V VM running the Zorin distro (built on Ubuntu which in turn is Debian). The machine is a refurbed i7 — so it took maybe all of 15 minutes to compile including DL’ing all the required libs. Hmmm … the current production release of Asterick wants the *-dev versions … oops, that’s an old coder no no.
Turns out getting a remote, headless version of Linux to work in Winderz is not so simple. I ended up using NoMachine because all the other RDP’s just didn’t work or ended up being an Xorg/VNC mess. (I had to nuke Zorin’s Gnome desktop at least four times to get the beast to work headless. They don’t recommend XCFE because of Zorin’s lack of long-term support for it but XCFE is obviously the best choice for a lightweight, headless machine.) I picked Zorin because it can be made to look very much like Windoze so my users would be comfortable with it if they need to drill into it with a full desktop.
Because of all the VM headaches, I’m probably just going to take a refurbed cheapo machine, put Ubuntu server on it. Then run Asterick and EspoCRM. The latter as we want to get away from Micro$oft’s OutLook. (Or as I say "Look Out! :O)
EspoCRM is free and open source but has a rather expensive telephony extension - so I’m going to roll my own from their API docs. (It too is REST - like most all API’s have become.) We need just a basic CRM tied to the phones - as mentioned here or in another thread, the workflow is: an inbound fires up Espo contact via Caller ID. Or user looks up a contact and hits “Call” … Right, it’s about as basic as it gets. Currently, to my knowledge, achieving this set up for free is possible only when you use Asterick as the middleman.
Clearly, having to insert Asterick into the mix adds enough complexity to give one pause. A direct API from VoIP.ms would (literally) get around that whole messy stack. (Aside to Canada: hey! Get with it! - Many of your competitors have had a telephony API for a while … so watch your back … which, I guess would be the Arctic Circle? :P)
ciao - Howard
Hello @Howard,
I totally agree that having a PBX for 3–4 people (small business) looks overkill. Twenty years ago, there were only 3–4 people in a business I worked for, and we installed it because at that time it saved the business literally thousands of dollars compared to traditional phone systems (for customer support and 800 numbers, etc). So this was worth all the trouble. We had a used PC, installed Asterisk (or Elastics, I can’t remember, a pbx distro all ready), and bought a PCIe card with FXS FXO ports, plug the lines and fax, and voilà. We then used the AMI interface not long after, etc. The time and money we saved was worth it all. (Marketing cold calls could be made from our CRM in one click, etc.)
Nowadays it is possible to run such systems in VMs. I even think that a small Rasberry Pi device could run a PBX or a small used thin client device. If it is only for trunking plus 3–4 phones, this is enough. (To be verified. If 20-year-old used normal Dell PCs could run it, I mean… anything today could run it! 
)
I agree with you and from experience that the simplest solution is having a dedicated box or VM (on a linux box, proxmox, etc.) to run it, and to use a ready-made distro. I would not use Windows as base OS (from experience) because of updates and whatever. I use windows, but for servers and services, I try to stay as far as I can.
Then if someone needs an OpenAPI interface, I would use docker to have a stack to get a REST interface speaking with AMI. But otherwise, any app can talk to AMI with a simple socket connection and sending text commands. There still needs to “interface” AMI to read and write properly to the socket, but it works.
In the end, if voip.ms was providing a simple API to initiate a call, this would be the easiest solution. And it is not that hard (at least from a “local” point of view, I do not know about their global architecture). It might be more of a business decision than anything else.
But in the meanwhile, one must evaluate the gains and costs and see if it is worth it for each use case. If one already saves a lot of money with SIP systems, it could be seen as “reinvesting the saving into more ease and more features.”
This is not an easy project, but this is doable. I had like no practical experience with voip technology when we installed the PBX. I had to learn everything with the internet of 20 years ago. But it was done. One step at the time. One mistake at the time. One feature at the time.
I am sure it would be faster and probably easier today.
Kind regards!
Exactly.
Those APIs are mainly for building a custom dashboard or end user interface.
I just asked support and still no api for websocket.
Now they have their own voice ai (AI Voice Agent Beta – Automate Calls with VoIP.ms), super expensive, $0.25/min, they absolutely won’t get any customer. Unsure who made the decision to charge 0.25/min, really shall do some reality check first.