Using Q.SIG to Integrate Unity with Multiple CUCM Clusters

Author
William Bell
Vice President, Solutions and Products

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.

2 responses to “Using Q.SIG to Integrate Unity with Multiple CUCM Clusters

  1. Just configuring this now in a multicluster setup with SME and qsig sip trunks. I’ve got all the leaf nodes in a single route list with a wildcard route pattern to send calls around(my dn ranges are spread across all clusters). Unfortunately it looks like this is not supported with that setup. Specifically, I found a Cisco doc stating that mwi notifications over trunks need to be directly assigned to a route pattern to be supported. With my setup, the mwi worked with the first cluster in the route list, but not for the rest.

    So a call continues to route if it receives a 404 from one cluster, but the mwi notification stops when it does. We’re back to running multiple phone system configurations from the one unity connection cluster.

    Thanks!
    Rick

  2. Just configuring this now in a multicluster setup with SME and qsig sip trunks. I’ve got all the leaf nodes in a single route list with a wildcard route pattern to send calls around(my dn ranges are spread across all clusters). Unfortunately it looks like this is not supported with that setup. Specifically, I found a Cisco doc stating that mwi notifications over trunks need to be directly assigned to a route pattern to be supported. With my setup, the mwi worked with the first cluster in the route list, but not for the rest.

    So a call continues to route if it receives a 404 from one cluster, but the mwi notification stops when it does. We’re back to running multiple phone system configurations from the one unity connection cluster.

    Thanks!
    Rick

Leave a Reply

 

Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.

 

Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.

 

John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.