What term do you use to describe the company you work for? Are you a telephone company, a service provider, a carrier, or a network operator?
These days I’m seeing more use of this last term – network operator – in large part because the network is becoming more important than the application (voice).
Most of our work is focused on voice applications – switches, SBCs, PBXs, and the like – but recently we’ve been digging deeper… looking at the underlying IP network. In particular, we’ve been looking at how best to operate an IP network to provide high-quality, reliable voice services – i.e. to build IP networks for voice applications.
High-Quality, Reliable VoIP
What does it mean to design an IP network that supports high-quality, reliable VoIP?
#1 Resilience
The underlying network needs to have multiple paths between each pair of endpoints, and it needs to self-heal. If a particular router or IP link goes down, or becomes congested, the underlying network needs to re-route traffic via an alternative route without the change being apparent to the applications and services using the network.
With the emergence of SDN, we’ve seen a focus on the idea of an underlay network (the underlying infrastructure, which is focused on availability) being separate from the overlay networks (which are used by the particular applications (e.g. voice)) – and it’s this underlay network which provides resilience.
#2 Capacity Design
Unlike a data network, where the available capacity can always become congested through enough HD streaming and online gaming, with a voice network you have a much clearer idea of the capacity requirements. If you’re providing the voice services, you’ll know the number of phones, the likely contention ratio, and the codecs being used.
Based on current needs, and plans for growth, you can allocate resources in the IP network to provide more than enough capacity for the anticipated needs – thereby ensuring that you don’t have issues with congestion, dropped packets, excess latency or jitter.
#3 Security
Ideally your voice network will be totally isolated from the public internet. If you create a separate overlay network for voice you can use a private address space that can’t be reached from the outside world, and thereby protect yourself from DDOS attacks or attempts to steal voice service.
If your network does need to be publicly available then an array of redundant SBCs can be used to protect from external threats, with DNS SRV used to provide redundancy even with a single published FQDN.
#4 Monitoring
Despite your best intentions, it’s unlikely that your IP network for voice will work perfectly, particularly on day one. So you need monitoring tools that can continually monitor the quality of connections across the network, spot any areas where the network isn’t hitting your expected quality, and highlight these issues to your NOC for investigation.
Each time this happens, your NOC can identify the issue, and fix it manually… the first time. But then they can create an automatic rule, which spots similar problems in the future and automatically heals the network – so that next time the network itself will resolve the issue without any manual intervention.
#5 Not tested, not working
As I wrote recently, I prefer to approach networks like Sherlock Holmes rather than Mycroft Holmes. You can (and should) start with the theory, but it’s only through testing that you can know for sure how your network will respond to stress or to failures.
IP networks for voice are complex
I’ve only just scratched the surface of this topic. Designing an IP network for voice applications is complicated, but if you do it well your customers will be happier, and you’ll be able to sleep at night.
If you’ve been having problems with voice quality or even outages due to your IP network, go ahead and contact us. If you had problems in the past but have fixed them, I’d also love to hear more about your story – what you learned and how you resolved the issues.
