Showing results for 
Search instead for 
Did you mean: 

Intermittent inbound call failure via H.323 faststart



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 :

  • Enable Inbound FastStart
  • Wait for Far End H.245 Terminal Capability Set

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

  • debug voip ccapi inout
  • debug h225 asn1
  • debug h245 asn1
  • debug cch323 h225
  • debug cch323 h245

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 :

1)Resource unavailable/unspecified

2)temporary failure

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

to 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.

Related Information

Recognize Your Peers
Content for Community-Ad