The promise of SIP trunking has been touted for years: You'll save money! It's easy to manage! It's flexible! It offers better business continuity! While this all may be true in theory, the reality is that an integrated approach and careful planning are required to achieve these results. It's not as simple as order it and call it a day.
In a traditional circuit switched environment, you call the carrier, order the service, the service is delivered to your demarc in some reasonable (or unreasonable) timeframe, you cross connect it to your PBX, and you are off and running. Some minor tweaking of signaling protocols or timing is sometimes required, but other than that, the process is relatively painless.
The first secret to understanding SIP trunk implementation is grasping that they are not trunks in the traditional sense at all, rather real-time IP voice or video data services with connections managed by the SIP protocol. These pipes are sized to accommodate an amount of throughput equivalent to that of a traditional trunk. Because the word "trunk" is an industry term that conveys an easily understood concept, it is used when describing SIP services, albeit inaccurately. This mismatch between terminology and reality creates a misunderstanding of what is required to successfully implement SIP trunk services.
We see the challenges in implementing SIP trunking falling into four main areas:
Today, I'll be focusing on challenges in planning and communications complexity, while next week's article from my SCTC colleague Ivan Sindell will focus on challenges in design errors, procurement, and monitoring.
Organizational planning and communications is paramount in a SIP implementation because SIP trunks overlay other infrastructure and rely on multiple underlying protocols to work. Not only can SIP ride over any WAN technology, but because the SIP standard is flexible, it is offered in different flavors by different vendors. As an unregulated service, service providers implement and codify it in different ways. Some sort of translation between components is therefore often required. At a minimum, the players are: carrier/SIP/WAN provider, SBC vendor, customer, equipment VAR/integrator, and PBX manufacturer. Everyone involved must have the same understanding of what they are implementing to ensure success.
Because SIP projects involve so many players, every SIP implementation needs to start at the organizational level. Prior to "placing an order," organizations should have a strategy in place -- not just for voice architecture, but for overall network and services. There needs to be a clear vision and direction, with support across the organization, including at the executive level.
The organization should be able to answer a series of strategic questions. For example, is the company moving towards outsourced/managed services in general, or continuing with a premises-based strategy? How important is resiliency in the network architecture? Is the existing network capable of supporting additional load? What resources are available within the organization; is there the knowledge and skill to support the services on day two and beyond? Has the organization effectively articulated its vision, and has the vendor taken the time to understand the vision? Or is the vendor simply selling SIP trunks without understanding the business's overall strategy and vision?
On the vendor side, there are also certain factors that will need to be worked out at the organization level. For example, will the entire solution be sole sourced? Or will a different vendor be responsible, say, for the wide area network than the SIP trunks themselves? Will a session border controller (SBC) be required, and who will supply it? Is there configuration required for the IP-PBX? Who is providing last-mile connectivity? Finally, do the vendor resources assigned to the project have a deep understanding of the technology they are deploying? Are the needed skills available, and do they have organizational support required to be successful?
While simplifying design elements where possible is a solid strategy, there may be times when higher resiliency can be achieved by implementing a solution using multiple vendors for last mile connectivity and access. For example, if separate access routes can be overlaid on diverse facility entrances, utilizing diverse carriers, and diverse central offices, resiliency can be further strengthened. Two entrances, two fiber providers, two Internet providers, and two central offices, do, however, increase the need for coordination both internally and externally, even when using a sole SIP trunk provider. This means that prior to placing orders, the overall design of these elements need to be decided, documented, and communicated.
If your organization is thinking of moving to SIP, the first step is to understand your architectural vision and strategy, as well as your organization's internal resources. The second step is clearly articulating your vision to the vendor or vendors involved.
Stay tuned next week for part two in this series, which will cover design errors, procurement, and monitoring.
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.
