Melissa Swartz | No Jitter | March 23, 2016
A deeper dive into factors around facilities, configuration, and failover that can complicate a move to SIP trunks.
There are many ways that a move to SIP trunking is more than a simple replacement of current digital or analog services, as I began to explore in my previous article on No Jitter.
When moving to SIP trunks, you need to consider a range of factors related to facilities, configuration, and failover.
Facilities
There needs to be a way for SIP trunks to reach your network. You have two main options:
- A private connection such as MPLS. Some clients have added a connection to the SIP trunk provider, or have had the SIP trunks come in over an existing MPLS connection when the carrier was the same for both.
- OTT, or Over The Top services, where SIP trunks come in over an existing connection such as your Internet.
Of course, there can be costs for these services if it requires you increase bandwidth or add a new location to your network; this needs to be factored into your pricing analysis.
However, there are other considerations as well:
- If you are using an OTT connection, you will lose QoS once your calls hit the public Internet. This can result in poor call quality, since the priority markings don’t stay with the call. Even if you have a private connection, you can still run into call quality issues, but normally you can work with the carrier to get the issues resolved.
- Are you on the same carrier the entire route, or is there another provider for the last mile? Adding another provider into the mix can create delays when there are problems with the service.
- Depending on how services reach you, there may be different equipment needed on your end. Is the physical connection fiber, Ethernet, or bonded T-1s? You may need to buy some gear to support a different type of connection. If you are getting bonded T-1s, ask the provider how you will be alerted if one of the T-1s is lost. We had a client who was getting a lot of complaints about slow service and finally figured out that one of the bonded T-1s was down. It took some digging to figure out the cause.
- Installation intervals are typically longer for private connections if you can’t use an existing one. We are routinely seeing it take 90 days to install new MPLS connections.
- Number porting can be unpredictable. We’ve seen it go very well, and we have seen nightmares. In some rural locations, numbers may not even be able to be ported. We’ve run into this scenario three times in the past year. The process can be frustrating and create delays (see this article).
When evaluating SIP trunking, be sure you understand:
- How your provider will be bringing the services to you
- Whether there is a different last-mile provider involved
- What the physical handoff will be
- How long it will take to get services and port numbers. (Then add more time into your project time line to account for unexpected delays. If you don’t have any delays, it will give you extra time for testing).
Configuration
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 that you are installing a new communications system, the system provider will usually include SBCs (Session Border Controllers) in its 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 not going 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 can be an issue with VoIP and SIP trunks. Some carriers can change the settings in their network to work better with fax, but in my experience, that has not fixed all of the issues. Other fixes include slowing down the fax machines to 9600 baud, changing the codec to G.711, 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. For other carriers, this scenario might play out differently, as some might make the connection in their network so as to not tie up customer resources. Other providers still, 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.
Caller ID is another area where I 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. I’ve also seen the wrong caller ID displayed when a user makes a call to conference in a third person.
To avoid problems with configuration issues:
- Create a test plan
- Execute the test plan
- Fix the problems
- Test again
Failover
Configuration problems can impact failover. I have a client who has multiple locations on SIP trunks that come into two separate locations for failover. A cable cut took out the SIP trunks in the main location, and DID calls failed over to the second site as planned. Their toll free calls did NOT fail over. The carrier did not configure them to fail over, even though it 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.
Be sure that you also know what triggers your SIP trunks to failover. My team and I 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 the SIP trunks 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 seven critical numbers. In the carrier portal, there is no way to re-route all seven numbers as a group. Each number needs to be routed individually. I guess it’s a good thing they don’t want to re-route 700 numbers…
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; but some are able to do this.
To avoid these failover problems, discuss your requirements with your SIP provider in detail, and (again) test.
