Sorry, I do not know what to tell you. The webhook provided in the module works for me with voip.ms. You can change the query string separator from ; to & if you want; the script will accept either. Take a look at @rwize post at New open source SMS Connector module - #117 by rwize also.
We have been running the SMS Connector for weeks not and our Beta group has had no issue. For us we did the following:
update Freepbx modules and system updates
add the SMS connector (perform the setup steps important Advanced setttings specifically) and update all modules
In VOIP.ms setup the API and copy the password
Back in FreePBX, under SMS Connector setup the Provider Voip.ms using the the user email and API secret. Copy Webhook that is generated and save some where.
Setup number - under SMS Connector ==} add number
If usingSangoma Talk - Goto User Management and enable Phone Apps and Sangoma Talk. Under Sangoma Talk ==} Sangoma Talk Mobile App ==} Enable SMS + defautl DID
VOIP.ms Portal ==} Goto Manage DID ==} Enable SMS and copy Webhook you saved in step 4.
(edited - added 7a step)
(edit-2: After further testing - determeined white listing voip.ms servers is not required - testing ongoing (mar/10.24)
7a. Add Voip.ms server IP’s that are assocaited to all / any DID’s setup on PBX. Goto Firewall ==} Networks.
Thats it. if it is not working, try and reboot PBX.
If you are not using the Sangoma softphone you can test using UCP.
As of writing this comment, we are fully functional with SMS/MMS through UCP, Sangoma client and VOIP.ms portal.
Remove all other SMS setup stuff you may have configured prior to following the SMS Connector setup, including any reference in the trunk for Message Context.
Good Luck - we are running 5 extensions and no issues.
I have identified that the issue lies with the firewall. Upon restarting the machine, I observed that I started receiving SMS messages before the firewall was fully operational. The attached screenshot displays the firewall config for voip.ms what further steps are necessary to ensure that the service operates correctly while the firewall is active?
I reviewed our configuration and yes, I missed a step in the list I provided, which was to add the IP associated to the Voip.ms servers that are assocaited to Registered DID’s to the firewall exclusion list. Thus I would recommened in addition to my list is to add all voip.ms servers associated to the DID’s on your system to the Network section.
I have whitelisted all Voip.ms POP Server that I connect to, yet incoming SMS are not being received. The only workaround is to disable the firewall. Do you have any suggestions?
I highly doubt the API that allows account manager, ordering and other features (like SMS/MMS) is being run on every individual POP server that Voip.ms has. That would be over a 100 servers for this to run on. If they are like every other provider out there (it’s a stretch), their API would be separate from the actual voice servers since it does more that just voice.
The API is coming from https://voip.ms/api/v1/rest.php, it is also where you send your requests to and where callbacks will be sent from. Have you tried actually whitelisting the two IPs that voip.ms resolves to?
Why does it work when you disable the firewall, even after putting all the Voip.ms POP servers in the firewall? Because it’s not coming from one of those IPs. It is clearly coming from an IP(s) that are not whitelisted.
You can try to whitelist 172.64.147.66 and 104.18.40.190, which are the two IPs listed for VoIP.ms. You can also disable the firewall, send a message to one of your DIDs so it triggers an inbound message to be sent to the PBX. Watch the log files for Apache and you’ll see where the request comes from. You will see something like (just guessing at the POST string):
[SOURCE IP] - - [10/Mar/2024:09:57:58 -0400] “POST /sms.php?to=DID&from=source&message={mesage} HTTP/1.1” 200 556 “https://voip.ms/api/v1” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 Edg/122.0.0.0”
As for what @rwize suggested, that is for if you are using SIP MESSAGE method of the SMS. That is when they send it down over SIP but you’re not using SIP you’re using the RESTful API which is completely different.
Thanks for your suggestion, @BlazeStudios. Looking at the Apache Log, I found the IP that I need to whitelist: 72.251.239.208. Thanks again for your help.
Hi GrilloVillegas, We have performed some more testing of this beta service, SMS+VOIP.ms+FreePBX, we are working on and have determined that SMS/MMS with VoIP.ms and the SMS Connector module are working with the Firewall enabled and no Firewall Excemptions for Voip.ms. Therefore I would deduce the Firewall is not your issue. I unfortunely do not have any suggestions other then to remove any previous setup for SMS. Perhaps Simon is able to offer some direction. Cheers
note in our VOIP.ms API setup we have added the Public IP of the PBX into the whitelist.
Thanks @rwize, all your help was invaluable. I finally managed to get VOIP.MS working by allowing that particular IP on my firewall; that was the only thing that made it work.
I see it has an option to send email notifications if the extension is offline. It’s not clear to me if it sends the actual message or just a notification that a message was received.
I am using your Freepbx Telnyx SMS module, which I believe was the inspiration for this module, and it sends the actual message to email, which is what I want. Not just a notification.
Yes, this is a new feature I have been working on, client-side SIP device support with fallback to email. (because I don’t want to implement a queuing system, which would be messy anyway considering PJSIP’s multiple AOR contacts capability)
If you set up a user in SMS Connector then go and edit that user in User Manager, the SMS Connector tab will have options for enabling SIP SMS, which means that SMS will be delivered to PJSIP devices using SIP MESSAGE, if possible. If no devices are registered to that extension then it will send email to the user’s email address (configured in User Manager, not the voicemail-to-email target for an extension).
The email option here sends the SMS body, not only a notification.