Redundancy Considerations and Cisco IP Phone Services

Cisco Unified Communications Manager (CUCM) and, more specifically, Cisco IP Phones support application extensibility by leveraging web server applications and the Extensible Markup Language (XML). Anyone who has used Extension Mobility, Corporate Directory, Missed Calls, Received Calls, and other similar apps on a Cisco IP phone has witnessed a XML application in action. 


Users of these standard applications and the numerous other productivity applications optimized to leverage the Cisco IP Phone XML capabilities have grown to expect these applications to be 100% available. A common question I field from customers and one I have seen on the Cisco Support Forums from time to time is: "how to make these web-based applications redundant?".

IP Phone Services

In CUCM the applications that can be used by an IP phone are aptly named IP Phone Services. IP phone services can be XML application or Java Midlets hosted on either a CUCM node or some third-party application. You can find IP Phone applications on other Cisco products as well (Unity Connection, Unified Contact Center Express, MeetingPlace (Express), etc.).

CUCM Services

The following IP Phone services/applications may reside directly on a CUCM node:

• Extension Mobility
• Unified CM Assistant
• Corporate Directory (and other system directories)
• Personal Directory (and sub-applets like FastDials)

You can even extend this list to include the context-sensitive help key and the "Services" key itself. These are both tied to a web application running on the CUCM cluster (typically the publisher node).

Internal and External Provisioning

There are several URLs that may be provisioned for IP phones which are not traditionally considered "subscribed" services. I am talking about the handful of URLs that you will find on device-level configuration screens and the Enterprise Parameters.

Starting with CUCM 7.x, Cisco introduced the concepts of "Internal Provisioning" and "External Provisioning". With Internal Provisioning, subscriptions to IP Phone Services are delivered to IP phones as part of the TFTP configuration file. External provisioning uses the same "call and response" that is all to familiar with those of us who have worked on pre-7x CUCM deployments.


I am bring this topic up in this blog because the way "Internal Provisioning" operates provides a solution to the redundancy question. Well, at least for a subset of user applications.

Redundancy Considerations


IP phone interfaces and desktop interfaces that utilize applications like Extension Mobility and Web Dialer require a certain level of redundancy in large enterprises (and maybe not so large, depending on the user needs). Users become accustomed to being able to leverage such applications as part of their daily workflow.


Internally Provisioned Services

Some applications provide redundancy natively by allowing phones to use their assigned CUCM node list (provisioned via the CUCM Group configurations) to access the application or service. Specifically, the services that are provisioned using Internal Provisioning define this category of application. The following services can leverage Internal Provisioning and provide native redundancy:

• Corporate Directory
• Personal Directory
• Missed Calls
• Received Calls
• Intercom Calls
• Voicemail

So, how does this work. Basically, Cisco IP phones that support the capability will learn about these services via their TFTP configuration file. The application URL written in the TFTP configuration file uses a syntax that essentially says: "use the CUCM node you are registered with". This approach is different than pre-7x systems and the External Provisioning model where the phone goes to one URL and deals with the results.

What about those other apps?
 

Clients accessing 3rd party applications or Cisco IP phone applications that do not support Internal Provisioning are in the same boat they have always been. These applications use a specific URL that directs the client request to a particular host name or IP address. If the node hosting the requested application is off-line then users will experience a disruption in service. An example application that falls into this bucket is Extension Mobility.


There are basically two approaches to providing redundancy for IP phone services that use static URLs. The first approach is to leverage Domain Name System (DNS) as a redundancy mechanism. Using this approach, you create multiple DNS host ("A") records for the target service. These A records would use the same fully-qualified domain name (FQDN) with different host IP address assignments. The following figure illustrates this example.

In this example, the IP phone submits a DNS query for emapp.ucguerrilla.com and the DNS server replies with all possible options. The IP phone selects one of the options and submits a request to that host (10.3.8.20, in our example). If the target fails to respond, the IP phone will use one of the other IP addresses returned by the DNS server. 


There is a big drawback to using this approach. In the event that the 10.3.8.20 node is off line or unable to fulfill the request, the phone will wait 30 - 45 seconds before attempting a connection to the secondary node. This delay may reoccur on subsequent requests to the same application, including navigating menus within the same "session". 

Note: A while ago, I tested this behavior and found in 8.5(3) and later phone firmware on the 7941/61, 7942/62, 7945/65, and 7906 that there was an improvement to the user experience with subsequent delay. Basically, the first 30 - 45 second delay is still present. However, the phones appeared to "remember" that the primary node was unavailable and continue to use the secondary node. Thereby avoiding 30+ second delays on subsequent requests. According to my notes, I attributed this to a bug fix: CSCsz94878. I never did repeat the test on 9.x+ firmware or on the latest generation of phones.

The second redundancy approach is to leverage a Server Load Balancer (SLB) such as Cisco's IOS SLB or Cisco ACE (or a combination). An example is provided in the following figure.

In the above example, the phone sends a DNS request for emapp.ucguerrilla.com. The DNS server returns an IP address which corresponds to a virtual interface (or VIP) on the SLB device. This VIP is provision with the appropriate CUCM nodes as "real servers". 


The advantage with this solution is that the SLB can proactively identify a disruption in service to one of the real servers. Once an issue is identified, the SLB device can be configured to ignore the defunct node and directly send clients to the secondary node. Of course, the SLB must be "in-line" with the conversation flow to be optimally effective.


Considerations


There are several considerations you need to address when including fault tolerance in your IP Phone Services design. First, consider the "facilitator". If you have only one DNS server then you really haven't solved your redundancy need. You have merely moved it to a different appliance that you probably have less control over. The same is true for a SLB solution. 

Second, remember that the "Services" button on the IP phone is also a web application running on a CUCM node. So, it is subject to the same redundancy concerns. 

Third, you should determine how critical an application is to your user's workflow before you go engineering a complicated redundancy scheme.

Fourth, you can use the same methods for 3rd party applications as long as those applications are deployed in a redundant fashion.

---

Thanks for reading. If you have time, post a comment!