Just checking in to see if anyone has come up with a good solution to deliver inbound (acknowledgement) SMS messages from Twilio. Our Corporate Security team won’t allow any inbound ports to be open.
I’m considering some pub/sub or MQTT cloud stuff where Twilio would deliver acknowledgements to a cloud and then have Ignition poll it but haven’t really thought through the details yet and wanted to see if anyone came up with something clever.
I think I remember Kevin saying something about the possibility of them hosting an EC2 instance or something.
Yeah, we'd have to build and host a cloud service to have a really first-class solution for inbound with Twilio that doesn't make security compromises, and I doubt we have the time or resources to even think about that kind of thing until Ignition 8 is released.
It's unfortunate that Twilio itself does not allow polling.
You could build that service yourself, but you'd also have to build your own notification module that communicated with that service to go along with it.
Nah, you won’t need to build a module. Here is what I would do.
Spin up a cloud server. Pick any host you want. Install a vpn server, like openvpn or softether. VPN the site server to the cloud server,
Set up a cloud server running nginx or similar, and set up the filter in the server conf file to listen for the twilio servlet. Forward all requests from there to the vpn’d server, using the reverse proxy directives.
Should only take you half a day, if that. Good luck!
Just a thought… How about piping the incoming SMS into Twilio into a Chat channel (https://www.twilio.com/docs/api/chat) then poling the chat channel from the Ignition gateway? I should be easy to have some TwiML or Script to pipe the incoming SMS to chat using Twilio. You could somewhat use the Chat as a poor mans broker…
Thanks guys. Those are some good ideas. Kyle’s method seems possible. I think I’m going to wireshark a demo with bidirectional Twilio communication (not on the corporate network) and see how it works and then look at tunneling over an SSL VPN for inbound traffic. Hopefully the corporate next-gen Fortinet Firewalls can’t distinguish between regular https and a VPN over https.
I guess we could always run a Gateway in the cloud with a distributed setup but I’m trying to avoid that if possible.
My method is possible. We use this in production now.
Another option would be to use 2 servers, we have used node-red. The local node-red server sets up a web socket to the remote node-red server. When the remote node-red server receives the http request from twilio, it fires it down the web socket, and the local node-red server dispatches a new http request to Ignition. Not as basic as a http proxy, but it serves a purpose when you can’t vpn out.
Create web socket nodes between the local Node Red and Fred
Shoot the payload to an HTTP out node to the Ignition gateway
Potentially reply with TwiML to Twilio that the message was accepted (maybe the Gateway does this?)
Do you guys think this would work?
I wonder what type of “checking” is done on the gateway to make sure a response request from Twilio is legit. My guess is that there’s not much going on…maybe it checks to see if the source phone number is the same as the one configured in the Roster for an active Alarm? Hoping it doesn’t do much with Source IP checks or anything because they’ll probably get overridden when local Node Red passes it along.
The top set of nodes deals with messages coming in from twilio, trying to get to the server. It is an HTTP node, and the top just pipes the request through a web socket to the local node instance. The other nodes deal with storing the incoming message to a list, as we will need it after we get a response from the server. We are keying it with the sid of the message.
The bottom set of nodes deals with the response coming from the ignition server, going back to Twilio. We convert the payload to json, inject the payload from the web socket as the originating requests payload, and use an http response node to respond to the originating request.
Ok, this is the local flow. We are accepting a message through the web socket, converting the original payload to json, while, in parallel, sending the original message from twilio to the local server, then packaging the response into a msg to then rejoin with the original message, and firing back down the web socket, which then responds to the original request.
Its all like black magic, and it works. We are probably going to modify our Twilio module to allow us to use web sockets, just have not had time. This is all my proof of concept work.
