During last weekend’s maintenance window (maintenance window because the upgrades are performed in the early hours of Sunday morning; no down time occurs) two new dial plan functions were introduced. The new functions are to do with applying a user’s time zone settings within their dial plan. The functions aren’t particularly sexy but they will make certain operations easier such as determining when calls should be sent to voicemail based on the time of day.

The two new functions are:

  • sys.GetTimezone()
  • sys.GetTimezoneOffsetMinutes()

For a full description and how the functions can be used please visit the dial plan help page.

There’s been a bit of buzz around the VoIP ecosystem lately with the news that Voxalot are closing down their service from the 31 Dec 2011. I’ve put together a guide for all Voxalot users considering SIPSorcery as a replacement service. I’d strongly encourage any existing Voxalot users to check the guide out and here at SIPSorcery we are hungry for your business.

One feature of SIPSorcery that some Voxalot and other users have mentioned as being a problem is the need to construct dial plans in Ruby script. To those of us that have a programming bent the ability to use Ruby scripts allows the creation of almost infinitely powerful and flexible dial plans but understandably for those without a programming bent that just want a few speed dials or custom rules it can all be a bit daunting. Voxalot provides a much more limited way to express dial plans but also a simpler way at least up until now.

I’ve been working for a while on new dial plan wizards for SIPSorcery and the latest one which I’ve baptised the “Simple Wizard” is my attempt to combine the power of the SIPSorcery Ruby dial plans with a much simpler wizard like interface. The new wizard is in the final stages of development and I hope to release it later this month but given that Voxalot users are currently weighing up their options I thought I’d give a preview. In the sections below I’ve included a screenshot of the Voxalot way of doing things and compared it to the SIPSorcery Simple Wizard way of doing things.

Add Speed Dial

List Speed Dials

Add Smart Dial Rule

List Smart Dial Rules

As well as being able to use the Simple Wizard to construct dial plans for outgoing calls it will also be possible to construct incoming dial plan rules. For incoming rules the pattern gets applied to the From header. The incoming rules can be applied to an individual SIPSorcery SIP account or all SIP accounts.

There is a lot more detail to come with the Simple Wizard but for Voxalot users considering their options I’m confident that it will make building SIPSorcery dial plans simpler and more flexible than the various Voxalot screens.

Recently I had a request from a user on how to get redirect processing working with their SIPSorcery dial plan. Redirects are when the destination of a call responds with a specific type of response, appropriately called a redirect response, that indicates that the called destination is unavailable and that the caller should instead try and call an alternative destination. The alternative destination is specified in one of the SIP headers on the redirect response. The most common scenario for redirects is the do not disturb (DND) or call forward buttons on IP phones. IP phones typically allow a user to press the DND button, enter a call forwarding destination and then have the phone redirect all that calls to that destination.

Redirect responses are potentially very dangerous if appropriate precautions are not taken. The reason being that the alternative destination specified in the response could be anything including a premium rate number in some far away country. For that reason redirects are disabled by default within SIPSorcery dial plans and it is only if they are explicitly enabled using a dial string option that they will be acted on.

After a redirect response is accepted the next question is how to process it? A well as blocking undesirable numbers the alternative destination could be a safe PSTN number and the caller will want to make a decision about which of their providers to use for the call. This presented a bit of a quandary for a while as a dial plan would potentially need to contain the same call processing logic in multiple locations, once in the main dial plan and then everywhere a redirect response was being accepted. The solution to that problem was to allow a new second instance of a dial plan to be executed for a redirect response. However while that approach provided for the most flexibility it was also a bit complicated so a simpler approach that did allow the redirect response to be processed within the same dial plan instance was also implemented. The two different approaches are outlined below.

Approach 1 – Inline redirect processing

This is the simplest of the two approaches and allows redirect responses to be processed inline within the currently executing dial plan. It also does not require a redirect option to be set in a dial string since specific dial plan logic is required to employ it. An example of this approach is shown below.

if sys.Dial("myaccount@sipsorcery").to_s == "Redirect" then
  sys.Log("Redirect was requested to #{sys.RedirectURI.ToString()}.")
  sys.Dial("#{sys.RedirectURI.User}@someprovider")
end 

In the example the key point is that the sys.Dial method will return a result of “Redirect” if one of the call legs within it receives a redirect response. At the same time the alternative destination will be set in sys.RedirectURI (which is a SIP URI object the same as req.URI).

Approach 2 – New dial plan instance redirect processing

The second approach causes a new instance of the current dial plan to be executed for the redirect destination. Some additional variables are set in the new dial plan execution which are sys.Redirect, sys.RedirectURI and sys.RedirectResponse. The sys.Redirect property is a boolean that gets set to true for a dial plan instance initiated by a redirect, sys.RedirectURI property holds the alternative destination set in the redirect response and sys.RedirectResponse holds the full response.

