Your SIP Trunking Implementation Checklist

When session initiation protocol (SIP) trunking first emerged as a substitute for traditional T1 and primary rate interface (PRI) connections to the public switched telephone network (PSTN), enterprises experienced a number of deployment problems. This was to be expected, because connecting to a SIP trunk isn't exactly plug-and-play.

What is surprising is that, years later, many of these problems continue to plague the enterprise. The basics of SIP and SIP trunking are no longer new to providers, so why are these problems still surfacing?

Having knowledge of common SIP trunking issues and a checklist for dealing with them upfront can help enterprises avoid problems with their SIP trunking implementations. Some of these considerations are the same as those for T1 and PRI PSTN deployments, but enterprises must take into account that SIP uses a different transport technology and carries digital voice packets.

Common SIP Problems

First: what are the problems you might expect? Last year, The SIP School conducted a survey in conjunction with online news source Techistan of 400 industry professionals to find the most common issues encountered during SIP trunk deployment. More than half of the respondents (58%) were from the U.S.

The survey, which determined that 59% of respondents had deployed SIP and another 26% were testing or evaluating it, asked, "If you've had problems [with a SIP trunking implementation], where have the issues been?" The respondents' answers are shown in Figure 1.
The issues are associated with three areas: the SIP trunk provider, the edge devices (network address translation, NAT; and session border controller, SBC), and the PBX and its configuration. The largest number of respondents said their problems stemmed from the PBX and its configuration, but the other areas were also generously represented.

The SIP School survey also found a number of specific problems with providers, as shown in Figure 2.

Sidestepping Trouble

Now that you can see where the problem areas tend to fall, your first step is to determine which features and functions your enterprise already has in place and what the SIP trunk can provide in required services and operation. The enterprise can obtain reports from its current PBX (whether it is IP-based or not) that describe existing trunk connections and utilization. Such reports provide a foundation for developing the trunk traffic requirements. Here are some important questions to ask when doing so:

• Will secure encrypted connections be required?
• Will the G.711 codec or compressed voice using G.729 be used?
• Will teleworker connections be supported?
• Does the IP PBX or legacy PBX support SIP? If so, is the support proprietary or for the standard SIPconnect Technical Recommendation ?
• What is the schedule for SIP trunking implementation?
• Should multiple Internet telephony service providers (ITSPs) be selected and tested for a SIP trunking pilot?

The second step should include an RFP that clearly spells out the enterprise's requirements. SIP trunking is new for most enterprises, and it's not like the commodity PSTN connections of T1 and PRI, which are typically differentiated only by price. The SIP trunking RFP will be different from past procurements in a number of ways:

• Voice, data and video might go over the same SIP trunk.
• Local, long-distance and international calling might vary by service package and provider.
• A major goal is cost reduction, so the provider's proposal must demonstrate savings and include all costs for installation and any needed modifications to the IP PBX or PBX to connect to the SIP trunk.
• Voice quality requirements might call for the use of Multi-Protocol Label Switching (MPLS) or Virtual Private LAN Services (VPLS) network services, which could increase the cost.
• The provider might not connect to other ITSPs; if so, many of the calls will be off-network at a higher cost.
• The enterprise might want the SBC and media gateway to be provided and supported by the ITSP.
• The provider's pricing plans for HD voice, T.38 fax and hosted solutions might or might not be attractive.
• The support of Microsoft Lync necessitates TCP for SIP signaling - not a common requirement.

SIP trunking should be trialed and tested with two ITSPs. All features in use with the T1/PRI connections should be tested over the SIP trunks. And all issues listed in Figure 2 should be tested for successful implementation.