There are a couple of reasons why this happens, all of them ultimately due to the h225 TCP session not opening between the CallManager and the gateway.
First is the IP address the gateway is using as a source address is different to what the CCM has configured. The CCM does not accept anonymous H225 connections - it needs to know the originating IP address. By default, IOS uses the IP address of the egress interface the packets leave the router from, so in this case, unless you have a H323 bind command configured, the source address of the signalling will be the closest interface pointing to the callmanager. If your CCM has the IP address of the remote Fast ethernet as the gateway IP address, then the call will fail in the direction GW-->CCM, but will work fine CCM-->GW since IOS (by default) is happy to accept traffic to any local interface IP address.
Assuming the CCM has the IP address of the Fast ethernet configured, but the router has a WAN port , the fix would be to add this command under the FE interface -
h323-gateway voip bind scraddr
2) There is a firewall in the middle blocking certain traffic types such as H323. You may be able to see this by doing a 'debug ip tcp transaction' to look at the 3 way handshake that opens the session. Otherwise ask the firewall administrator to pass this traffic type.
3) there could be some kind of TCP MSS issue. By default, IOS will use H323 fast start, so it will embed h245 caps and negotiation messages inside the initial h225 signaling to speed up the call connection process. This can make some of the H225 packets exceed the default Maximum Segment Size (MSS) across the network. If there are GRE tunnels, VPN's, IPSec or similar in the path, the packet size may be too large to be handled by the intermediate network and it may get dropped. Other traffic passes without any problems so pings, telnet ssh etc ... all work fine, only H323 fails. A quick and dirty test for this is to reconfigure the signaling as SIP ... the SIP packets are smaller, less of them and UDP based so they pass across the IP cloud unobstructed.
Since the calls are working in one direction, I would take a guess and say it is probably due to (1) - confirm if you have the bind command , if not, add it and make sure the interface you bind to is the one that is configured in the callmanager gateway setting.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...