Deploying Cisco Collaboration Edge – Updated


Collab Edge is now supported.  The official Mobile-Remote-Access-via-Expressway-Deployment-Guide is located here.

I’m updating this document to reflect changes made in Expressway-C/E 8.1 that make importing the certificates MUCH easier.


This document explains how to deploy Collaboration Edge with on-prem presence (IM&P/CUP) on a non-redundant set of Expressway-E and C VMs.  Deploying with WebEx Messenger is not covered here, but the bulk of the configuration is the same as far as the Expressway piece.

The biggest challenge in the initial deployment was finding all of the necessary documentation!  Things you need to know like certificate chaining, or OpenSSL are in various docs.  I’ve linked all of the documents that I used and tried to summarize things to make it quicker to deploy.

What you’ll need to deploy Collaboration Edge today:

  • CUCM 9.1(2)+
  • IM&P (CUP) 9.1+
  • VCS or “Expressway” X8.1.1+
  • A Collaboration Edge enabled Jabber client:  Cisco Jabber for Windows 9.7+, Cisco Jabber for iOS 9.6, Jabber for Android 9.6+ or Cisco Jabber for MAC 9.6+
  • Updated jabber-config.xml on CUCM with RemoteAccess turned on  (This is no longer required for Jabber 9.6+)
  • Two certificates (one for VCSe another for VCSc) – either signed by your own CA (OpenSSL or similar) or  publically signed certs like GoDaddy, Verisign, etc.

A few notes about nomenclature:

Collaboration Edge is the architecture umbrella term for the VCS/Expressway edge proxy for CUCM-registered clients (Jabber  and TC7.0 TP units).  It’s commonly used to refer to the Jabber piece of it, but will support endpoints too.  (The DX650 will support Collaboration Edge in a future release of firmware.  Traditional IP phones will not be supported, they will use VPN Phone or CUBE lineside proxy.)

Mobile and Remote Access (MRA) is the term used in VCS/Expressway documentation for the VPN-less Jabber (and CUCM-registered TC7.0 endpoint) proxy feature.

Cisco Expressway-Edge is the same software as VCS-Expressway, just packaged for CUCM registered endpoints.  Expressway-Edge is a VCS-Expressway that is deployed as a Mobile and Remote Access proxy or for traversal calls for CUCM registered endpoints.  There is a license file actually changes the title to say “Expressway-E” when it is loaded.  In the rest of the document, I will refer to VCS-Expressway, VCS-E, Expressway-Edge, Expressway-E as Expressway-E since we are primarily talking about MRA.

Expressway-Core is the same story.  It is VCS-Control software deployed as an MRA proxy only with the Expressway-C license loaded.  We call it VCS-Control when it is licensed for device registration, non-traversal calls, FindMe, and other features like Lync interop.  For purposes of this document I’ll call it the Expressway-C below.

Customers with a valid UCSS contract for UCL-Enhanced, CUWL-STD, or CUWL-PRO are entitled to Expressway-Edge and Expressway-Core for free (for MRA) and their license will reflect the Expressway names.  Licenses are charged for the other VCS features mentioned above.  Licenses are required and have a cost for B2B/B2C (Jabber Guest) calls through Expressway-C/E  Each box requires one media session license to get a session through.

VCS-C and VCS-E can have the MRA features turned on and run on a pair and do both functions.  We are still awaiting clarification as to when you must break these apart and run a separate set of VCS (for B2B, interop) and Expressway (for MRA) servers.  (Update:  VCS is supported for limited sized deployments.)

Expressway licenses should be orderable via PUT, or you can use your existing VCS severs by upgrading to X8.1.  (Update: I posted a later post that discusses what to order.)

Prepare CUCM for MRA

1) Create an AXL user if you don’t already have one on CUCM and IM&P.  There’s a good guide here –

