This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
SIP trunk installations don't need unnecessary complication and the long list of "Oh by the ways" that follow installation attempts. Follow the basics and invest in upfront planning and testing before you proceed.
Establishing the plan for moving traditional services over to SIP doesn't mean one massive sweep of changes; in fact, I'd avoid this. Why? Somewhere between user experience being compromised, management being really unhappy, and why not manage this change in smaller increments?
Even before you implement SIP trunks, your chosen provider needs to provide you with test trunks. In the past I've lamented over the "trial periods," and some are good, some are not so good--this is where "providers" are falling short. They are seemingly too anxious to get you on and move on to the next kill. Time, motion and money I understand, but providers need to understand what's at stake too. The proverbial egg-on-face isn't cool, and when an organization experiences failed attempts with SIP trunking, it leaves a lasting negative impression on everyone within that organization.
The trial period for SIP trunk services is your tool to test and then examine your network and infrastructure for weaknesses or issues--don't wait for a live porting. How long should providers give "free" trial periods to evaluate and test SIP trunks? What are you comfortable with?
Determining the codec choice (compression) and order of choices may depend upon your provider. Will G.711MU or G.729A be your first choice? From here, you make new determinations such as: Do I have the bandwidth to support it (G.711MU) or can I fall back and will my "communications solution" support a fallback from G.729A or anything else to G.711MU if call quality cannot be maintained under G.729A? Then, what is the vehicle in which you are deploying SIP trunks? MPLS, best route via Internet, or something else?
In most cases, you will need time to play out different codecs and routing schemes to come up with an optimal solution for your organization. SIP trunking isn't really a "static decision," and as much as you want something to be "fixed" or "always on and available," the reality is you must pay due diligence and determine what works best for your organization.
A dark hole that customers venture into is backup routing over POTS, cellular or any alternative to SIP. What actually constitutes a "failure" to invoke the backup routing to engage? When an Ethernet link is up, is it really up? The short answer is, don't assume yes. Herein is where I believe many providers are falling short.
When audio quality dives and doesn't return, most SIP providers are not going to invoke failover automatically. Some may configure in alternative routing, but if the customer end is still experiencing issues for whatever reason and that link is up, what good is the alternate routing via SIP? It won't improve call quality and the complaints will still roll in.
When T1 spans are involved, we have the same exact issue from the carrier end: "We tested to the smart-jack and found no issues...blah, blah, blah." So what? From the so-called "smart-jack" to the physical connection on the customer's gear there remains the "void," and that void is created by the marketing concept that T1 smart-jacks are in fact smart. Not only are they not smart, I would rather peg them as idiot lights without meaning. Of course they do have value, but too often the issue is the pair (of wires) or the lack of understanding and meaning of the data that the provider is seeing, and this is where assumptions are made.
While the recent forecast that John Malone wrote about here shows that SIP trunking is expected to grow, there needs to be an expectation set that providers of SIP trunking services grow their offerings. By that I mean their services need to grow beyond emulating dial tone and pushing calls across a medium. Those routed calls need something more than marketing a phrase such as "smart-jack" and providing automatic choices that remove human involvement (to fail a link to achieve failover) and to self-adjust when call quality dives.
When providers of SIP trunking services provide consistency, they will experience more than organic growth. We know there is a pending death date of the PSTN and we also know that voice is in a transition, and so is how we communicate using cell, the PSTN or IP. SIP trunking is a cost play and you can argue it anyway you want, but it comes down to dollars. Everyone wants an edge on cost. SIP trunking gives that edge and provides features and value over the PSTN.
In defense of the providers and of what they are doing right, I believe there will be more SIP trunk deployments. Early last week, after porting services for one of our customers, the customer commented to me, "It sounds like you are in the same room with me," and that is revealing. That's cool but don't settle for cool because we still have a long journey. When customers say, "It looks like you are in the same room with me," don't get complacent. We still need that consistent mix of both quality and user experience, because that's what people value most: Knowing what to expect without variations. Voice is rebuilt and the process doesn't end with growth or market share. It must improve continuously and offer better-than-before service--and yes, it can be done.