Cisco Spark Hybrid Services – Call Service Connect Deployment


Undoubtedly we’ve all heard about Cisco Spark over the past year. Lumped in between the cloud and the cloud’s cloud, there is a component referred to as Hybrid Services. Hybrid Service is summed up as multiple components designed to bridge the preverbal gap between the Cisco Collaboration Cloud and your On-Prem UC (Unified Communications) infrastructure. For some of us, migrating to the cloud may not be an option for quite some time, if ever. Designed to introduce the customer to Cisco’s Cloud offerings, Hybrid Services aims to highlight the benefit of having a unified experience for all collaboration applications. This article is aimed at the engineer looking to deploy the Call Service Connect feature into their companies infrastructure, all the while helping us see a world that is Jabber-free. For instance, If I receive an incoming call on my 10 digit DID (Office number), Call Service Connect will allow me to receive that same incoming call through Cisco Spark on any of my mobile devices. Pretty cool, right? Likewise, outgoing calls to the PSTN are also routed out of your company’s gateway via SIP Trunk or PRI.


Let’s make a few assumptions. The first being that you have a working CUCM (Cisco Unified Communications Manager) and the second being that you have read our deployment guide for Expressway located here and here, respectively. Strap yourselves in, it’s a two parter. Satisfying those requirements will help immensely with the configuration and troubleshooting in the next few sections.

The below diagram depicts what the Call Connector will look like in your environment.Screenshot 2016-08-15 12.56.21.png

Its important to note that you MUST and I mean MUST be running Expressway 8.7.1 or higher on your Expressway-C. The image below was taken directly from the deployment guide. Certain pieces will work on 8.7, but the guide specifically mentions that in order to take “full advantage” of the feature, you need 8.7.1. In addition, CUCM MUST be chugging along at 10.5(2)SU3. The guide(s) I used from Cisco are here and here.

Screenshot 2016-08-15 13.12.29.png


