New open source SMS Connector module

Version 16.0.15.2 has some code improvements that make the module compatible with PHP 8.2 and FreePBX 17.

I am also experiencing this error. Do you know if there’s been any progress on getting texting fixed within the app?

Clearly sent me some beta code which fixed the issue - believe it’s in QC and should be released widely shortly

1 Like

Thanks. I’ll also touch base with them about this. I’m awaiting two items before deploying a new FreePBX server for a company I’m working with. There’s this issue with ClearlyAnywhere, and also this issue Unsure which address to use for AMPWEBADDRESS · Issue #40 · simontelephonics/smsconnector · GitHub

Using latest (v16.0.15.2) version.

I don’t use Sangoma softphones and can’t seem to receive messages to MicroSIP, LinPhone, or Zoiper 5 free edition using Telnyx. It’s received by the PBX and shows up in UCP, it just never gets to the softphone. Sending SMS from those softphones works fine. It’s just receiving that is not working. I also tried downgrading the module to the previous 4 releases.

This is the error message from the asterisk console.

ERROR[28445]: res_pjsip_messaging.c:1257 msg_send: PJSIP MESSAGE - Could not find endpoint 'sip:[email protected]:20001' and no default outbound endpoint configured

Where x.x.x.x is the public IP of my softphone. This exact configuration works using your freepbx-telnyx-sms script. The only thing I changed was switching from that script to the smsconnector module. I am pretty sure I have all that configured correctly because everything else works in both directions, including SMS to email when the extension is offline.

The PJSIP extension is definitely registered and reachable and is working for voice calls.

 Endpoint:  999/999                                              Not in use    0 of inf
    OutAuth:  999-auth/999
     InAuth:  999-auth/999
        Aor:  999                                                1
      Contact:  999/sip:[email protected]:20001            dbe13d98e9 Avail        52.531

Firewall and fail2ban are disabled on the server and no other iptables rules. MicroSIP app is fully allowed through Windows Defender firewall. Telnyx API log says delivery successful.

This is what’s in the freepbx.log.

[freepbx.INFO]: Error sending message to PJSIP/999/sip:[email protected]:20001: Message failed to send 
 [] []
[freepbx.INFO]: Webhook (telnyx): Return Code 202 [] []

Good, definitely not an issue with the Telnyx side.

Please reinstall the most current :slight_smile:

Did you remove the custom dialplan and PHP script from the former freepbx-telnyx-sms solution? It shouldn’t interfere with anything, but I recommend it.

therefore,

it’s not going to be a firewall problem. If you can receive calls you can get SMS - same path.

The SIP client parts are fairly new and thus the code is more “beta” quality but I have it working inbound/outbound on Zoiper, Groundwire, Sangoma S705 and Fanvil phones. When you say “LinePhone” I don’t know whether that’s a typo for Linphone but I didn’t see it working successfully for outbound on that client because it couldn’t be configured to send plain text content types. Anyway, I’ll pick this up with you on the ticket you opened on Github.

Your patch appears to have resolved it.

https://github.com/simontelephonics/smsconnector/commit/1b2e32e08cb333907ba9b69ae22dc9b9cae53b14.patch

Updated module will be released later this afternoon.

Release v16.0.15.3

Today’s release of v16.0.16 has two new providers, SignalWire and Sinch.

My setup is also FreePBX + VoIP.ms + Sangoma Talk and I had all my configuration in-place and for a while couldn’t figure out why my Sangoma Talk app had no SMS/MMS functionality… Then, @billsimon showed me your steps @rwize and the UserMan > Sangoma Talk > Enable SMS button being No was my issue the for that!! So huge thanks for identifying that. I reset the mobile app and re-registered with a new provisioning link and the SMS tab was immediately present again.

Now after all these steps, and many hours of checking over my configuration over and over and over again, I still wasn’t able to get FreePBX to receive a single text from my DID. As it turns out, that same IP that @GrilloVillegas found (72.251.239.208) was ALSO my issue for that!! As soon as I marked that IP as trusted my SMS started flowing through to FreePBX for the first time.

These last few posts in this thread begs the following questions though:

  1. What is that IP which @GrilloVillegas and I require for receiving SMS? A whois doesn’t show it’s owned by VoIP.ms, is it some kinda application proxy they forward their API connections through??

  2. Moreover, how’s it possible that @rwize supposedly doesn’t need any firewall exclusions set in order for his similar setup to work correctly?

  3. Is having multiple firewall IP exclusions set really such a security risk if they’re verifiably owned by a company which facilitates a critical resource for your PBX? Such as VoIP.ms server IPs to make SMS work. I mean, we’re talking multiple-multiple layers of security would have to fail for our own PBXs to be compromised as a result of a single excluded IP for a specific service, right? @tonyclewis

Hope it’s okay to shove the wall-of-text that is my experience today so far into this thread… Now I finally have everything I need out of FreePBX. After hours of toil it feels great to have everything wired up and working seamlessly, especially SMS! Big thanks to everyone here who contribute to this, and I hope that I can repay back the same level of contribution here some day!

1 Like

Since this seems to be a common problem people are running into, perhaps a feature could be added to the SMS module to add a rule to the firewall module.

Said providers should be providing what IPs this traffic can come from just like they provide their signalling and RTP IPs for customers to open in their firewalls. Why does the SMS module need to add rules to the firewall? You can do that just fine with existing methods when setting all this up.

1 Like

My issue here is that the whole IP address gets whitelisted. It’s not just whitelisted for the port needed for SMS but that IP has full access with no firewall now to your PBX on all ports. If that IP gets compromised it now has full access to hammer on your system with no firewall or fail2ban to stop it as its whitelisted.

I agree, and it’s unfortunate that some don’t. At least if a range of IPs can be determined, you have something narrower than “wide open.” Also to Tony’s point, you don’t need to whitelist the IP entirely, only allow it inbound to HTTPS. It doesn’t need to be able to reach sip, ssh, etc.

All the more reason to have the SMS module do that so that it’s done right.

If the provider isn’t giving you a list of IPs to allow for their SMS service how is this module going to automagically add these IPs to the firewall? Where does the list of IPs to allow come from?

HTTP(s) access is typically not firewalled in the first place.

If you are paranoid about unlimited HTTP(s) access it would probably be more appropriate to limit that in Apache rather than iptables imo.

You will get various opinions about this; however, I don’t fault anyone who is generally blocking HTTPS, because historically the web interface has been the most vulnerable part of FreePBX. (People worry a ton about protecting SIP but that’s not where the vulnerabilities have been.)

Distro does some things to differentiate web access, such as having unique ports for provisioning, admin, user control panel, and APIs. This is something that could be done for SMS Connector but not without integrating with System Admin or requiring people to do a bunch of Apache config, neither of which I think are good options.

Not sure what would be involved but perhaps you could have the SMS connector check for blocked access and then throw a warning?

It’s a new incoming request to the network. The PBX may or may not be behind an external firewall. It may or may not be using the built in firewall in the distro. If the firewall is drop-all (by default) and you do not have an IP allowed in the firewall, it will be drop/rejected.

Then even if checking security logs for the drop, how do you know said IP is good and should be allowed?