My SIP Switch

Unified Communications is another commonly (mis)used techno term. Like many technical concepts, the aspiration is far ahead of the reality with marketing departments running rampant through R & D departments in search of the next big thing. However there is a clear trajectory emerging which traces its path from simple telephony through email and messaging, mobile and presence, leading to VoIP and IP technologies.

The idea that all methods of communications could converge on a single device is beginning to crystallise, particularly with new phones like the iPhone providing email, text, instant messaging and of course voice. One missing ingredient has been a single portal to manage the availability of each method – a concept such as presence which enables a prospective caller to determine how best to make contact – email or voice, instant message or text. This is beginning to emerge with applications which log on to all your IM services along with your VoIP service provider and can show prospective callers which contact options are available.

Blueface was founded in Dublin in 2004 to provide Voice over Internet Protocol (VoIP) telephone services to the Irish & UK Markets. As this telephone service works over a broadband connection, the availability and quality of broadband is central to the success of VoIP. Although the provision of broadband continues to be a hot topic for debate, there has been a marked improvement in the past 2 years. (ADSL2+ and SDSL, Wireless, 3G) .The increased availability of un-contended broadband connections in particular has been a very welcome development for business customers who are considering adopting VoIP for their Business. There are a number of reasons to adopt VoIP including improving efficiency and reducing costs.

VoIP provides the ability to obtain international geographic numbers and route them to any other phone, anywhere in the world. Hence a Virtual office in the US or UK, or even China is both cheap and simple. Re-routing out of hours calls to mobile phones or enabling teleworking is greatly simplified and becomes almost trivial. Getting voicemail delivered by email or free call conferencing are just some of the immediate benefits of VoIP. Combine this with a good IP device, particularly a mobile device and suddenly Unified Communications becomes part of the present rather than the future.

For those ISP’s wishing to provide VoIP themselves, Blueface have developed a white label platform that enables a company to offer these services under their own corporate brand. Several Irish ISP’s are already providing a telephone service to their customers using the Blueface White Label Platform. The White Label concept enables ISP’s to move along the unified communications trajectory by adding VoIP services to their existing portfolio, and enabling their customers to start reaping the benefits of the latest communications tools.

The cost benefit analysis for a white label platform is often only evident after an ISP has tried the in-house development route. Many of the Blueface customers tried this route and realised after many months, and sometimes years, that it is far more difficult to provide VoIP than it at first appears. While setting up an open source platform for a hundred users is relatively simple, supporting tens of thousands of users and providing them with a reliable telephone service using a broadband connection is extremely difficult. Hence the white label route is both a quick and a cost effective means of getting to market. Adding VoIP to an existing broadband service is also one of the best means of increasing customer retention.

There is no doubt that within the next few years unified communications will cease to exist as an aspiration and most devices will support Instant Messaging, VoIP and Internet connectivity. Until then it is still possible to get the benefits in advance with a good VoIP and broadband provider, and if you’re reasonably tech savvy you can get going now with devices like the N-series Nokia phones, the iPhone and some of the latest Samsungs. You can get a free VoIP trial account at Blueface Free Trial along with instructions on how to configure many of these latest devices. If you haven’t got one, you can still try out VoIP with a softphone on your PC, or buy an ATA to convert an existing phone – free and a cheap options respectively to getting started in Unified Communications.

Feargal Brady Blueface Ltd

For quite a while now our new users were asking for a kind of wizard to generate Ruby dial plans. We have been working on this and we released a 1st version today : Rubyzard

It allows creating basic dial plans. The aim is to help less technical people and new comers to get started quicker and also not to get afraid of the dial plans (we agree that at 1st glance it can look nasty to people not used to programming).

Depending on the feedback we are getting from this and on the use that people are making of it, we’ll update it in the near future.

Future evolution of this application will allow to create more advanced dial plans which include : tables, ENUM, callback, speed dial …

Do not hesitate to share your impressions on this new tool

Zoiper is nice little softphone that works well on MAC OS (note that they also have Windows and Linux versions). It has been tested with My SIP Switch and is working more than fine.

You can download it for free on http://www.zoiper.com/

It’s quickand easy to set it up and if you don’t have firewall or connection issues you should be able to get started quickly.

Here is a step by step configuration guide.

1) This is the default interface, click on the spanner to open the “Options” window.

2) Select “SIP accounts” and then “Add new SIP account”. You’ll be prompted to enter a name. MySipSwitch in our example, but that can also be your name or something else.

