The State of SIP TrunkingThe State of SIP Trunking

A look at some of the problems that still exist with SIP trunking, from an objective integration expert.

SIP trunking should be a commodity implementation, but it's not. Problems persist with all those involved: IP PBX and SBC vendors, providers, VARs, and the enterprise. I wanted to learn more about the state of SIP trunking so I contacted Chakra Devalla, CEO of tekVizion, who takes a vendor/provider neutral position as an observer of SIP trunking deployments, to get a better sense of the state of SIP Trunking today.

tekVizion helps service providers, vendors and enterprise customers deploying multi-vendor business communication networks. They offer a range of services including solution validation, interoperability testing, on-demand access to virtual interoperability lab environments, integration services, and custom application development.

SIP Trunking has been around for several years now, however we are seeing that it is at the tipping point of mass adoption. SIP trunking adoption is accelerating due to the fact that several major carriers and service providers have begun to phase out legacy phone services (T1 and PRI connections) altogether in favor of SIP Trunking. Some no longer offer traditional TDM access in certain sections of the U.S.

Most enterprises have experienced problems with deployments. A recent study from The SIP School found that of enterprises that have deployed SIP trunks, over 80% experienced some kind of problems with them. (See related posts, "Different Year, Same Old SIP Trunk Provider Problems" and "Why SIP Problems Persist--and What to Do About Them.")

Success has been slow because of tactical issues. Most of these problems can be avoided with proper testing and documented configuration guides. Enterprises should be asking their SIP trunk provider what testing and configuration has been verified in advance of deployment.

Not at all. This is an issue that confuses many of the enterprise customers we work with. Some providers define a SIP trunk as a single session. Others define it as several sessions, equal to a PRI trunk. Some support fax, some don't. Not all carriers offer G.711 end-to-end. It may be G.711 at the edges, but is compressed to G.729, blocking fax, PC modems, and telemetry connections, as it traverses the network.

Referring back to The SIP School survey, the vast majority of survey respondents that had implemented SIP trunking had problems. Most of these problems are due to interoperability issues.

One example is Microsoft's support of SIP transport over TCP, while the vast majority of providers use UDP for transport. That means there has to be a gateway/SBC in the middle, and that has to be thoroughly tested. The full end-to-end solution needs to be tested in the same configuration in which it will be deployed.

The leading vendors and service providers have gained considerable expertise with SIP in general and how to implement it within their own offerings. However, the challenge comes in having detailed knowledge of every other vendor/service provider product with which they may need to interoperate. In the T1/PRI world of the past, knowing each other's products in this detail was not the provider's responsibility.

When an enterprise customer opened a trouble ticket in the past with a service provider, the service provider was responsible for solving the problem. Now, service providers may point back to a vendor problem. The enterprise customer now has to manage the interactions and trouble-shooting between their vendors and the service provider. We have come across many cases where an enterprise invested in a solution on the promise that it would all work together because "it's all SIP," yet when it came to implementation things didn't work together, causing the enterprise customer to have to invest considerably more time and money, and experience a service delay.

The service providers' demarc was the edge of the enterprise network at the T1 or PRI connection. They were agnostic to what was going on the LAN. Problems emerge due to issues within the LAN. This is a whole new world for the service providers to have to learn and troubleshoot.

Both vendors and service providers encounter challenges that they can't possibly test with every permutation of a solution that exists. For example, an IP-PBX vendor may decide to test a new release with the top three to five service providers they encounter. But what happens when either the vendor or service provider issues a new point release? And how do service providers service all of their customer requests? They come upon sales opportunities every day where the prospective customer has an IP-PBX they have not interoperability tested.

Fax is definitely a problem, and is one of the common problems we see when testing or assisting enterprises with deployments. 911 is not as problematic, however. Again, it needs to be properly tested, especially in multi-campus environments.

We have SIP trunks coming into our lab from our service provider customers. We have over 250 UC network elements. This includes just about every PBX on the market and the leading SBCs. We use this to simulate an enterprise's end-to-end solution, test it extensively for interoperability, and provide a proven configuration guide for deployment.

Vendors and service providers come to us for independent verification of interoperability. As far as the vendors go, the leaders in the market have all signed agreements with us to be the "go to" lab for certification between their product and another product or service. Service providers use us to test their trunks with the IP-PBXs and SBCs deployed by their customers or prospective customers.

Most service providers contract with us on an annual basis for testing as a service (TaaS). We are their outsourced test team for interop testing. Platform vendors and ISVs can contract with us for a single test or on an annual contract basis. The same is true for enterprise customers.

The bottom line is we are truly independent. We don't resell products, we don't recommend one product over another, we provide the factual results, and we offer a guarantee to the enterprise customer that if they deploy a solution that we have verified (in the same configuration and versions tested), and experience an interoperability problem, we will provide troubleshooting and problem resolution at no cost to them. The enterprise won't be left holding the bag.