Sponsored By

The Single Call Control Plane Myth in a UC WorldThe 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.

Marty Parker

June 9, 2013

5 Min Read
No Jitter logo in a gray background | No Jitter

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.

About the Author

Marty Parker

Marty Parker brings over three decades of experience in both computing solutions and communications technology. Marty has been a leader in strategic planning and product line management for IBM, AT&T, Lucent and Avaya, and was CEO and founder of software-oriented firms in the early days of the voice mail industry. Always at the leading edge of new technology adoption, Marty moved into Unified Communications in 1999 with the sponsorship of Lucent Technologies' innovative iCosm unified communications product and the IPEX VoIP software solution. From those prototypes, Marty led the development and launch in 2001 of the Avaya Unified Communications Center product, a speech, web and wireless suite that garnered top billing in the first Gartner UC Magic Quadrant. Marty became an independent consultant in 2005, forming Communication Perspectives. Marty is one of four co-founders of UCStrategies.com.

Marty sees Unified Communications as transforming the highly manual, unmeasured, and relatively unpredictable world of telephony and e-mail into a software-assisted, coordinated, simplified, predictable process that will deliver high-value benefits to customers, to employees and to the enterprises that serve and employ them. With even moderate attention to implementation and change management, UC can deliver the cost-saving and process-accelerating changes that deliver real, compelling, hard-dollar ROI.