December 2010

You are currently browsing the monthly archive for December 2010.

A couple of months ago I got inspired to muck around a bit with Google’s Analytics service thinking it would be a good way to collect some interesting statistics on the sipsorcery service. So I wired up a handy little .Net library called GaDotNet into the sipsorcery application servers and started collecting the host portion of each SIP URI. In this day and age of highly sensitive privacy concerns I realise that may worry some sipsorcery users but I have made sure the tiny bit of information collected is anonymous and if an IP address that didn’t belong to a SIP Provider showed up in any graph I would not publish it.

The Google Analytics graph illustrating the 10 most popular call destinations for sipsorcery for the last month is shown below.

It’s not particularly exciting but it’s interesting for anyone who may want to track their own statistics or events from their sipsorcery dialplan. If there is any interest I can add a new method to the sipsorcery dialplan. It does take a little bit to work out how Google Analytics works for event tracking so for anyone considering it be aware there is a little bit of research to do.

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

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", "[cd=5]")

That dialplan rings my “myaccount” sipsorcery SIP account and when I answer dials 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:$[message]$

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.

I’ve been half heartedly seeing if any softphone makers are interested in supporting the pseudo ICE mechanism that GTalk uses when setting up the media on an XMPP call. It doesn’t look promising at this stage. Google did make a change around the start of this month to their XMPP call set up mechanism, which broke the ability for Asterisk 1.8 to place outgoing calls through GTalk, so maybe they are working on the service and will have full Jingle support soon which in theory would allow ICE compatible phones such as Counterpath’s softphone range and others to be able to place SIP calls through sipsorcery and have them terminated via GTalk/Google Voice’s XMPP/Jingle service. That would be neat as it would be a validation of SIP and XMPP signalling working together and interconnecting two technologies which both support a large number of users.

However Jingle for GTalk isn’t here yet and in the interests of encouraging any developers that are involved with writing softphones to look at supporting the Google STUN requests on the RTP sockets I’ve created a prototype application that shows how to do it. The application is written in C# and hosted on codeplex here. What the application does is listen on a socket for a SIP INVITE request and when it gets one translates it to an XMPP request which it sends off to GTalk. As well as handling the SIP and XMPP signalling the prototype application also fires up two media sockets, one that talks to the Google XMPP end and one that talks to the SIP phone end. The media sockets are needed so that the STUN requests and responses required by the Google XMPP end can be handled correctly and that’s the bit that’s missing from the softphones.

A no frills rudimentary HTML/AJAX site is now available at:

It has all the functionality of the Silverlight client except for the console messages.

A new feature available on the HTML site is a forgotten password page to allow people to reset their password. I’ll get around to adding that to the Silverlight client at some stage as well. A direct link to the forgotten password page is:

The new site is hot off the press so there may be bugs. If you encounter any please let me know by posting in the forums at: