Gordon,
The latest deployment guide for Cisco VCS and Unified Communications Manager (UCM) is available here:
http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_Cisco_Unified_Communications_Manager_Deployment_Guide_CUCM_6-1_7_8_and_X6.pdf
Based on your post, I'd think you want to go this route:
1. Build a SIP trunk between VCS and CUCM. You have to make some decisions as to how you are going to do this:
- Security: Are you going to use TLS for setup? SRTP for media? If yes, then you will need to look at getting certificates aligned on both systems. The best approach is to use an internal CA to generate server certs for both clusters and then configured CUCM and VCS with the appropriate CA trust list. There are several docs for both products that cover this.
- Call failover and/or load balancing: If load balancing is required, you will need to leverage DNS SRV records that point to your CUCM cluster and a separate set of DNS SRV records for your VCS cluster. The pros: you can get away with one SIP trunk on CUCM and a single DNS neighbor zone on VCS. The cons: Some folks get squeamish with DNS SRV. An alternate approach is detailed in the deployment guide reference above. You would createa "neighbor zone" on the VCS. One per CUCM call processing node. On the CUCM you would create a separate SIP trunk for each VCS (or, if using CUCM 8.6 you can get away with one trunk, multiple peers).
- SIP profiles: This is easy. The deployment guide lays it out for you and the VCS includes a pre-canned profile so it knows how to talk to CUCM.
2. Dial plan. You will want to configure your dial plan so that you avoid overlaps/conflicts/call routing loops. As a simple example, assume you program all 7xxxx extensions to be video. Done. Tell CUCM to send all 7xxxx extensions to VCS. Tell VCS to send CUCM extensions to CUCM. Tricky parts come in when you want to enable features like SnR. Both products have a facility for this. You have to learn both and pick one as an authority. There is more to it. But no need to get too fancy at this point.
3. SIP/H323 interworking. The VCS Control can support up to 100 concurrent, interworked calls. So, the VCS can handle SIP to H323 interworking for you. It is good like that.
- MCU: You can avoid interworking for your MCU if it supports SIP natively. If your MCU is one of the Codian boxes then it can do H323 and SIP simultaneously. A discussion on this can get quite involved. The basic idea is that you configure a SIP Neighbor Zone for the MCU. You configure membership rules on the VCS to put MCU SIP URI registrations into this neighbor zone. Finally, you configure search rules on the VCS so that H323 and SIP dial patterns for a MCU resource are given the same search priority. Say, you use 100 as your H323 prefix. Then you would have a "100\d*" H.323 rule and a "100\d*@mcu.uri.com" SIP rule. The first rule points to Local Zone and the 2nd points to the MCU SIP Neighbor Zone. They are given equal priority and are searched at the same time. VCS will prefer SIP if the original caller is SIP. If this is too much info for you, just do the interworking until you get comfy and can optimize your design.
- VCS registered endpoints: VCS registered endpoints that support SIP and H.323 should have both protocol stacks enabled. This will minimize interworking when you call from VCS-to-CUCM. For CUCM-to-VCS you will probably still deal with interworking since your SIP URis probably are something more useful than an e164 number@yourdomain.
Phones on the CUCM can stay on the CUCM. Their calls will route via CUCM to VCS over the SIP trunk. You may need to dork around with CODECs, regions, and locations to ensure transcoding isn't needed. The bottom line is that if a phone is registered to CUCM, it doesn't need to have a separate registration for VCS:
phone-->CUCM-->VCS-->endpoint/mcu/etc.
Get things configured right, then you can think of this solution as a single system with multiple components rather than individual systems spliced together.
HTH.
Regards,
Bill
Please rate helpful posts.