2) Decide if you want to deploy valid security certificates on CUCM, IM&P and CUC.  You will likely want to do this independent of Collaboration Edge as all of the Jabber clients are no longer trusting self-signed certificates.  By providing a publicly trusted cert, Jabber won’t throw Invalid Certificate errors as you log in.  Granted they are only shown once during the very first login if the user accepts them on each client.  If you do put certificates on those components I’d suggest getting them for a 5-year term so you aren’t dealing with it in a year when the certificates expire.

Directory Lookup Considerations


MRA only supports UDS as the directory lookup service.  If you are inside you can use LDAP (EDI/BDI), outside UDS.

Jabber-config.xml Update for 9.6 clients

Update:  This section is no longer required as current versions of the clients (Win 9.7, iOS 9.6.1, Android 9.6, OS X 9.6) to do MRA by default, negating the requirement to pull the jabber-config.xml file first (expect in the case of split internal/external domains).

CUCM UC Service Profiles

Make sure that you’ve configure CUCM UC Service Profiles (this should have been done as part of your initial IM&P/CUP deployment and won’t be covered here) and assigned them to the end users.

Deploy Expressway OVAs

For new installations, you’ll need to download and deploy OVAs – – See my previous post about upgrading to X8.1 if you’ve already got VCS installed – here

Recall there is a single OVA that does both Expressway-E/C and VCS-E/C that you need to deploy — it’s just a matter of how you configure and license (request via PUT as mentioned above) it as to what it is called.  Download the OVA from Cisco here

You’ll deploy the Expressway-C on your internal network (presumably on the same VLAN as CUCM and other UC components)  e.g.

