Backing up your iPBX Call Center, what is your plan?

“The Check is in the Mail”;
“I gave at the office”;
“The software if fully tested and bug free”;
“We are working on the documentation”;
“Go ahead tell me, I promise I won’t get mad”;
“Yes we backup our data every day, off site”.

These are just a few of our favorite white lies.   That last one, however, is a real resume creation event.  Today I took my late model SL convertible in for a smog inspection.   You could have knocked me over when the technician informed me that the car failed the certification!  Just the day before I had the car into the dealership to get the “consumer electronics” battery changed and have the normal scheduled maintenance.   Apparently, at least here in the peoples republic of California, if you have On Board Diagnostics (OBD)  in you automobile, that data is submitted or evaluated as a part of your smog inspection.  Having just had the battery changed, my dealer had failed to backup or protect this data and as a result the OBD  had no history.  I failed the smog check , wasted several hours of my life and can now retest when I get 100 miles of driving history back into the on board automotive computer.   Clearly my dealer had no data plan or process in place to protect the data during routine maintenance.

Now imagine if that had been your VoIP phone system or call center?   Simple server upgrade? New Version of the iPBX being installed?   The question is, does your dealer have a process in place to protect your data during routine maintenance?  More importantly do you have a plan and process in place for backing up your iPBX configuration database, system prompts, voice messages, call detail records and even your maintenance history (e.g. Logs)?   Want to play, “bet your company’?   Chances are that you have this on your list of “things to do” but you just have not had the time to execute.   You may even be trusting that your dealer is taking care of this as part of that expensive maintenance contract you entered into.

If you are really feeling secure about your iPBX failover plan why not just pull the power plug and test things out?  There is nothing like a crashed phone system to bring out the facts about database backup, recovery and the  business continuity preparedness of you and your vendors!  The facts are that having an active emergency back up and restoration plan in place is absolutely essential in this day and age.   Cloud backup automation services abound and there is not acceptable reason for not having this process in place.  Just as important, is a restoration plan that is periodically exercised.  You can have all the data available on backup, but if you can not restore that data, it is useless to you and your business.   Yes, it may be just another “fire drill”, but it will save your company if you include this process in your maintenance activities on a regularly scheduled basis.

Very recently we have had an opportunity to experience cloud based, on demand, iPBX redundancy and disaster recovery strategies.  We have explored some of the current cloud options for both day to day redundant operations and disaster recovery.  In one case we were able to bring up a complete PBX in the cloud in a matter of minutes, on demand using predefined Amazon Machine Instances.  The results were remarkable, dramatic and redefined operational readiness. Hit the AskDrVoIP button for details!

ShoreTel SIP, Mobility Router & the Firewall (Part 1)

This is not a SIP tutorial,  only an overview on the issues that impact remote SIP phones on any iPBX.  When you set up a SIP call between two end points, there are upwards of four “holes” that might need to be punched in your firewall for the phone call to work properly.  Clearly, there is the entire process of registering a remote phone and the process of setting up a phone.  Once these events have been negotiated, we  then have the issue of the media stream between the two phones.  Generally the registration and call setup are taking place through TCP/UDP port 5060 on a public IP address that terminates on your firewall.   Generally, your Firewall will have these ports forwarded to your SIP Proxy or iPBX which lives on your internal private network.   (Take note:  Public and Private IP, we will talk more about that later).

Once the call is setup, there is a “mouth to ear” path setup for each leg of the call.  These “dial peers” are really just media streams.  These media streams take place over UDP ports using RTP protocol, one for each “mouth to ear” stream, so that is two more ports open on the firewall.   Each of the RTP streams has a UDP cRTP protocol port requirement as well, so we need to open two more ports your firewall.  So to summarize, you will have TCP/UDP port 5060 open on your Firewall all the time, and four UDP ports open for each active phone call.  Your firewall is starting to look like a sponge?

You don’t have to be a network security guru to figure out this strategy has some obvious challenges!   12 year old Elementary school kids run port scanners looking for open 5060 and then run Sipvicious  in hopes of registering a rouge phone.   Through in the fact that your ISP may or may not block 5060, and or refuse to use the same ports and you have the making of a SIP nightmare!  SIP was never expected to traverse from public to private IP addresses either!  So we have SIP savvy firewalls and border controllers to help us out.  These devices, among other features they provide, can police ports, opening and closing them as required when a legitimate connection is required between an inside phone and an outside phone.   They also translate between the public IP address and the internal private address keeping an internal scratch list of who is using what, closing ports when done to increase security.

