Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
A 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.
Although MGCP gateway fallback is most often used together with SRST to provide
gateway functions to IP Phones in SRST mode, it can also be used as a standalone feature.
For example, with a fax application server using a PRI ISDN interface controlled by MGCP,
connectivity to the PSTN can be preserved by MGCP gateway fallback. An MGCP-fallback
standalone configuration may also be used to allow analog interfaces that are controlled by
SCCP to stay in service even when the WAN connection to the CUCM is down.
MGCP gateway fallback preserves active calls from remote-site IP Phones to the PSTN
when analog or channel-associated signaling (CAS) protocols are used. For ISDN protocols,
call preservation is impossible, because Layer 3 of the ISDN stack is disconnected
from the MGCP call agent and is restarted on the local Cisco IOS gateway. This means that
for active ISDN calls, all call-state information is lost in cases of switchover to fallback
operation.
MGCP Fallback Operation
MGCP gateway fallback, shown in Figure 5-7, is a feature that improves the reliability
of MGCP branch networks. A WAN link connects the MGCP gateway at a remote site to
the Cisco Communications Manager at a central 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.
108 Chapter 5: Examining Remote-Site Redundancy Options
Figure 5-7 MGCP Gateway Fallback in a Normal Situation
Main Site Remote Site
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 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.
MGCP Gateway Fallback During Switchover
The MGCP gateway performs a switchover to its default technology of H.323 or SIP (as
shown in Figure 5-8) when the keepalives between CUCM and the Cisco MGCP gateway
are missing.
GCP Fallback Usage 109
Figure 5-8 MGCP Gateway Fallback During Switchover
The MGCP gateway fallback feature provides the following functionality:
MGCP gateway fallback support: All active MGCP analog, El CAS, and Tl 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 During Switchback
The MGCP-gateway-fallback feature provides the rehome functionality to switch back
to MGCP mode. As shown in Figure 5-9, the switchback or rehome mechanism is triggered
by the reestablishment of the TCP connection between CUCM and the Cisco MGCP
gateway.
110 Chapter 5: Examining Remote-Site Redundancy Options
Figure 5-9 MGCP Gateway Fallback During Switchback
Rehome function in gateway-fallback mode detects the restoration of a WAN TCP connection
to any CUCM server. When the fallback mode is in effect, the affected MGCP gateway
repeatedly tries to open a TCP connection to a CUCM server that is included in the prioritized
list of call agents. This process continues until a CUCM server in the prioritized list
responds. The TCP open request from the MGCP gateway is honored, and the gateway
reverts to MGCP mode. The gateway sends a RestartlnProgress (RSIP) message to begin
registration with the responding CUCM.
All currently active calls that are initiated and set up during the fallback period are
maintained by the default H.323 session application, except ISDN Tl and El PRI calls.
Transient calls are released. After rehome occurs, the new CUCM assumes responsibility
for controlling new IP telephony activity.
MGCP Gateway Fallback Process
The MGCP gateway maintains a remote connection to a centralized CUCM cluster, as
shown in Figure 5-10, by sending MGCP keepalive messages to the CUCM server at
15-second intervals.
MGCP Fallback Usage 111
Figure 5-10 MGCP Gateway Fallback Process
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 servers 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 methods.
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.
No comments:
Post a Comment