You’ll deploy Expressway-E one of two ways.  Either on a stick in your DMZ (perhaps, or two-legged with the external interface in the DMZ network (e.g. – or on your public address space), and the internal interface on the internal network (presumably on the same VLAN as Expressway-C and other UC components – e.g.

You’ll need to trunk your DMZ to your ESXi host if you haven’t, or figure out how to deal with getting the Expressway-E external  (LAN2) interface in the DMZ network.

Once the VM’s are deployed edit the Expressway-E VM settings to put LAN2 in the DMZ network (alternately you can put LAN2 on the inside and LAN1 in the DMZ).  If you don’t see options for the second NIC, or options for NAT, you are missing the Advanced Networking license.  You need this in order to have it two legged, or do NAT.

Firewall Configuration

I don’t know how long I wasted on my first install because I forgot to modify the ACL to include the additonal ports that MRA requires.  I just assumed that beause VCS was working for B2B that it would work for MRA.  Not the case!

You’ll need to configure NAT on your firewall from a public IP address outside your network to the DMZ address of Expressway-E, or do 1:1 public to your DMZ if you’ve deployed it with a public address.

Look at p.258 of the Expressway Admin Guide for a concise list of ports.


A couple notes about DNS records

You will need two DNS servers for MRA to function properly.  Jabber decides if it is inside the network or outside the network depending on what SRV records it can resolve.  Depending on what records it resolves it will either try to use MRA or it will directly connect to CUCM/IM&P.

Internal DNS Server

Create two A records:

  • A – (make this name whatever you want) Pointing to the INSIDE interface of Expressway-E for two-legged deployments, or pointing to the DMZ address if it’s on a stick.  The record is used by Expressway-C to lookup and validate the certificate against.  You will use this hostname anywhere you are asked for the expressway server’s name whe configuring the C server.
  • A – (any name you want) Pointing to Expressway-C.

Create two SRV records:

  • SRV 0 0 port 8443 – Pointing to CUCM.  (NOT IM&P!)
  • SRV 0 0 port 8443 – Pointing to IM&P  (TBD if this is really required for Jabber 9.6 with IM&P 9.1 – I don’t believe it actually is)

When you launch Jabber, if it can resolve these DNS records, it knows it’s inside and pulls the service profile directly from CUCM and logs in to IM&P and CUCM.

External DNS Server

Create one A record:

  • A – (any name you want) Pointing to the public address assigned (or NATted) to your Expressway-E.

Create one SRV record:

  • SRV 0 0 8443 – Pointing to Expressway-E (in our case

Configure Expressway-Edge and Expressway-Core

Follow this chapter of the Expressway Admin Guide  – Mobile and Remote Access (feature preview) beginning at p.52 but stop half-way down p.56 (before the beginning of the Certificates section).

A couple notes:  I did not enable TLS verify mode on my CUCM and IM&P server definitions because just wanted to get it up and running.  I’m suggesting putting real certs on CUCM, IM&P, and CUC, and turning TLS verify on, but this can be done later.

The admin guide is located here (p.52-56):


Valid CA-signed certificates are required to setup the traversal zone for MRA.  You can either get public ones, or sign your own with your own CA.  I’ve done it both ways.  The major reason for a valid trusted CA-signed certificate is to stop Jabber from throwing a certificate warning on the initial MRA login to Expressway-E itself.  I highly recommend deploying a publicly trusted CA signed certificate.

Update:  This is fixed in Expressway 8.1.1  Ignore this section below:

Deprecated instructions for VCS 7.x:   The best document out there is this WebEx enabled Telepresence VCS Config document that describes how to chain up the intermediate cert properly here –

When importing the CA trusted certs, the key is to make sure the intermediate cert appears in the CA trust list ABOVE the root cert.


Expressway 8.1 Certificates

You will need to get a specific type of certificate, the multi-SAN (subject alternative names) also called a UCC certificate). 

Expressway-C CSR will be generated with the IM&P, and CUCM SANs.

Expressway-E needs the server itself and domain only as a SAN.

See the Expressway Certificate Guide for detailed information.

For Expressway-E follow this basic flow:

  1. Generate CSR
  2. Add UC Domain ( and XMPP server information
  3. Download the CSR
  4. Upoad the CSR file to the CA to get the certificate signed
  5. Get the signed server PEM and the root/intermediate chain PEM back from the CA.
  6. Upload the signed server cert to Expressway-E under Maintenance | Security Certificates | Server Certificate
  7. Break apart the CA-intermediate-root certificates into individual PEMs for import – See the WebEX instruction for VCS 8.1 to learn how to do this.
  8. Import into the Trusted CA certificate list: the top-level cert (“CA”), then the root cert, then the intermediate cert found under Maintenance | Security Certificates | Trusted CA Certificates
  9. Reboot to make them active.

Follow the Webex instructions to break apart the CA-intermediate and root PEM into individual certs using Windows so that you can import them into the CA trusted cert list properly.

Repeat this procedure for Expressway-C.

For the customers that I’ve worked with using GoDaddy certificates.  I’ve worked with four certificates – Go Daddy Class 2 CA; Go Daddy Root Certificate Authority – G2; Go Daddy Secure Certificate Authority – G2; the server certificate itself.

I used Chrome on Windows to export the three Go Daddy certificates individually to Base 64 .PEM and then loaded them into the Expressway-E/C trusted CA list.  This worked perfectly for me after loading and rebooting the servers.  The UC traversal zones came right up.


Sign your own using OpenSSL if you’d like

If you want to use OpenSSL to create your own CA cert and sign your CSR, it is actually easier than you’d think.

Start at the bottom of p.13 of this document –

Click to access Cisco-VCS-Certificate-Creation-and-Use-Deployment-Guide-X8-1.pdf

You’ll follow the procedure twice.  Once for Expressway-E and once for Expressway-C.  Take the CA root cert that you generated and import it into the trusted list on both boxes, and then import your signed server cert on the appropriate box.

Traversal Zone Configuration

Resume the configuration tasks in the Admin guide on p.58 making sure to put the proper settings for both Expressway-E and Expressway-C.

If your certificates are good, you will see the traversal zone go active on both servers under Status | Unified Communications.  If not, double-check your configuration settings, and double-check your certificates.

Troubleshooting Zone Configuration

If the zone won’t go active and you think it looks good, check the logs to see what is happening.  My initial attempt where the certificates were not chained properly showed a continuous loop of TLS failures.  When I had my Expressway-C pointing to the external public address instead of the inside interface of Expressway-E, TLS looked good and even the SSH tunnel showed “up” but traffic wasn’t actually flowing.

The best place I found to troubleshoot this stuff was by putting the Expressway-C and E in “Devel mode” to enable the Experimental menu.  (Instructions for this are found on p.207 of the admin guide.)  The reason for this is because the CollabEdge/MRA feature is still considered experimental.  You need to look at the Developer Logs.  You can enable them for debug level as well as collect a tcpdump.

HTTP Whitelisting


Make sure to add your Unity Connection, and any other servers that Jabber needs access to.   Unity Connection requires it for Visual Voicemail to work.

Launch Jabber 9.6 internally

Update:  No longer required unless you are doing separate internal and external domains. (I’ll detail this in a later post.)

Launch Jabber on your client device on the inside network (so that it has direct access to CUCM/IM&P).  When you enter your email address Jabber should automatically discover your servers (using the before setup internal DNS SRV records).  If Jabber does not auto-discover, troubleshoot your SRV records.  The easiest method is to use dig or nslookup.

The quick nslookup method is to:

  1. Launch the program,
  2. Make sure it shows your internal DNS servers (that your device should be pulling via DHCP scope options)
  3. Enter set type=SRV, then type  This should resolve to the hostname of CUCM, or the IP address of it.
  4. If using the hostname, exit nslookup and try to ping the hostname.

Once you enter your credentials you will likely be presented with several invalid certs to accept, and your client should connect and have IM, Presence, CUCM, CUC, and be able to IM and do voice/video calls.

Sign out and close Jabber

Launch Jabber 9.6 externally


Disconnect from your internal network and make sure your device is outside your network where a) it cannot resolve the internal SRV records, and b) it can resolve the external _collab-edge SRV record and access your Expressway-E from the outside.

Launch Jabber on your device.  Jabber will attempt to resolve and will fail to do so.  It will also attempt to resolve and will fail.  It will then attempt to resolve and get pointed to the public IP address of Expressway-E.

It will then connect to Expressway-E, and a if everything is configured properly it will login and you’ll show connected to IM, CUCM and CUC!

Notes about iOS


On iOS the timeout for attempts to login is MINUTES long.   Be very patient for it to either succeed or fail.  It can take a significant amount of time to login successfully on the 9.6 build.  9.6.1 is supposed to be much faster.

If your login fails, click the Send Error Report and email it to yourself.  Open the ZIP file and look through (going from bottom to top) to see where the errors are.  The logs will include more than just the current login attempt, so note the time when you are attempting to login and look at the timestamps in the log.  This is critical so that you aren’t troubleshooting an old login that isn’t relevant to your current problem.

From my experience:

  • When I had firewall issues, I was seeing CONNECTION_TIMEOUT errors when trying to login via MRA, but not when I was inside.
  • When I had neglected to enable RemoteAccess in jabber-config.xml I was seeing RemoteAccess Policy errors.


I’m impressed with the ability to finally be able to do voice/video calls from anywhere!  It’s about time.  Collab Edge is still considered a Feature Preview by Cisco and isn’t TAC supported yet.  Please send me questions that you have as you attempt to deploy it.



“VPN Phone” via CUBE in IOS 15.3(3)M

Have you fought the fight to setup ASA phone-proxy (back in the day) or VPN Phone on the ASA?  While VPN Phone was a solid solution, it could be a bear to setup and troubleshoot.

So, file this in the how did I miss this folder, but CUBE 10.0 (IOS 15.3(3)M) on the ISRG2 and ASR supports line-side SIP proxy for all of the current generations of phones (69xx, 79xx, 89xx and 99xx).  So CUBE can do the dirty work for you. 

I’ll set it up soon and document my experience with it once I get my CollabEdge guide out, but here is more information:

ESXi 5.5 Support for Cisco Collaboration Applications – Latest Information

Various Cisco Collaboration apps are now starting to support ESXi 5.5.  More info as they get certified on the docwiki.  From the product manager: has been updated for the first wave of applications that can support this VMware version.

A few caveats:

  • We don’t yet have every app supporting 5.5 (or even 5.1).  All apps support 5.0.  Here are the ones who are supporting 5.5 (for which versions, check their page on and R-VMW-UC-FND continue to ship a “5.x license” and 2 media files (5.1 and 5.0).  PUT for 5.5 not complete yet (ETA TBD).  Plan for 5.5 TBD.
    • UCM
    • SME
    • IM&P
    • TMS
    • PCP
    • PCA
    • IME
    • CUC, MediaSense, UCCX / IP IVR are also expected soon but those teams haven’t checked in yet.
    • See app PMs for other updates – several apps are targeting CSR 10.5 timeframe but I haven’t seen committed dates for that.
  • BE6000/BE7000 preloads continue to ship “5.x license” with 5.1 media.  Plan for 5.5 TBD.
  • 5.5 breaks backwards compatibility with older native OS versions relative to 5.1.  E.g. 4.0 thru 5.1 can support UCM 8.0.2 thru 10.0, but 5.5 can only support UCM 9.x and 10.0.  Don’t assume every version will work with 5.5.  I am emphasizing this because for ESXi 4.0 thru 5.1, every release of UCM supported every ESXi release.  For first time that isn’t true so watch out.
  • 5.5 increases the minimum physical RAM required.   4.0 thru 5.1 only required 2 GB, but 5.5 requires 4 GB.  All of our TRC builds should still be ok but if you are doing Specs-based remember this.  Sizing Guidelines page and upcoming UC on UCS mini-SRND call this out.
  • For UCM 10.0 with ESXi 5.5, read the OVA readme for some migration considerations due to the native OS changes we made in 10.0.

ESXi console session repeated characters

Ever get the dreaded repeated characters when you’ve remote desktopped into a windows machine to to gain console access to CUCM or other UC app via vShpere client?

Here’s the fix:

With the guest OS shut down edit its settings.  under Options | General | Configuration Parameters add a new row:

keyboard.typematicMinDelay = 2000000

Start the VM back up.  Now you can actually interact with the CLI properly.

8945 Firmware 9.4(1) – Worthwhile New Features – Use Caution Upgrading


9.4(1) Firmware was just released for the 8941/8945.  This release adds several features that the platform has been needing for sometime.  The two major features that customers have been asking me about are Electronic hookswitch capability, and Firmware file sharing.

The release notes have the complete list of features here.

Please note, the firmware is the first build in the 9.4 train, and shows a significant number of open caveats.

Major Features

Electronic Hookswitch has been sorely needed.  The addition allows for certain Platronics wireless models to answer the phone from the headset without a lifter. –  From Plantronics: Announcing New Cisco EHS Cables
APC-42 EHS for Cisco 6945 phone will be available at the end of February 2014. APC-82 EHS cable for Cisco 8945 phones, samples and customer shipments were available as of January 2014.

Peer Firmware Sharing allows for an 8945 at a remote site to cache and share its firmware with other phones at that site.  This is a huge feature for customer upgrading firmware at sites that have multiple phones over slow WAN links.  This will save a significant amount of bandwidth and time in upgrading remote sites.  (This feature requires the latest Devpack be installed on CUCM to enable CUCM to take advantage of that feature on the phone firmware.)

Gateway Recording for SIP – One major feature in CUCM 10.0 is the ability for CUCM to fork calls to the recording server from teh gateway rather than the BiB in the phone.  This makes sense in cases where there are remote phones, or phone models that don’t have a BiB.  The voice gateway will need to be converted from h.323 or MGCP to SIP to take advantage of this feature, and all phones will need to be upgraded to a firmware level that supports it.

Upgrading – Use Caution

I followed the typical – OS Admin install cop file, restart TFTP, and reboot a test phone, then reboot all of the phones process.

Unfortunately I had several phones completely hang and get stuck in a loop upgrading.  The fix required physical intervention.  Several phones, after initiating the reboot, got stuck at the “Upgrade in Progress” screen.  The phones in this state quit doing CDP and were no longer in the CAM table of the switch they were plugged into, so I had no way to figure out which ports they were plugged into remotely to shut them off.  They had to be physically bounced.  The problem is that they would go right back to the “Upgrade in Progress” hung state.  Infinite loop…

To cure them, I had to:

1) Manually specify the previous code in device’s Phone Load Name field (e.g. SCCP8941_8945.9-3-4-17) (in CUCM – Phone Device Settings)

2) Physically unplug and replug the phone.

