August 2011

You are currently browsing the monthly archive for August 2011.

I had a query today about programmatic access to SIPSorcery CDRs. In fact access has been available for a couple of years via the provisioning service. I have posted some previous samples about accessing the provisioning web service but not a specific one using Ruby and SIPSorcery CDRs so here it is.

require 'httpclient'

puts "sipsorcery get CDRs sample"

provisioningURL = "https://www.sipsorcery.com/provisioning.svc/rest/"
myUsername = "yourusername"
myPassword = "yourpassword"

client = HTTPClient.new
client.ssl_config.set_trust_ca('ca.pem')
resp = client.get_content("#{provisioningURL}customer/login?username=#{myUsername}&password=#{myPassword}")
authID = resp.delete('"')
puts "authID=#{authID}"

resp = client.get_content("#{provisioningURL}getcdrscount", nil, "authID" => authID)
puts "get CDRs count response=#{resp}"

resp = client.get_content("#{provisioningURL}getcdrs?offset=0&count=3", nil, "authID" => authID)
puts "get CDRs response=#{resp}"

client.get_content("#{provisioningURL}customer/logout", nil, "authID" => authID)

puts "finished"

For the sample to work you will need to download the certificate authority for the SSL certificate used on the SIPSorcery site and copy it into the same directory you run the Ruby script from. The certificate authority file is needed because openssl, which Ruby uses, doesn’t recognise the signing authority as valid even though in my case I had the whole certificate authority chain installed in my trusted certificates store. If anyone knows a way to get openssl to recognise the www.sipsorcery.com SSL certificate without having to resort to using ssl_config.set_trust_ca option I’d be very interested to know.

The SIPSorcery server experienced a 90 minute outage on the 15th of August at approximately 1700 PST. The first purpose of his blog post is to apologise to all people affected by the outage. The second is to provide a summation of the technical information that has been gathered about the cause of the outage.

The server event logs corresponding to the outage had numerous log messages as below.

Event ID: 333
An I/O operation initiated by the Registry failed unrecoverably. The Registry could not read in, or write out, or flush, one of the files that contain the system’s image of the Registry.

From lengthy research it appears the error message can be caused by a variety of error conditions on a Windows server but the predominant one is typically related to an exhaustion of resources on the underlying operating system. The resource could be pooled memory, handles, registry size limits and others. So far the only way found to recover from the issue is to reboot the server which is what happened with this outage.

One question is why would this issue crop up now when the SIPSorcery server has been running in the same configuration for over a year. The answer to that may lie in the fact that the server hardware was recently upgraded and at the same time the MySQL database version was updated from 5.1 to latest 5.5 version. It could be that a different hardware configuration, the new MySQL software, a combination of them or something else entirely has caused the issue to crop up.

The SIPSorcery server is closely monitored on a daily basis for performance characteristics such as CPU utilisation, memory utilisation, threads, SIP traffic, disk IO and more. However in this case no pre-emptive signs were recognised. At this point the prime suspect is the MySQL service and more detailed monitoring has now been put in place in order to track the resource usage of the MySQL process.

The short term goal is to identify the cause of the issue, whether it be related to MySQL or otherwise, and fix it. The medium term goal is to look into adding hardware redundancy to the SIPSorcery service. There will always be issues with server hardware, operating systems etc. and a single server system will always be vulnerable. Up until this point with the SIPSorcery service operating largely as a free offering it was not viable to add additional hardware to the platform. Now that the service is generating some revenue from Premium accounts there is scope to look at enhancing the platform. I will keep the blog updated with developments as they arise.

I apologise again to any users affected by today’s outage and a similar but shorter one on the 8th of August and would like to assure users that reliability is the top priority of the SIPSorcery service and is the focus of the majority of my efforts. There are also real-time status updates regarding the availability of the SIPSorcery service on this blog site at Status Graphs. A red line on the monitoring graphs indicates a simulated call request to a SIPSorcery application server timed out after 15s or did not get an appropriate response. There are now 3 remote monitoring servers sending probes to the SIPSorcery server and the fourth graph is for a monitoring service that runs on the server itself in order to distinguish between network and service problems. And in the event that an outage does occur I always endeavour to issue updates as frequently as possible on the SIPSorcery twitter account.

One last friendly reminder for SIP Sorcery Beta users that the switch to a Free account service level will be happening within the next 24 hours. For anyone that hasn’t already done so an wants to avoid any disruption to the operation of their account please upgrade to a Premium service.

For anyone unsure the main limitations on a Free account compared to a Beta account are:

  • Only a single dial plan will be usable. Any additional dial plans will become read only and will not be able to be assigned to a SIP account and calls attempting to use a read only dial plan will be rejected,
  • Only a single SIP provider will be usable. Any additional SIP providers will become read only and attempts to use them in a call will fail. The single allowed SIP provider will be able to register but read only providers will not be able to,

The logic that will be applied to determine which dial plans and SIP providers get marked as read only will be:

  • If a record exists with the name “default” it will be used as the single allowed one and all other records will be set as read only,
  • If no record exists with the name “default” than the first record in alphabetical order will be used as the single allowed one and all other records will be set as read only.

It will be possible to view and copy information from the read only records as well as delete them but it won’t be possible to update them.

Thank you to all those who have purchased a Premium service to date!