At times it seems like the mysipswitch/sipsorcery effort becomes overwhelming. Certainly the challenges are far above what I encounter in my 9-to-5 programmer’s job. I guess that’s part of the allure as well; all programmers like a challenge. The biggest of them at the moment are stability and load. The memory leak problem has been overcome but the “long running dialplan” is still around and a new problem with the Amazon EC2 instance deciding to drop offline cropped up twice last week. Another one has been with the incorporation of the DbLinq library to enable database agnosticism – the users of local versions particularly wanted this feature – has resulted in higher than acceptable loads particularly on database updates. I’ve got ideas on how to solve all these problems and hope to do so over the coming weeks. It’s tough at times to get motivated when the project becomes just an engineering effort week after week (and yo-yo comments on the forums site don’t help either even if they do have an inkling of merit).

To get a fresh injection of enthusiasm I’ve grabbed one of the applications that I’ve been wanting to re-implement for a long time. In this case it’s one that poked it’s head up right at the start of mysipswitch but then disappeared shortly afterwards due to the AJAX interface proving too unwieldy. The feature was the virtual switchboard that allowed calls to be managed in realtime through a browser, kind of like being able to make the dialplan up on the spot rather than having to program it in advance.

One of the big things with a Silverlight interface is that the difficulties encountered with providing a switchboard in AJAX can be overcome. Not only that but because it’s possible to run a SIP stack and IronRuby engine within Silverlight it’s possible to go way beyond what’s possible with AJAX and javascript.

For the last few days I took a break from engineering and commenced work on the sipsorcery switchboard. Most of the work has been to get the SIP stack working properly in Silverlight, it required a bit of massaging as Silverlight does not run the full .Net runtime. That’s done now and today I was able to use a Silverlight based swtichboard to receive a call from my Cisco 7960 and then click a button to forward it on to my Polycom IP500. On the surface that’s nothing spectacular and I could have dialled between the two phones directly but it is interesting if you consider that the call was manipulated by using SIP requests to and from a web browser.

switchboard

The above interface does a poor job of showing what’s going on but it’s better than nothing. The sequence of events was:

  • Log on the sipsorcery server through the Silverlight GUI,
  • Click the switchboard link which causes the Silverlight client to register with the sipsorcery server by sending a SIP REGISTER request over a TCP connection
  • Dial an extension from my Cisco phone which is connected to the same sipsorcery server and which gets forwarded to the Silverlight GUI,
  • The Silverlight GUI receives the call and extracts the From header and writes it to a text box so I can see who is calling. The other information presented such as the name, company and image could be pulled down from a CRM or web service based on the information in the From header,
  • Now that I know who the caller is I can click a button to direct them to the phone I want to take the call on and in this case I clicked the aaronpolycom button to get the call to my Polycom IP Phone,
  • The call arrives at my Polycom and when I answer it I have audio between the Cisco and it.
  • It’s a little bit to wrap your head around and that’s without even considering that instead of a button click just forwarding a call it could run a Ruby script locally within the Silverlight GUI. The first time I was able to run the SIP stack within the Silverlight GUI was a big moment and today was the first time I was able to do something useful with it. It does open the possibility for some very powerful applications.

    Advertisements