if sys.Out
 sys.Log("Out call")
 sys.Dial("someuser@local[rm=n]")
elsif sys.Redirect
 sys.Log("Redirect call")
 case sys.RedirectURI.User
  when /^300$/ then sys.Dial("#{sys.RedirectURI.User}@someprovider")
  else sys.Log("Sorry, redirect destination not permitted")
 end
else
  sys.Log("In call")
end

In the example above the dial plan has separate logic for In, Out and Redirect calls. The rm=n dial string option translates as redirect mode should be processed with a new dial plan.

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 http://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!

There was an announcement a while ago on the xmpp.org site about Google’s adoption of the official Jingle standard. The same announcement was posted by Peter Thatcher a Google engineer to the Jingle mailing list. The announcement got a bit of attention and I originally came across it on Hacker News. After spending a fair bit of time looking into what the upgrade means as far as integrating with Google’s XMPP service the conclusion I’ve come to is not much at least not yet.

The original reason I, a SIP person, started messing around with XMPP and Jingle was to see if there was a better way to integrate with Google Voice. I made a few blog posts at the time and ultimately the investigation didn’t end up yielding any fruit because of a peculiarity in the way the Google XMPP server deals with the RTP media streams which would preclude it working with standard SIP devices (very briefly it requires that STUN packets are exchanged on the RTP sockets before the RTP can flow).

So fast forward 8 months and I finally found some time to delve into the Google XMPP service again to see if there’s any chance of getting SIP interop, or more correctly RTP interop for SIP devices, working. The other thing that spurred me on a bit was Google + and specifically the integration of the Google Talk Gadget into the Google + application. The Google Talk Gadget is not new it’s been in Gmail for quite a while but the integration looks a lot more interesting with Google +, specifically being able to call from a SIP phone into a Google + Hangout (a web based voice/video conference call) would be cool.

As alluded to above the results of my latest little adventure into Google XMPP land haven’t been very fruitful. Yes Google now appear to be sort of using Jingle for their call set up but the media side of things doesn’t appear to have changed at all and in fact the original email from Peter Thatcher did state the work on XEP-0176: Jingle ICE-UDP Transport Method, which is more down to the nuts and bolts of the RTP side of things, is ongoing. In the meantime the XMPP call set up mechanisms used by Google are a combination of Jingle and Gingle (Google’s original implementation of a Jingle like protocol) and crucially the media layer is still Gingle.

My hope is that when Google get the Jingle ICE-UDP transport implemented they will also implement the XEP-0177: Jingle Raw UDP Transport Method which should allow RTP level interop with SIP devices which will in turn allow SIP Proxy services like SIP Sorcery to make and receive calls with Google’s XMPP network. Some SIP servers that proxy media such as Asterisk and FreeSWITCH are already integrating with Google’s XMPP network by implementing the Gingle/XEP-0176 STUN connectivity check mechanisms on the RTP sockets. In SIP Sorcery’s case and also for other non-media proxying servers such as Kamailio the integration is not possible because it then needs the end SIP devices to do the STUN connectivity checks and until ICE support becomes widespread they wont be able to.

Unfortunately this is another example of the really painful issues caused by NAT. If NAT had never been invented and the World had been forced to upgrade to IPv6 the internet would be a much better place :). In the meantime communications protocols like SIP and XMPP end up with as many addendums and extensions to deal with NAT as they do to deal with their core functions!

I’ve had a couple of requests from people who made a previous donation to the SIP Sorcery project regarding whether the donation would count towards a payment for a Premium account. The answer is that yes it can. I’m happy to apply a pro-rata basis for all donations towards a Premium account. In fact all types of previous payments including donations and the eBay auctions are treated the same. If you would like to take advantage of this offer please send an email to admin@sipsorcery.com with your sipsorcery username and if your PayPal payment came from a different email address please include it or a copy of the payment receipt.

I’ve just added a new dial plan option to the SIP Sorcery Silverlight client. The dial plan option is another non-script wizard type and in this case the idea has been to make it as simple as absolutely possible, hence the name.

The Simple Wizard dial plan allows a set of rules to be specified to be applied to outgoing calls, incoming call rules will follow in the future. The creation of the rules should be straight forward for anyone familiar with SIP Sorcery dial strings. In the simplest case a dial string can just be the name of a provider. There is some help information for the Simple Wizard at Simple Wizard Help.

Simple Dial Plan Wizard Screenshot

Someone suggested this week that an IRC channel may be useful for some more technically minded people looking for help on their dialplans or anything else to do with SIP Sorcery. I’ve always been a fan of IRC so I’ve gone ahead and created a channel on freenode.net, the channel name is #sipsorcery. I’ll hang around in their when I’m working on the SIP Sorcery code which is normally 0900 to 1300 UTC (early in the morning US time, late in the evening Australian time). If anyone wants to pop in and ask a question I’ll be more than happy to help out.