Let’s start by agreeing CUCM and Expressway meet the version requirements for this to work. k? cool. Next let’s make sure we have DNS working as it should. Below you’ll see our SRV record we use. The Spark application uses this to route calls destined for your CUCM infrastructure to the correct host. Spark does an SRV lookup for the protocol sips using tcp as the transport protocol and sipmtls as the subdomain for this domain. In our case, we weight this record at 1 (lower value is more preferred) and priority at 10 (only relevant if we have more than one SRV record). The port we tell it to use is 5062 (Mutual TLS) and the target is our Expressway-E ( Like B2B or MRA, this uses the same protocol with the exception of us having it use 5062 instead of 5061. If you are using 5061 for MRA today, changing the MTLS port will break connectivity.

➜ ~ nslookup
> set type=SRV

Non-authoritative answer: service = 1 10 5062

Since we just declared that Cisco Spark should use 5062 on all inbound connections to our Expressway-E, we need to tell Expressway-E that. Below are our SIP settings. Ensure you have Mutual TLS mode set to On and its using 5062 as its Mutual TLS port.

Screenshot 2016-08-15 13.52.24.png


Once DNS is verified and the Expressway-E knows that port to use for MTLS, let’s hop over to CCM (Cisco Cloud Collaboration Management). From there, navigate to Services, Hybrid Call; Settings. Scroll down to the bottom and enable Connect. Under SIP Destination, enter in yourdomain will be the external DNS zone you used for your SRV entry above. This step ensures calls destined for your org make it to your Expressway-E. It does this by doing an SRV lookup against the sipmtls service offered by Another item involving DNS you will want to take care of while you’re here is Aware. Most notably, Aware makes Spark “aware” of all calls across your UC system enabling Spark to view recent call history. To verify your domain as a valid domain for your org, click Add Domain.

Screenshot 2016-08-15 13.57.59.pngScreenshot 2016-08-15 14.00.13.png

Enter in the domain you wish to add. After submission, the domain will go into a Pending state. Select Verify. In order for Cisco to verify you own that domain, it forces you to manually add a TXT record to your domain’s external DNS zone file. Simply go to your external DNS manager and create a new TXT record with the string below. This string will be unique to each domain.

Screenshot 2016-08-15 14.10.02.png

To verify, let’s look at our external DNS zone to ensure it created the record. For obvious reasons, we can not verify since we don’t own it. Instead, we will use

➜ ~ nslookup
> set type=TXT

Non-authoritative answer: text = “7744b423ac3a7d45bb83103d9a645168f3e3db5d9e52880f197e6638c7eefa3c”


Once DNS is configured and we’ve verified that inbound Spark calls to our org will route to the correct place, we need to head over to our Expressway-C and configure the CUCM integration. From Application>Hybrid Services>Call Service select New and add the CUCM IP address. Select Verify CredentialsNOTE: This user must have AXL and CTI access permissions. 

Screenshot 2016-08-16 13.00.31.png

Once verified, the status on both CTI and AXL will change to up. If you run into issue with this part, verify application user permissions for the account you used, as well as the AXL Web Service. Ensure it is running.

Screenshot 2016-08-16 13.04.27.png

Once added, navigate to Application>Hybrid Services>Call Connector and toggle the Active radio button to Enabled. This will start the Call Connector.

Screenshot 2016-08-16 13.49.15.png

Now that we’ve enabled the Expressway-C, we need to start work on how we’re going to place and receive calls. As depicted by the diagram, the call originates from the endpoint signaling CUCM where the destination is. As we can see, both outbound and inbound calls traverse the Expressway-C and E through the Unified Communications traversal zone. Outbound calls from CUCM to URIs will look at the SIP Route Pattern. In our lab, we are using * to default route any domain not matching a specific one to the trunk towards the Expressway-C. As this is a lab, we ensure that all domains listed as a destination in a SIP header get routed. The official guide will have you use * as your SIP route pattern. Screenshot 2016-08-16 13.59.50.png

Once the destination is matched to a SIP route pattern, it routes to the Expressway-C.

Screenshot 2016-08-16 14.22.01.png

The Expressway-C then looks at its Search Rules and determines the best match for the destination to route the call. In our case, we again have a default rule to send anything not matching a specific domain towards the Expressway-E. We do this because during the selection process, it queries its local zone for the destination. As the destination * doesn’t match any of the URIs on CUCM, it knows to send it on. Below is our rule we use to match.

Screenshot 2016-08-16 14.07.21.png

In our case, the TraversalZone is the Neighbor Zone to the Expressway-E. As this call enters the Expressway-E, it looks at its search rule to find where to go next. As you see by our outbound search rule towards CCM, we see it is matching any pattern string that contains and routing it out the DNS Zone Cisco Spark Hybrid ServicesScreenshot 2016-08-16 14.34.39.png

The Cisco Spark Hybrid Services DNS zone then makes a determination on where to send the call based on the configuration we have listed below. This configuration is similar to default DNS zone you most likely have on your Expressway-E with the exception of isolating the destination to look for. As this is a MTLS connection, we want to ensure TLS Verify mode is set to On as well as including the TLS Subject Verify Name of This ensures that all routes routed to this domain are encrypted using TLS.


Thats outbound. Let’s work on getting inbound calls. Since we have already completed the requisite steps above when we first started, all we need to do is ensure users have a Spark Remote CTI device in CUCM. Under your Unified CM Server setting on your Expressway-C there is an option for your Call Service Connect Configuration. For our lab, we opted for automatic provisioning. If you have thousands of devices, manual import may be better. Once you’ve done that, you will need to go into CCM and enable Connect for the users you want Call Service Connect enabled for. Toggle the switch to On and restart the Call Connector on the Expressway-C.

Screenshot 2016-08-16 14.52.38.png

Almost there. After Call Connector restarts, you should now see the Onboarded Users change to reflect the number of users you enabled for Call Service Connect.


Screenshot 2016-08-16 14.54.37.png

To verify, check CUCM to see the automatically provisioned device.

Screenshot 2016-08-16 15.01.02.png

From the Spark cloud, we can now work through getting calls inbound to our remote CTI device (Cisco Spark application). Caller A initiates a call to Caller B via their PSTN number (7048675309). Caller B will receive an inbound call to that PSTN number through the Spark application. It does this by matching inbound URI destinations. For example, when the Expressway-E receives a call, its destination will look like this:;user=phone

Our Expressway-E has a Search Rule targeting the Traversal Zone. This is directing all incoming URI destinations towards the Expressway-C. Screenshot 2016-08-16 15.11.20.png

Once our Expressway-C receives the SIP packet from the Expressway-E, it then looks where to route calls with the destination;user=phone. As you can see by the below figure, its matching any destination with the;user=phone suffix. The target destination to route this call is CUCM Neighbor. In this case, that is our CUCM. Screenshot 2016-08-16 15.17.13.png

One of the most time time consuming parts in all of this was the last part. I was able to get calls outbound and inbound but CM traces showed me that once the Expressway-C sent the calls to CUCM, it was stripping everything but 4 digits. If you are a victim of this nonsense, make sure to check the incoming allowed digits on the SIP trunk connecting CUCM to Expressway-C.

Screenshot 2016-08-16 15.19.28.png

We hope this guide can provide benefit in configuring Cisco Spark Hybrid Services for your organization. For any revisions, questions, or comments, feel free to contact myself directly (through Spark obviously) or drop a comment below.

2016-08-16 15.30.05.png


Tropo Log Tailing

Working with Tropo’s scripting API is a quick and easy way to get great call and SMS functionality into your applications. But while building with the scripting API is great, debugging your code can be very frustrating.

Currently, to get a peek into what’s happening on Tropo’s end, you need to download your logs from their application manager on These log files can grow very large (over 100MB) and load very slowly in their in-app editor. It’s also highly difficult to parse through the logs to find information that is relavent to what you are doing at that moment.

Most apps today have great real-time logging, like Ruby on Rails which lets you dig into the details of your app and see it executed in real-time. To bring this kind of experience to Tropo development, I’ve created the tropo_tail gem.

Tropo Tail Gem

To install, from your terminal or command prompt, type:

gem install tropo_tail

Installing this gem will give you access to the


command. Upon running it will ask you for your Tropo username and password. This is to login to Tropo’s FTP server. The gem will then feed the log file as it is generated on Tropo’s servers to your terminal in realtime!

You’ll notice that Tropo’s logs come with a lot of information, sometimes too much. To help with this during development you can use a flag:

tropo_tail --truncate

This will cut off a large portion of Tropo information such as the application ID and session ID, and let you see Tropo’s output and a timestamp.

In addition to helping debug issues with the scripting API, this will work for any Tropo applications including those using the webAPI to help get an inside track into what’s going on behind the scenes and help you develop higher quality apps in no time at all!


How to Click To Call Back With Tropo and Ruby on Rails

In this post, we’re going to build on our previous work on number masking. Let’s say you’ve created a mask for your number and someone called that mask. Now you want to call that person back. How do you do so without revealing your actual number?

Here’s how. Once again, we’ll be focusing on the Tropo back-end side of things.



  1. Create a model for saving call history.
  2. Create a view that shows this history and allows you to click on a number, triggering call_back
  3. Have Tropo call you and add you to a unique conference
  4. Have Tropo call the other person and add them to the same conference


Reminder: number is your actual phone number, while a mask is the phone number that is made publicly available. Calls to the mask get transferred to your actual number, keeping it anonymous.


Create a model for saving call history and a view for triggering the call back

We want to keep track of all calls made to a mask. To achieve this, we create an inbound_calls model that stores the number of the person calling and the time that the person called. An inbound_call belongs to a mask, which allows us to also keep track of the mask that was called and the number associated with that mask. Remember from our previous blog that a mask belongs to a number. 

Here is example code that stores an inbound call before making the transfer.

def transfer

    from = params[:session][:from][:id]
    to = params[:session][:to][:id]
    timestamp = params[:session][:timestamp]

    mask = Mask.find_by mask: Phonelib.parse(to).e164
    number = mask.number.phone_number

    inbound_call = from, mask: mask, time: timestamp)
    if ! 
        puts "Creating inbound call failed: #{inbound_call.errors.to_json}"

    t =  
    t.transfer(:to => number, :from => from)

    render :json => (t.response)


