September Stability and What’s in the Works

September was a good month with regards the stability of the sipsorcery service and a drastic improvement on August. There have been no incidents of the application servers (they are the ones that process calls) stalling with the dreaded “Long running dialplan” message. That’s not to say that the service is five 9’s reliable there were still two incidents where administrative intervention was required to disable some user accounts that were doing very unsociable things, effectively causing a denial of service, but it’s getting there.

It’s been 2 and a half weeks since the last significant change was made to the sipsorcery service and I’ve been spending the time since then working away on two new improvements for reliability and security.

SimpleDB

The first improvement in the pipeline is to switch from using a MySQL relational database for storing all the sipsorcery data to use Amazon’s SimpleDB. The big advantage of SimpleDB is that it already takes care of the hard database things like scalability, fault tolerance, load balancing, and replication. MySQL does have a Cluster solution that would be suitable for the sipsorcery service but one it’s a lot of effort to set up and two and more significantly a redundant deployment scenario involves a minimum of 6 servers which is prohibitive for a free service like sipsorcery.

There are a some trade offs between an RDBMS like MySQL and Amazon’s SimpleDB for instance the querying capabilities of SimpleDB are much less sophisticated and in fact are limited to string comparisons and restricted to case sensitive ones at that. Also the SimpleDB only exposes services over a REST or SOAP endpoint which involves the overheads of HTTP and SSL whereas an RDBMS can use a direct TCP connection with much lower overheads. The sipsorcery service does rely heavily on its database and there are multiple queries performed for each call that gets processed. If the processing time of the queries is high then the result will be big call set up delays. So far it doesn’t look like that should be an issue the response times of SimpleDB queries have been low. I will be doing further testing but ultimately if things work out the plan is to migrate from MySQL to the SimpleDB.

SSH

The other improvement is to move from using a telnet connection for the monitoring console to an ssh one. That means the sipsorcery server will have to incorporate an ssh server and the Silverlight GUI and ssh client. Thankfully there’s an open source C# ssh server library called NSsh that is a good starting point. I’ve been doing some work with NSsh and have managed to get it working with putty and the cygwin ssh clients and am now attempting to build a client from the same library to incoporate into Silverlight.

These two improvements are plumbing and won’t offer any new features but what they will do is make the service more reliable and secure. After they are done the hope is to get back to the interesting stuff and to spend some time on SIP transfers and the switchboard GUI.

Aaron

  1. patrick’s avatar

    SSH would be great! I love having the terminal when I’m working on new dial plans, but I cringe every time I type my password in telnet 🙂
    Thanks, Aaron!

    Reply

  2. Thomas’s avatar

    If you move to SimpleDB then while all local installs also have to use the Amazon service? Is it not possible to leave MySQL in there and let the local admin choose which they want for their local server?

    Thank Aaron for a wonderful product.

    Reply

    1. sipsorcery’s avatar

      The RDBMS (MySQL etc.) storage option will remain. It was months of work to implement it so I’m not going to throw it away.

      Reply

Reply

Your email address will not be published. Required fields are marked *