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.
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.
The above interface does a poor job of showing what’s going on but it’s better than nothing. The sequence of events was:
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.