Note that Tropo provides the timestamp of the call in the session timestamp parameter. Here is an example view for triggering the call backs.




Have Tropo call and add people to a conference

def call_back(from, mask, number)
    conference_id = from.to_s + mask.to_s + rand(1000).to_s
    tell_tropo_to_invite_to_conference(conference_id, from, mask)
    tell_tropo_to_invite_to_conference(conference_id, number, mask)
def tell_tropo_to_invite_to_conference(conference_id, to, from) 
    tropo_params = {action: "create", conference_id: conference_id, to: to, from: from, token: token} 
    response = tell_tropo(tropo_params) 
    if response.code === '200' 
        puts "successfully invited #{to}" 
        puts "error: #{response.body}" 

def invite_to_conference 
    from = params[:session][:parameters][:from] 
    to = params[:session][:parameters][:to] 
    conference_id = params[:session][:parameters][:conference_id] 
    puts "Inviting #{to} to conference #{conference_id} with callerid #{from}" 

    t = to, from: from) 
    t.conference({ name: conference_id, id: conference_id}) 

    render json: t.response 

def tell_tropo(tropo_params) 
    uri = URI.parse('')   
    uri.query = URI.encode_www_form( tropo_params ) 
    http =, uri.port) 
    http.use_ssl = (uri.scheme == "https") 
    request = 
    return http.request(request) 