After it rebooted it pulled the old code back down rebooted itself and registered to CUCM.

3) Removed the Phone Load Name specified in 1) from the configuration so it would pick the default (9.4.1) and rebooted the phone again (from CUCM this time).

The second time around the phone upgraded successfully.  I had to do this process for every one of the hung phones.


Worthwhile new features, but you might want to be on-site in case some of the phones don’t successfully take the upgrade.

CUCM 10.0 Phone Self-provisioning with PLAR


Self-provisioning is a feature in CUCM 10 which allows users to add phones with minimal effort.  The general idea would be to use this function to automate the addition the typical employee phone.  It creates an IVR that a user can call into, enter their “subscriber ID” and a PIN (if desired) and add a new or additional phones to the system.   (It also allows a user to provision the phone via a Idle URL app if desired.)  It is similar in functionality to TAPS, but does not require CCX to implement.  More information can be found here.

I decided to build a lab utilizing this feature and PLAR (private-line auto ringdown — a way to have a phone automatically call a certain number as soon as it is taken off-hook) to make it as easy as possible to add a new phone.

The basic steps being:

  • Administrator assigns an extension to the user via Active Directory/LDAP.
  • User is synced to CUCM.
  • User gets a new phone out of the box and plugs it in.
  • It auto-registers to CUCM with an extension set to PLAR to the self-provisioning IVR.
  • When the user goes off-hook it calls the IVR, they enter their assigned extension and the phone reboots with their personalized configuration.

