By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
SIP trunks fail, and the longer the outage, the costlier the problem is to resolve. Thoughtful design of a disaster recovery plan for SIP trunking will help businesses ensure the great cost savings and benefits of SIP trunking and reduce or eliminate downtime that can quickly erode the ROI of SIP trunking. In part 1 of When SIP trunks fail, I outline the key criteria for selecting an Internet telephony service provider (ITSP) for SIP trunking services and what you need to know about an ITSP's disaster recovery plan for SIP trunk failures. In part two, When SIP trunks fail: Disaster recovery for SIP trunking, I'll help you devise a disaster recovery plan for SIP trunking to gain alternative and diverse routing, and high availability, and to retain the cost savings of SIP trunking.
A key consideration for disaster recovery with SIP trunks is selecting a provider for SIP trunking services. A respectable Internet telephony service provider (ITSP) will have in place its own disaster recovery plan for SIP trunking. This is something you should cover upfront during the selection and procurement of an ITSP -- not afterwards, when you are experiencing a major SIP-trunk outage. You need to know the ITSP's geographic redundancy, network architecture and related components included in its network, local redundancy, diverse routes, and failover capabilities.
From my surveys, SIP trunking services range widely across the board. Some are IT shops hawking service from an office park, while others are tier 1/2 carriers, with the remainder being everything in between. The ITSP with a resilient network is going to have data-center-grade facilities that already have SIP trunking failover routing in place. The locations of the provider's network operating centers (NOCs) should be geographically dispersed.
You should note that not all ITSPs have certified every telephony solution, and some may lack availability in certain areas. What you may not know is that some ITSPs have in-house development teams. They will strip and modify the SIP message header and even ignore what the customer telephony solution is sending, because this is faster and more effective than waiting for new software releases from the manufacturer -- if the manufacturer is even willing to comply with the request or change.
Think of the SIP header message as a value-added, dial-plan tool for solving individual customer problems. The SIP header message routes calls that can be manipulated, changed, added to and taken away from, in part or in whole. This capability extends beyond the telephony solution that must also have a dial plan (including anything dialed by any user, digits received inbound on any trunk, and digits transmitted).
How do ITSPs handle SIP trunking failover?
The configurations, hardware/software and platforms for telephony and ITSPs vary, but the basic concepts still apply to SIP trunking failover – where does the ITSP route the traffic? Then, if the rerouted traffic is going to another IP PBX or telephony platform (other device) in your network, will it resolve direct inward dial (DID) numbers?
Use this time to build your relationship with your ITSP, because it will be key in supporting you and identifying limitations on either side of the network. SIP trunking has a huge potential for payout in benefits, but they don't come free or without tradeoffs and effort.
You can always use more than one ITSP to provide SIP trunking services, but simplicity is the best place to begin. One way to use more than one ITSP for SIP trunking services is to use one provider for outbound traffic and another for inbound traffic. Or you could use just one provider for inbound and outbound traffic, but use a secondary provider to manage overflow traffic and diversity. Finding a carrier willing to failover and overflow DID calls to another carrier is challenging.
When SIP trunks fail, security is a solid SLA
In a hosted network environment, enforceable service-level agreements (SLAs) must be wisely crafted and include resources to ensure that SIP performance metrics, terms and availability criteria are being met. During the procurement process, the same discovery process must reveal the capabilities and limitations of the provider. Here is a complete guide to writing RFPs and negotiating with VARs.
Establish the SIP trunks and get them working. Document baselines for service and implement basic plans before moving into other areas, including disaster planning for SIP trunking; otherwise, you may encounter issues that are masked by configurations you introduce that are beyond the basic service and could be difficult to troubleshoot and isolate.
My company has just one site, and we tested the SIP trunks for 12 months before we moved our former Verizon services over -- and we still missed some fine details. It's also important to get comfortable with the risk and test installations. This will provide plenty of on-the-job learning experience, which should prove invaluable. Next, assess what level of risk you and your company are willing to take, and then consider the amount of effort and resources required to minimize and counter risks of loss.
In part 2 of When SIP trunks fail, I hope to encourage thoughtful consideration of your unique network configuration by providing generic concerns and considerations for crafting a solid disaster recovery plan for SIP trunking.
About the author:
Matt Brunk is a 35-year veteran of the telecommunications industry and president of Telecomworx, a Washington, D.C., area interconnect company. Previously, he was chief network engineer for Amtrak. In 2000, Brunk founded the NBX Group, whose members included dealers, users, 3Com, the media and consultants spanning 14 countries, to develop solutions for the 3Com NBX 100 and create a web portal directed at the IP PBX. He has presented at VoiceCon, authored articles for Business Communications Review and has written for the former VoIPLoop blog. He now writes weekly for the NoJitter blog.