cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays
3415
Views
133
Helpful
21
Replies
Felipe Ramos
Beginner

Intercluster Trunk Rejecting Calls - RTMT RouteListExhausted Reason=41

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

1 ACCEPTED SOLUTION

Accepted Solutions

Its just the Route List acting up..Its that simple..Glad to know its working..Dont forget to rate the posts and mark the thread as answered to help others in the future           

Please rate all useful posts

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

Please rate all useful posts

View solution in original post

21 REPLIES 21

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"

Please rate all useful posts
Suresh Subramanian
Rising star

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.

//Suresh Please rate all the useful posts.
Felipe Ramos
Beginner

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
Rising star

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 Please rate all the useful posts.
Suresh Subramanian
Rising star

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.

//Suresh Please rate all the useful posts.
manpres2
Beginner

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
Beginner

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.

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"

Please rate all useful posts

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

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"

Please rate all useful posts

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.

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"

Please rate all useful posts

##1275 9994 From NY to Brazil

##1269 2000 From Brazil to NY

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"

Please rate all useful posts
Content for Community-Ad

Spotlight Awards 2021