You should see the interface below, to add your My SIP Switch account details.

The domain is : sip.mysipswitch.com (you can also specify the port : sip.mysipswitch.com:5060 but this should be optional)

Then mention your MySIPSwitch username and password.

The Caller ID is your Username, so write it again.

Once you are happy with the settings you specified, press OK at the bottom and you should be ready.

If the line one shows “green” (as below) that indicates a successful registrations. Now you need to take a look at your dial plan and get calling.

If you need help regarding the dial plan, you can refer to older post on this blog :

Default Ruby Dial Plan and  Inbound Call Management in Ruby

Do not hesitate to use our forum if needs be.

What makes a system “Carrier Class” (as in Telecoms Carrier)?? The answer is subjective of course but a few idle ideas popped into my head that I thought worth wasting a few lines for.

• 5 Nines Reliability, i.e. 99.999% uptime or 8.76 hours/year downtime (although hardware targetted at carriers usually quotes 6 Nines),
• 10^5 transactions/second on server infrastructure costing less than 10^5 dollars,
• 10^5 user capacity,
• 10 x 5 simultaneous calls per second,

Hi all,

Here are some screen shots of the configuration interface of a Grandstream Handytone 286 ATA that with indications on how to set it up with My SIP Switch service.
Note that it is very similar to Budget Phone 100 / 101 configuration screens.

Thanks a lot to Luc for the screen shots.

Note that the IP settings are specific here. This ATA is connected behind a Linksys WR54G router with NAT enabled ! You will want to change that depending on your network configuration.

The DHCP options means that the IP settings will be assigned dynamically by the router. It may be handier for less technical people.

The DNS values are specific to your broadband provider so mind these  values.

Note that the “local SIP Port” has been changed here for a specific reason. 5060 is in most cases fine. You need to make sure that the router which is in front of this ATA allows SIP traffic on this port.

