Using Q.SIG to Integrate Unity with Multiple CUCM Clusters

So, a customer I am working with is planning an upgrade for CallManager 4.1.  The plan is to migrate to Communications Manager (CUCM) 7.1(2).  They plan to use a parrallel migration method where they will have both systems running in production during a fixed period of time.

The plan is to move “early deployment”/pilot groups over to the 7.1(2) system.  During this migration, the Unity system (v. 4.0.5) will remain on its currently running version.  This system will be upgraded later as it is a UM system and there are plans to upgrade Exchange 2003 to 2007.  So, of course we update the TSP to make sure we have cross platform compatibility (Unity is very nice this way).  The next decision to be made is how to have Unity service both clusters with complete feature support (i.e. subscriber integration and MWI) across both clusters.

There are essentially two methods available:

Adding a Cluster to An Existing Integration

This method involves adding a cluster to an existing Call Manager integration using the Unity Telephony Integration Manager (UTIM).  A second cluster is added in much the same way as the first cluster.  When adding a second cluster you must make sure that the total ports (answer, mwi, etc.) across all clusters is equal to or less than the total number of licensed ports.

So, this means you may need to remove ports from the existing integration and add them to the second.  You will need to at least add MWI ports so that message waiting status is properly maintained.

Depending on the version of Unity you are running, how you configure UTIM for this application will vary.  You also have different considerations for versions 4.0/4.1 and versions 4.2 or later.  See the following documents for more information:

1. Unified Communications Manager SCCP Integration Guide for Cisco Unity 4.0

2. Multiple Phone System Integration Guide for Cisco Unity 5.0

Using Q.SIG to Tunnel MWI

Since my customer only needed to keep the “dual” integration operational for a short period of time I wasn’t too keen on reconfiguring ports and creating a new integration.  By itself, this procedure is relatively painless.  What really made the UTIM option unappealing was that my customer would have to “reassign” or “move” subscribers from one integration (CM 4.1) to another (CUCM 7.1) as part of their process.  This adds time to each migration and is a little tedious.

I wanted to use a method where the integration could be configured and the customer could migrate users without worrying about configuring Unity for each migration.  The most viable option, in my mind at least, is/was Q.SIG.

There are several integration guides on using Q.SIG from Unity to non-Cisco PBXs and CUCM to non-Cisco PBXs.  There is also some guides on tunneling Q.SIG over Intecluster Trunks (ICTs).  On initial configuration I found some issues with integration and MWI which were resolved by applying configurations picked up from multiple guides. The following outlines the procedure I followed.

The Players:

Cisco Call Manager 4.1(3):  The cluster that is on its last days.

Cisco Unified Communications Manager 7.1(2): The cluster that is going to be the new production system

Cisco Unity 4.0(5):  The Unified Messaging system

Unity Configurations:

No additional configurations are needed on Unity.

Call Manager Configurations:

You have to configure several service parameters in the Call Manager service on each cluster:

• ASN.1 ROSE OID Encoding: Use Local Value
• QSIG Variant: ISO (Protocol Profile 0x9f)
• Retain Forward Information: TRUE
• Forward by ReRoute Enabled: FALSE
• Transform Forward By ReRoute Enabled: FALSE
• Include Voice Mailbox Address in QSIG Call Diversion APDUs: FALSE
• Always Forward Switch Voice Mail Calls: TRUE
• Include Original Called Info for Q.SIG Call Diversions: Only After First Diversion
• Path Replacement Enabled: TRUE
• Path Replacement on Tromboned Calls: TRUE
• Start Path Replacement Minimum Delay Timer: 1
• Start Path Replacement Maximim Delay Timer: 10
• Path Replacement PINX ID: or blank
• Path Replacement Calling Search Space:

After configuring the service parameters, you need to create the ICT between the two clusters.  I like to create an ICT and assign them to route groups, particularly for migration efforts.  Using an ICT route group I can insert the designated group in the top priority position in existing route lists and allow one cluster to tandem calls for another cluster.  Once the migration is complete, I can remote the route group from existing route lists.

For the ICT, you simply need to enable the Q.SIG tunneling protocol on both sides of the trunk.  In CM 7.1 you will see that you can specify some of the Q.SIG parameters locally on the trunk or the ICT will inherit settings from the service parameters.  Nice.

Finally, I also had to remove MWI On and MWI Off DNs from the CUCM 7.1 system.  In the scenario tested, the CUCM 7.1 system was built using DMA.  Therefore, the CUCM 7.1 system had the same MWI On and MWI Off extensions as the CUCM 4.1 system.  I am not sure exactly what about the MWI patterns disrupted MWI functionality at this time.  I didn’t actually remove the extensions, I simply moved them to a partition that was not visible by the ICT calling search space.

Testing direct, redirect, off-net, ICT, and on-net calls all worked as desired and we don’t need to deal with making sure the Unity subscriber is “homed” to the correct integration during the migration effort.