There are 4 H323 gateways and a 21 node CUCM cluster connected through WAN .
Also there is a network acceralator [Riverbed] and firewalls between them .
Call Flow : Telco---PRI--H323 GW---CUCM---IP Phone
There is an intermittent call drop issue for both the incoming and the outgoing calls.
Following is explanation on the 2 parameters namely :
1) Enable Inbound FastStart : This checkbox is used to force "FastStart" for inbound calls between CallManager and the gateway.
There are two types of negotiations between a h323 gateway and callmanager - Slow Start and Fast Start.
The difference is the time needed to establish a conversation over H.323. In 'call start
fast' a fastStart element is added to the H.225 setup indicating which codec, IP address
and port to use for RTP.
In 'slow start' there are implementations that wait until after the CONNECT to negotiate IP addresses,
ports and codecs. In 'slow start' mode a lot more H.245 messages are exchanged over a (possible) separate TCP connection.
In 'fast start' mode, the transmitted H.225 SETUP message is a lot larger (the more suggested codecs, the
larger). Hence there are no implications as such, it is just the way h245 negotiations are done
between the gateway and the callmanager.
2) Wait for Far End H.245 Terminal Capability Set : This step enables Cisco
CallManager to send the Terminal Capability Set (TCS) without waiting for the other side.
This field applies only to H.323 devices. (By default, this box is checked to specify that
Cisco CallManager must initiate capabilities exchange. This check box specifies that the
Cisco CallManager must receive the far-end H.245 TCS before it sends its H.245 TCS.)
For a h323 gateway, we generally keep it unchecked. It has to do with media capabilities
exchange between the callmanager and the gateway, as to who will send the TCS first.
Perform the following steps to resolve the issue:
1: Enable the following debug and reproduce the issue.
Debug from GW
2: Packet Capture From gateway.
From taking packet capture you can use IOS based method.
3. CUCM trace.
Is there any WAN accelerator / firewall between gateway and CUCM which can cause to block h323 packets
After the Analysis of log file ;
The calls always failed with two cause codes , namely :
From the logs it was able to analyze the for the first cause code , the gateway was
sending TCS , MSD , and not receiving the same messages from CUCM , neither was CUCM
acknowledging the gateway capabilities , this point to messages not being transmitted end
For the “temporary failure” cause code , the required , TCP connection for h.245
negotiation itself does not seems to get established (as we can see from the logs , the
h245 SM is stuck at:” H245_WAITING"
To resolve this issue you need to bypass traffic from the riverbed, as the packet drops are happening there.