TechTarget and Informa Tech’s Digital Business Combine.
TechTarget and Informa Tech’s Digital Business Combine.
Together, we power an unparalleled network of 220+ online properties covering 10,000+ granular topics, serving an audience of 50+ million professionals with original, objective content from trusted sources. We help you gain critical insights and make more informed decisions across your business priorities.
As I mentioned in last week's post, SIP trunks keep gaining in popularity, but implementation problems persist. This was among the learning from The SIP School's fifth-annual SIP survey.
The survey results, which reflect the input of almost 1,100 respondents, show fewer problems have cropped up on the equipment side than in previous years. This isn't to say that equipment vendors don't have their problems; it's just that this year's survey respondents report having a greater number of problems with service providers.
Middle of the Pack Session border controllers (SBCs) and network address translation (NAT) devices sit at the boundary between the IP PBX and the provider. Respondents associated about 21% of SIP trunk problems to these edge devices -- fewer than they attribute to providers but more than they consider the fault of IP PBX vendors. In this year's survey, IP PBX vendors accounted for 16% of the problems; this is a major improvement over 2013 and 2014.
Note that SIP trunk problems aren't usually technology issues. Rather, the problems stem from mismatches, improper configuration settings, impatient and inexperienced installers, poor training, and poor documentation.
Survey respondents indicated that they consider value-added resellers (VARs), the fifth component in SIP trunk implementations, as the weakest participants. As you can see below, results show a lack of confidence in VARs and hosted VoIP providers.
Problems at the Edge When compared to 2014 and 2013 survey results, some problems with the SBC and NAT devices have worsened. The table below compares the percentage of problems reported over the last three years.
How can these problems persist year after year? The survey results are public. Aren't the right people paying attention?
Let's take a closer look at a few of these:
IP PBX Problems That the IP PBX generates fewer SIP trunk problems is gratifying to see. Let's take a closer look at these, too:
IP PBX problems (Source: The SIP School)
Codec issues are preventable with the proper inspection of settings. Could we have an automated validation check to match codecs?
Registration failures and SIP trunks dropping are attributable to misconfiguration or poor documentation.
No licenses is a really ridiculous reason to have for experiencing SIP trunk problems. Don't enterprises know for what services they are paying? This should not happen.
Learn the Survey's Lessons Enterprises are rapidly replacing T1/PRI trunks with SIP trunks. In comparison, these legacy trunks have few problems. Enterprises, of course, want their SIP trunk installations to be as clean as legacy trunk installations.
All five parties -- IP PBX and SBC vendors, trunk providers, VARs, and the enterprises themselves -- should develop a good working relationship before, during, and after the implementation. Problems after cutover won't disappear, but VARs and enterprise IT staffs must take responsibility for getting the chain of components to work together seamlessly and to stop the fingerpointing.
You can blame most of the aforementioned problems on ignorance, which points to the need for more training and experience, proper documentation, and more care to reduce typographical configuration entry errors. An enterprise can avoid all of these with installer patience, good training, and independent configuration verification.
According to recent research, telcos haven't given enterprise customers any reason to be optimistic about technological innovations done in a timely fashion, or competitive pricing in the market.
Overexposure, overpermission and overdistribution all present threats to an enterprise's security – but there are ways to offset all three of these security issues.
The WAN is the most important link in this whole chain of dependency on the cloud, as the WAN is the weakest link. Therefore, 'X' As A Service is only as good as the ability to get to X.