We talked in my last post about what IT staffs, and voice folks as well for that matter, have to take into consideration when it comes to determining trunk bandwidth needs, how to prioritize voice and video, and understanding the roles that different pieces of equipment play.
If you want to get down and dirty with the calculations, an article by Gary Audin over at NoJitter.com is an excellent place to start. It offers a good introduction to the ingredients that go into the proper sizing of SIP trunks, so you can assure enough bandwidth – but not too much. Alternatively, you don’t want to be so conservative that it leads to insufficient call capacity and the customer service issues that can result from that.
Old telecom hands will recognize the terms Erlang, grade of service, busy hour traffic, and call arrival rate, but these calculations can seem like some ancient, arcane language to the uninitiated. Essentially, it boils down to assessing how many calls are likely to be handled in a given period, in order to make sure that incoming callers “almost” never get a busy signal or are otherwise forced to abandon their call.
Similarly, you don’t want your own people to be unable to access a line when they need to make a call, either.
The tradeoffs are a bit like network security. If you make a network perfectly secure, no one (not even your own people) can access it, which defeats at least one of the purposes. And if you make sure no one ever fails to get a call through, you will end up paying for loads of capacity that goes unused 99.8 percent of the time.
For the benefit of the telecom people, the article also goes into depth on how to calculate VoIP bandwidth needs, taking into account factors such as compression technology, packet sizing and overhead, protocols involved, and more.
SIP Trunking is great technology, with a tremendous potential for saving enterprises money (see how it benefited DSI Systems, for instance), for gaining the efficiencies of a converged network, and for migration to Unified Communications. But as with most technologies, the “unknowns” must be discovered as the implementation details are defined.
