Intercluster Trunk Rejecting Calls - RTMT RouteListExhausted Reason=41

[Felipe Ramos]

Guys, need backup!

I'm setting up a ICT between two CallManagers Clusters (Brazil and NY). The calls are working from Brazil cluster to NY Cluster but not the reverse.

I'm attached the logs from NY Cluster!

Cheers,

Felipe

[Ayodeji Okanlawon]

There are no details with this log...Calling number, called number? Time of call? What do you get when you call from NY to Brazil? Engaged tone? an announcement?

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Suresh Subramanian]

Felipe,

Cause No. 41 - temporary failure.
 
 This cause indicates that the network is not functioning correctly and that    the condition is no likely to last a long period of time; e.g., the user may    wish to try another call attempt almost immediately.What it means:
 This means that there is a temporary failure at the physical layer on the ISDN  network. If you remove the ISDN cable from the Netopia, you would see this. It's usually temporary.
 

in case if you don't have the cause code list for RL exhausted, here is the link: 

https://supportforums.cisco.com/docs/DOC-29032

https://supportforums.cisco.com/docs/DOC-2759

Though not detailed info, i assume you collected the traces for a test call which was failing and found the below.

17:09:52.011 |DbMobility: getMatchedRemDest starts: cnumber = 10219994|*^*^*

17:09:52.011 |DbMobility: getMatchedRemDest: full match case|*^*^*

17:09:52.011 |DbMobility: can't find remdest 10219994 in map|*^*^*

17:09:52.011 |SMDMSharedData::findAliasRegInfo - AliasName = 6f04412f-7ec6-2509-9e86-e19da81d03b3 not in AliasInfo hashmap|2,100,13,605934.906^10.21.8.33^RJ-INFRA-0001

17:09:52.011 |DeviceManager::star_DmPidReq - RequestedName=6f04412f-7ec6-2509-9e86-e19da81d03b3 LookupName=6f04412f-7ec6-2509-9e86-e19da81d03b3|2,100,13,605934.906^10.21.8.33^RJ-INFRA-0001

17:09:52.011 |SMDMSharedData::findLocalDevice - Name=RL_Intersite_BR_RJ Key=6f04412f-7ec6-2509-9e86-e19da81d03b3 isActvie=1 Pid=(2,81,174) found|2,100,13,605934.906^10.21.8.33^RJ-INFRA-0001

17:09:52.012 |GenAlarm: AlarmName = RouteListExhausted, subFac = CALLMANAGERKeyParam = , severity = 4, AlarmMsg = RouteListName : RL_Intersite_BR_RJ, Reason=41, RouteGroups(RG_ICT_Intesites)

AppID : Cisco CallManager

ClusterID : StandAloneCluster

NodeID : ABC-SUB

>> 10219994, is this the number you dialed?

>> The RL couldn't find this number. could you please crosscheck the RP and TP?

>> ensure you are sending the right number out to the ICT and do the translation in the receiving ICT configuration if required.

[Felipe Ramos]

Hey Guys,

First, thanks very much for your help.

Answering your questions:

Calling number? 10692000

Called number? 10219994

Time of call? 17:09:52.012 (Brazil time)

What do you get when you call from NY to Brazil? Just fastbusy

I ran the DNA on this and the call is being routed correctly. Not only from NY perspective but from Brazil too.

Do you have any debug that i can run on this?

[Suresh Subramanian]

Hi, make a test call again and collect detailed ccm traces from both the cluster. Provide us the calling, called numbers and times of call.
Perhaps you can crosscheck the trunk configuration in NY cluster for the ip address of Brazil cluster and incoming call CSS

Sent from Cisco Technical Support Android App

[Suresh Subramanian]

Sorry, we need to check the trunk configuration in Brazil cucm.make sure it is configured with the IP address of the NY cluster. Also check the incoming CSS configured in the Brazil ICT to reach the correct endpoints.

[manpres2]

Check the sequence of the servers in the CM group applied on the trunk and than the target of the incoming trunk. for example if the sequence of  servers in the CM group of the ICT from NY to BR is PUB SUB1 SUB2 than the target of the trunk coming from the BR to NY should be PUB SUB1 SUB2.

[Felipe Ramos]

Hey,

Thanks all for the answers.

So... Checked again. I run DNA on both cluster for in and out calls. Everthing is perfectly on DNA.

