SIP Sorcery is very different. SIP Sorcery started out known as “My SIP Switch.” It’s an open source project created by Aaron Clauson, who describes it as a “SIP service aggregator.”
What does that mean, you ask? Well, consider the plight of the old skool analogue terminal adapter (ATA). For example, the pioneer in that area…the venerable Cisco ATA-186. Early devices of this kind supported registration with only one SIP service provider.
In contrast you might have accounts with SIPGate, Gizmo5, FWD and VoIPUser.org. SIP Sorcery provides a middle layer, allowing you to register your various service provider accounts with SIP Sorcery, then create a device login for your ATA. Finally, it requires that you establish some dial plan logic to define how calls are routed.
In the end your simple ATA with no internal dialplan smarts is given a new lease on life through SIP Sorcery aggregating all those service providers. Incoming calls from any of those accounts with ring to your ATA. You can use some dialing logic (dial 9 to use SIPGate, 8 to use Gizmo5, etc) to select which account you use each time you place an outbound call.
It’s magic….or in this case…sorcery.
SIP Sorcery is a free service. One the reasons that it can be free is that it acts only in the realm of SIP signaling. SIP Sorcery doesn’t do any media handling. This reduces its bandwidth and hardware requirements making it possible to run SIP Sorcery relatively inexpensively.
The simple fact that SIP Sorcery doesn’t handle media has certain implications. For example, nowhere will you find settings for voice mail, as it doesn’t provide such a service. Nor does it provide for IVR menus and the like. All of that would require handling the media, which it simply does not do…by design.
Setting aside the earlier example of the ATA, the very fact that SIP Sorcery doesn’t handle media works to out advantage with respect to HDVoice. SIP Sorcery is codec agnostic. It will route calls regardless of your preferred codec as long as the two end-points can reach an agreement on a codec that they both support.
So, any ATA registered with SIP Sorcery will be doomed to a narrowband existence forevermore, but if you should register a number of G.722 capable phones they will happily make and receive HDVoice calls between themselves all day long….for free. That ain’t bad. Not bad at all.
The story of the history of the service will make for an interesting VoIP Users Conference call when Aaron is our guest some time in the next month or two. Over the course of it’s evolution SIP Sorcery has run from a single server, then on dual virtual server instances on Amazon EC2. More recently it’s been running on Microsoft’s Azure cloud host, but is presently in the process of transitioning back to dedicated hosting hardware.
At the time of this writing SIP Sorcery is still running on Microsoft’s Azure cloud platform. In the effort to migrate to that platform Aaron wound up creating a new user portal implemented in another Microsoft technology…Silverlight.
Silverlight is Microsoft’s latest GUI development frame and is supposed to be in response to all of the AJAX stuff taking place online. Like many Microsoft technologies before it Silverlight is intended to deliver convenience to developers by relying upon a set of published libraries. To use the user portal you need to install the Silverlight run-time libraries. Of course, that’s not a problem on Windows systems.
My understanding is that Silverlight is supported on MacIntosh and the Mono group is working on a Linux port called Moonlight. But both of these efforts are a little behind the current Microsoft offering, which is Silverlight 4.0
There’s another possible speed bump along the path to using SIP Sorcery. It remains experimental so it will not be 100% reliable, or even 99.999% reliable. However, for a free service who can justifiably complain?
My own expectation is that SIP Sorcery would be less reliable that Google Voice, another free service. Whereas Google services, like GMail remain officially in “beta” state for an eternity, SIP Sorcery is not backed by an online advertising behemoth. Simply put, it seems like a wonderful platform for experimentation and learning about SIP, but not the way to route your 911 calls.
As of today I’ve done only a cursory bit of experimentation with SIP Sorcery. I have one of my OnSIP accounts registered as a service provider and one set of device credentials established, which I set-up in an instance of X-lite. This initial setup was pretty quick and painless.
Here are a few relevant screen shots of the GUI. In each case you can click on the image to see a full sized version in a separate window.
The SIP Accounts Menu
The SIP Providers Menu
The List of Dialplans
The Console Display
The Call Data Records Menu
Dialplan Script Types
One of the more interesting aspects of SIP Sorcery is that dialplan logic can be expressed in one of two ways; “extension” or as Ruby script. I’m not really certain what constitutes “extension” but the user forums are full of nice examples of Ruby script that seem pretty approachable. The SIP Sorcery blog also has some interesting reading for the technically inclined.
The following example is a Ruby script that establishes outbound dialing by SIP URI, which was the very first thing that I got working.
# ****************************************
# if a full sip dial, dial here and quit.
# skip to number dial if sipsorcery host
# ****************************************
if sys.GetCanonicalDomain(req.URI.Host.to_s) == "sipsorcery.com"
sys.Dial("local")if req.URI.User =~ /[a-zA-Z]/ # if dialled sipsorcery name not number
sys.Respond(480, "failed sip dial.") if req.URI.User =~ /[a-zA-Z]/ # A failed sip dial, quit dial plan
else
sys.Log("Sip Number in #{req.URI.User}@#{req.URI.Host}")
sys.Dial("#{req.URI.User}@" << "#{req.URI.Host}".downcase) # dial full sip address entered
sys.Respond(480, "failed sip dial.") # A failed sip dial, quit dial plan
end
# end of sip dial.
Using the above bit of logic I was able to use Eyebeam to call the ZipDX wideband demo at sip:wbdemo@conf.zipdx.com. The bridge reported that I was connected in wideband, confirming that SIP Sorcery doesn’t make any distinction about such things.
This is my first exposure to Ruby. It seems similar to things that I already know. While I’m definitely not a developer Ruby seems like something that I could learn given a real application. So I’m soon going to embark on a little project using SIP Sorcery to overcome some issues that have kept me from properly evaluating the Panasonic KX-TGP550 phone system that I’ve had on loan for several months.
It’s easy to see how someone could open a SIP Sorcery account and provision a number of phones for their extended family around the globe. Family could call each other for free, but share a common set of termination providers, getting the best rates possible in each country.
Of course, all the calls that were IP end-to-end could be in glorious HDVoice given suitable hardware or software.
That brings me to the end of this little outing. SIP Sorcery is the sixth service that I’ve profiled as a way to achieve wideband telephony right now. It’s a powerful, open source, SIP switching engine, freely available on an experimental basis. I look forward to speaking with it’s founder, Aaron Clauson, when he makes a guest appearance on a VoIP Users Conference call some time later this summer.
