As carriers increasingly incentivize their customers to migrate away from copper TDM-based services through significant price increases or abrupt sunset notices, we've seen client activity increase as they transition to SIP. The replacement of primary rate interface (PRI) trunks with session initiation protocol (SIP) trunks on the enterprise communications system can be a relatively straightforward technology replacement project. However, we have seen situations where effectively making this change has involved substantial preparation and planning. This article may provide insight into areas that deserve consideration for those preparing to make the journey to SIP. Keep the following in mind as you transition from PRI to SIP.
A Fundamental Approach to SIP
There are two fundamental approaches to delivering SIP. In one camp, some providers deliver SIP trunks over a customer’s existing IP connection (e.g., Internet circuit), and carriers refer to this as “Over The Top” (OTT) SIP; the provider of the SIP trunks and the provider of the access circuit are separate. In the other camp are the providers (typically the established carriers) that deliver both the SIP trunks and the access facilities (e.g., Internet, MPLS); in this case, the provider is the same for both elements of the overall SIP solution. Both offer their own set of advantages as it relates to price and performance. Note: the major carriers do not sell their SIP trunks as an “OTT” offering — you must purchase them with that carrier’s IP access/transport.
Another factor to consider with either approach is whether the IP access/transport will be shared or dedicated. Organizations that can verify that they have plenty of capacity may elect to add their SIP trunks to an existing Internet or MPLS circuit. Other organizations elect to keep their SIP trunks on separate IP access/transport that only carry SIP traffic and size them specifically for that duty.
Evaluate Your Architecture
In some cases, the move to SIP will involve either the evaluation — or a definite decision — to change the architecture of the voice network. Specifically, we see this especially when organizations have been employing a distributed design with local PRI’s serving individual sites and decide to move to a centralized design where SIP trunks are delivered to select data centers and pooled as a resource for the entire enterprise. The centralized model can result in significant efficiencies. Also, the number of call paths required is typically (surprisingly) less than the number of PRI call paths found in the legacy network. Reviewing traffic studies can help to assess anticipated future load.
Organizations should carefully consider their ability to throttle down call paths from their provider once they can see the true usage picture from the portal reports. Being able to do this without penalty allows organizations to get in the “ballpark” at implementation and then fine-tune the number of call paths once everything settles in.
For some organizations, transitioning from a distributed PRI environment to a centralized SIP environment may require backend changes with the communication system or data center site(s). In the case of a single data center, diverse service entries that support the delivery of SIP from two different directions may be prudent to consider. Some organizations decide to set up a second geographically diverse data center with a survivable node to support SIP trunking access for the enterprise.
Don’t Forget Failover
If delivering SIP trunks to two or more locations (e.g., data centers), you will want to consider failover carefully as capabilities vary by provider. In some cases, failover capability even varies by the access type employed (e.g., MPLS may provide enhanced failover capabilities over the use of Internet). IP access/transport should be sized to accommodate total call path load under failover based on the primary CODEC that will be used. It is sometimes helpful to provide different failover scenarios. Ask your provider to state if active calls will drop, how many call paths will be available at the remaining active data center, and what level of redundancy/diversity is designed into your organization’s quote. You may also ask under what circumstances might their failover solution depend upon your organization’s private network elements to make it work.
Add a Session Border Controller
A move to SIP will (generally) require the addition of an SBC at each location receiving SIP trunks. Be aware that the current supply chain shortages may increase the lead time needed to receive these components.
Assess Your Faxing Traffic
Faxing over PRI is typically rock-solid; moving fax to SIP can sometimes pose challenges. If your organization still depends heavily on fax machines running as analog stations over the PRI network today, you will want to assess your provider’s commitment to supporting your fax traffic over their SIP network. If fax users send out or receive many high page count transmissions, the potential to have fax failures increases over IP. Generally, your provider’s engineer will set up your fax traffic to use T.38 or G.711 and then test before cutover to verify that it works properly.
Support 911
Organizations need to assess what they are currently doing to support 911 calling from their communication system connected to the PSTN via PRI services – then consider their approach to SIP and work with their potential providers to understand how to address 911-calling. There is too much variability to consider within the scope of this article. Factors include: Will the organization move from distributed to centralized? Does the organization already use a 911 (PS-ALI) solution? How is the organization addressing State/Federal (Ray Baum’s Act) 911 regulations today? The move to SIP needs to address how to handle 911 calling for everyone connected to the enterprise communications system.
Make Time to Process Porting Orders
Processing port orders to move numbers (DIDs) from your PRI provider to your new SIP provider is a coordinated dance that must be perfect. Otherwise, one of the carriers will reject the order to correct it (sometimes without any direction as to what they must fix) and re-submit the order. For organizations with numerous PRIs from multiple carriers, the effort involved in processing port orders increases, and the risk of delays – or missed - port dates increases. Porting is a picky-picky process that demands time (~ 20-30+ days per order) and attention to detail with access to current records (bills/CSRs) to complete.
We recommend staying ahead of the “PRI curve” and planning your move to SIP before you receive a notice that your rates will be going through the roof soon, or worse yet, your PRI service will shut off after a certain date. One-for-One replacement (PRI for SIP trunks) is generally a straightforward affair. However, larger organizations with more complex designs/requirements should allocate time to work with their prospective providers and figure out how best to transition from PRI to SIP — and navigate the changes to make this leap successfully.
Ted is writing on behalf of the SCTC, a premier professional organization for independent consultants. SCTC consultant members are leaders in the industry, able to provide best of breed professional services in a wide array of technologies. Every consultant member commits annually to a strict Code of Ethics, ensuring they work for the client benefit only and do not receive financial compensation from vendors and service providers.