The IP address used for the cluster in NY is one server in Brazil that is in the CallManager Group in the Device Pool of this cluster. The same for Brazil to NY. I tried to add all IP address from both cluster on each other trunks and select the option "Run on all cluster" on both trunks. The same.

When i run the SDI log on CUCM at Brazil i can see h323 info been exchanged. When i do the same in NY i can´t. As i i´m receiving this error 41, who in ISDN means no phisical connection or something like that, i´m guessing there is a service stucked.

I will try to reboot the server or restart the CallManager service, but i was not able to get a maintance windows yet.

[Ayodeji Okanlawon]

Cause code 41 means "network out of order"...

Do you see h323/h225 messages exhanged on both? If you cant see h225 messages exhcnaged on both then you need to check your ports on the firewall if you have any between them...If you see h225 setup but you dont see h245 capabilites been exchanged..then you need to also check your firewall to ensure that you have h245 dynamic ports opened..

CUCM will not exchange h225 or h245 messages until the TCP connection on the required ports are established

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Felipe Ramos]

Thanks for your answer!

I guess that is the point, but i don't know what am i missing. I cant see h225 messages from the NY cluster using the RTMT on NY. Is like that cluster was not even trying to make the call.

I tried to restart the trunk and the RL both clusters.

I'm with a open case on Cisco (625563973) too. I'm starting to belive this is a bug or pig head buried over my data center....

[Ayodeji Okanlawon]

Felipe,

Have you got the logs for the NY cluster..If you have send them over

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Felipe Ramos]

aokanlawon,

In attach. You will see i changed some address and number in the olders replays. I tought it would be more secure, but thinking straight this dont matter at all.

Thanks for your answer.

[Ayodeji Okanlawon]

Felipe,

So whats the calliung and called number in this trace

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Felipe Ramos]

##1275 9994 From NY to Brazil

##1269 2000 From Brazil to NY

[Ayodeji Okanlawon]

SO here is whats going on and why you cant find any h225 setup messages...

+++Here CUCM attempts to send the call to the route list+++

RouteListControl::idle_CcSetupReq - RouteList(RL_Intersite_BR_RJ), numberSetup=0 numberMember=1 vmEnabled=0|2,100,13,620999.1307^10.21.8.33^RJ-INFRA-0001

++Next CUCM attempts to send call to the members of the RL+++

16:52:26.196 |RouteListCdrc::algorithmCategorization -- CDRC_SERIAL_DISTRIBUTION type=1|2,100,13,620999.1307^10.21.8.33^RJ-INFRA-0001

16:52:26.196 |RouteListCdrc::whichAction -- DOWN (Current Group) = 1|2,100,13,620999.1307^10.21.8.33^RJ-INFRA-0001

16:52:26.196 |RouteListCdrc::routeAction -- current device name=58ce7d43-9866-4ffc-b0bf-1aafe588ac3c, down|2,100,13,620999.1307^10.21.8.33^RJ-INFRA-0001

16:52:26.196 |RouteListCdrc::executeRouteAction: SKIP_TO_NEXT_MEMBER|2,100,13,620999.1307^10.21.8.33^RJ-INFRA-0001

16:52:26.196 |RouteListCdrc::skipToNextMember|2,100,13,620999.1307^10.21.8.33^RJ-INFRA-0001

16:52:26.196 |RouteListCdrc::null0_CcSetupReq check vipr call mViprReroute=0 mViprAlreadyAttempt=0 CI=37384266 BRANCH=0|2,100,13,620999.1307^10.21.8.33^RJ-INFRA-0001

+++Here we see the error..CUCM says the devices are busy or stopped with a cuase code of 34 (no circuit or channel available)++++

16:52:26.196 |RouteListCdrc::null0_CcSetupReq - Terminating a call after the RouteListCdrc cannot find any more device.|2,100,13,620999.1307^10.21.8.33^RJ-INFRA-0001

16:52:26.196 |RouteListCdrc::terminateCall - No more Routes in RouteListName = RL_Intersite_BR_RJ.  Rejecting the call|2,100,13,620999.1307^10.21.8.33^RJ-INFRA-0001

16:52:26.196 |RouteListCdrc::terminateCall - Sending CcRejInd, with the cause code (34), to RouteListControl because all devices are busy/stopped.|2,100,13,620999.13

So there is the problem..CUCM is unable to reach the devices in the RouteGroups(RG_ICT_Intesites).

Can CUCM ping the ip address of the Server in the route group? Is there a firewall between the two clusters

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"