Session Initiation Protocol (SIP) is inherently simple. It is readable, meaning that with a probe you can follow the session initiation by simply reading the messages as they travel between two devices. The protocol does not establish the route the content will traverse, nor its quality. After the session is established, SIP, as a protocol, is only responsible for ending the session.
SIP trunks were created to replace TDM B Channels in T1 lines -- one SIP trunk for one SIP Session. This allows VoIP premises switches to have a less expensive alternative to T1s. But more than 10 years after RFC 4904 created the specification for SIP trunks, more than 20% of SIP trunk installs today still have issues during implementation and operation. My SCTC colleague Beth English explored this last week on No Jitter. While Beth's article focused on organizational planning and communications complexity issues, this week's article will focus on challenges in design errors, procurement, and monitoring.
SIP Implementation Complexity
Ongoing issues associated with SIP trunks are troubling to us as system engineers. The IP devices we use every day communicate with billions of other devices over wired and wireless networks. So why does this is one segment, the SIP trunk, prove to be so difficult?
The diagram below from Cisco shows the number of network elements that are part of an end-to-end SIP deployment and account for the difficulty in deploying solutions, especially when the enterprise elements do not match service provider networks.
The large number of network elements combined with the large number manufacturers and service providers that may be part of any SIP trunk installation indicates the technical and organizational complexity that confronts an organization replacing a line item or two on their service provider's monthly invoice.
Problem Areas to Look Out For
SIP implementation problems can occur at many different points in the process, including with SIP trunk providers, edge device vendors, PBX configuration, and equipment manufacturers (see "SIP Trunk Provider Report Card" and "Grading SIP Trunk Equipment Providers"). Because that covers a lot of ground, my first word to the wise for organizations undergoing a SIP implementation would be to be careful and go slowly, commit resources appropriately, and use in-house and/or other independent expertise in all evaluations.
We assume you have committed appropriate resources and expertise to the team that will make procurement and implementation decisions, as well as manage its operation. The fact that we know there is a high probability of encountering broken voice communications or connections with SIP makes allocating adequate staff and resources the most important step for success.
Gather your enterprise's requirements carefully, including useful information like the life of existing IP switches and the enterprise cloud services migration plan. Design simplicity is the goal, and design errors may be the root cause of many of the problems that arise with SIP implementations. For the purposes of this article, let's assume that your business plans to keep your IP switches, but that you will be procuring new voice IP WAN capacity as well as the SIP trunks.
The new network element that is used by almost every SIP trunk implementation is a Session Border Controller (SBC). The SBC terminates the SIP trunk and provides an array of call handling, security, and management functions. It may also function as the network edge device for WAN.
It seems that there are hundreds of providers of SIP trunks and many providers of SBCs. Here is a suggestion: You may not need or want to sort through this array of choices. Create one procurement package for IP WAN connectivity and SIP trunks with the requirement that the service provider be responsible for delivering the WAN edge and SBC. In the procurement documents, you need to require and verify that the configuration bid has an installed configuration that will operate with IP Switches and their trunk cards that are already in place as well as with any cloud connections that are necessary.
Misunderstood or loosely defined customer needs; failure to perform a cost/benefit/risk analysis including new equipment, new WANs, or new WAN routing; insufficient dedicated voice bandwidth to shared services; cost of end-to-end management; and/or poor procurement judgements -- these are all factors that come into play with design errors. Remember, regardless of vendor promises and capabilities, it is your enterprise requirements that hold the ultimate sway. Take into account any necessary changes to your enterprise's infrastructure and service provider configurations that may need to be put in place prior to SIP trunk turn up.
Using your budget cost numbers, make a decision to go forward or not; and if possible, make one entity responsible for overseeing the complete implementation and operation process. If that's not possible, minimize the number of vendors your enterprise has involved. Remove unnecessary WAN segments and edge components from your architecture design, and ensure that system management and monitoring are part of requirements/design. This includes real-time monitoring and management of key performance indicators (KPIs), including voice-specific KPIs, such as mean opinion score (MOS). At the end of the day you want do know who is responsible for solving any given problem that may arise during the SIP implementation and operation. Put specific responsibilities in the requirements and have vendors sign up for them. For large enterprises you can require the name, title, and contact info of the responsible employees.
Whether procuring SIP trunks by RFP or another approach, remove risk by asking vendors for the specific configuration your enterprise needs. Then verify that this is what will be provided. These configurations may involve the WAN service provider, SIP trunk service provider, session border controller (SBC) provider, and/or the VoIP switch provider. If possible, procure an end-to-end solution that comes from one vendor with one invoice, and require that this vendor operates its own 24/7 NOC, and has direct connections to the level 2/3 of any other entity in the implementation that they do not directly control or did not build.
Roll out very carefully, with a schedule agreed upon and signed off on by all the players. At each point, it should be possible to back out and return to the original configuration. If you are doing a pilot, it should be sufficiently large and operate over a long enough time frame to provide good data.
Is All the Hassle Worth It?
Often enterprises might find themselves wondering if one to three years of cost savings is worth the trouble and all the work involved in a SIP implementation.
The answer will depend on your view of whether IP PBXs (as stand-alone PSTN connected units) connected by SIP trunks are viable technologies for the future (2021-2023), and also whether your legacy systems are at or near end of life.
Voice and other real-time communications media will always require special handling. Looking once again at SBCs, vendors of SBC technologies have added significant capabilities to the handling of these real-time sessions, and SBCs will continue to remain part of hosted and hybrid solutions. There is an ETSI Industry group creating Virtual Network Function (VNF) specifications as part of software-defined networking activity. In this concept, for which the first specifications have recently been released, SBC functions are included as virtual network functions. SBC dedicated silicon will be replaced by CPU power in the virtual appliances, as shown in the below diagram.
The VNF idea will be a topic of another blog. For now, remember that given the complexities and opportunities for design errors in the underlying architecture when implementing a SIP solution, extensive planning, communication, and design are critical to ensuring success.
Learn more about SIP/SIP Trunking at Enterprise Connect 2018, March 12 to 15, in Orlando, Fla. Elizabeth English will be presenting on this topic in the session, "SIP Trunking: Getting the Implementation Right," on Monday, March 12, at 9:00 a.m. If you haven't yet registered for Enterprise Connect, register now using the code NOJITTER to save an additional $200 off the Regular Rate or get a free Expo Plus pass.
"SCTC Perspectives" is written by members of the Society of Communications Technology Consultants, an international organization of independent information and communications technology professionals serving clients in all business sectors and government worldwide.
Related content:
