What do we want? Video! When do we want it? NOW!
In this post, we will be covering the deployment and configuration of Cisco’s Telepresence video-conferencing solution. After reading this you’ll be able to deploy Cisco’s Telepresence solution.
Cisco has plenty of deployment guides (and assorted other documentation) for this product, but I haven’t found a concise and clear guide to just getting it working -so I figured I’d write one up.
For those of you unfamiliar, Cisco’s Telepresence solution is the de facto standard in most corporate offices worldwide. Telepresence isn’t so much one device as it is a suite of them. Wikipedia defines “Telepresence” as a range of products developed by Cisco Systems designed to link two physically separated rooms so they resemble a single conference room regardless of location. While most of that is true, it can do so much more. From integration into Jabber to multi-conference room meetings, it really is the king of enterprise video.
In the next section and throughout the article, we will be demonstrating the exact steps we took to get our current lab Telepresence up and running. While its assumed that your setup may differ slightly, the same principles are applied. As always if you run into issues or have questions, feel free to drop a comment below.
Lets dive in!
Listed below is what we used to get things going. The versions don’t matter so much as long as they are all compatible with one another. Compatibility guide is available HERE.
- VMWare ESXi 5.5
- Telepresence Conductor
- Telepresence Server (vTS)
- CUCM 10.5
- Jabber Client for Mac
- Jabber Client for Windows
Once you’ve successfully obtained all the OVFs, its time to deploy. The order in which they are deployed makes no difference. Note: You will need entitlement to download the OVFs.
Conductor- Download Link
vTS- Download Link
Jabber for Mac-Download Link
Jabber for Windows-Download Link
DEPLOY THE VMs!
We’re ready to deploy VMs. Log into vCenter and select File>Deploy OVF Template. Select your OVA file that corresponds to the items above and do the obligatory next, next, finish. Ensure you select Thick Provisioned, as Thin is not supported.
- Upon first boot, you will be prompted for username/password. Username is admin, password is TANDBERG. Once in, you will roll through the initial setup. This part is fairly straight forward and will require you to assign it an IP. Note: before its all said and done, conductor will have 3 IPs all in the same subnet. For now, we will just need to assign one. If you are using a voice VLAN, you will want to assign Conductor an IP in that subnet.
- After an IP has been assigned, navigate to the GUI https://<IP> and login using admin and the password you changed it to during setup. If you are deploying this to anything other than lab or POC testing, make sure to change the password.
Telepresence Server (vTS)
- Upon first boot, you are dropped into a generic shell that has TS:>. Without reading the config guide, it’s almost impossible to know what to do next. Once you are at this stage, we need to assign an IP. Below is the syntax you will use to do so. This line assigns the address 192.168.1.2 to the TelePresence Server, with subnet mask 255.255.255.0 and default gateway 192.168.1.1. Obviously your environment may differ so change the IPs accordingly.
static 192.168.1.2 255.255.255.0 192.168.1.1
2. Reboot the vTS server for the changes to take effect. After the vTS server comes back up, navigate to the GUI https://<IP> and hang tight. We will come back to this soon.
At this point, you should have a vTS server and a Conductor online and accessible from the PC you are working from. Below I will provide steps with descriptions on why we are doing them.
- Navigate to the IP of your vTS server. Go to Users>Add New UserCreate a username, name, and assign a password. Make sure to give the user Administrator rights.
This user will be used to authenticate from the conductor to the vTS server and to select available resources.
- First order of business is to create a service template. For this demo, we have created one, but feel free to create as many as you want. These are simply used to allocate resources (Conference Bridge Pools).
- Once added, you should see the image below indicated communication between the conductor and vTS is successful
- The IP or FQDN (if you prefer DNS) will be the IP of your vTS server. The username/password will be the one you just created with administrator right. For this, I’ve selected HTTPS as my protocol but you can use HTTP if you’re just wanting to test it out. Select Save
- Give it a name and select Create Conference Bridge
- Navigate to the IP of your Conductor. Go to Conference Configuration>Conference Bridge Pools>New. Create new bridge
- Let’s create some conference templates. These templates will be used in the Location setting to define the setting used when creating a conference either Ad-Hoc or Rendezvous. If you are doing both (which we are in this guide) we will need two separate templates. Select New. Below is our configuration.
- Once the templates are created, we need to create some locations. On Conductor, go to Conference Configurations>Locations. Under Related Tasks add two additional IP address. One will be used for Rendezvous Conferencing, the other Ad-Hoc. These IPs should be in the same subnet as Conductor. Select New. The configuration below is essentially where we are creating a SIP trunk to CUCM. In the interest of simplicity, we are creating one trunk for both Ad-Hoc and Rendezvous. We will create the other end of the trunk later. As the name implies, select the Ad-Hoc template for Ad-Hoc conference. Select the IP addresses that you just created. One will be used for Ad-Hoc, the other for Rendezvous. Under Trunk 1, type the IP of the CUCM server. Since we are using TCP for the protocol, the port number does not matter. Save
- One of the other items I missed when setting this up initially was Conference Aliases. These are used to setup Rendezvous Conferences by simply dialing a pattern and appending the conference number. Let’s say the incoming alias we create is (850….)@.* this would mean that anyone who dials 8501234 would create a conference at that number. It allows users who want to plan a meeting at a certain time to give that number out to the participants and have them dial in. Hence, Rendezvous.
- That just about does it for Conductor. Next item up to bat is the CUCM configuration. Since this post assumes you have a working CUCM, we will start by configuring two additional SIP trunks. The first will be our Ad-Hoc. Next will be the Rendezvous. Overall, setup of these trunks is fairly straight forward with the exception of the screenshot below. For additional help configuration trunks, check out this guide.
- After the SIP trunks have been created, we need to create a Route Pattern to route calls destined for 850XXXX out the proper trunk, i.e. the Rendezvous SIP trunk. In CUCM, select Call Routing>Route/Hunt>Route Pattern. The screenshot below tells us that any devices in PT-CH-Internal that dial 850XXXX will get routed out the Rendezvous_Meeting SIP trunk, which of course, is one of the IPs on Conductor. From there, Conductor will take that as “Oh hey, this device wants me to create a conference!”. Remember our Conference Alias we created? This is where it gets used.
- Last but not least, we need to create a Conference Bridge and add the bridge to an MRG that the endpoints are using. Under Media Resources>Conference Bridges select Add New. The SIP trunk will be the Ad-Hoc trunk you created in the step above. The username will be an administrator user. For our setup I created a user on Conductor called “conductor” and assigned it admin privileges.
- Under Media Resources>Media Resource Groups, select either a new or existing MRG. Typically, creating a new MRG, adding the MRG to an MRGL and then assigning the MRG to the device is the way to go. Under Available Media Resources, select the new created Conference Bridge and click the ^ arrow to push it to Selected Media Resources. We called ours Conductor_AdHoc but obviously yours will differ.
- As I mentioned above, we will be using an SX-20, Jabber for Mac, and Jabber for Windows applications to test conferencing both Ad-Hoc and Rendezvous. Since writing about a verifying video is boring, we would rather just show you! In our test, the SX-20 being used in the Conference room has already dialed into the 8501234 Conference. We are simply just joining in.
- Jason Murray- CCIE Collaboration at Cisco