It’s always been possible to initiate a sipsorcery call with an HTTP request of the form:

https://www.sipsorcery.com/callmanager.svc/webcallback?user=username&number=1234

The sipsorcery server processes the call by sending it to the special webcallback dialplan. That means that there’s no chance of users inadvertently having web callbacks initiated on their account and also allows such calls to be restricted to safe destinations.

My own web callback dialplan is currently:

sys.Log("webcallback dialplan starting...callback number=#{req.URI.user}")
sys.Callback("myaccount@local", "music@iptel.org[cd=5]")

That dialplan rings my “myaccount” sipsorcery SIP account and when I answer dials music@iptel.org and bridges the two calls. If I don’t answer the second leg doesn’t get dialled. The [cd=5] sets the duration of the call to 5 seconds. I’m currently only using web callbacks for testing but if I ever need to initiate a call I can replace the call leg destinations with real numbers and my SIP providers.

Denis Chukhryaev from Anveo recently suggested adding the ability to initiate a sipsorcery call via the recent SMS receive functionality added to the Anveo platform. Anveo provide 3 actions that can be taken when an SMS is received and since an HTTP POST request is one of those options initiating a sipsorcery call is extremely simple. The trick is to get the SMS message text into the HTTP POST request and Denis was good enough to make the following variables available for processing a received SMS.

  • $[from]$ – contains the phone number from which SMS message was received.
  • $[to]$ – contains Anveo Phone Number which received SMS message.
  • $[message]$ – contains the actual text of the message.

By texting the destination number for the callback it can be placed into the HTTP POST request with the $[message]$ variable.

The full URL for the HTTP POST request is:

https://www.sipsorcery.com/callmanager.svc/webcallback?user=yourusername&number=$%5Bmessage%5D$

That’s it couldn’t be much easier!

For anyone considering following this example you need to be aware there is no security mechanism to authenticate the web callback requests made to sipsorcery. Ideally you should restrict the destinations your webcallback dialplan is allowed to call and preferably always make the first call leg one of your own phones so that you will always be a participant in any callback initiated on your account.

Advertisements