One Way Calling on Intercluster trunk between 4.1.3 and 3.3.x

Question

We've encoutered a bizarre situation, one which so far even TAC is stumped on.
We just turned up a new site, running 4.1.3SR3b and have set up the usual intercluster trunks (non-gatekeeper) between the new site and our other sites. Most of our other sites are 3.3.4 or 3.3.5. Calls from the other sites to the new 4.1.3 site work fine, but when you try to call from the 4.1.3 site to another site, the phone rings on the receiving end for a split second (not even a full ring), then the calling end gets a fast busy. Detailed traces on both ends show the info getting to the receiving end, but when the call drops, this appears on the sending end:
07/15/2006 11:30:38.499 CCM|StationD: (0000129) DEBUG- star_DSetCallState(6) State of cdpc(337) is 5.|<CLID::StandAloneCluster><NID::10.40.2.11><CT::0,0,0,0.0><IP::10.12.1.12><DEV::>
07/15/2006 11:30:38.499 CCM|H225D::restart0_TcpStopSessionInd: H225Cdpc(2,100,38,91), ConnPid(2,100,132,258), crv=12, mCiCrCrpEntries=1, mCrtoCiEntries=1|<CLID::StandAloneCluster><NID::10.40.2.11><CT::0,0,0,0.0><IP::><DEV::>
07/15/2006 11:30:38.499 CCM|Cc::wait_CfDataInd, total fie to handle is 0 |<CLID::StandAloneCluster><NID::10.40.2.11><CT::0,0,0,0.0><IP::><DEV::>
07/15/2006 11:30:38.499 CCM|ConnectionManager - wait_AuDisconnectRequest:NO ENTRY FOUND IN TABLE,CI(33555134,33555133),dcType=1,IFCreated(0,0),PID(0-0,0-0),IFHandling(0,0),MCNode(0,0)|<CLID::StandAloneCluster><NID::10.40.2.11><CT::0,0,0,0.0><IP::><DEV::>
We just tried the latest engineering special (63 I believe), but the issue remains. Has anyone encountered this before?
This occurs with either G711 or G729 codecs, with or without MTP's enabled on the intercluster trunks.

Answer 1

Hi,
Did you checked the H245 Options in the CCM trace options?
I dont see any H245 messages in CCM.
I see that this IP Phone (43867) is registered to node 2.
Is this the SUB in PHL cluster?
We sent a H225Setup sent to IP=10.12.1.12
In the other side:
H225Handler::SdlConnectionInd: from IP=10.40.2.11
If this non-gatekeeper-controlled intercluster trunk accesses the device pool of a remote non-gatekeeper-controlled intercluster trunk and that device pool has a second Cisco CallManager node, you must enter the second remote Cisco CallManager IP address/host name in this field. (ie. Cluster1 4 servers and Cluster2 2 servers
ICT1 has a CCM Group which contains 3 servers.
ICT2 has a CCM Group which contains the 2 servers
In ICT1 you need to enter the 2 server's IP addresses.
In ICT2 you need to enter the 3 server's IP addresses)
Make sure the order is correct.
In the incoming cluster I see IP Phone is registered to node 3.
Node selection for outgoing calls is controlled by which node the originating endpoint is registered with. If the originating endpoint is registered to the same node as the H.323 Trunk, the call is signaled from that node. If the originating endpoint is not registered to the same node as the H.323 trunk, a random selection is made between all nodes configured with the H.323 trunk
This error is the one which terminates the call taken from SDL in CCM SUB 3.
SdlSig-I | CcDisconnReq | restart0 | StationD(3,100,92,87) | LineControl(1,100,37,2258) | (1,100,101,34868).1-(*:*) | [NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0] Cause=41
Temporary failure (cause code 41)
Normally this happens when GW, in this case the ICT is not registered correctly.
In CCM PHL, I see this:.
000221594| 06/07/15 11:30:38.499| 002| SdlSig | TcpStopSessionInd | restart0 | H225D(2,100,39,33) | H225Handler(2,100,40,1) | (0,0,0,0).0-(*:*) | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0] PID=(0,0,0,0)
000221595| 06/07/15 11:30:38.499| 002| SdlSig | TcpStopSessionInd | call_received7 | H225Cdpc(2,100,38,91) | H225D(2,100,39,33) | (0,0,0,0).0-(*:*) | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0] PID=(0,0,0,0)
This means that TCP connection was ended. By checking the SDL looks like destination node send a RST at TCP level and thats why call finishes. But problem seems to be the CMH cluster.
If ICT configuration is fine I would reboot|restart ccm.exe service in the CMH cluster.
If after that it doesnt work I would open a TAC case so we can get access and check whats going on.
HTH
//G