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.
I experienced an issue when using the API commands on a Codec Pro vie the serial port: the command:xCommand Phonebook Search PhonebookType: Corporategives this response:*r Result (status=Error): \x0D\x0A*r Result Reason: "Unknown command"\x0D\x0A*r R...
Hello, A VC system receive a call during a few seconds without ever accept it and the call is disconnected (see the file attached). In the opposite, this specific system can call anyone. So, we think the signalling flows aren't opened in on...
Hi Team, In our infrastructure, we have 48 PGs (24 active & 24 passive) across 2 data centers. We want to setup a automatic daily health check for the PGs before the business day start so that none of the CTI clients fails. Please suggest a best way t...
I am trying to create a script where you indicate a specific time in the UCCX and the IVR calls you back on that time, for now I have only made it so that it calls you on the XX:00:00 mark, exactly on the hour. I can not alter specifically minutes in the ...
We were in the process of upgrading PCCE from 11.6 to 12.0 and what we found during CUIC upgrade that it fails and when we checked in the replication , it says replication_not_setup on both cuic publisher and subscriber nodes.Please advice if anyone has o...