Network functions virtualization (NFV) could revolutionize VoIP services for both telcos and enterprise customers...
by improving reliability, availability and lowering costs. But while the technology is still new, enterprises must be aware of providers that call a UCaaS service an NFV service. To understand the difference between cloud voice and NFV services, see part one of this article. To avoid false NFV service claims, read below.
In this early time of NFV testing and adoption where firm specifications and sample installations are not available -- enterprises need to be wary of exaggerated NFV claims for VoIP and UC services. For several more years, organizations are more likely to be preyed upon by NFV service claims than benefit from them, in fact, so it's important to know how to sort through the claims.
Navigating true and false NFV service claims
The main point in assessing a claim of NFV support is to ensure that the provider actually has a complete NFV implementation. Many vendors and providers that talk about NFV are actually doing nothing more than cloud-hosting, something that's hardly new in the VoIP or UC/UCC spaces. NFV specifications are set by the ETSI NFV Industry Specification Group, and they provide an end-to-end model for reference. Be sure a provider that claims NFV support actually supports that complete model.
The second point of assessment is the scope of services provided. Network QoS over the Internet cannot be guaranteed, so claims of higher voice quality mean that a virtual private network (VPN) of some type should be part of the service. If not, then the claims can't be substantiated with or without NFV. Even if a VoIP or UC/UCC provider supports VPN connectivity, it may not be able to spin up additional virtual SBCs as needed or change VPN service quality if they are not the providers of the VPN service itself.
More about NFV service claims
Learn about NFV service claims in mobile networks
The third thing to look for in an NFV voice service is specific integration of voice features and cloud applications. Voice and collaborative features could be made components of an application just like pieces of CRM or ERP, and seamlessly provide for communication and collaboration. This tight coupling of voice service topology and application topology could keep things like click-to-call/WebRTC working optimally even if pieces of an application are duplicated for performance reasons or switched to the public cloud for availability.
A final point is that NFV is still evolving, and actual NFV deployments aren't likely to come until late 2014. Not only does that mean that anything touted as NFV today may be pre-standard, but it also means that some of the possible benefits of NFV are still suppositional. We'll have to wait to see what is actually offered before we can draw a cloud-versus-NFV chart for voice hosting and make a definitive choice.
Management and orchestration groups will likely influence cloud DevOps trends and bring more integration between applications, VoIP services and network infrastructure even where the VoIP provider isn't a carrier. These trends will help voice users migrate to the cloud by changing and improving on what "cloud voice" really means.