Inbound calls on MGCP-controlled FXO port not reaching CUCM

[Lando.Griffin]

Hi, we have a VIC2-4FXO card installed on a Cisco 2921 ISR. The FXO ports on it are MGCP controlled. We can call out over the ports, but external calls can't call in.

The behavior we experience is that the external caller hears ring back that never stops, but the onsite phone never rings.
I checked trace logs using RTMT and it doesn't appear that CUCM ever gets the call attempt. This router also has a PRI, and calls in and out over the PRI work just fine. 

Some troubleshooting so far:
-Router reboot.
-If we disconnect the POTS lines normally running into these FXO ports and connect them to a buttset, incoming calls work fine.
-Tried removing and re-adding FXO config in both router and CUCM Gateway config.
-Tried replacing the VIC2-4FXO module with a spare.
-IOS is the most current.

Here is the ios config for the first FXO port:

voice-port 0/2/0
no vad
no comfort-noise
timing hookflash-out 50
timing guard-out 1000
connection plar 1000
caller-id enable

As you can see, calls are going to extension 1000. 1000 is also entered as the Attendant DN on the Gateway config page in CUCM. 1000 is assigned as the primary line to a registered phone.
The voice port on the Gateway page in CUCM is assigned to a CSS that can reach the phone.

The FXO port has a dial peer assigned by MGCP:

dial-peer voice 999020 pots
service mgcpapp
port 0/2/0

And when I run "show dialplan number 1000" from the CLI on the router I get this outbound dial-peer, which points to the IP of our Call Manager:

dial-peer voice 56 voip
destination-pattern 1000
session target ipv4:10.14.160.3
dtmf-relay h245-alphanumeric

I'll attach the entire "Show Run" output, as well as the output from a test call in which the following commands were running:
Debug voip ccapi inout
Debug vpm signal
Debug voip vtsp session

Can anyone help me figure out what the issue is, or at least suggest new troubleshooting steps? I'd be in your debt! Thanks!

[Nithin Eluvathingal]

If its a MGCP controlled port remove "connection plar 1000" from voice-port 0/2/0.

I prefer to use H323 than MGCP when using FXO.

[Lando.Griffin]

Thanks. I tested, but the problem continues.

[mradell]

If I recall correctly, as long as those FXO ports are in a registered state to the CUCM via MGCP they are going to ignore any dial peers except the default created MGCP dial peer for that port. Reason being is that in MGCP all the call routing is going to happen inside the CUCM, not the gateway. It appears you want that FXO port to ring to DN 1000. To accomplish that with it as an MGCP controlled port you need to set that in the config for the FXO port in CUCM under "Attendant DN".

 

[Lando.Griffin]

Thanks. That's correct, and as I stated in the original post, I have the Attendant DN set to 1000 in CUCM, just as you indicated in the screenshot.

The problem continues.

[Nithin Eluvathingal]

On shared debug I can see calls to 1000 with outbound dial peer 56. Which is you dial-peer to CUCM.

and I can see disconnect cause 38.

does your FXO port showing status registered ?

[Lando.Griffin]

Thanks. Yes, the FXO port shows as registered in CUCM.

[mradell]

Apologies, I see that now. Have you tried any MGCP debugs to see what might be happening with the MGCP signaling between the Gateway and the CUCM? You may want to try running debug mgcp events and debug mgcp packets and see what the resulting output might indicate.

[Lando.Griffin]

Thanks, I just checked those debug MGCP commands both in and out of a call, and the entries don't seem to indicate any kind of a problem with MGCP. 

[Lando.Griffin · Accepted solution]

Thanks, everyone, for your help. I have a resolution, but not a satisfying one. While troubleshooting, I once again checked to see what dial-peer was being selected, and this time it was saying it was trying to grab an outbound dial-peer, one that I'd setup for use with SRST. No reason why it should have grabbed it that I could see. I removed it, and then inbound calling worked fine. Funny thing is, I re-entered the dial-peer, just to see what would happen (knowing that it should start failing again) but everything worked fine. Still working fine. Don't know if it's a bug, or what. Thanks all.