These methods are in the controller. The call_back method starts the whole process. The from is the number of the person we’re calling back. The mask is the mask that the person called. And the number is the number associated with the mask, i.e., your number. We will use the conference_id to invite people to the conference. We create a unique conference_id each time the call_back method is ran, or else every one will be added to the same conference.

The tell_tropo_to_invite_to_conference method tells Tropo to start the Tropo application that we created for inviting people to conferences. The script link we provided in that app points to our invite_to_conference method. The invite_to_conference method calls in a person to the conference_id provided. We pass the conference_id and other parameters to the invite_to_conference method by including the parameters as part of the query. We then access these parameters in the invite_to_conference method via params[:session][:parameters]. Notice that when calling the other person, the callerId is set to the mask, keeping your number anonymous 🙂

The tell_tropo method simply makes a GET request to Tropo with the query parameters that are passed in.

Here are the Tropo docs for making a call, setting up a conference, and passing parameters:


And that’s it! You can now call back people without revealing your phone number.



I’ve put together a collection of Ruby scripts for preparing exported CSV files from CUCM 7.x to import into CUCM 10.x and above. Download them here.


When migrating configurations between CUCM 7.x and CUCM 10.x and above, a typical task involves using the Bulk Administration system to export phones and configurations as CSV files. One of the issues with importing these CSV files directly into CUCM 10.x is that there are many headers in the 7.x CSV file format that aren’t supported in CUCM 10.x and will cause a failed import. These files will help to clean up the exported CSV files as well as provide some basic filtering functionality to limit the import to certain users and phones (as the CSV files can be very large sometimes they can be difficult to work with in Excel). Before importing any files be sure that your new CUCM system has all referenced dependencies configured (device pools, partititions, etc) or the import will fail.


