MGCP Fallback to 323, can we preserve existing calls?

Unanswered Question
Dec 13th, 2007

Is there a way to have an MGCP gateway preserve existing calls when it enters Fallback mode and reverts to H323? One of our senior VP's was at a remote site when the MPLS circuit dropped out and they were kicked off an important conf call when the gateway switched over (They were able to re-dial in once it was in fallback mode)

Basically I've been ordered to never let this happen again and I'm not relishing the thought of converting about a dozen MGCP gateways over to H323 just to accomplish this.

Is there a better way? :)

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
gogasca Thu, 12/13/2007 - 10:46

For MGCP gateways, call preservation depends on the type of circuit. For analog or CAS circuits, calls are preserved on failover from CallManager to SRST. For ISDN circuits, active calls are dropped on failover. Technically, the call is dropped when you initiate MGCP Gateway Fallback. This is because the D channel of the ISDN circuit is backhauled to CallManager. When MGCP Gateway Fallback is initiated, the gateway tears down and reestablishes the D channel, resulting in all active calls being dropped. Calls are also dropped when communication is reestablished with CallManager.

MGCP calls will be preserved as long as you have a CCM secondary server.

mhering8650 Thu, 12/13/2007 - 10:55

Yeah, that's what I figured, I was just hoping (Praying actually :) ) that there was some super secret cisco command that would mabye have the Gateway watch the D channel and step in when it went into fallback mode.

Oh well looks like the next few weekends I'll be converting gateways :(

Thanks anyway :)

ecstillman Mon, 04/21/2008 - 15:03

Hi,

Your last line seems to contradict everything above. Can you pls explain?

Thanks!

maharris Mon, 12/01/2008 - 11:36

Hi! I just ran across this discussion because I had a server that dropped our call when it failed over to the secondary, and I was trying to verify that it should have preserved it - here is the doc that says it should, I think we had complicating factors in this case (almost out of memory, so took too long to preserve call):

The MGCP gateway also establishes a TCP link to the backup (secondary) Cisco Unified Communications Manager server. In the event of a Cisco Unified Communications Manager switchover, the secondary Cisco Unified Communications Manager server performs the MGCP PRI backhaul functions. During the switchover, all active ISDN PRI calls are preserved, and the affected MGCP gateway is registered with the new Cisco Unified Communications Manager server through a Restart-in-Progress (RSIP) message. In this way, continued gateway operation is ensured.

http://www.cisco.com/en/US/docs/ios/voice/cminterop/configuration/guide/vc_mgcp_t1cas_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1009115

Just posting for posterity..so, you should have MGCP PRI call preservation for server failover, but not for SRST fallback, as discussed in the SRND. For SRST PRI call preservation, you need to use H323 and add the extra commands

Mary Beth

Tommer Catlin Thu, 12/11/2008 - 17:32

anyone know does this work for H323? For example, H323 gateway to/from CUCM? If Sub drops out, CUCM is active, do active calls stay up?

cjhunt Fri, 12/12/2008 - 07:55

Hi,

You should have no problem if this is all H.323 because there is no direct relationship / dependency on CUCM for the circuit to stay up, i.e. the link is not backhauled to CUCM and the controller will not have to be reconfigured to locally control the D channel.

If calls are not not reliant on MTP resources in the CUCM and endpoints are still able to communicate with the gateway, then no problems.

/Chris

Tommer Catlin Fri, 12/12/2008 - 07:59

Thanks! I found another post about CUCM needs to have an advance parameter set from False to True about keeping the H323 Peer connection alive. Once I did this on my (4) clusters, it all started working with the gatekeepers I have.

Actions

This Discussion