SwitchVox Review – Part I

9-12-05  Update: I’ve posted an introduction to this review – as I had some feedback that I didn’t introduce the concept of VOIP very well (at all).

Tom’s Hardware Guide recently reviewed the Asterisk @ home system.   AAH was the first system that I used to implement Asterisk, and enabled me to learn about this wonderful open-source PBX.  This review will cover a commercial implementation of Asterisk – SwitchVox – from Four Loop Technologies

Implementing Asterisk with AAH is reasonably easy for someone with moderate technical skills – and I have previously been able to set up a home phone system without too much trouble.  Over the course of a few months last Spring, I learned enough about the innards of Asterisk to understand the potential of the software, and developed a rough model for how it might be used to enhance  the functions of a medical office.

But I also recognized that the setup and management of Asterisk requires technical skills.  Sure – I can build a system for home and if it breaks – I’ll fix it later (though the teenagers wouldn’t be too happy .. )  But while I’m seeing patients, I can’t step into the back room and troubleshoot the system for 2 hours.  A medical practice needs to install something that can be set-up and managed by normal humans – not nerds.

So I started looking at commercial versions of Asterisk.  There are several alternatives:  Fonality is well-known, but from the documentation and a review of their software, it seems that they don’t have an API that would support some of the more interactive features that I want to implement.    I reviewed Scopserv briefly – but the setup and maintenance requires more technical skill than most of our office staff currently has.  In looking at SwitchVox, I was impressed that the look-and-feel is very clean and well designed,  my e-mails were answered very promptly, and that one of the founders of the company gave me access to their test server said so I could build a thorough understanding of the capabilities of the software before I purchased it..

Unfortunately, there aren’t a any reviews that I could find in the Internet of any of these packages, so I have decided to write this short review of the SwitchVox system so that others can build a better understanding of how it functions and what some of the strengths and weaknesses are.

Although SwitchVox is based on Asterisk, this is invisible to the user.  Set up is accomplished with a CD-ROM for installation on a server, although most SwitchVox systems are sold preinstalled on hardware provided by the company.  While resellers can purchase the software for installation on certified systems, (systems that the company has approved as capable of supporting the software) this is clearly not the company’s standard operating procedure, as resellers receive only a minimal discount off of the retail pricing.

Initial configuration of the system involves setting it up with the appropriate IP address settings as one would any new computer system.  A series of menus walks the user through this set up.  It’s quite easy to do and requires no significant technical skill.

After this initial set up, which needs to be done locally on the computer, all of the interaction with the SwitchVox system is through a web-based interface.

The main screen provides access to set up extensions, PBX features, hardware and network configurations as well as some rudimentary diagnostic screens.

Before using the system, extensions need to be set up.  The process is very straightforward and once again, most of these functions could be performed by a non-technical user.  

The extension management page is clean and well-designed.  As you can see in this figure, it lists all of the currently configured extensions and provides intuitive buttons that permit the user to modify or delete existing extensions.  By clicking "create a new extension" the user is brought to the extension configuration page.  As with most pages, a well-written and well-designed help functionality is present and can be accessed by clicking on "how do I use this page."

To create an extension, one chooses the kind of extension, and the extension template.  Options for extension types include SIP telephones, analog telephones (so long as the appropriate hardware is installed), call queues, IVR (interactive voice response) menus, virtual extensions, directories, call queue agent logins, as well as dial tone access.   Notably missing from this menu are IAX extensions and fax "in" boxes.

The extension management screen for a SIP telephone or SIP ATA, which is accessed either by clicking "create a new extension" on the previous screen or clicking "modify" on the main extension management screen, provides access to the extension number, name of the primary user, in the ability to enable or disable access to PBX functions such as call forwarding, voice mail, call parking and web access.  Outgoing call rule access can also be defined here, so (for example) some extensions can access local calling only while others may have the ability to make local and international calls.

Overall, the extension management functionality is well-designed and in demonstrations of the software to office staff and clinical users, everyone seemed to "get it" after clicking around on the screens for only a minute or two.

Most of the commercial systems provide similar ease of use, so I don’t think we’ve yet seen anything that is extraordinary or unique.

The power of the SwitchVox system lies in the PBX functionality.

Features in the PBX menu include music on hold, IVR editor, sound manager, time segment manager, and agent settings.

These menu choices don’t seem to be grouped in any logical fashion.  The process of setting up an IVR menu requires quite a bit of planning and in fact, the first thing that is necessary to set up a robust IVR menu is to set up the proper sounds that will be played as the caller moves through the menu.  For example, if the first menu is going to say "Thank you for calling, press 1 to make an appointment and press 2 to request refills for your medications and press 3 if you are calling to review lab or radiology results” then before you even go into the IVR menu, you will need to go to the sound manager and record this prompt.  Therefore, I would have put the sound manager as the first menu item since this is the first step in creating an IVR menu.  Similarly, the “time segments” functions, which permit you to define when the office opens, when lunchtime is, when the office is closed, etc. would be the second step in creating a robust IVR since you would want to create one IVR tree during business hours and another IVR tree for when the office is closed.

Ideally, I would like to see a method for creating sounds within the IVR editor since I frequently found that I would have to go back and forth between IVR editor and sound editor to create new sounds for functions and prompts that I hadn’t anticipated the need for.

Nonetheless, these functions are easy to reach and going back-and-forth between sound manager and IVR editor is quite straightforward. 

The IVR editor is the most powerful component of the system and enables one to build extremely complex IVR menus (and in fact IVR menus of IVR menus) with a very straightforward user interface that is quite well-designed.

The software retains some of the nomenclature of Asterisk.  This can be a bit confusing for new users and I’m not sure that it’s necessary.  For example, IVR’s are created within "contexts"  the context is given and name for example "main switchboard greeting."  

As you can see here, one can name the context and provide a description of what the context does.  When introducing the system to new users, this was confusing because the term “context” doesn’t mean anything to them, and most would prefer to use a more descriptive term such as menu or menu tree.

After creating the new context, one  is presented with the main context configuration screen:

Although this screen is a little bit confusing, one gets used to it fairly quickly.  On the left is an overview of the context and on the right are buttons that permit the user to go into editing mode to add, modify or delete actions from the contexts.  Let’s look at how to add an action:

With the addition of an action, you can cause the system to do nearly anything.  At first, this is hard for users with no experience building such a menu to understand.  When working with the staff in our practice, I ended up taking a deck of 3 x 5 cards and writing the titles of the actions on the cards.

For example there are several cards called "record sound" and "record digits" and "play sound ___” so to plan an IVR, all one needs to do is choose the appropriate cards from the deck, and assemble them into a sequence of events.

This makes it easy to then sit down in front of the computer and create events in sequence using SwitchVox after the planning had been done. 

As you can see, menus to guide the user through IVR creation quite well and they even permit branching from one IVR menu to another by using the "Go to context/Action" option.

A unique component of SwitchVox (and one that caused me to purchase the product) is the ability of SwitchVox to send parameters and return data from an external web site.  The mechanism for doing this is pretty straightforward.

Let’s look at the demo on-call IVR that I am creating for our practice.  You can see the overall IVR tree on the left which shows the general sequence of events that occur throughout the menu. The details are on the right, and can be edited by clicking the edit buttons.  The first event is the announcement about the time of day and gives the user a series of choices to make regarding what they would like to do.

By clicking on a button called "modify actions" a detailed action modification screen can be accessed.  The screen provides detailed information about each of the actions, allows the user to move actions to different parts of the sequence, and allows for modification or addition of actions.  The first option obviously plays the sound as I mentioned above.

The second action "send call values to URL" is what we’re looking at now.  Let’s look at the details of this action.

The first section provides a field to enter a URL.. this has to be the URL of a web site that will provide the information back to the user in a form that SwitchVox can consume.  The SwitchVox documentation does provide some guidance for  how to do this so it didn’t take me too much time to figure out how to use this.

The goal of this action is to retrieve from an external data source which physician is on call tonight so that the appropriate physician can be paged to notify them of this patient’s phone call.  We’re using oncalls.com, which happens to be an ASP for physician call schedules that I developed with David Ross several years ago.  It took me about 10 minutes to configure a custom page that would respond to URL variables (a username and password – optionally encrypted) and would respond with an XML page with the appropriate data for SwitchVox.  If you look closely at the URL, and will see that an ID (my medical group) and a username and password are the only parameters passed into the oncalls.com web site.

At this point, OnCalls looks to see which provider is on call tonight in our group.  It will only return this information if a userid and password are passed which identify this physician as a user in this group.

In the middle section of the page, SwitchVox provides an easy mechanism to pass additional parameters out of SwitchVox and into the receiving system.  Any information that the user has entered for even information that SwitchVox has acquired in recent interactions with the a URL can be passed here.  

The XML page that OnCalls returns to SwitchVox  looks like this:

<?xml version="1.0" ?>
<ivr_info>
<variable name="docname">Reider,</variable>
<variable name="pager">########</variable>
</ivr_info>

So there are two values –  “Reider”  and “######” (which of course is my pager number that I didn’t want to publish on the Internet so you won’t page me to the Domino’s pizza in Anchorage, Alaska)