From your 7.x Cisco Unified CM Administration page, navigate to Bulk Administration > Phones > Export Phones > All Details. Select “All Phone Types”, add a name for your export, select “Run Immediately”, and then click “Submit”. Next go to Bulk Administration > Users > Export Users. Click “Find” to pull up all user accounts, and then click Next. Input a file name and select “All User Format” for the file format. Select “Run Immediately” and then click “Submit”. Both of these export jobs can be viewed in Bulk Administration > Job Scheduler and, once completed, can be downloaded from Bulk Administration > Upload/Download Files. After downloading rename the files from .txt to .csv and place them in the CiscoCSVToolkit folder.

Replace the importfile variable in the stripbadcolumns.rb script to match your exported phone CSV file. Next run the script from a command line (ruby stripbadcolumns.rb). It may take a little while to run. This will save a file called “forimport.csv” that you can upload to your 10.x system and run using Bulk Administration > Phones > Insert Phones.

If necessary you can use the filterbydevicepool.rb script on your forimport.csv file to limit which phones you want to import by device pool. You can also use the filteruserbypartition.rb script to filter your exported user CSV file by the primary extension’s partition.


Prime Collaboration 11.x Review – Part 1 – Deployment


The Prime Collaboration Suite from Cisco consists of three components – Deployment, Provisioning, and Assurance. When these products were first released I didn’t hear a lot of good things about them (sorry Cisco), so I avoided them with most of my deployments. That said, it looks like Cisco has made a lot of updates in the last release and I wanted to get an unbiased review of each of these three products and if they are worth using in my upcoming projects. Prime Collaboration Standard is included with CUWL licensing since version 10.x – so if you have CUCM 10.x and higher, you can use these products. You can’t beat free, right?

This will be the first of three blog posts, each one focusing on one of the Prime Collaboration products. I’ll cover some Frequently Asked Questions, an overview of the benefits and drawbacks of using each product, and my experiences using it in the lab and in customer environments.

What is Prime Collaboration Deployment?

Prime Collaboration Deployment (or PCD) is meant to help manage installations, upgrades and migrations on to VMWare ESXi platforms. Cisco’s intention with these products seems to be making it easier for customer IT departments to manage Collaboration implementations once they are up and running, but it also can make some tasks much easier for partner consultants to initially set things up. Some of these things it does really well and can save you a lot of time, and some of these things may only be beneficial in certain situations. I’ll give my overall review and feedback of each function below.

How Do I Install PCD?

All Prime Collaboration images come preinstalled with any BE6k or BE7k installation, which can save some time with initial installs. In fact, Cisco has a new Config To Order Portal (CTOP) that lets you preconfigure a BE6k during the ordering process with IP addresses so it comes ready to go! Check out for more information on this.

If you aren’t using a BE6k or need to install it from scratch the process is very similar to setting up a CUCM or other VM based UC server. Simply deploy the OVA and then mount the bootable ISO image and boot the VM. Sadly the bootable ISO image is not available from CCO, so contact your Cisco account rep if you need to get a copy of the bootable version. Non bootable upgrade images and OVA templates are available here.

One thing to note that I learned the hard way – do not change the IP address of the PCD server after installation. It will seem to work fine and load the admin page, but most tasks will fail without any helpful error messages. If you do have to change the IP, just reinstall the server. I would also recommend disabling LRO on any ESXi blade before running your VM install tasks to reduce failures due to time of installation.

What Licensing Is Required?

To me this is one of the really dumb things about PCD – the normal license that you would get from Cisco for ESXi does not actually support the VMWare features that you need to use PCD. During the initial 60 day evaluation period for ESXi all features are enabled, so you could use PCD during that time, but once you apply the license you would normally get with a BE6k or BE7k type server you can no longer mount the NFS stores from PCD. To me PCD should not only be for initial deployment of images but also for managing the system after that point for patches. If you want to do this be sure to purchase the higher license type. From the documentation:

