Call Survivability and Call Preservation

Current Job Listings

When considering the use of Media Gateway Control Protocol (MGCP),. H.323, or Session Initiation Protocol (SIP) gateway protocols, feature support should be a consideration. This blog will cover the call preservation feature. Call preservation (aka call survivability) is a feature that allows active calls using a gateway to be preserved during a CUCM outage. Each gateway and trunk configuration device discussed in this post has a device pool with a Call Manager group configuration. The Call Manager Group configuration will accommodate up to three call managers for triple call processing redundancy. If communication to the primary Call Manager is lost, the gateway will communicate with the secondary Call Manager. If the secondary Call Manager is lost, the gateway will communicate with the tertiary Call Manager. Media Gateway Control Protocol has supported call survivability (call preservation) since it was introduced on the gateway routers, but H.323 gateways did not support this feature until Cisco IOS 12.4(9T). Call preservation SIP trunk support was introduced in CUCM 5.0. Call preservation is on by default in both MGCP and SIP, but must be provisioned for H.323. The configuration is as follows Router(config)#voice service voip Router(config-voi-service)#h323 Router(config-voi-h323)#call preserve Although the underlying premise is the same, the functionality of MGCP call survivability is a bit different than H.323 call preservation. If communication between an MGCP gateway and the CUCM server that setup the active calls is lost, the call continues over the gateway. A message on the LCD of the screen will display the following message: “CM Down, Features Disabled”. At this point, supplementary services including call hold, park, transfer, conference, etc. will not work. New calls to the MGCP gateway will not work until the MGCP gateway re-registers with the backup call processing servers (secondary CUCM server in the Call Manager group). All new calls from the PSTN through the MGCP gateway will fail during this graceful failover. The failover mode can be configured to switchover to the secondary CUCM immediately, but then all active calls through the gateway would be lost. If MGCP is a requirement, and high availability is a concern, it is advisable to have two MGCP gateway with two different Call Manager group configurations. MGCP gateway A would have CUCM server A as the primary server and CUCM server B as the secondary server; while MGCP gateway B would invert the server relationship (Primary: server B, Backup: server A). Call routing from the PSTN service provider would still be a consideration. If inbound call routing was performed on the MGCP gateway that did not have communication to CUCM, the inbound calls would fail. The voice interfaces to the PSTN still have carrier detect (CD) so the provider would not know there was a call processing outage at the site. Although H.323 call preservation support may require an IOS upgrade on the gateway routers, the H.323 call preservation offers more functionality while providing additional fault tolerance. If communication between an H.323 gateway with call preservation provisioned and the CUCM server that setup the call, the gateway would immediately begin to use the backup Call Manager for supplementary services, outbound call routing, and inbound call routing. The gateway router would need to have multiple VoIP dial-peers pointing to the CUCM servers with different preference commands to configure dial-peer hunting. The following is a sample configuration example: Router(config)#voice class h323 1 Router(config-class)#h225 timeout tcp establish 3 ! Router(config)#dial-peer voice 21 voip Router(config-dial-peer)# preference 1 Router(config-dial-peer)#destination-pattern 11... Router(config-dial-peer)# voice-class h323 1 Router(config-dial-peer)# session target ipv4:10.1.1.100 Router(config-dial-peer)# incoming called-number .T Router(config-dial-peer)# codec g711ulaw Router(config-dial-peer)#no vad Router(config-dial-peer)#ip qos dscp cs3 signaling ! Router(config)#dial-peer voice 22 voip Router(config-dial-peer)# preference 2 Router(config-dial-peer)#destination-pattern 11... Router(config-dial-peer)# voice-class h323 1 Router(config-dial-peer)# session target ipv4:10.1.1.101 Router(config-dial-peer)# incoming called-number .T Router(config-dial-peer)# codec g711ulaw Router(config-dial-peer)#no vad Router(config-dial-peer)#ip qos dscp cs3 signaling The voice class is very important to ensure inbound calls are processed properly during the primary CUCM server outage (10.1.1.100). When a Q.931 Setup message is sent from the carrier’s class 5 switch, the carrier starts the T.310 timer. If a Call Proceeding message is not received from the destination site within 10 seconds, the carrier will play reorder tone to the calling party. Unfortunately, the default timeout mechanisms in the VoIP dial-peer are also set to 10 seconds. By the time the router attempts to route a call to 10.1.1.101 (preference 2 / dial-peer 22), the carrier has already timed out the call. The H.323 voice-class configuration used in the example above will fix this situation. Feel free to ask any questions regarding this blog entry or to share any of your knowledge regarding call survivability mechanisms. H.323 Call Preservation http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/cisco_ios_h323_configuration_guide/old_archives_h323/4gwconf.html#wp1149764

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:
Now read: Getting grounded in IoT