Im looking for some help for the following situation.
Problem Details: We have a Cisco H323 GW configured with two dial-peer pointing to a Cisco
CCM 4.1(3) cluster build with Publisher and Subscriber.
The dial peers have preference (lowest number) for the Subcriber and then the Publisher.
The phones are registered to the Subscriber as primary and the Publisher as secondary.
We were able to preserve calls from H.323 GW to Subscriber modifying the service
parameters (Allow TCP KeepAlives For H323* >False and Allow Peer to Preserve H.323
Calls* >TRUE), we tested rebooting the Subscriber while we had calls going on on, and
it works even phones showed "CM Down, Features unavailable".
We were expecting to see not impact when we rebooted the Publisher, but for our surprise
all calls get dropped and the phones showed on the screen the Message "Temporary Failure",
for this test all phones were registered with the subscriber and the calls were setup from
H323 GW to the Subscriber.
Please help to understand why the Publisher going down affected the calls and how to fix
To understand this call disconnect issue, you need to know which CM is primary for the H.323 GW. Because only the primary CM communicates with the GW for outbound calls.
Configuration of H.323 VoIP call preservation enhancements for WAN link failures involves configuring the call preserve command. If you are using Cisco Unified Communications Manager, you must enable the Allow Peer to Preserve H.323 Calls parameter from the Service Parameters window.
The call preserve command causes the gateway to ignore socket closure or socket errors on H.225.0 or H.245 connections for active calls, thus allowing the socket to be closed without tearing down calls using those connections.
Example of H.323 VoIP Call Preservation for All Calls
The following configuration example enables H.323 VoIP call preservation for all calls:
voice service voip
Hope this helps
Please rate if posts are useful
Thanks for the replies everybody,
It looks like is is a misconfiguration on the CM Group assigned to the Gateway. We are going to fix this tonight and I will let you know the results.
about the gateway configuration we use no h225 timeout keepalive instead call preserve and it seems to work with CCM 4.1(3) but not sure about CUCM 7.1 and newer.
We have two different type of H323 gateways, AS5400xm and 2851.
AS5400xm accept both configuration "call preserve" and " no h225 timeout keepalive".
2851 accept only " no h225 timeout keepalive"
do some bosy know the difference between both?
call preserve and no h225 timeout keepalive are both used for the same general purpose, which is to preserve a call when the call processor goes down. h225 is limited however to only keep TDM-IP calls active. This means that all IP-IP calls will be dropped, regardless if the h225 command is used, whereas the IP-IP calls would be preserved if you used call preserve.
AFAIK the call preserve command is available with the faily new 12.4T code.
Hope this helps.
PS: Pl rate helpful posts
Am curious to know if there is an equivalent for SIP. We use a CUBE (sip to sip) to connect to our SIP trunk provider and am wondering if call preserve config is needed. CUCM 6.1.
Well, good news is we got this working on the H323 GW to CCM 4.1 and here is what I did.
voice service voip
!--- Previously we were using "no h225 timeout keepalive"
voice class h323 30
call preserve system
!--- This last one because our voip dial-peers have a reference to it. see below.
dial-peer voice 50004 voip
voice-class h323 30
On the CCM 4.1
Make sure the Device pool assigned to the Gateway and Phones have a CM group that contains both primary and secundary CCMs. My case then CM Group contains Subscriber then the Publisher.
Then change service parameters following the steps below.
- Service > Service Parameters
- Select the server to affect (both on my case)
- Callmanager Service
- Click Advance
- Look for Clusterwide Parameters (Device - H323) section and change the following parameters
- Allow TCP KeepAlives for H323 to FALSE
- Allow Peer To Preserve H323 Calls to TRUE
I still haver to test this on out CUCM 7.1.
Thanks to everybody who contribute.