Call Survivability for MGCP

flash2200 · ‎10-30-2007

Hi all,

I'm wanting to get something straight in my own mind about how MGCP call survivability works...

I understand when a MGCP controlled GW uses PRI/BRI connections it backhauls the D-Channel to the CM. Therefore if the loses connection to it's CM and has to switch to SRST mode it will drop active calls. Makes sense so far...

However my books also suggest that the same MGCP gateway will not drop active calls on a PRI/BRI if the connection to primary CallManager is lost as long as it can switch to it's secondary CallManager. That part does not make sense to me.

During the switchover to the second CM would the backhaul not need to be torn down and re-established on the second server just like with any TCP connection??? Seems to me you would lose the backhaul connection in the process and drop any active calls. Am I missing something?

TIA

Rob Huffman · ‎10-30-2007

Hi Steven,

Excellent question. I have thought about this a great deal and had trouble coming to grips with how this could work until I thought about it this way. CCM is the Call Agent used only in the setup and teardown of calls via the Gateway. Once the call is established the CCM is really out of the picture somewhat, so active calls remain connected during the Failover to the redundant/backup CCM. Calls in the process of being setup are not completed and must redial/reconnect;

MGCP Gateways and Cisco Unified Communications Manager

MGCP enables the remote control and management of voice and data communications devices at the edge of multiservice IP packet networks. Because of its centralized architecture, MGCP overcomes the distributed configuration and administration problems inherent in the use of protocols such as H.323. MGCP simplifies the configuration and administration of voice gateways and supports multiple (redundant) call agents, eliminating the potential for a single point of failure in controlling the Cisco IOS gateway in the network.

MGCP can be configured as a master or slave protocol to ensure that the gateway receives and executes the configuration, control, and management commands that are issued by Cisco Unified Communications Manager. The MGCP gateway is under the control of Cisco Unified Communications Manager.

MGCP uses endpoints and connections to construct a call. Endpoints are sources of or destinations for data and can be physical or logical locations identifying a device. The voice ports on the Cisco MGCP gateway are its endpoints. Connections can be point-to-point or multipoint. Cisco Unified Communications Manager acts as the MGCP call agent, managing connections between endpoints and controlling how the Cisco IOS gateway functions.

From this excellent doc;

http://www.cisco.com/en/US/products/ps6441/products_configuration_guide_chapter09186a00805583bd.html#wp1056830

Hope this helps!

Rob

flash2200 · ‎10-30-2007

Hi Rob,

Thanks very much for this and I follow what you're saying about CCM being out of the picture once the call is established. Makes sense that you could re-establish the backhaul to another CCM without affecting active calls.

That said, given the way you describe it I would think the failover to SRST should not affect active calls either since they are already established and again CCM is out of the picture?? I would think again that the issue would only be with calls in the process of being setup??

Rob Huffman · ‎10-30-2007

Hi Steven,

In the SRST failover the IP Phone has lost connection with all available Servers listed in it's CCM Group and must re-establish connection with the SRST Router. My take on this is that this is where the call is lost;

When Cisco IP phones lose contact with primary, secondary, and tertiary Cisco CallManagers, they must establish a connection to a local Cisco SRST router to sustain the call-processing capability necessary to place and receive calls. The Cisco IP phone retains the IP address of the local Cisco SRST router as a default router in the Network Configuration area of the Settings menu. The Settings menu supports a maximum of five default router entries; however, Cisco CallManager accommodates a maximum of three entries. When a secondary Cisco CallManager is not available on the network, the local Cisco SRST router's IP address is retained as the standby connection for Cisco CallManager during normal operation.

--------------------------------------------------------------------------------

Note Cisco CallManager fallback mode telephone service is available only to those Cisco IP phones that are supported by a Cisco SRST router. Other Cisco IP phones on the network remain out of service until they reestablish a connection with their primary, secondary, or tertiary Cisco CallManager.

--------------------------------------------------------------------------------

Typically, it takes three times the keepalive period for a phone to discover that its connection to Cisco CallManager has failed. The default keepalive period is 30 seconds. If the phone has an active standby connection established with a Cisco SRST router, the fallback process takes 10 to 20 seconds after connection with Cisco CallManager is lost. An active standby connection to a Cisco SRST router exists only if the phone has the location of a single Cisco CallManager in its CallManager list. Otherwise, the phone activates a standby connection to its secondary Cisco CallManager.

http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_configuration_guide_chapter09186a0080393a3c.html#wp1445728

Hope this helps!

Rob