What Activates a Survivable Avaya Communication Manager Server?
I’ve been teaching Avaya Aura Communication Manager (CM) for about 8 years now. When the topic of CM’s survivability strategy comes up, I like to ask students, “What causes a CM-Survivable Core or a CM-Survivable Remote server to become active?” Typically, students respond with, “the CM-Survivable Server takes control when it loses communication with CM-Main.”
I’m always surprised by how many experienced engineers give that wrong answer.
We all agree that CM-Survivable Core (CM-SC) and CM-Survivable Remote (CM-SR) are doing essentially nothing during a “sunny day,” when CM-Main is in full control of the environment. More specifically, no call processing is occurring within them.
To know what is healthy, Avaya depends upon “heartbeats” between various devices. Those “heartbeats” are called many things, such as keep-alives, or sanity checkslots. For the purpose of this discussion, heartbeats are exchanged between CM-Main and survivable CMs, H.248 Media Gateways (MG), IPSI (Internet Protocol Server Interface) circuit packs within Port Networks, H.323 phones, and starting in CM version 7.0, Avaya Aura Media Servers (AAMS). Further, for some devices, CM is responsible for generating the heartbeats, and for other devices, the device itself generates the heartbeats.
First, all of these devices must have registered with CM-Main. This “gatekeeper” function requires that the device present some credentials to ensure its legitimacy, and then CM needs to be told, or to learn, the IP address of that device.
In older CM versions, those devices (except for IPSIs) could register with any of up to 106 CLAN (control local area network) circuit packs. Acting as a front-end processor, the CLAN would collect the registration requests and forward them to CM. Recently, Avaya deprecated the use of CLANs, and wants all devices to register directly to CM at the Processor Ethernet (also known as PROCR) IP address.
So now imagine that CM-Main can no longer communicate with some, or all of these other devices. Perhaps a power outage took CM-Main completely offline, or maybe some network issue separated CM-Main from one or more of these devices. In this “rainy day” scenario, the heartbeats are not being exchanged.
In a well-designed system, each of these devices has a list of alternate CM “gatekeeper” addresses that it could register to. Further, there are several administrable fields that determine how frequently heartbeats are sent, how many heartbeats need to go missing before the device recognizes it has lost communication with CM-Main, and how long the device should wait before registering to another CM.
Most of those settings should be provided to all CM-survivable servers every night when CM-Main automatically performs a ‘save translations.’
With all that as background, here is the answer to my question: It is the Media Gateway, IPSI or AAMS that decides to register to a CM-Survivable. The survivable CMs are passive. Upon registration by one of these three devices, CM-Survivable becomes active. In other words, the survivable CM did not “take control.”
So from this perspective, what is the difference between CM-Survivable Core (SC), (formerly known as an Enterprise Survivable Server) and CM-Survivable Remote (SR) (formerly known as Local Survivable Processor)? A CM-SC is activated by the registration by a MG, an IPSI, or an AAMS. However, a CM-SR can only be activated by the registration of a MG. IPSIs and AAMS’ cannot register to a CM-SR.
“But no wait, John” some students have said. “Registration by an H.323 phone can also cause a CM survivable to become active.” Unfortunately, no. CM will not let an H.323 phone register if CM cannot provide it with a VoIP resource. And those VoIP resources reside within the MGs, Port Networks, and AAMS’. So, only after one of those devices registers to a CM could that CM allow an H.323 phone to register.
To focus on the point that registration by an IPSI, MG or AAMS is what activates a CM-survivable server, I kept this article vague. In future articles, I’ll provide details about how the IPSI, MG and AAMS know when and where to register. I’ll also discuss handling split registration.