At the bottom, you can see that these values will be passed back in the variable names "docname” and ” pager.“

So now if we return to the overview of IVR screen, you can see that step three "play sound" is annotated to play the name of the physician on call.   I had previously recorded a sound with the name of the physician on call, and so now at this point, I can just play that name and the system will speak the name the correct person is on call.

From here on, you can see that I enjoyed playing with some if/then causes and dialing of telephones.  It would be easy for example to have the system call the physician’s pager number, cell phone, home phone all at once, and if one of telephones is picked up, the call would be routed to that extension (even if the extension is forwarded to my cell phone!)

Obviously, there would be more IVR options than this in real-life.  We will likely need to make sure that patients who have messages for daytime office staff ("I can’t come to my appointment tomorrow afternoon") don’t leave such messages for the on-call physician at three o’clock in the morning.

A more extensive method for using the IVR menu is to provide interactive experiences for the user based on who they are.  We are in the beginning stages of creating a menu that will permit the patient to enter a unique ID number and automatically retrieve the results of recent laboratory tests or radiology tests that will be entirely built with the system.  By sending a captured (patient – entered) series of digits to the URL, the URL can return an identifier for a certain type of lab result.  This identifier (when sent back to SwitchVox) can cause the system to play the appropriate message that is related to this patient’s result.

For example, Bob Jones calls the system and his ID number is 12345.  Bob pressed "5" for "retrieve my lab results" and then SwitchVox sends "12345" to the lab result reporting system.  The system looks and finds that his cholesterol report is available, and the result is a bit high – so a return variable "highchol" is sent back to SwitchVox – which plays the previously recorded message about high cholesterol, and what we advise Bob to do about this.

Of course,  the a system like this can’t provide information for all results, but we expect that roughly 70% of results would be available in this way – which significantly reduce the number of phone calls and letters that we currently generate.

So, as you see, the system not only interacts with itself and permits people to make telephone calls to each other easily within on office and beyond the office, it provides many functions that will allow office staff and patients to easily obtain or convey information.

Clearly, there are many more functions that the IVR editor can do and I have been working with Fourloop, the developers of SwitchVox on software that will interact with a future version of their product (hopefully in September) that will enable me to loop through a list of patients who have appointments in the next day or two and cause SwitchVox to call these patients —  reminding them of their appointments.  The call they receive will provide them with options such as "press 1 to confirm that you made this appointment and that you will be able to attend the appointment at the specified time, press 2 to if you would like to reschedule right away and you will be connected to a receptionist immediately … Press 3 to leave a message for the administrative staff who will assist you in rescheduling your appointment during the next business day.”  (Or something like that)

The system set up section of the Web administration menu for SwitchVox provides options to create channel banks and channels for hardware that is enabled directly in or attached to the system.  There’s also a fairly easy-to-use management interface that allows for the addition, modification or removal of new inbound or outbound VOIP providers.  These screens work reasonably well unless there are any problems.  Unfortunately, every VOIP provider’s requirements for set up are a little bit different.  We were able to get Teliax to work flawlessly with their default settings, but Broadvoice, Sixtel and voip-jet (we’re testing several of these providers to see which we have the best luck with) have been problematic to some degree and we have been frustrated by the cryptic nature of many of the errors in error reporting system.  I keep thinking that if I had accessed to the real Asterisk error logs, I would be able to diagnose and adequately repair the VOIP settings.  Nonetheless, neither I nor my consultant were successful in getting incoming calls from these providers to work with SwitchVox – though I have been able to get them working with an AAH installation just fine.

And there’s the trade-off of a commercial version of Asterisk.  If everything works perfectly, being protected from the configuration settings for Asterisk is just fine.  But when there are problems, we’re locked out – and can’t even adequately diagnose things.

I hope to provide additional information about  logging functions and other diagnostic and administrative functionality of the system.  I didn’t discuss call queues at all and I think that call queues are very important and robust part of the software, but this has gotten a bit longer than I intended .. so I’ll  quit for now  and begin working on Part II on the next day or two  …

Well, this isn’t really of review of the hardware in any significant detail, we purchased a series of Polycom phones to try them out.  The Polycom 301 and the Polycom 501.  The phones are excellent although I think that the better screen quality and better sound quality of the 501 may in fact make it the most popular phone in the office.  We also bought several SIPURA 2002 ATAs and I have been testing these as well.  Set up the scrape straightforward and takes about 90 seconds.  These phones will be given to employees who need to work from home  (or anywhere) yet retain an office extension and office callers ID members when calling hospitals, doctors offices or patients.