Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

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

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.

8 REPLIES
Green

Re: One Way Calling on Intercluster trunk between 4.1.3 and 3.3.

Hi Smburke,

Could you please upload the detailed CCM|SDL trace.

Checking H245 options.

Do you have a firewall in the middle, ACLs or other devices that my be blocking some ports?

If you have Cluster1 which points to Cluster2.

The ICT in cluster 1, contains all the CCMs for the Device Pool|Call Manager Group| of ICT in cluster 2?

Let us know.

G

New Member

Re: One Way Calling on Intercluster trunk between 4.1.3 and 3.3.

Attached is a zip containing traces for all call managers in both clusters. The call is initaiated from extension 43867 in the PHL cluster bound for extension 36229 in the CMH cluster. We have all the CCM IP's in the ICT configs on both clusters. There should be no restrictions on any IP traffic between the two clusters.

Green

Re: One Way Calling on Intercluster trunk between 4.1.3 and 3.3.

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

New Member

Re: One Way Calling on Intercluster trunk between 4.1.3 and 3.3.

It looks like the H245 trace option wasn't checked. I'll reset everything and run another pair of test calls.

We have the IP's of each cluster's servers in the ICT configuration. When you say 'make sure the order is correct', what is the correct order? Is it publisher, subscriber, subscriber?

We have run tests to phones registered to all three CM's in the destination cluster, and to another cluster at another location, all with the same result.

I just tried the CCM reset on each server in the destination cluster, still no dice.

We do have a TAC case open. We'll probably pick it back up first thing tomorrow morning (our engineer left at 2 today, and we're about to break for the night).

I appreciate all the insight you're giving us.

Attached is a new set of traces from a series of test calls from 43867 to 36229, 35001, and 36420, all in the same destination cluster.

Green

Re: One Way Calling on Intercluster trunk between 4.1.3 and 3.3.

Ok, I mean the order would be First,second, third depending the CCM group of the remote cluster ICT.

If in cluster 1 the CCM Group of the ICT contains.

SUB,PUB. Configure in cluster 2 ICT First the SUB, then the PUB. The same for the other ICT.

Could you please let me know which case number is?

I will check the traces and get back to you.

//G

New Member

Re: One Way Calling on Intercluster trunk between 4.1.3 and 3.3.

OK, now I understand the order. They are set correctly in the ICT's.

Our TAC case is 603960735.

We're setting up sniffers at both ends to verify that the traffic is getting completely across, but haven't had a chance to run them yet.

New Member

Re: One Way Calling on Intercluster trunk between 4.1.3 and 3.3.

After some digging, it appears that the one endpoint on the VPN between our two

sites, a Checkpoint Firewall, may be the issue. The administrator of the

Checkpoint is seeing some drops in the logs:

Here are some drops

Number: 651529

Date: 17Jul2006

Time: 14:09:06

Product: VPN-1 Pro/Express

Interface: q57w2k1

Origin: SECAUCUS_FW (63.240.103.251)

Type: Log

Action: Drop

Protocol: tcp

Service: H323_any (1720)

Source: CMPHL41-2 (10.40.2.11)

Destination: 10.12.1.12

Source Port: 53710

Information: H.323 reason: Malformed H.225 message

Number: 651672

Date: 17Jul2006

Time: 14:09:09

Product: VPN-1 Pro/Express

Interface: q57w2k1

Origin: SECAUCUS_FW (63.240.103.251)

Type: Log

Action: Drop

Protocol: tcp

Service: H323_any (1720)

Source: CMPHL41-2 (10.40.2.11)

Destination: 10.12.1.10

Source Port: 53713

Information: H.323 reason: Malformed H.225 message

The firewall admin is opening a case with checkpoint on this.

New Member

Re: One Way Calling on Intercluster trunk between 4.1.3 and 3.3.

did you ever find a fix for this? I am running into the same problem with my install. I am running checkpoint NGX R60. By the looks of it, R60_HFA_01 hotfix from checkpoint will fix this. They are at R60_HFA_04 release so I think I may try this since it includes previous hotfixes. Just wanted to see how you were able to resolve the problem.

595
Views
0
Helpful
8
Replies
CreatePlease login to create content