In order to set this up there are several settings in CUCM that need to be configured:

  • The first component is to configure self-provisioning, the associated universal device/line templates, user templates and IVR settings.
  • The second component is PLAR, it’s partitions, CSS auto-registration pool and auto-registration universal device/line templates.

Configuring CUCM Self-provisioning

1) Create a CTI Route-point and assign an extension that’s in an accessible partition (typically the internal Line partition)


2) Create a self-provisioning application user that has the CTI route-point assigned as a controlled device.  Add it to the Standard CTI Enabled group.

3) Under User-management | Self-provisioning select the authenticathion method (I set mine to No Auth to make it very easy to add a phone, requiring the PIN is likely the best way to deploy this in production.  However the challenge with that is there is no way to sync the PIN from LDAP, you can just set a default in CUCM to assign users, or manually edit this after the user is synced over.)


4a) Under User Management | User/Phone Add | Universal Device Template load the Sample Device Template with TAG usage examples and edit the settings that you want customized for a phone that is added.  Things that you’ll typically want to change would be the Device Pool, CSS, Subscribe CSS, Softkey template, Phone button template, etc. to match the settings that you want a typical phone to have.


4b) Create additional Universal Device Templates for other types/configurations of phones that you want to allow to be self-provisioned.   For a multi-site deployment where device pools need to be unique, you will need to create one for each device pool.

