If you’re in IT, you’ve likely heard the saying, “In technology, the only thing constant is change itself,” and boy is that right! For technical companies, if you are not moving forward, then you’re falling behind. There is no such thing as standing still!
A perfect example of this mindset is in Cisco’s evolution of video conferencing and telepresence.
In an effort to provide a “being there” experience for video conferencing, Cisco introduced their first telepresence products in 2006. The initial focus was on delivering staged telepresence conference rooms with call control being provided by Cisco Unified Communications Manager (CUCM).
One of the larger changes in the Cisco video-conferencing environment was the April 2010 purchase and subsequent integration of Norwegian company Tandberg. Tandberg brought to the table a suite of products, including small and medium-sized conferencing units, as well as software for managing video conference systems.
But now come the dilemma and the challenge in any product integration. Cisco already used CUCM for call control, while Tandberg products utilized Video Communications Server (VCS), which could work in either Control or Expressway mode. When these endpoint product lines merged, which call control solution should be utilized?
As it turns out, there was no quick solution to this question. Instead, the plan was to transition call control capabilities for many of the Tandberg-based endpoints to CUCM. However, the VCS-Control still plays a role for call control in some scenarios.
Beginning as early as CUCM v8.5, endpoints, such as the E20, could register directly to the CUCM or choose to register to the VCS. Support for more endpoint registrations was added in subsequent versions of CUCM.
Is this confusing yet? Now, many of the video conferencing / telepresence endpoints can register to either CUCM or VCS. So how do you decide what the design should look like?
Much of the answer lies in determining what the existing architecture looks like, which protocols need to be supported, and which interworking capabilities are required.
CUCM supports video endpoint registration using SIP but does not support H.323 video endpoints. VCS-Control supports both SIP and H.323 protocols for endpoint registration. With the most recent versions of CUCM, there is support for a broader range of features, such as native voicemail, call forwarding, music on hold, and Unified Mobility, while the VCS may not provide the same feature set.
The VCS-Expressway is the recommended element for interworking support. Business-to-business connections, SIP to H.323, and IPv4 to IPv6 are all made possible with the VCS-Expressway.
Additionally, with SIP signaling growing in dominance, support for URI dialing (berni@home.com instead of 902–555-1234) was required. Beginning with CUCM v9.0, endpoints can have alphanumeric URI aliases associated with their directory number and can be reached by dialing either the URI or the directory number.
Pulling it all together, elements from both the Cisco CUCM and the original Tandberg product lines have been streamlined and repurposed to remove overlap of functionality and capabilities. CUCM should be used to support SIP or Skinny-based voice and video endpoints. VCS-Control can be used to support H.323 and third-party video endpoints. CUCM can connect to VCS using SIP trunks, and VCS-Expressway can be used to provide interworking and business-to-business capabilities. Keep your ears to the ground to hear what the next version of CUCM brings to the table!
Related Courses
ICOMM — Introducing Cisco Voice and UC Administration v8.0
CIPT1 — Implementing Cisco Unified Communications IP Telephony Part 1 v9.x
CIPT2 — Implementing Cisco Unified Communications IP Telephony Part 2 v9.x
VIVND v1.0 — Implementing Cisco Video Network Devices, Parts 1 and 2