sipsorcery's blog

Occassional posts about VoIP, SIP, WebRTC and Bitcoin. response times SIP Sorcery Last 3 Hours
daily weekly status

Simple Wizard Enhancements including Highrise Integration

A new version of the Simple Wizard is now available. The SIPSorcery Silverlight portal with the new changes is version (the version is displayed in the top left hand corner when the portal is first loaded).

The changes are:

  • Rules can now be disabled,
  • Incoming rules can now be applied for Any call, for calls to a specific SIP account, for calls from a specific SIP provider or by a regular expression match on the called SIP URI,
  • A new Highrise Lookup command is available for incoming calls. This command allows a caller to be looked up in a 37signals¬†Highrise instance (Highrise is a contact management application).

Rule Disabling

The disabling of rules is self-explanatory. Disabling a rule will prevent it from being used when processing a call. Re-enabling the rule will cause it to be used again.

Incoming Rule Matching

The incoming rule matching is now more powerful and flexible. The Any option will match all incoming calls (although caller ID and time matching are subsequently applied and could result in the rule not matching a call). The ToSIPAccount option requires a specific SIP account to be selected and will cause the rule to only match incoming calls to that SIP account. The Regex option allows a regular expression¬†to be applied to the incoming call’s SIP URI (Uniform Resource Identifier, the equivalent of an email address for SIP).

The final option is ToSIPProvider and can be used to match calls that have been received from a specific SIP provider. The way this option works is that the incoming SIP URI must be in a specific format of “provider” for example “” where blueface is the provider name and aaron is the username of the SIPSorcery account. In order for the SIP URI on received calls to be in the required format it will need to be set on the Register Contact for the provider. An additional update will be coming soon which will set that format as the default on new SIP provider entries but in the meantime it will need to be set manually.

Highrise Lookups

The HighriseLookup command is a new one that will be useful to people who already manage their contacts in a Highrise instance. By setting a Highrise URL and authentication token in the Simple Wizard command parameters the SIPSorcery application server will lookup the contact in the Highrise instance and if found it will set the display name on the SIP From header of subsequent forwarded calls. The command is primarily designed to be used with a new version of the Switchboard that’s coming soon but it may also be useful for anyone with an IP Phone or softphone that has enough screen space to show the display name on incoming calls.

Getting Started with the Simple Wizard

The Simple Wizard is the new way to create SIP Sorcery dial plans. It’s designed for people with fairly straight forward call handling requirements with one or two steps per call.

This post is an overview of how to get started with the Simple Wizard and includes a guide for the some common steps that are likely to be undertaken with it.

Step 1: Create a new Simple Wizard dial plan

The dial plan option is only available in the Silverlight portal. Once logged in select the dial plans menu option and then the Add button. A dialogue box will appear with the different dial plan options available. Select Simple Wizard, choose a name and then click Add.

Create a new Simple Wizard dial plan

Once the dial plan is created the Simple Wizard screen will appear and you are ready for step 2.

New Simple Wizard dial plan ready for rule creation

Step 2: Create speed dials for outgoing calls

A common requirement for outgoing call rules is to create some speed dials for frequently called destinations. The Simple Wizard allows any format desired for speed dials but a common way to create them is to use a * prefix, for example *100, *101 etc. For this example we will create 4 speed dials for calling family member’s mobile numbers.

  • *100 for Mum
  • *101 for Dad
  • *102 for Older Brother
  • *103 for Younger Sister

The screenshot below illustrates the creation of the first speed dial. The crucial point is to leave the Destination Match type as Exact. An exact match is as the name suggests one that matches the called number exactly without applying any substitutions, wild cards etc.

Create a new speed dial

Once all the speed dials have been entered they will be displayed in the outgoing rules grid and are immediately ready for use (remember to update the Outgoing Dial Plan on the SIP account you want to use with the dial plan).

Outgoing rules grid with speed dials

Step 3: Create outgoing call rules for international routing

Once your speed dials are set up the next thing is to create some rules for processing calls to the traditional telephone network or PSTN. For PSTN calls it’s common to use different providers for calls to different international destinations. For this example we will set up rules for 3 international prefixes.

  • Irish calls with a prefix of 011353 use provider blueface,
  • Australian calls with a prefix of 01161 use provider faktortel,
  • US calls with a prefix of 0 or a prefix that doesn’t start with 0 use provider callcentric.