The STUN server can be changed of course. There are a bunch of free ones you can use (see : http://www.voip-info.org/wiki-STUN)

Press Update and give it a go !

On the status page, you should see the SIP packets getting through and RTP ones if you are making calls.

You can also take a look at the configuration guide on Blueface’s site : HandyTone286 Configuration

Any questions , refer to our Technical Forum

The last few months have been a bit of a roller-coaster ride for mysipswitch. The ride started on Mar 25th when Ruby dial plans were introduced. Initially the new dial plan format did not gain a lot of traction but then a combination of people wanting to do more complicated things and the default dial plan for new users being set to Ruby saw their use increase considerably.

Around the start of June the roller-coaster, which had been on a nice gentle climb, encountered a little dip, just enough of a dip to cause some worry about what was around the next corner. This corresponded to a few incidents where mysipswitch had 3 outages over the space of three or four weeks. Up until this point outages had been virtually non-existent. 

The outages were tracked down to abnormally high memory usage on the mysipswitch process followed by it becoming unresponsive to registrations and calls. Restarting the process fixed the problem but then the memory usage would start creeping up and reach a dangerous level somewhere between 2 and 7 days later.

Now memory leaks are not uncommon in software and apart from buffer overflows are probably the second biggest software defect. However in the case of mysipswitch it is written in managed C# and runs within a runtime that takes care of memory management making it difficult, but not impossible, for memory leaks to manifest. Initially we thought that we must have introduced a leak within the SIP stack in one of the lists that tracks registrations or calls. However after a couple of weeks of poring over the code and purchasing some profiling tools nothing was discovered and the memory leaks were still occurring.

Our attention was then turned onto the IronRuby assemblies. Straight away we found that if a Ruby dial plan generated an exception then memory utilisation would shoot up by up to 2MB. Some re-jigging of the way the scripts were loaded and executed improved things a lot but there was still a slow leak which meant a restart of the mysipswitch process was needed about twice a week.

Restarting twice a week was not that problematic but it was not ideal either. As such it was decided to get started on another initiative which was to split out the mysipswitch agents into individual processes. That would have the advantage of verifying that the leak was definitely in the process hosting the Ruby scripts and also meaning only it would need to be restarted and the other agents would be able to keep running. The mysipswitch agents are:

• SIP Proxy/Application Server, this is the process that is the first point of call for all SIP traffic into and out of mysipswitch and handles dial plan processing and Ruby scripts,
• SIP Registrar, registers user agents and records their contact details for incoming calls,
• SIP Registration Agent, registers 3rd party SIP accounts with external SIP Providers,
• Monitor, the telnet shell that allows some rudimentary monitoring of the other mysipswitch agents to add in troubleshooting and diagnostics.

The splitting out of the agents was always going to involve a bit of pain because it involved significant changes to both the code and the mechanisms used. As one example the SIP Proxy could no longer ask the SIP Registrar for a list of bindings for a particular account and instead would have to retrieve them from the database. The splitting out of the agents took two weeks or so and actually probably caused less pain than anticipated.

After a week or so of running with the indiviudal agents the memory leak was able to be verified to be confined to the SIP Proxy process and deemed to be manageable enough there to keep things going as the IronRuby code base continued to evolve (it’s still only on alpha 3 so gremlins have to be expected) and eventually eliminated whatever was causing the memory leak.

So up to this point the rollercoaster had been fairly sedate or at least not bad enough for anyone to lose their lunch. However trouble was just around the corner. Since the agents were all operating smoothly and not having any integration problems it was decided to get back to the feature requests. The most in demand feature was the Callback application. Now the Callback application is a lot trickier than it seems and requires some serious SIP Kung Fu! In theory what the application does should be straight forward enough using transfers (SIP REFER requests) but in the real World most providers don’t support REFER and some clever hacks using things such as raw sockets for IP impersonation are required.

A new version of the Callback application was introduced around last weekend (2nd of August) and in hindisght that’s when things went Pear Shaped and the roller coaster started the stomach churning descent (excuse the metaphors, they make it easier to keep writing dubious quality material). The problem was after the update was introduced strange things started happening with the Registration Agent and the SIP Registrar. Initially there was no obvious link to the happenings and the SIP Proxy but on Friday, after 3 or 4 days of pulling our hair out, the incident was finall observed and the strange happenings occurred at the same time the Proxy utilisation spiked.

After identifying there was a link between the agents it took three more solid days of investigation to indentify and then fix the issue (or at this point it may be better to say “hopefully” fixed the issue).

So after all that we are now hopefully at a point where the rpevious stability of mysipswitch is just around the corner. Despite the last 3 months of intensive effort not a lot has happened in the way of new features which is frustrating on one level but since most of the effort (the last week excepted) has been as a consequence of introducing Ruby dail plans it’s undoubtedly been well worth it.

 Another benefit of the recent work is the that the mysipswitch architecture is a lot more flexible and means it will be possible to change the modulus operandi slightly. Up until now new versions of the software has been rapidly released to the live mysipswitch service in line with its purpose as an experimental tool. There is no desire to take a step back from that rapid release approach but since most of the new development work is confined to the dial plan and dial plan applications it will now be possible to isolate the areas subject to rapid development and even give users the choice of using the cutting “edge” version or the “stable” version.

 The diagram below illustrates where we are aiming to get to with the mysipswitch architecture. Previously all teh mysipswitch agents were encapsulated in a single process. Now they are separate and two new ones are being introduced. The first is the Stateless SIP Proxy which will take over the role of the Stateful Proxy of being the first point of contact for all external SIP traffic and acting like a traffic cop for all the other agents. The second is an “Edge” application server. This server will fulfil the same role as the current Stateful Proxy, or SIP Application Server as it could now be more correctly termed, but will be used as for cutting edge releases of new code. The new server will likely be given a name like edge.mysipswitch.com and users will be able to conenct directly to it for their calls or alternatively will be able to stay connected to the stable server and choose to forward only specific calls to the edge server from within their dial plan.

Hopefully that gives people some idea of where our efforts have been going of late and provide a bit of a roadmap about where we are heading to. It hopefully also explains why I have been more grumpier than normal! Even though mysipswitch is a free service we do still take pride in keeping it running smoothly and it gets suprisingly stressful when that’s not the case.

Regards,

Aaron

Default Ruby dial plan line by line.

When getting started, the default Ruby dial plan can be a bit hard to understand and many people don’t really know what to edit inside. This small article is aiming at explaining the basics so you can get started easier.

The first thing to mention is that with My SIP Switch there are 2 (very) different syntaxes for the dial plans. The “old one” is based on Asterisk syntax and using lines like that: “exten => …”. The new one is based on Ruby scripting and his much more powerful. You cannot use both syntaxes in the same dial plan! You need to pick one.

Here is the default Ruby dial plan (as of July 2008 and minus a few comments for clarity):

#Ruby

sys.Log(”call from #{req.Header.From.FromURI.ToString()} to #{req.URI.User}.”)

if sys.In then

# Do your incoming call processing customisations here.

sys.Dial(”#{sys.Username}@local”)

else

# Do your outgoing call processing customisations here.

case req.URI.User

when /^303$/ then sys.Dial(”303@sip.blueface.ie”)

when /^612$/ then sys.Dial(”612@fwd.pulver.com”)

when /^\*1/ then sys.Dial(”${dst:2}@provider1″)

when /^\*2/ then sys.Dial(”${dst:2}@provider2″)

when /^\*3/ then sys.Dial(”${dst:2}@provider3″)

else sys.Dial(”provider1″)

end

end

A Ruby dial plan must start with the line (Never remove that line):

#Ruby

The lines starting by # are comments. They are not interpreted as part of the dial plan. I removed most of them here.

The line:

sys.Log(”call from #{req.Header.From.FromURI.ToString()} to #{req.URI.User}.”)

will “log” all calls into the monitoring page. That allows to keep track of what’s going on and also to debug when you are testing the service.

The syntax is the following: sys.Log(” my log here “)

If you want to insert a variable into a log, you can use #{variable_name} for instance : #{req.URI.User}, as you’ve seen in the example above.

Then, starts the actual dial plan!

Inbound and outbound calls are clearly separated with the following structure:

if sys.In then

# INbound calls here

else

# OUTbound calls here

end

When you receive a call: sys.In will be equal to “True” and only the code between “then” and “else” will be interpreted.

The next line, starting with a #, is not interpreted. It’s a comment.

Incoming calls:

sys.Dial(”#{sys.Username}@local”)

That line, when interpreted, will call the phone which is registered to My SIP Switch.

sys.Username is a variable as is, it must not be changed! It will be equal to your actual username. Don’t do anything like that: sys.JohnSmith ; that would trigger an error.

If you want to receive your incoming calls on another phone, you can edit this line like that:

sys.Dial(”123456@myprovider”)

Where 123456 is the number you want to dial with the provider: myprovider (the provider’s name used here are the ones you set up when adding a new provider, in the 1^st field).

That’s it of the incoming calls on this guide.

If you need further help, you can refer to this article:

Inbound Call Management with Ruby Dial Plans

You can also refer to these threads on the forum:

http://www.mysipswitch.com/forum/viewtopic.php?t=139

http://www.mysipswitch.com/forum/viewtopic.php?t=399

Then for the outgoing calls, by default we have:

case req.URI.User

when /^303$/ then sys.Dial(”303@sip.blueface.ie”)

when /^612$/ then sys.Dial(”612@fwd.pulver.com”)

when /^\*1/ then sys.Dial(”${dst:2}@provider1″)

when /^\*2/ then sys.Dial(”${dst:2}@provider2″)

when /^\*3/ then sys.Dial(”${dst:2}@provider3″)

else sys.Dial(”provider1″)

end

case req.URI.User is another test based on “pattern” which include several possibilities: each when represent a different situation if the outgoing call can’t be match to any of those cases then my SIP switch will follow the else rules.

As pattern match tool, we are using Regular Expressions (everything between /^ and / is a regular expression).

when /^303$/ then sys.Dial(”303@sip.blueface.ie”) means that when you dial 303 on your SIP phone. You will hear Blueface speaking clock.

when /^612$/ then sys.Dial(”612@fwd.pulver.com”) means that when you dial 303 on your SIP phone. You will hear FWD speaking clock.

when /^\*1/ then sys.Dial(”${dst:2}@provider1″)

Any number starting by *1 will match this case. Note that the * is a special character so we need a \ before it. ${dst:2} is representing the number you dialed minus the 2 first digits (*1 here).

If you called your provider something different than “provider1″ you’ll need to modify this! It must be one of the names you set as provider. If you don’t do that, when calling, you’ll notice an error message in the monitoring page saying : “Cannot resolve provider1″.

when /^\*2/ then sys.Dial(”${dst:2}@provider2″)

when /^\*3/ then sys.Dial(”${dst:2}@provider3″)

Same thing with *2 and *3.

else sys.Dial(”provider1″) Forward outgoing calls to provider1.

If you dialed a number which doesn’t start by *1, *2 or *3 then this line will be used. That’s the provider by default. Note that there is not ${dst} involved, since here you don’t need to remove any digit but to dial the number as is.

If you wanted to match any UK number and dial them with a specific provider you can do something like that:

when /^0044.*/ then sys.Dial(”0${dst:4}@ukprovider”)

Any number starting by 0044 will match the case, and then we remove the 0044 and replace that by a 0 (to adjust to local dialing). Then the resulting number is called via the provider named: ukprovider.

Then we have the closing tags “end” of the IF and of the CASE. Make sure not to remove them!

Remember that, this is a basic guide so I mentioned only a few possibilities of the software. If you want to go further you can refer to our forum and blog; quite a few examples have been written there.

Guillaume

PS : Thanks Thomas for the draft you made about this article

Over the last 6 weeks there has been a bit of a slowdown in new features with the sipswitch this has been in due solely to the memory leak that we have been chasing down during that period. I’ve posted on the forums site about the problem 3 times in the News section. A number of times we thought the issue was fixed only to find the sipswitch memory usage creeping up again. This is a real problem as if it’s not caught the sipswitch will at the very least become slow and unresponsive and at worst will crash.

One issue was found in the IronRuby engine that was a definite problem and a workaround was put in place that made a big difference. The ironRuby developers were made aware of the problem and hopefully it will be fixed over time. However despite that we still supsect that even with the workaround in place there is still a slow leak occurring. As such we have been working to re-factor the software so that each of the individual agents can run in its own process. The four main agents are the SIP Proxy, the SIP Registrar, the Registration Agent and the Monitoring Console. Currently they all run in the same process which is a nice easy approach to manage but not so good for troubleshooting and scalability.

The idea is to be able to have the sipswitch software able to run as a single process, useful when run locally, or to be able to split out into multiple processes. The splitting out has required quite a bit of refactoring as when everything is in the same process information can be share easily, things such as the Proxy looking up the contact on the Registrar. If they are split out some extra work is required.

So that’s it another quick update for anyone wondering what has been going on in the background. Hopefully we’llg et all this ironed out and get back to adding features in the near future. At the end of the day if the leak has been caused by IronRuby, which I strongly suspect, then it’s still been worth it. I can’t imagine not having a Ruby dialplan now I’ve had a taste.
Regards, Aaron

Following my previous article about PhonerLite I wanted to write a quick review of his elder brother : Phoner

http://www.phoner.de/index_en.htm

It’s a Windows only softphone (95/98/ME/NT40/2000/XP)

The configuration is also made with a step by step Wizard (nearly the same one as PhonerLite), so it is really convenient and easy. I tested it with My SIP Switch and my impressions were the same as for PhonerLite : really fast to get started, easy to use and I cannot complain at all on the audio quality.

It is fully compatible with SIP and has all the main options/feature you would expect on a softphone. What makes it a bit special is that it has ISDN facilities (which is not that common on a softphone). Note that you need an ISDN adapter.

The complete list of features is available here : Phoner Features

I discovered today (Thanks to our user : deeknow) this nice, very easy to use and free softphone : PhonerLite.

Official site and download

The offical English web page is :

http://www.phonerlite.de/index_en.htm

PhonerLite is the lighter version of Phoner. It shares most of the code but with a (much) lighter interface in order to save resources. It was using 8Mo of RAM on my Windows XP while idle which is much lower than the idle XLite which was using up to 32Mo.

The donwload page is :

http://www.phonerlite.de/download_en.htm

If you download the ZIP file, you don’t need to do any installation (just don’t mess with the DLL); you can start using the phone by double clicking on PhonerLite.exe .

Screenshot and a quick review

It does all the necessary thing : easy control of settings and options (sound settings, codecs, security, network settings) … Regarding the phone features : call on hold (that’s the little hand near the green ‘pick up’ button), redial (the yin-yang like image below the hang up button), do not disturb, conference calls , call forwarding (I didn’t test these 2 features so far), logs, phone book …

Another thing I like about it is that it provides live statistics about the line such as Jitter and packet loss for instance. If you are having call quality issues, you can easily check if it is due to your network or broadband connection.

I have not tested it for long enough to judge it properly but the voice quality seemed nice; as nice as you can expect it to be on a softphone.

My SIP Switch Configuration

Now here are the steps to configure it with My SIP Switch:

Note that if you are behind a firewall, you may want to enter a STUN server (for instance : stun.xten.com).

Enter your My SIP Switch username and password. The authentication name is not necessary.

Select your audio devices.

Confirm and start My SIP Switching