I got the msg: RouteListExhausted. HELP PLEASE!!!!

[wflores]

The complete msg is the following:

At 15:44:22 on 03/19/2007 on cluster StandAloneCluster.

Number of RouteListExhausted events exceed 0 within 60 minutes.

I have a callmanger 4.2 using MGCP gateway with 5 E1s is CISCO 2851.

It has 3 PVDM2-64.

Around 150 IP phones in the LAN.

Around 40 IP phones in the WAN.

I?ve received this message very frequently, I read that could be two issues:

1. There are no B channels enable for the CCM get through the call.

I tested each E1 ISDN PRI alone connect to the gateway and the 5 E1s work fine.

2. The resources (DSPs) of the gateway are not enough.

BUT HOW TO KNOW, which one of the two issues about is???

Besides when someone wants to call from the IP phone in the LAN, receives the message on the phone?s screen OUT OF BANDWITH.

Besides I configured only one Route List

and one Route Group for the 5 E1 ISDN PORTS.

ANY HELP WILL BE APRECIATED

REGARDS

W.F.

[thisisshanky]

This thread may help.

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Unified%20Communications%20and%20Video&topic=IP%20Telephony&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.1ddcd9e8/0#selected_message

[wflores]

Thank very much for answering.

I already read this conversation.

What I?m looking now is how to determine if there aren?t B channels idle on the E1s OR

THE RESOURCES OF THE GATEWAY are running out??

Regards

W.F.

[Zin.Karzazi]

Use RTMT for that. Open RTMT->Performance->YOur CCM-> Cisco H323 (or MGCP, depends on what you are using)-> Double Click Call Active-> select Gateways you have-> you will now have a graph showing the number of all B Channels used, right click on it select-> Alert / Treshold-> Enable Alert (Severity: Warning-> Click Next: on "trigger alert when the following condition meet" select a Value ie Over 25 (which means when 25 B channels are simultanueously used you will get an email alert of it). Do this for all Gateways and all Callmanager processing Calls.

HTH

Zin Elabidine Karzazi

[MARTIN STREULE]

If you think you have enough channels, this is probably a false positive.

Here an interesting thing I found:

http://www.tek-tips.com/viewthread.cfm?qid=1238879&page=1

Routelistexhausted means that a call was made and callmanager has gone through all devices in the route list and cannot route the call. You will get this if someone dials a wrong number... so most likely you are getting this error not really meaning it indicated a call not completed.

Cheers,

Martin

[jsailers]

This has been a struggle for me. We get these often, and there have been times we were out of B-Channels, but most often it's because the caller dialed the wrong number. I haven't found a way to tell whether it was a false-positive or not.

One suggestion would be to use the datetimestamp of the error, then look in the CDR records at that time to find the call that failed.

[johnnylingo]

Can you provide some examples of numbers the user mis-dials?

I see a couple of these a day, but since they are zero duration they are not logged to CDR by default. I've changed this setting, but am just curious as to what types of numbers you saw this for.

[jsailers]

Any time you dial a number that is "out of service" you get an error message from the telco saying such. This may result in a message that comes accross on a PRI D-Channel with a generic disconnect cause code. This could cause this alert to be raised.

When I say someone misdialed a number, I mean that they dialed someone's number but was off by a digit and the resulting number isn't actually an assigned number at the far-end telco. That has caused this alert to be generated in the past for me.

Another example is someone calling into a radio station to participate in a contest, but all the lines were busy. The resulting Q.931 disconnect cause code may trigger this alert.

If it happens regularly, you could turn on isdn q931 debugging on the gateway and log it to a syslog server so you can correlate the CDR record with the actual cause code on the gateway. I would just be careful to not leave that debugging on for long. If you have a gateway that takes a lot of calls, you might not want to do this at all. The CDR record should give you a disconnect cause code that may be useful as well.