5) Likewise, Under User Management | User/Phone Add | Universal Line Template load the Sample Line Template with TAG usage examples.  Edit settings like the Partition and anything unique to the phones.

5b) You may need to create additional Universal Line Templates for other configurations of phones that you want to allow to be self-provisioned.

6) Under User Management | User Management | User Profile load the Standard (Factory Default) User Profile and modify the name to reflect the phone model, device pool, etc.  For example, HQ-8945-User Profile.  Assign the appropriate Universal Device and Line Templates, and check the box to allow self-provisioning.


6b) Create any other User Profiles needed for other sites, and select the approprate UDT/ULTs for those profiles

7) (Optional for automated CUP/Jabber setup) Under User Management | User Phone/Add | Feature Group Template specify the User Profile and Service Profile (which specifies the CUP server settings).

8) Add a user in LDAP, making sure to specify the IPPhone or Telephone number field that you use for the extension and sync the user to CUCM, (or alternately create a local user making sure to assign a Self-service User ID and Telephone Numer) to test self provisoning.

When the user is synced, the Self-service User ID will automatically be synced to the field that you sync the phone number from (typically IPPhone or Telephone Number).

Modify the User Profile if it needs to be different from the default (for a user who is at a different location or who has a different phone type/service as discussed above).

9) Activate the Self-provisioning IVR service in CCM Serviceability

