Singlwire Informacast Resiliency feature

Somewhere around version 9 Singlewire introduced a "resiliency" feature where you no longer had to depend on a single server to provide paging, alerting, bells, etc. to your masses.  You can now deploy multiple backup servers (much like CUCM, called subscribers) that would perform all the paging functions in the event the publisher or higher order subscribers failed.  Now that they are on version 11 and I haven't deployed one since about version 8, here are few tips to get you over the resiliency feature deployment that I bumped into today.

1. Send Commands to Phones by JTAPI

If you are familiar with the single server deployment model or audio paging solutions from other vendors, you may be familiar with the suggestion they all make to modify the CUCM cluster's Authentication URL.  The Singlewire documentation still addresses this in multiple places, which is good as it is a common point of failure in these types of deployments.  Singlewire and others will strongly recommend you change the default CUCM Authentication URL to a custom URL pointing to your fancy new paging server instead.  The idea here is to have all the phones authenticate to the paging server when they are sent a page request rather than potentially overloading the CUCM Publisher with those same authentication requests.  You don't want thousands of phones smashing on CUCM's Tomcat door just because your receptionist wants to announce she found a pair of sunglasses at the front desk. 

The challenge is now that if you have redundant paging servers, what do you use for the new Authentication URL?  Normally you would use a URL that points to the Singlewire server.  But now you have two (or three or whatever). If your first paging server fails and the second takes over all the paging functions, your phones are still going to look for the first paging server to authenticate against and nothing will work even if subscribers are up and healthy because there is no paging server to authenticate the page requests.

What do you do?

You use JTAPI instead of HTML requests.  HTML sounds way simpler to me and it's been how things were done for some time now.  Why not stick with it?  Quietly you will find the Singlwire subscriber servers use JTAPI regardless of how you've chosen to authenticate requests from the Singlewire publisher.  This solves the problem of what URL to change the CUCM Authentication URL to as you can now set the one and only option to your one and only paging server using HTML requests, the Singlewire publisher.  But since the subscribers use JTAPI rather than HTML, why not use JTAPI on the publisher as well?  Just do it.  When you buy another administration bolt on tool and it wants you to change the Authentication URL to itself as well you'll thank me.  How many daisy chained authentication server requests do you need?

On the publisher you will find the single checkbox option under Admin | Broadcast Parameters.

2. Unified Communications Application User

Having installed you subscriber and it looking healthy you decide to shutdown the publisher and actually test the resiliency function.  You dial a CUCM route pattern that was working perfectly when the publisher was up but now hear something like "We're sorry. No devices could be activated. Your broadcast will not be completed."  You know your SNMP and AXL settings are correct since your pages worked through the publisher and you know it's not a HTML authentication issue since you are using JTAPI now so what is the problem?

Although most of the configuration information in a resilient Singlewire solution is replicated from the publisher to the subscribers, the CUCM Application User settings are not. Why? Don't know.  They just aren't.

Log into your subscriber server HTML interface where you typically are prevented from really doing anything and set your CUCM Application User credentials there.  Go to Admin | Telephony | Cisco Unified Communications Manager Cluster | Edit Telephony Configuration and enter the user name and password there.

3. Stop / Restart the singlewireInformaCast service

How do you replicate a server failure to test resiliency?  You could shut down the whole server, maybe use a fancy network ACL, maybe just pull an Ethernet cable, whatever, because you just can't find a tool in the administrative interface to stop or restart services. 

From the main administration page, choose the Webadmin option.  This wil take you to another log in and adminstrative interface.  From there choose System | Bootup and Shutdown.  That's right.  You can simply stop and start services manually from the option labelled Bootup and Shutdown.  This is not terribly intuitive as far as I'm concerned but it works.  Scroll down the service list and click singlewireInformaCast.  You can Stop Now or Start Now on the Publisher server to simulate a server outage.

Here's what it looks like if you're in the right place: