The SIPSorcery blog has moved to

I’ve created a short guide on how SIP manages audio streams and the sorts of things that go wrong when those streams traverse NATs. The full guide can be read at SIP and Audio Guide.

To complement the guide I’ve whipped together a diagnostics tool.

SIPSorcery RTP Diagnostics Tool

In an attempt to help people diagnose RTP audio issues I have created a new tool that provides some simple diagnostic messages about receiving and transmitting RTP packets from a SIP device. The purpose of the tool is twofold:

  1. On a SIP call indicate the expected socket the RTP packets were expected from and the actual socket they came from,
  2. On a SIP call indicate whether it was possible to transmit RTP packets to the same socket the SIP caller was sending from.

To use the tool take the following steps:

  1. Open in a browser and click the Go button. Note that the web page uses web sockets which are only supported in the latest web browsers, I’ve tested it in Chrome 16, Firefox 9.0.1, Internet Explorer 9,
  2. A message will be displayed that contains a SIP address to call. Type that into your softphone or set up a SIPSorcery dialplan rule to call it,
  3. If the tool receives a call on the SIP address it will display information about how it received and sent RTP packets.

The tool is very rudimentary at this point but if it proves useful I will be likely to expend more effort to polish and enhance it. If you do have any feedback or feature requests please do send me an email at

SIP uses a cryptographic algorithm called MD5 for authentication however MD5 was invented in 1991 and since that time a number of flaws have been exposed in it. The US Computer Emergency Readiness Team (US-CERT) issued a vulnerability notice in 2008 that included the quote below.

Do not use the MD5 algorithm
Software developers, Certification Authorities, website owners, and users should avoid using the MD5 algorithm in any capacity. As previous research has demonstrated, it should be considered cryptographically broken and unsuitable for further use.

Does that mean SIP’s authentication mechanism is vulnerable? While not necessarily so, at least in relation to the MD5 flaws, the real answer is it depends on how much your password is worth to an attacker? For example if your SIP password only uses alphabetic characters and is 7 characters or less in length it can be brute forced for less than $1!

Read the full article here.

Due to popular request, mainly from Voxalot refugees, a new web callback feature is now available for SIPSorcery Premium and Professional users. The feature is available on the AJAX portal. Unlike the original call manager approach (outline at the bottom of this page) which initiated a Ruby dial plan execution and did not require authentication the new mechanism DOES require authentication and sets up a call between two pre-configured dial strings rather than executing an existing dial plan.

The new mechanism is simpler to use but is not as powerful and flexible as the original approach. Hopefully the new mechanism is closer to what Voxalot refugees are used to and will allow any saved Voxalot callbacks to be used.

There is help available but the mechanism should be fairly intuitive to use.  The way it works is that you enter in two dial strings (dial strings are the same format as those that can be used in sys.Dial in Ruby dial plans and can include multiple call legs and other options) and a description. After that it’s just a matter of clicking on “place call” and the SIPSorcery server will attempt to call the first leg and if it gets an answer will then call the second leg and finally bridge the calls together with a SIP re-INVITE.


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.

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.

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.