CME/CUCM Failover

[billybjo1]

I have a scenario where the main ISDN30 comes into a CME (9.1) system.

The calls then get pushed to CUCM (8.0) via a H323 dial-peer. The CME is only for emergency situations.

If I have a specific number that gets pushed to CUCM, is there any method I could get it to remain on CME if CUCM is down? It may require a translation as the extensions are slighty different on CME.

I was thinking possibly of initially having that number get pushed to a CME extension, then placing a call forward all to the CUCM extension. Then if CUCM goes down, the user removes the call forward from the CME phone. I'm not sure if that will work, but plan to test.

Does anyone know of another method that could do this, even automatically if possible when CUCM goes down?

I know we can amend the gateway at CUCM failure, but I wanted to look for a slicker method that didn't involve reconfiguration.

[ajayviswanath]

Hi Billy,

Are you using the the cme gateway as SRST..?? are there some phones registered to the cme which are used as the emergency line..??

AJ

[Chris Deren · Accepted solution]

Simply build another dial-peer with session target of the CME IP address and assign preference 1, then since the numbers are different build translation rule that modifies the number and assign the profile to this dial peer.

HTH,

Chris

[William Bell]

Chris' option is viable (+5 Chris). Though, the preference you assign will depend on how many dial-peers you have pointing to the CUCM cluster in the current config. Since ephone-dn's are essentially POTS dial-peers (sh telephony-s dial-p),

the mechanics of Chris' approach is essentially the same as the tertiary ephone-dn approach.

So, now you have various options to get the call path working. I think you may need to think over the experience you want to provide to your CME users.

HTH.

-Bill (@ucguerrilla)

[William Bell · Accepted solution]

If I follow, you have a CME host (not a CME-SRST host) and you have the CME host tandem routing certain calls to CUCM. In the event that CUCM is not reachable, you want the CME to handle the call locally. An additional consideration is that the dial plan for station DN assignment on CME is different than what is provisioned on CUCM.

Based on the above, I think I know of one way to address your needs. The following config example illustrates the approach.

Let's say that the "specific number" you are concerned about is 53000.

Config example:

!

voice class h323 1

h225 timeout tcp esta 2

voice class codec 1

!

dial-peer voice 81010 voip

destinatiion-p 53000

session-target ipv4:SubscriberIP

no vad

dtmf-r h245-a

voice-class codec 1

voice-class h323 1

incoming called .

!

dial-peer voice 81011 voip

destinatiion-p 53000

session-target ipv4:SecondaySubscriberIP

no vad

dtmf-r h245-a

voice-class codec 1

voice-class h323 1

prefe 2

!

ephone-dn 3

number 53000

label SomeLabel

prefe 3

!

ephone 1

button 2:3   <<< puts 53000 on the 2nd button of the ephone

!

That is one approach. The basic idea is that CME is going to try and route the call using H323 as it does today. Since we have set the preference value on the two dial peers and the ephone-dn, then we are controlling which path order is used. This approach assumes you are using the default dial-peer hunting algorithm  (dial-peer hunt ?). The TCP establish timer (under voice class h323 1) may need to be tweaked based on your environment. In the sample, CME with send a TCP SYN to the primary subscriber. Since we are assuming that host is off line or the network path between CME and CUCM is broken, there should be no TCP response from CUCM. After 2 seconds, CME will try the second dial-peer. Again, this should fail and then we will try the local ephone dn. Which should work. The net effect is there is a delay in presenting the call (approx 4 s) to the ephone dn. You can tweak timers but be mindful of the broader impact.

If you wanted to avoid creating multiple dial-peers with specific destination patterns then you could use something like the following:

Config example2:

!

voice class h323 1

h225 timeout tcp esta 2

voice class codec 1

!

dial-peer voice 81010 voip

destinatiion-p 5....

session-target ipv4:SubscriberIP

no vad

dtmf-r h245-a

voice-class codec 1

voice-class h323 1

incoming called .

prefe 1

!

dial-peer voice 81011 voip

destinatiion-p 5....

session-target ipv4:SecondaySubscriberIP

no vad

dtmf-r h245-a

voice-class codec 1

voice-class h323 1

prefe 2

!

ephone-dn 3

number 53000

label SomeLabel

prefe 3

!

ephone 1

button 2:3   <<< puts 53000 on the 2nd button of the ephone

!

dial-peer hunt 2

In example 2, we have more generic destination patterns on the voip dial-peers, we have put a specific preference on dial-peer 81010, and we have changed the hunting logic for dial-peer processing to use preference as the primary selection criteria for candidate dial-peers. Other than those changes, the call setup behavior is basically the same. You will want to take a holistic view of your design when deciding whether to change the dial-peer hunting preferences.

There are other options, such as using the CME loopback as a tertiary dial-peer w/translations.

HTH.

-Bill (@ucguerrilla)

[billybjo1]

Thanks for all the great (and detailed!) answers.

For some reason I had it in my mind having an extra dial-peer pointing direct to the CME wouldn't work, but I wasn't too sure. If I had the extension on the CME the same as the CUCM, I also thought that would take precedence for any incoming calls (direct registered ephone over a dial-peer), hence the reason we numbered them slightly different.

The CME users are only emergency phones for when the main system is down, but they required a number of features which made CME more attractive than SRST.

I'll give this a go.

[William Bell]

No problem.

The default dial-peer selection logic on CME is going to prefer longest match. So you can have specific ephone-dns on the system and generic destination-patterns which are a superset of the ephone-dns and it would work. In your case, you want to have a DID that would route through the dial-peers by default and then fallback to an ephone on your system.

Using a tertiary voip dial-peer (pointing to the loopback) will get you there and you don't need to modify the dial-peer selection logic. Using an ephone-dn gets you there and, depending on whether you want to add a special set of voip dial-peers for CUCM or not, you may need to modify dial-peer selection logic.

-BIll

[billybjo1]

Just a follow-up update after my testing.

I have setup 3 dial-peers (CUCM1, CUCM2, CME) preference in that order. I had my h225 timeout set to 1 second. This works ok and eventually CME gets selected when both CUCMs are unavailable, but for some reason it takes about 15 seconds. Anyway I added "monitor proce icmp-ping" to both CUCM dial-peers and it now works perfectly within 2 seconds if the CUCMs are totally off the network.

[William Bell]

Well, that is one method. Make sure you look at all of the default values for the various thresholds involved with the underlying mechanism invoked by that config.

You do highlight an oversight in my original response. I was assuming the CUCM nodes would be completely offline or that the network path from CME to CUCM would be 100% compromised. I did not account for partial connectivity such as the CUCM node being online but the CM service being down.

In this latter scenario the "h225 timeout tcp establish" command is not addressing the issue. This is because "tcp establish" timer is simply monitoring the TCP handshake (SYN-SYN-ACK) process. Using the timer "h225 timeout setup" under the voice class would address the partial connectivity issue more cleanly.

voice class h323 1

h225 timeout tcp establish 2    !or whatever value works in your environment

h225 timeout setup 2               !or whatever value works in your environment

Anyway, sounds like you found a method that works for you and that is fine. I just wanted to round out the conversation.

Bill (@ucguerrilla)