Updates and New Features

You are currently browsing the archive for the Updates and New Features category.

I’ve just added a new dial plan option to the SIP Sorcery Silverlight client. The dial plan option is another non-script wizard type and in this case the idea has been to make it as simple as absolutely possible, hence the name.

The Simple Wizard dial plan allows a set of rules to be specified to be applied to outgoing calls, incoming call rules will follow in the future. The creation of the rules should be straight forward for anyone familiar with SIP Sorcery dial strings. In the simplest case a dial string can just be the name of a provider. There is some help information for the Simple Wizard at Simple Wizard Help.

Simple Dial Plan Wizard Screenshot

Someone suggested this week that an IRC channel may be useful for some more technically minded people looking for help on their dialplans or anything else to do with SIP Sorcery. I’ve always been a fan of IRC so I’ve gone ahead and created a channel on freenode.net, the channel name is #sipsorcery. I’ll hang around in their when I’m working on the SIP Sorcery code which is normally 0900 to 1300 UTC (early in the morning US time, late in the evening Australian time). If anyone wants to pop in and ask a question I’ll be more than happy to help out.

In recognition of the valuable feedback and in some cases assistance to other users that Beta users have provided I have created a special offer for anyone that wants to convert to a Premium account. For a $50 once off payment (no subscription required) Beta users can purchase 2 years of a SIP Sorcery Premium service. This compares to the normal price of $35/year and represents nearly 30% off.

The Premium service has unlimited SIP Providers, SIP Dial Plans and access to all Dial Plan functions. From the 1st of Aug 2011 Beta accounts will be treated the same as Free accounts and subject to a single SIP Provider, a single SIP Dial Plan and not able to access some Dial Plan functions.

Please note the offer will only last until the 31st July 2011. After that date any Premium account upgrades will be at the normal price.

The link to the offer is below. Note you’ll be prompted to login and the offer will only show up for Beta users:

Beta Users Special Offer

For anyone requiring additional SIP Provider or Dial Plans on their free SIP Sorcery account Premium accounts are now available for purchase.

For those on the Beta plans the service will remain unchanged until the 1st of August 2011. At that time Beta accounts will revert to Free accounts and only one SIP Provider and Dial Plan will be enabled on each account.

The sipsorcery.com will be migrated to a new server this Saturday at around 2300 PST (the exact time has not been scheduled yet). There will be some downtime as the database and IP address are migrated to the new server. If everything goes smoothly the downtime should only be 5 or 10 minutes. During the migration all calls, registrations and 3rd party SIP Provider registrations will fail. No end user action is required for this migration. The new server will end up with the same IP address ( as the old server so apart from a brief outage the impact should be minimal.

Many SIP Sorcery users have reason to be grateful to the resident Ruby expert Mike Telis and his Flexible table-controlled dial plan (version 2). This dial plan has saved many users from having to dive headlong into Ruby programming in order to set up a speed dial or set the rules for how they forward through their different providers. After seeing how popular the dial plan was becoming I thought it would be a good idea to incorporate it into the sipsorcery Silverlight portal (and eventually the AJAX portal). That would mean the users of Mike’s dial plan would not need to do any Ruby programming at all which I get the feeling a large number would appreciate.

The point of this post is to announce that the sipsorcery Silverlight portal now does include a new dial plan option that is based around a slightly modified version of Mike’s dial plan, the reason for the slight modification is to do with the practicalities of designing the GUI. The new dial plan option is called TelisWizard (the full name being a bit of a mouthful).

The dial plan has 6 sections which correspond to the same sections in Mike’s original plan:

  • Speed dials – numbers that can be set for commonly dialled destinations like family members,
  • Dial plan provider – entries for existing SIP or Google Voice provide entries that can be set for prefix dialling and configured for use in routes,
  • Routes – these are what determine how outbound calls get routed. A pattern is specified that attempts to match the dialled number and when one if found the route is used for the call,
  • ENUM – a way to map PSTN numbers to a SIP URI (kind of like a speed dial but for PSTN numbers),
  • CNAM – a way to map incoming numbers to common names (sort of the opposite to ENUM),
  • Options – a number of handy options for use in the dial plan.

The GUI has a help panel at the bottom of each screen to provide assistance.

The Ruby that’s actually running the dial plan is hosted in the sipsorcery repository on github.

I suspect there are still a few things to iron out with the GUI and the dial plan to make it simpler to use and I’d encourage anyone who is already using Mike’s existing dial plan to try it out and provide feedback on the forums.

And of course a massive thank you to Mike Telis for not only the huge number of hours he put into writing and testing the script but the seemingly endless support he provides to questions that people ask about it!

As part of the recently announced changes to the sipsorcery service I’ve decided to get the web site re-designed (actually that should just be designed since my initial effort doesn’t deserve to be called a design). I’ve commissioned a contest and got feedback from family and colleagues as I don’t trust my own judgement much when it comes to design type things. However so far the feedback has been confusing. A couple of colleagues swear one design is a real stand out but my wife thinks it’s rubbish and that a different one is the bee’s knees.

Instead of that approach I though I may as well ask people who are likely to visit the site on occasion rather than those making a choice based on aesthetics alone. So if anyone has got a spare minute I’d appreciate any feedback at http://99designs.com/web-design/vote-qf6uz1.

It’s been almost a year since I moved the SIP Sorcery service off Amazon’s EC2 and onto a dedicated server. During the intervening period the dedicated server was filling up at a rate of knots so I was forced to limit new accounts by auctioning invite codes on eBay. I’ve received the bill for the renewal of the dedicated server which coincides with the thinking I have been doing regarding the future direction of the service. There’s also been a number of different views expressed on the forums and it’s great that people actually find the service useful enough to care about what happens to it.

The decision I’ve come to is to move the SIP Sorcery service to a freemium model. That means there will be a level of service offered for free and a charge for a service which has more advanced features or greater resources. The details of exactly what will be in the free service will be announced when everything is ready but it’s likely to be along the lines of unlimited SIP accounts, a single SIP provider and a single dial plan. The paid for service will be unlimited everything and likely to be priced around $35/year. Those numbers aren’t cast in stone at this stage but I expect them to be close.

The main motivation to switch to a freemium model is that without it sipsorcery is likely to stagnate and then probably slowly die. The combination of donations and auctions would probably bring in enough to keep one or even two dedicated servers running but as more servers get added the administration overhead goes up and I find myself spending most of my time keeping things running rather than coming up with anything new. For example it’s taken me nearly 6 months to come up with a user interface for Mike Telis’ popular dial plan. The hope is that if demand for the service is great enough I’ll be able to devote one or two full days a week to development and keep the new features coming.

As for anyone who has previously donated or purchased an invite code that will be taken into account. On top of that thanks go to everyone who has used the service over the last nearly 4 years. For the first three years the mysipswitch and then sipsorcery services were very experimental and people had to invest a lot of time, effort and sometimes frustration to use them. Their efforts and feedback enabled the service to get better and I’m very grateful to them. In the past I did state that the basic service would always be free and my hope was that additional applications such as things like the switchboard would generate revenue to cover the service’s running costs. Unfortunately it’s become a bit of chicken and egg situation: I spend most of my free time maintaining the existing service and less and less on new applications. I’d rather it had worked out that the basic service could have stayed free but at the very least most people who have been using the service have had it free for up to 4 years.

I’ll make further announcements closer to the time and nobody will have their existing service affected without lots of notification. The freemium model will not be coming into effect for at least a month and most likely two or more.

The sipsorcery switchboard project was released with great fanfare 6 months ago now. Despite the fact that I wrote it I still think it’s a great product with a lot of potential. The biggest problem the early adopters have had is the extra effort required to configure their dial plans; sipsorcery dial plans are tough enough as they are without having to include yet another trick for a product that’s supposed to make life easier. Consequently shortly after its release I set about to remedy the situation by creating a new dial plan wizard to make creating dial plans a lot simpler and avoid the need for users to be Ruby experts. However I got sidetracked with various things such as digging into Google Voice’s XMPP support and the sipsorcery AJAX client.

I’m still yet to finish the dial plan wizard although in the last couple of weeks I’ve made some good progress. What I’ve also been working on in parallel is another aspect of the switchboard that I realised could be a lot better. In the current version the switchboard can match incoming calls against a list of contacts that are maintained in a sipsorcery maintained contacts list. That works fine but for the small business users the switchboard is aimed at they are already likely to already have their contacts maintained in a CRM system somewhere else. To make it more attractive to such users I’ve chosen SharePoint 2010 and Highrise from 37Signals to integrate the switchboard with. I have also done some proof of concept work with SugarCRM. Salesforce would be another obvious candidate but I’ve got to start somewhere.


Highrise Integration

The screenshots below demonstrate the integration with Highrise.


Contact in Highrise


Switchboard lookup on Highrise Contact


SharePoint 2010 Integration

With SharePoint the integration can be very tight since the switchboard is a Silverlight application and SharePoint 2010 can host Silverlight web parts out of the box. However the standard SharePoint contact management is nowhere near as good as a dedicated application like Highrise. That being said there are a multitude of companies that produce web parts to enhance SharePoint and there’s bound to be a few good contact management ones around.


Editing a SharePoint 2010 Contact


Switchboard lookup up on a SharePoint 2010 contact


Raison d’etre

In case you are still wondering the whole point of the switchboard is to be a virtual replacement for a small business PBX system. One of the painful things about starting work at a new company is working out the black magic that’s required to operate the phone system. The switchboard would remove that burden by being the application to handle all the normal PBX functions like transfers, call hold, line presence and of course CRM integration. With the switchboard a small biz could purchase any old SIP phones and not have to worry about maintaining their own SIP server or PBX system. It would also be better than a hosted VoIP or SIP offering as there are very few of those that offer any real-time call handling capability and invariably they want to get in the call path adding extra latency. The switchboard actually runs a SIP stack within the Silverlight application which means when the operator presses the menu buttons or extensions the call handling is all done via SIP signalling. This gains anywhere from one to five seconds over a mechanism that overlays HTTP or Web Services on top of SIP and means there’s no danger of a caller hanging on the other end of the line while a web server sorts itself out or does the data crunching to wrap up a SOAP request.

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", "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:


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.

« Older entries § Newer entries »