10) Test by calling the Self-provisioning IVR from a phone that you’ve plugged in.  The IVR should answer, you’ll enter the extension (Self-service User ID), confirm, and the phone will reboot with the new configuration.

If the IVR responds with an error that the phone cannot be provisioned check that the user has a Self-service User ID, and that the User Profile is specified.  

Configuring Auto-registration with PLAR

Using auto-registration with PLAR will enable the phone to auto-register to CUCM with a dummy extension in a PLAR parition/CSS and automatically call the IVR when it goes off-hook.  This way the new user doesn’t have to know the self-provisioning IVR extension.

Information about configuring PLAR can be found here, but I’ll include the summary steps below:

1) Create a PLAR1 partition, and a PLAR CSS that has only the PLAR1 partition in it

2a) For SCCP phones: Create a blank (or null) Translation Pattern whose CSS can see the internal Line partition that the self-provisioning IVR CTI Route Point is in.  Typcially this is an Internal CSS or Restricted CSS.  Set the Called Party Transformation Mask to the extension of the IVR.   This essentially sets it up so that any phone that has the PLAR CSS, when it goes off-hook, will hit this null xlate and get told to dial the self-provisoning IVR.

2b) For SIP phones (9900 series, etc.) you must create a SIP Dial Rule (found under Call Routing > Dial Rules > SIP Dial Rules) to accomplish the same thing as the Translation Patten did for the SCCP phones above.  Add a new rule, the Dial Pattern is 7940_7960_Other, call it PLAR1, and add the IVR extension in the Pattern Description field.

3) As we did above, create a new Universal Device Template and call it Auto-registration Device Template. In the Device Routing section select PLAR1 in the SIP Dial Rules field, and PLAR_CSS in the Calling Search Space field.  Any new device that is auto-registered will now be set to PLAR to the IVR.

3b) Remove the IDLE URL from the Universal Device Template if you don’t want the user using the application on the phone’s screen to self-provision.  I found it preferable to use the IVR and PLAR.

4) As we did above, create a new Universal Line Template and call it Auto-registration Line Template. Set the Route Partition to PLAR1 and CSS to PLAR_CSS.

5) Under System | Cisco Unified CM, select the CallManager server that you want to use for auto-registration.  Select the Auto-registration Device Template, and the Auto-registration Line Template under the Appropriate UDT/ULT fields.  Give it a range of dummy extensions to register to, and make sure the Auto-registration Disabled on this Cisco Unified Communications Manager checkbox is not selected.

Now when phones auto-register they will pickup the PLAR UDT/ULT settings and automatically call the IVR when the go off-hook.  After the user enters their extension the phone will reboot with the new settings.  I’ll add a video of my system in action shortly.

Please ask any questions that you’d like about the setup and usage.

Upgrading to VCS X8.1

If you’re upgrading an existing system, you’ll need:

  • VCS X8.1 upgrade tar file (as opposed to the ova file for a fresh deplyoment) – Found Here
  • New VCS 8.x release keys from Cisco – request via PUT

Once you’ve baked up your systems (VCSc and VCSe), and you’re in a maintenance window (this will disrupt all system registrations and calls), SSH in to each machine and put the system in Maintenance Mode:  xConfiguration SystemUnit Maintenance Mode: On

Initiate the upgrade in the GUI, and add the new release keys.

My VCSc upgrade failed with an error:

System error: tar zxf /tmp/tandberg-image.tar.gz: Execution failed: tar (child): /tmp/tandberg-image.tar.gz: Cannot open: No such file or directory

I rebooted VCSc and attempted the upgrade a second time and it succeeded.