The following are compatible with Cisco Prime Collaboration Deployment:

  • Cisco UC Virtualization Foundation (appears as “Foundation Edition” in vSphere Client)
  • VMware vSphere Standard Edition, Enterprise Edition, or Enterprise Plus Edition
  • Evaluation mode license

The following are not compatible with Cisco Prime Collaboration Deployment:

  • Cisco UC Virtualization Hypervisor (appears as “Hypervisor Edition” in vSphere Client)
  • VMware vSphere Hypervisor Edition

New Installations – 6/10

PCD can potentially save you some time in the initial deployment of UCM, CUC, and IM&P servers onto ESXi blades. Especially if you have a lot of servers to deploy. That said, I had issues deploying IM&P and couldn’t get an installation to successfully complete (this may have been related to an issue with my ESXi server, but I couldn’t get it to work after multiple attempts). It seems to take a lot longer than doing the installations manually, and on failed attempts it takes a long time to know that things failed, and the information provided isn’t as useful as it could be. I would like to see Cisco add diagnostic dump file information to failed installs automatically to assist in troubleshooting when this happens. Also once an install task starts running it is impossible to cancel it.

The process is pretty straightforward to get new installations running:

  1. Log in to the web interface using “globaladmin” account.
  2. Upload all bootable ISO images to the built in SFTP server in PCD under the /fresh_install folder. Note that you have to use the adminsftp account to connect to SFTP, which uses the same password as the globaladmin account you used on setup. PCD lets you set up external SFTP servers, but it doesn’t seem like you can use these for much of anything, so stick to the built in server for images and other ISOs.
  3. From your vSphere client, deploy the OVA templates for servers you want to install on your ESXi server but don’t start them or mount any ISO images.
  4. Set up all UC server records in DNS ahead of time. This will save you time in failed installs.
  5. Add your ESXi blades in PCD under Inventory > ESXi Hosts. This lets PCD use NFS to mount ISOs and manage the VMs on the server.
  6. Add your UC servers that you want to install under Inventory > Clusters. You can’t group CUC together with UCM and IM&P, so set up one cluster for UCM/IM&P and one for CUC. Be sure to select the “Publisher” task under both your UCM Publisher and also your IM&P primary server (this was a bit unintuitive for me at least). I have no idea why “Primary Voicemail” is an option for the server role in CUCM, so I didn’t check that box.
  7. Set up your install tasks under Tasks > Install. PCD will search the local datastore for the ISO image appropriate to your deployed OVA template. PCD will complete UCM publisher install tasks before running subscriber installs or IM&P, and it seems to add your server references to UCM for you, so you don’t need to do any of that.
  8. Expect to wait a while (6-8 hours potentially) for your install tasks to come back and say they are complete. As I mentioned, this is a bit slower than doing things manually, but the installations are completely unattended so you don’t have to sit there and enter any information or watch reboots. Which is nice.

Upgrades – 7/10

Upgrade tasks are pretty easy, whether it’s installing a patch or adding a locale file. Simply add the files to the /upgrade folder using SFTP and add a new upgrade task under Task > Upgrade. I can’t speak for doing major version upgrades using this feature, but doing minor release patches was very easy. I also like the capability of scheduling upgrades for later (such as during your maintenance window), and the option to reboot back into the same version you were running before. This would allow you to complete your upgrade but wait until a later maintenance window to actually make the upgrade live.

Migrations – 8/10

This is really where PCD might let you do things that there is just no clean way to do otherwise. I have recently had a few projects where I had to move a customer from UCM 7.x to 10.5 and had to do a lot of painful editing of CSV files to export/import configurations – and still had to do a lot of manual configuration on top of that because Import/Export just wouldn’t work. I now wish I had used PCD migration for these. That said, this function is only available during a fresh install – you can’t migrate configurations onto an already installed cluster. Also note that you can only do migration tasks for the last 3 versions of UCM, so if you installed PCD 11 and wanted to migrate from UC 7 this would not be possible (but would be if you were using PCD 10).

