CUCM 7.0.2 design question - PRI-->SIP Trunk failover to PRI-->Hunt List

Unanswered Question
Aug 8th, 2009

Hello All,

On 3 PRIs (MGCP gateway) I have every inbound PSTN call directed to a SIP trunk pointing to a 3rd-party IVR server. That works great.

What I want to do is set up a failover scheme by which - in the event the IVR server fails - the same inbound PSTN calls get sent to a Hunt Group, ringing many agent phones (registered to the same CUCM) simultaneously, bypassing the IVR. Basically, I want to add a Hunt Group to a Route List - which is not possible.

I could easily put route patterns into a second partition and list it beneath the SIP target partition . . . But the inbound calls would still match the first route pattern pointing to the SIP trunk, and calls would fail in the event the server were down. They would never hit the route pattern pointing to the Hunt Pilot in the subsequent partition.

Ideas would be greatly appreciated.


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
Jonathan Schulenberg Thu, 08/13/2009 - 06:35

I think you may need to turn the gateway into H.323 or SIP and use a lower preference dial peer to fall back to. The gateway would have a dial peer pointing directly to the 3rd party IVR server using SIP as the protocol. A lower preference dial peer for the same destination-pattern would point to UCM. You would probably want to tweak the timeout values so this fallback happens faster. Also note that this will bypass UCM CAC so plan carefully.

The lower preference dial peer for UCM would need to change the DNIS to the hunt pilot. The normal route pattern in UCM would need to point to the voice gateway in case an on-net user were to transfer the call.

kc-ussugar Mon, 08/24/2009 - 07:22

This is a great idea - I think it will accomplish what we're trying to do. Thanks!

kc-ussugar Thu, 10/01/2009 - 05:55

Here's a Postscript, in case it's helpful to anyone - - TAC came up with a clever twist on j.schulenberg's idea - let the VG use BOTH H.323 and MGCP. So, in CUCM we added the gateway as H.323 and listed it in the RL as a separate RG beneath the SIP RG. Gateway is now defined twice inside CUCM - MGCP and H323. The H323 comes into play only in the event of a SIP failure, where CUCM sends calls back to the gateway via H323 (translating digits on the way), then gateway returns calls to CUCM via H323 and they get routed to phones (instead of the failed SIP trunk). It's worked flawlessly in several real-world failures of the 3rd-party IVR application. The idea may sound complex, but the implementation is really not - only took two dial peers on the IOS VG, and the addition of one VG / RG inside CUCM.


This Discussion