MGCP Controlled FXS Port still hitting outbound H323 Dial Peers

[shane.orr]

Layout:

Centralized CUCM 7.1.3

Remote Site 2951 Voice Gateway

IOS 15.1.2T

2 x PRI MGCP Controlled

23 x FXS Ports MGCP Controlled

Configured with CME as SRST

All FXS Ports are registered with CUCM properly and can accept inbound calls from the PSTN or from IP Phones.

However, dialing out from the FXS Ports fail becauase they are matching dial-peers that are configured on the router for SRST only.  Both attempting to call an IP Phone or PSTN outbound both fail.

PSTN calls fail because it matches a dial-peer with destination-pattern 9 but the PRI port is not failover mode so the D channel is backhauled to CUCM.

IP Phone Calls fail because it is matching an ephone-dn telephony-service dial-peer configured for whatever extension I am trying to dial.

Why is an MGCP controlled FXS Port matching H323 Dial Peers when dialing out?

I will attach my configuration.

[shane.orr]

And to add to the strangeness we attempted to dial out on all Ports and turns out only Ports 1/0/0, 4, 12, 20, and 22 do not work.  All other ports work as expected.

[Steven Holl]

 Why is an MGCP controlled FXS Port matching H323 Dial Peers when dialing out?

This is because it's a valid inbound dial-peer match, as per:

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010fed1.shtml

The easy fix is to add 'service mgcpapp' to the H323 POTS peers, so that if those peers are matched inbound, it still kicks to MGCP.  Then, as long as you have 'service alternate DEFAULT,' when MGCP goes down, it will ignore the service command on that peer and treat it as an h323 peer.

[shane.orr]

I added service mgcpapp to all dial-peers that have a destination pattern that start with 9 and unfortunately it is still matching on PSTN calls for some reason and getting a busy as a resulte.  The strangest thing is this is only happening on 5 out of 24 FXS Ports.  That is what is so strange.  It is like MGCP is loosing some sort of call control on those random ports on outbound calls intiated by analog devices.

Much appreciated.....

[Steven Holl]

Then run a debug voip ccapi inout, find out what inbound dial-peer is being matched when the call goes offhook, and add 'service mgcpapp' to that peer.  You're missing one somewhere.

[Steven Holl · Accepted solution]

And I re-read this post:

I added service mgcpapp to all dial-peers that have a destination 
pattern that start with 9 and unfortunately it is still matching on PSTN
 calls for some reason and getting a busy as a resulte.

You want to add 'service mgcapp' to *all* POTS dial-peers, not just the ones with destination pattern starting with 9.  Destination-pattern is irrelevant for inbound dial-peer matching since you have 'incoming called-number .', so it's never going to look at dest-patt off ANI for a inbound match.

If that doesn't fix it, you're hitting dial-peer 0, but I doubt that since you have 'incoming called-number .' which will match anything.

[shane.orr]

You are definitely right but it gets complicated with CME as SRST.  I am in the process of taking inventory of the all analog extensions but I suspect that the ones in question accidentally have ephone-dn setup because the first one that I debugged "ccapi inout" it was matching a telephony-service hidden dial peer and then outbound dial-peer 0 so you got me on the right track.  Just need some time to map it all out.  I will post back.

Again much appreciated.