| BCStrategies Views | April 28, 2016
In Part 1 of this series, I discussed pitfalls involved in compatibility, pricing and facilities as SIP trunks are implemented. Next, we’ll cover issues that can occur with configuration and failover of SIP trunking.
Once you get your SIP trunks installed, they must be configured properly to do what you want them to do.
If you are moving to SIP trunks at the same time as you are installing a new communications system, the system provider will usually include SBCs (Session Border Controllers) in their proposal. But not all of them do. If you are adding SIP trunks to an existing system, SBCs could fall through the cracks.
I’m often asked, “Do I really need a Session Border Controller? I have a firewall already.” My answer is always “Yes, you need the SBC.” And it must be configured correctly. It’s been my experience that when there are problems with calls that don’t go through, it’s usually caused by the programming in the SBC or the firewall. Testing various types of calls (local, long distance, etc.) can uncover these types of issues.
Of course, this can also be another unanticipated cost item, so be sure that an SBC is included in your pricing analysis.
Your SIP trunks need to be configured so that 911 calls are routed to the correct Public Safety Answering Point (PSAP). This is especially important if you have multiple locations on centralized SIP trunks. We have clients who have left a POTS line in at every location to handle 911, due to liability concerns. Remember, if you lose power, you won’t be able to call 911 on your SIP trunks, but that POTS line will still work.
Faxing is an issue with VOIP and also with SIP trunks. Some carriers can change the settings in their network to work better with fax, but in our experience that has not fixed all of the issues. Other fixes include slowing down the fax machines to 9600 baud, changing the codec to g711, and tweaking the settings on the phone system. But even with all of that, faxes can still have issues. We have clients that have kept a PRI or analog lines just to keep their faxes working.
There is no standardization yet on SIP features. In fact, carriers will often use the same term but it will have different meaning to each of them. For example, there is a feature called SIP Refer. In the old days, we would have called it a “trunk to trunk transfer.” Here’s the scenario: an outside call comes in to a user, who then decides to transfer the caller to another number outside the system (such as a cell phone). For some providers, this would end up tying up two call paths or sessions, including two sessions in the SBC, even though there is no one in the system on the call. Other carriers would not tie up the call paths of SBC any longer; they make the connection in their network and don’t tie up customer resources. Other providers, by default, don’t allow SIP Refer and you have to make sure that you request it. Don’t assume that just because a term is used by multiple parties, that it has the same meaning to all of them.
We have a client who has multiple locations on SIP trunks that come in to two separate locations for failover. There was a cable cut that took out the SIP trunks in the main location, and calls failed over to the second site as planned. Well, DID calls failed over. Their toll free calls did NOT fail over. The carrier did not configure them to fail over, even though they did configure the DID numbers to fail over. The toll free numbers were moved to the SIP trunks at a different time, and the carrier missed the failover programming. The same thing can occur when you have multiple SIP routes within an organization; all of it must be properly configured for fail over. Testing fail over is important.
Caller ID is another area where we have seen configuration issues. Outbound caller ID must be properly configured or it can override the settings in your phone system. Incoming caller ID can be lost when calls come through an IVR. Sometimes transferred calls will send out incorrect caller ID. We’ve also seen the wrong caller ID displayed when a user makes a call to conference in a third person.
So how do you avoid configuration pitfalls? There are three ways: TEST, TEST, and TEST.
So we’ve already talked about how configuration problems can impact failover. But there are other pitfalls to be aware of.
First, be sure that you know what triggers your SIP trunks to failover. We were testing failover with a client, and we took down the phone system. No failover. We took down the data network. No failover. We unplugged the SBC, and then they failed over. That particular carrier doesn’t see past the SBC into the customer’s network, so for them, there’s no failover as long as the SBC is operational. This is important information.
If you want to re-route numbers, how is that done? Most carriers have a portal that allows the customer to control the number routing. We have a client that regularly re-routes about 7 critical numbers. In the carrier portal, there is no way to re-route all 7 numbers as a group. Each number has to be routed individually. I guess it’s a good thing they don’t want to re-route 700 numbers…
Be sure that all of your different types of service (DID numbers, toll free numbers, different SIP routes) are all configured for failover.
Many of our clients have a different backup carrier in place to allow them to continue service in case of an outage by their primary carrier. It can be tricky to get the SIP trunks set up to use another carrier service; some are able to do this.
To avoid these failover pitfalls, discuss your requirements with your SIP provider in detail, and (again) test thoroughly.
If you're thinking of using a cloud UC provider, be sure you understand the differences among solution types before making a decision.
If you want the job, you need to look knowledgeable and professional with your proposal.
Voice services are much more complex than they appear, and changing out a telephone system is no exception.
Which system is the best? Of course, the answer is: It depends. Here are a few of the factors you should weigh in making the judgment.