Is there a better way?  What if we could create a secure “tunneling strategy”?   Not a VPN,  but a strategy for getting the SIP call control and Media Stream to move through a single firewall port?   Sound like a winner?   This SIP Proxy Tunnel can combine all SIP (signaling) and RTP (media) VoIP Packets from one location (typically a remote office) and deliver them to and from another location (typically the PBX Server) using a custom TCP protocol.  This simple concept allows us to exploit the SIP Proxy Tunnel to overcome difficult situations, or to simplify a network scenario.

The SIP Proxy Tunnel can be used for the following reasons:

Resolve issues of NAT Traversal at both the remote and the PBX location
Simplify Firewall configuration at both the remote and the PBX location
Overcome difficulties with ISPs that block VoIP Traffic based on port numbers
Allows VoIP-over-WiFi in some restricted locations, such as Hotel rooms
“Fixes” Firewalls that cannot handle VoIP traffic correctly or which are very difficult or problematic to configure correctly, such as:
Microsoft ISA Server
SonicWall
What if “remote” also means a mobile phone?   When you have a user who is roaming around with a SIP soft phone extension on their cell phone,  we have no idea what IP address they will be connecting from!   The answer (excuse the pun) is an android or iPhone application  that enables you to create the tunnel from you mobile phone, bring up your iPBX extension and move your desk outside, down the hall or across the globe.  At the end of the day this would be a true Mobility router.   Last year ShoreTel acquired Agito Networks and obtained this very same technology and it is an outstanding solution. The ShoreTel Mobility Router and Roam Anywhere cell phone client can do all this SIP magic and even move your call seamlessly between WiFI and Cellular while your walking out to the parking lot.  How great is that?

How to Ring more than 16 phones in a ShoreTel Hunt Group?

How to ring more than 16 phones in a ShoreTel Hunt Group? Can’t say that we recommend this strategy, but none the less, we continue to see business applications in which the client insists on ringing a group of 16+ phones simultaneously! In ShoreTel, HUNT groups and WorkGroups have a limitation of 16 members per group if you want to ring them simultaneously. You can configure some 300 group members, but you can only ring 16 of them simultaneously. Why? Because call setup and feature processing (winking and blinking phone buttons) is not only processor intensive, it is done on the general purpose processor of a ShoreGear Switch not by the server. Basically, you are setting up 16 simultaneous phone calls and it takes lots of computer work, thus the limit of 16 phones per group.

So how do you ring more than 16 phones at a time? Well, there are two solutions that you can consider. One solution is to purchase an additional cost software package appropriately named “Super Group” that will ring upwards of 100 phones at the same time. The software package has the additional benefit of being shunupported by ShoreTel. The other solution, is to configure creatively and to push ShoreTel to do things it really was not designed to do. This option will work, but it is not supported and if you really cause your ShoreGear switch to overwork, strange and unpredictable results will be observed!

First, configure a new Hunt Group as you would normally do and give it an appropriate name (i.e. Customer Support). Configure the Hunt Group with a call stack of 16. Make sure that “skip a member if already on a call” is NOT selected. The Hunt group will support 16 phone calls before searching for the call stack full destination. You can also configure the “no answer” destination and even assign a schedule. So far, the configuration of this Hunt group is the same as any other, the only difference is that we are only going to add a single member to this hunt group!

Though you can use an existing User, you might even find it useful to burn another extension only mailbox license and create a new user expressly for this purpose. The trick here, is that this User will be the only member of the Hunt group and you will then configure your member phones to MONITOR this user extension. You should be able to configure a master user and then copy this users custom buttons to the other members of the group.

Here is what you will need to configure:

  1. In ShoreWare Director, select “Administration > Users > Individual Users”
  2. Edit the user you wish to include in the simultaneous ring group
  3. Click on the “Personal Options” tab
  4. Click on the “Program IP Phone Buttons” button
  5. For the appropriate button: Select “Monitored Extension”
  6. Enter a Label such as “SUPPORT”
  7. Choose the “SUPPORT” user’s extension
  8. Set “Ring Delay” to “None” (This will cause the phone to ring immediately)
  9. Set “Show Caller ID” to “Only when ringing”
  10. Set “No Connected Call Action” to “Unused”
  11. Set “With Connected Call Action” to “Unused

It would be wise to distribute the phones representing the member extensions across several ShoreGear switches. Don’t have all the group members be registered to the same ShoreGear switch if it can be avoided. This combination of Hunt group and extension monitoring will enable you to exceed the 16 member limitation when ringing phone simultaneously. Use it cautiously, but it will work!