You can also use this task to migrate UCM running on non VM servers onto ESXi for the same version, and then upgrade to new versions on the ESXi servers. Or you can readdress servers, which is a common step during these sorts of projects.

I haven’t used the migration tasks for production customers yet, so when I do I will come back and update my review, but based on what I’ve seen so far I would definitely recommend using PCD for these sorts of projects, and will be doing so myself in the future.



Connect to console using Terminal on OSX

For longer than I  can remember, I’ve used SecureCRT for all of my console needs. By far, the easiest and most intuitive application for ssh/telnet/console. With that said, we’ve all at one time or another been in a situation where we had to make due with what we had. Recently, I did an upgrade of OSX rendering my SecureCRT unable to open. After countless reboots, it came back to life. This got me thinking…..What would I do without SecureCRT? I’ll tell you. Use my Mac in all its glory to achieve the same goal. This is where I am today. Connecting to the console using terminal.

  • Open ‘’ on your Mac running OSX . Yours should look similar to this.

Screenshot 2016-01-20 14.00.57.png

  • Change your working directory to /dev by entering the command below. You should see your working directory change.

Screenshot 2016-01-20 14.03.04.png

  • Next, we’re going to make sure our USB to DB9 adapter is plugged in by issuing the command below. This command tells to return any lines that match usb. As you can see, I have two devices available. Most commonly, yours will be cu.usbserial.

Screenshot 2016-01-20 14.08.23.png

  • Now that we’ve verified we can see the adapter, time to connect. Issue the screen command followed by the full path of the device, plus the baud rate. In most cases, 9600 baud rate will work fine, especially if it is a newer Cisco device. This number is issued as a command line argument after specifying the full path of the device. See example below.

Screenshot 2016-01-20 14.13.17.png

  • Press Return/Enter to connect.
  • As you can see, the tab has now changed to screen. This is because we are now in the application window. NOTE: Control+C will not work here. To exit the screen application, issue CTRL+A then CTRL+\ You will be prompted “Are you sure?.” Of course you are. type and then enter. This will drop you back into working directory you were in before.

Screenshot 2016-01-20 14.15.34.png


We hope this helps a few of you out there who, like me, struggled with finding an alternative to ol’ trusty SecureCRT. Let us know if this has saved you once or twice…or if this is your daily routing by dropping a comment below!


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!

The Ingredients

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
  • SX-20
  • 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


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.

Telepresence Conductor

  1. 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.
  2. After an IP has been assigned, navigate to the GUI https://<IP&gt; 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)

  1. 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 to the TelePresence Server, with subnet mask and default gateway Obviously your environment may differ so change the IPs accordingly.


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 UserScreenshot 2016-01-04 09.36.03.pngCreate 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.

  1. 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).Screenshot 2016-01-04 13.50.19.png
  2. Once added, you should see the image below indicated communication between the conductor and vTS is successfulScreenshot 2016-01-04 10.11.29.png
  3. 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 SaveScreenshot 2016-01-04 10.08.56.png
  4. Give it a name and select Create Conference Bridge
  5. Navigate to the IP of your Conductor. Go to Conference Configuration>Conference Bridge Pools>New. Create new bridgeScreenshot 2016-01-04 09.43.21.png
  6. 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.Screenshot 2016-01-04 13.52.17.pngScreenshot 2016-01-04 13.52.51.png
  7. 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. SaveScreenshot 2016-01-04 13.56.11.png
  8. 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. Screenshot 2016-01-04 14.08.59.png
  9. 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.Screenshot 2016-01-04 14.28.20.png
  10. 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. Screenshot 2016-01-04 14.35.18.png
  11. 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. Screenshot 2016-01-04 14.43.59.pngScreenshot 2016-01-04 14.41.04.png
  12. 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.


Special Thanks

  • Jason Murray- CCIE Collaboration at Cisco

Deploying Conductor and Telepresence