Outgoing MGCP calls not making it to the gateway

[mainsourceC]

MGCP calls over a PRI, problem just started yesterday

Fast busy for any outgoing calls, local, long distance, 1-800 (I haven't tested 911).

Incoming calls work as they should.

This has been working correctly for over a year.

The only changes is the CUCM was upgraded to version 10 from 8 and the phone firmware was upgraded, both over a month ago.

I have reset the route lists, gateway, router, device pool, no joy.

The DNA shows calls being routed to the proper route list that includes the gateway.

Debug ISDN Q931 never shows any hits on outgoing calls, but works as expected for incoming calls.

Its like the calls are being blocked before they hit the gateway.

Everything else appears to be working as usual.

My next option is to delete and recreate everything like it was a new gateway, any suggestions before I try that?

[Ayodeji Okanlawon]

Have you bounce the mgcp process on the gateway?

conf t

no mgcp

mgcp..

If you have done that and it didnt work, then I suggest you pull cucm traces and send them over, so we can see whast going on.
 

[Aman Soi]

[+5] to Suresh and AOK.

We had a similar issue with CUCM 9 and opened TAC case. Two bugs were shared after analysing the traces as mentioned by Suresh as well.

Route Group Members being skipped and reporting as device down

CSCtq10477

Route Group Members being skipped and reporting as device down-8.x/9.x

CSCul71689

Workaround:
The following will recover the system but will not prevent the issue from re-occuring. These are alternate workarounds which could solve the issue:-
1) Restart Cisco Call Manager service or reboot the server - all nodes in a cluster.
2) Deleting and re-configuring the device 

regds,

aman

[Suresh Subramanian · Accepted solution]

do you get any Route List Exhausted alert during the outgoing call?

Please check if this bug CSCum85086 is applicable to you.

Symptom:
Outbound Calls via H323/MGCP GW (non ICT Trunk case) failing with the following error RouteListExhausted & Reason=41.

In multi-node scenarios, race condition is causing RoutePlanManager to learn trunk's status as down, while trunk is not actually down.
This is because the SM could not reflect the registration status for the trunk PID on the node that was up and running
This issue seems generic enough to happen with any other kind of trunks/GW inside the RouteList

Conditions:
The issue is triggered by a loss of connectivity of the MGCP gateway over the WAN. After this, the due to either the gateways sending RSIP (rm:graceful) or (rm:restart), they are down. But apart from this, the internal data in the SM() process is not updated of the changes.
Due to this, MGCP Endpoints in the primary route group are seens as device down when trying to route calls. Gateway is registered and inbound calls were working fine.

This issue can also occur by a CCM restart or the CCM server node going down or WAN link failure between UCM nodes.

Workaround:
1) Start with reset the MGCP gateway from callmanager admin page. If issue was not so severe, it will get fixed.

2) If above is not working then next option is following:
Restart Cisco Call Manager service or reboot the server where the device is registered.
Also, deleting and re-configuring the device can solve this.

//Suresh

[mainsourceC]

I forgot to mention that we do get the RouteListExhausted & Reason=41.

This sounds like the issue.

I'll try restarting the server tonight.

I have tried restarting the MGCP process on the local router.

[Suresh Subramanian]

could you please try deleting & recreating the RL,RG once before restarting the servers and check if it helps?

Also you may directly assign the MGCP endpoint (if it is only one) to the route pattern and try the outgoing calls instead of RL. The issue is most likely that the RL fails to find the devices under it.

[mainsourceC]

Yes I can try that first, tonight.

[mainsourceC]

Here is what I tried:

Creating a new RG and having it listed in the RL, reset the RL, no joy.

From the bug listed above, the issue seems to be with the CUCM server being used by the phone, I then tried this:

We have more then one CUCM manager group, so I went to the phones DP, changed the CUCM manager group, then reset the DP and the phones. This fixed the issue, the phones are now working as they should.

Note, we have over 1,200 phones, this issue only affected the 14 phones in this device pool.