sipsorcery's blog
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
With the SQL Azure migration complete and the second sipsorcery application server similarly bedded down now is a good time to provide the configuration options for SIP clients to avail of the new redundancy measures.
The quick steps to take to configure your SIP client are:
1. Do nothing.
In the majority of cases there will be nothing at all needed on the client side to allow it to failover between the two sipsorcery SIP servers. The sipsorcery SRV records are now configured for both sipsorcery.com and sip.sipsorcery.com (using either is exactly the same, I typically use just sipsorcery.com because it’s less typing).
For the failover mechanism to work a SIP client MUST support SRV records (RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers to be official about it). It’s also necessary that one of the two hostnames mentioned above, I’ll repeat them because they are critically important sipsorcery.com or sip.sipsorcery.com, are used and NOT an IP address or the hostname of one of the individual SIP servers.
There are still a few minor issues I am working on sorting out such as matching up GoogleVoice callbacks, which can now arrive at either of the two SIP servers, and fixing the event logging for the Silverlight console so that it gets the events from both server rather than just a single one. Apart from those issues the new sipsorcery deployment is working very well and given that it took 5 or so months of development work to make the changes to allow a multi-server deployment not to mention the work on Amazon’s SimpleDB that ended up not being used I am so far pretty happy with the way things are running.
The single point of failure in the sipsorcery system is now the Microsoft SQL Azure database platform. SQL Azure has a monthly SLA of SLA of 99.9% which would translate to 43.2 minutes of downtime in a 30 day month. That’s actually a pretty low level of reliability for a telecoms type service where five nines (26 seconds per month) is typically the bare minimum and six nines (2.6 seconds per month) is desired but hopefully the SQL Azure service will exceed expectations. Incidentally there has been an outage already in January, on the 17th between 0503 UTC and 0519 UTC the sipsorcery applications were able to read but not write to the SQL Azure database so that’s 16 minutes of the 44.6 minutes (January has 31 days so the SLA allows an extra 1.4 minutes of downtime) used up.
