The Single Call Control Plane Myth in a UC World
Call control planes and CAC are useful tools, especially in limited bandwidth zones, but be careful not to turn these tools into expensive or limiting elements of your architecture.
Unified Communications (UC, or UC&C, when "collaboration" is included) is a threat to the PBX. UC offers enterprises ways to use new communications capabilities, not all of which are voice or video, to solve communications problems. When these new communications solutions do require voice or video, the UC systems can use integral voice and video IP protocols. which do not require a PBX license, connection or route.
Of course, the PBX manufacturers have many defenses against this threat. One defense is to argue that the enterprise should have a "single call control plane." This means that all calls in the enterprise should be controlled by a single system. At a minimum, this means all voice calls. Increasingly, the PBX producer argues to include all real-time communications including video sessions.
The argument is that this single call control plane will give the enterprise better voice quality for calls between enterprise locations through a centralized allocation of voice and video bandwidth on each segment of the enterprise's Wide Area Network (WAN). Known as call admission control (or CAC), this allocation assures that no more calls will be allowed onto each WAN segment than is supported by the real-time communications class of service on that WAN segment. The logic is that a single call control plane will assure that other products, systems or software will not defeat the CAC strategy by using unauthorized portions of the protected real-time bandwidth.
However, the single call control plane approach has some drawbacks, which are often significant enough to disqualify the approach as an enterprise-wide strategy. When these drawbacks are examined, the result often shows that the importance of an enterprise-wide single call control plane is a myth. Here are some of the possible points to check before committing to a single call control plane:
First, a single call control plane may be irrelevant in some parts of the enterprise network topology. For example, most enterprises have an abundance of bandwidth at their main locations. This could be a large campus environment or could be a number of buildings in a major city that are supported by a Metropolitan Area Network (MAN) from an Ethernet Backbone service provider or an MPLS carrier. If bandwidth is plentiful in a low-latency network zone, there is no need to build and maintain a call control system to allocate that bandwidth. Note that in most cases, the Class of Service (COS) functions of an MPLS network can accomplish the same purpose as a single call control plane without the additional costs or administration on the enterprise's communication system.
Second, a single call control plane is irrelevant for some types of communications. For example, employees' calls on mobile devices are controlled by the cellular carrier's call control plane, not the enterprise call control plane. Calls from remote or mobile workers to other remote or mobile workers, if connecting between IP endpoints (hard phones or softphones), will route directly between those endpoints, outside the enterprise firewall, and will not require a single call control plane. Communications using audio and video conferencing bridges, especially if those are hosted services, are unlikely to be visible to, and therefore unlikely to be controllable by, a single call control plane. Communications from customers or partners through the enterprise's web pages or via collaborative workspaces may be routed directly to a web client, rather than through a single call control plane.
Third, the imposition of a mandatory single call control plane methodology may limit the types of communications systems or devices which the enterprise might use, to those which have compatible protocols for or have been certified by the producer of the single call control system, usually one of the enterprise's PBX vendors. This runs the risk of restricting the enterprise's ability to innovate at a time when innovation using new UC tools or new WebRTC methods is more important than ever.
Yes, there is a place for CAC to control communication calls and sessions to locations with scarce bandwidth, such as for video to or from small branch offices. This control can be provided by a system that controls communication to those locations, but does not require an enterprise-wide implementation.
This will likely be increasingly important when considering UC&C implementations. As shown by the Enterprise Connect 2013 RFPs, the most economical way to implement UC is to deploy an "overlay" solution in parallel with the existing PBX system. In those cases, the UC overlay will have its own call control plane. Also, as shown in the RFPs, the new UC solution can be connected to the existing PBX system to utilize existing trunks and telephones. Similarly, it is increasingly common to find communications functions built into business applications (SalesForce.com, SAP, and many others), again having a separate call control plane, which can connect to the existing PBX infrastructure when needed.
So, bottom line, it is not necessary to have a single call control plane before proceeding with UC&C. Call control planes and CAC are useful tools, especially in limited bandwidth zones within the enterprise, but be careful not to turn these tools into expensive or limiting elements of your enterprise architecture.