VCS, Video Communications server or is it just a fancy Gatekeeper? Well at least its not called "vucs" (video unified communications server). Has Cisco finally realised that they are misusing the word unified? The Telepresence architecture design guide states:
"As the Unified Communications and TelePresence markets continue to grow and mature, the line between the two markets continues to blur. Both TelePresence and Unified Communications video devices employ many of the same protocols and codecs, providing full integration and the ability to utilize infrastructure devices from both solutions."
This might be true from an end users point of view, but as a UC engineer I know better. There is still a stack load of boxes required to provide users with the whole Collaboration "experience". The VCS is no different, there is still a heap of call control, which functionally should be done on CUCM. And why is there still no native support for H323 endpoints on CUCM!!!????? Having said that, more and more Telepresence endpoints support SIP. What I do like about VCS is the VCSExpress gateway. And I am most interested in its capabilities around Jabber combined with Video and particularly how will it run on mobile clients for example.
The VCS has two modes of deployment:
- VCS control - Providing call control
- VCS Expressway - VCS Expressway is an appliance that works in conjunction with the VCS Control to provide firewall traversal using H.460.18, Assent, or SIP protocols. It supports Traversal Using Relay NAT (TURN) servers. VCS Expressway also provides endpoint registration and signal and media interworking for SIP and H.323 video devices across the public Internet.
As you can see, if you run an environment with a mix of endpoint, some might be supported on CUCM, some on VCS, some on both, some run SIP some H323, some both. Or as Cisco puts it:
The question is, how does all this integrate with CUCM, how can my CUCM registered end point make calls to Telepresence endpoint? For instance when external participants need to dial into an MCU hosted conference, or if you want a CUCM registered SCCP phone to dial into a video conference. For this particular example let's stick with our extension 46698 as figure 1, which is our MCU registered endpoint, the endpoint that hosts the conference. In order to reach this, CUCM will need a route pattern to it. We will also need to configure a SIP trunk to reach it:
So the only thing that you will need to do is create the SIP trunk in such a way that it points to your VCS server, or servers if you have your VCS's clustered. Then create a route pattern with a Route List and Groups all very stock standard stuff. Remember it is considered best practice to use a dedicated SIP profile for this SIP trunk, so when tweaking it, this will not interfere with existing trunks. The other thing you will need to take into consideration is how you will point to your VCS servers. If you are going to use IP addresses as the destination address in your CUCM trunk configuration, you will need to apply, what VCS calls "transforms" to bring these IP addresses back to domain names. For example if you use 192.168.12.1 as the destination of your SIP trunk, and all your endpoints are registered as XXX@acme.com.au your INVITES will reach VCS as XXX@192.168.12.1 and the call will fail.
<Normalization scripts, addition needed>
So what about making calls from a VCS registered endpoint back to CUCM? Remember I mentioned the VCS is mostly an enhance Gatekeeper? Well guess what, you need zones (Zones are VCS speak for what CUCM calls trunks, I guess if you consider VCS to be a Gatekeeper, the term "zone" is still pretty accurate). So the first thing to configure on the VCS is a neighbor zone (think of it like a gateway, very much the same way as CUCM uses a GW in a route pattern).
The screen shot below shows a default zone, a CUCM zone and a zone to a VCS Express Way.
|Figure 3a - VCS Neighbor zone configuration|
In the zone configuration, figure 3, put in the IP addresses of the CUCM servers that you will use for call routing. In my example I have used just two CUCMs. Please note that there is no authentication used in this zone.
So now lets add a pattern that uses the zone, as added in figure 3, to route calls. I am not worry about the priority of the patterns as there is no overlap in the dial plan anyway. As you can see these patterns are handed over to a zone called "CUCM", which is the zone that was configured as per figure 3.
|Fig. 4 - VCS search patterns to CUCM|
I will probably dig into the search pattern syntax and usage of VCS a little bit deeper in a separate post, because I am only trying to give a more high level overview on how to integrate CUCM with VCS.
So how does an MCU (tandberg Codian) register on a VCS for Teleconference purposes?
This is done by configuring the SIP proxy or H323 Gatekeeper on the MCU's:
After this, the MCU will become either an H323 or SIP end point on the VCS.