This document is intended to guide the users to understand the basics of Media Gateway Control Protocol (MGCP) Gateway Fallback operation & the process on Voice Gateway.
MGCP Fallback Operation
MGCP Gateway fallback is a feature that improves the reliability of MGCP remote site networks. A WAN link connects the MGCP gateway at a remote site to the Cisco Communications Manager at a main site, which is the MGCP call agent. If the WAN link fails, the fallback feature keeps the gateway working as an H.323 or SIP gateway and rehomes to the MGCP call agent when the WAN link is active again. MGCP gateway fallback works in conjunction with the SRST feature.
Cisco IOS gateways can maintain links to up to two backup CUCM servers in addition to a primary CUCM. This redundancy enables a voice gateway to switch over to a backup server if the gateway loses communication with the primary server. The secondary backup server takes control of the devices that are registered with the primary CUCM. The tertiary backup takes control of the devices that are registered devices if both the primary and secondary backup CUCM systems fail. The gateway preserves existing connections during a switchover to a backup CUCM server.
When the primary CUCM server becomes available again, control reverts to that server. Reverting to the primary server can occur in several ways: immediately, after a configurable amount of time, or only when all connected sessions are released.
Implementing Cisco Unified SRST and MGCP Fallback
MGCP Fallback Usage:
A Public Switched Telephone Network (PSTN) gateway can use MGCP gateway fallback configured as an individual feature if H.323 or SIP is configured as a backup service. SRST and MGCP fallback must be configured on the same gateway with Cisco IOS software release 12.2(11)T or later if this single gateway will provide SRST fallback service to phones and MGCP gateway fallback.
Refer this document for more information on Cisco Unified SRST configuration and MGCP Fallback configuration on Cisco IOS Gateway
Figure shows the MGCP Fallback and Cisco Unified SRST
MGCP Gateway Fallback during Switchover
The MGCP gateway performs a switchover to its default technology of H.323 or SIP, as shown in figure, when the keepalives between CUCM and the Cisco MGCP gateway are missing.
The MGCP gateway fallback feature provides the following functionality:
MGCP Gateway fallback support: All active MGCP analog, E1 CAS and T1 CAS calls are maintained during the fallback transition. Callers are unaware of the fallback transition, and the active MGCP calls are cleared only when the callers hang up. Active MGCP PRI backhaul calls are released during fallback. Any transient MGCP calls that are not in the connected state are cleared at the onset of the fallback transition and must be attempted again later.
Basic connection services in fallback mode: Basic connection services are provided for IP telephony traffic that passes through the gateway. When the local MGCP gateway transitions into fallback mode, the default H.323 or SIP session application assumes responsibility for handling new calls. Only basic two-party voice calls are supported during the fallback period. When a user completes (hangs up) an active MGCP call, the MGCP application handles the on-hook event and clears all call resources.
MGCP Gateway Fallback Process
The MGCP gateway maintains a remote connection to a centralized CUCM cluster, as shown in figure by sending MGCP keepalive messages to the CUCM server at 15 second intervals.
If the active CUCM server fails to acknowledge receipt of the keepalive message within 30 seconds, the gateway attempts to switch over to the next available CUCM server.
If none of the CUCM server responds, the gateway switches into fallback mode and reverts to the default H.323 or SIP session application for basic call control.
Note: H.323 is a standardized communication protocol that enables dissimilar devices to communicate with each other through the use of a common set of codecs, call setup and negotiating procedures, and basic data-transport method.
The gateway processes calls on its own using H.323 until one of the CUCM connections is restored. The same occurs if SIP is used instead of H.323 on the gateway.
Hi, Refer to below BoM would you kindly guide with the right license for 3rd party IP Phone to sync with the existing infra.? Call Manager Hardware 21.0BE6M-M4-K9=Cisco Business Edition 6000M Svr (M4), Export Restricted SWN/A121...
Hello, We have CUCM Cluster on BE7K on 10K user OVA, there is a branch with existing seperate BE6K with 100 users. we are migrating the the 100 users to HQ Cluster and need local call processing. I though of 2 options for the Branch.1. 10K user ...
Hi All, I have issue with UCCX to transfer call, what simulation has been done are :1. Calling from internal to external number (phone number) via UCCX , result is success2. Calling from external (phone number) to external number (phone number) via U...
I am trying to configure a script that has a time of day component Building menus one for school hours and one for After hours During 8:00 am to 3:00 no teacher should get a phone call from a parent After 3:00 pm parents should be abl...