The difference between setting up the international calling rules and the speed dial rules is that the Destination Match type used is now Prefix. Again as the name suggest a prefix match is only concerned about the start of the dialled number. Prefix matches can also use pattern substitution to represent commonly required number patterns.

  • X will match 0 to 9,
  • Z will match 1 to 9,
  • N will match 2 to 9.

New rule for international calls to Ireland

Once all the international rules are entered they to will appear in the outgoing rules grid and are available for immediate use.

International rules grid view

Step 4: More sophisticated outgoing call rules

The exact and prefix match rules and the default Dial command used in the above examples are just the start when it comes to creating outgoing call rules. More powerful matches can be created using the Regex destination match type, it allows full regular expressions to be utilised.

The DialAdvanced command also allows multiple stage forwards and different options to be set on the forward(s) used to process the outgoing call. The DialAdvanced command can use the same powerful dial string options that are used in the Ruby dial plans.

Step 5: Incoming rules

After the outgoing rules are successfully configured the next step is to take a look at the incoming rules. It’s not actually necessary to use a dial plan for incoming call processing with SIP Sorcery. By default all incoming calls will be forwarded to all registered bindings on the main SIP account. However if different behaviour is required such as forwarding an incoming call on one provider to a different provider or to multiple SIP devices then an incoming dial plan is required.

For this example we’ll set up two incoming dial plan rules.

  • Incoming calls from provider1 should be forwarded to mobile number 0447623322 at someprovider,
  • Incoming calls from provider3 should be forwarded to SIP accounts mine1 and mine2.

Currently an extra step is required to be able to distinguish calls by provider.

  1. Create a new incoming only SIP account for each provider that needs to be distinguished in the dial plan,
  2. For each SIP account created in step 1 set the Incoming Dial Plan to the Simple Wizard dial plan being created,
  3. On the provider’s Register Contact field use the SIP account set up for it in step 1.

Once the providers are correctly configured then to distinguish them in a Simple Wizard dial plan is as simple as selecting the corresponding SIP account in the drop down menu.

Incoming rule for calls to provider1

Once the rules have been created they will be displayed in the incoming rules grid and are available for immediate use.

Incoming rules grid

Step 6: Forward unanswered incoming calls to voicemail

The final step is to forward any unanswered incoming calls to voicemail. To achieve this it is as easy as creating a new incoming call rule that applies to Any SIP account rather than to a specific one as the rules in the last step did.

Since the SIP Sorcery service does not provide a voicemail service anyone wanting to use one will need to create an account with a 3rd party SIP provider. The instructions on how to set up a free voicemail account with Callcentric can be found in a SIP Sorcery Recipe.

Once you have a voicemail account set up the incoming call rule will be something like the one below.

Incoming voicemail rule

As with outgoing rules there are many more things that can be done with incoming call rules such as setting a time window that they should apply and filtering based on the caller ID.

Simple Wizard version 2

In July I made my first attempt at providing a simple wizard like interface for call processing. The effort was based on the fact that a lot of sipsorcery users find writing Ruby script based dial plans daunting not to mention time consuming. By providing a simple wizard interface the hope was that the portion of users that don’t need sophisticated dial plans would be able to started without having to churn out a line of code.

There wasn’t a big uptake of the simple wizard dial plans so I went back to the drawing board and today I’m announcing the release of the second version of the simple wizard. Conceptually it’s still the same in that you need to write incoming and outgoing rules but the difference is I’ve expanded the data entry section for the rules to make it easier to understand what each field does. In the first version the aim was to condense the data entry for the rules into a single line but I think that just served to confuse matters.

I plan on posting some more howto guides for the simple wizard and this post is really just a taster. There is a help page available that describes what each of the data entry fields are. Below are a couple of screenshots for outgoing and incoming rules respectively. If you’d like to give the simple wizard a spin it’s only available in the Silverlight portal; create a new dial plan and select Simple as the type.

Outgoing rule screen for Simple Wizard

Incoming rule screen for Simple Wizard

As always any feedback about how the Simple Wizard could be improved or whether it’s closer to the mark etc. are appreciated.

New time zone dial plan functions

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.

New dial plan wizard to ease Voxalot users moving to SIPSorcery

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.

Redirect Processing

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()}.")

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")
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")
  sys.Log("In call")

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.

Get Call Detail Records (CDR) script

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 = ""
myUsername = "yourusername"
myPassword = "yourpassword"

client =
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 SSL certificate without having to resort to using ssl_config.set_trust_ca option I’d be very interested to know.

Outage Report 15 Aug 1700 PST

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.

Final Reminder to Beta Users

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!

Jingle Adventures contd…

There was an announcement a while ago on the 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!