SRST Outbound Dialing Issues

[Joshua Falso]

Hello,

I am having trouble figuring out why my outbound calling is not working in SRST. During normal operation calls are sent to the GW with 11 digits so I setup the SRST dial-peer to forward 11 digits on LD calls to the carrier. I have tried forwarding all, 10 and 7 but nothing works. When I ran debugs on the ISDN q931 it does not even show the call, it is like the dial-peer does not forward the call to the serial interface. Any ideas what I am missing here? I have attached the debugs of the dial-peer.

Here are the details:

All phones are SCCP.

Normal Operation

MGCP controlled Gateway with PRI/T1

SRST Config

dial-peer voice 40000 pots

description ***SRST Long Distance Outbound***

destination-pattern 71[2-9]..[2-9]......

incoming called-number .

direct-inward-dial

port 0/0/0:23

forward-digits 11

interface Serial0/0/0:23 

no ip address

encapsulation hdlc

isdn switch-type primary-ni

isdn incoming-voice voice

isdn bind-l3 ccm-manager

isdn bchan-number-order ascending

no cdp enable

Debug 

ISDN q931 does not show the call hitting the T1

Debug Dial-Peer shows call hits DP 4000 Pots

Match Rule=DP_MATCH_DEST; Called Number=719194400699

005280: Apr 10 15:33:08.549: //-1/D0C23845AE4C/DPM/dpMatchPeersCore:

   Result=Success(0) after DP_MATCH_DEST

005281: Apr 10 15:33:08.549: //-1/D0C23845AE4C/DPM/dpMatchSafModulePlugin:

   dialstring=719194400699, saf_enabled=1, saf_dndb_lookup=0, dp_result=0

005282: Apr 10 15:33:08.549: //-1/D0C23845AE4C/DPM/dpMatchPeersMoreArg:

   Result=SUCCESS(0)

   List of Matched Outgoing Dial-peer(s):

     1: Dial-peer Tag=40000

[R0g22]

I see the following number being dialed -

005937: Apr 11 12:13:06.006: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Match Rule=DP_MATCH_DEST; Called Number=719194400699

and then see the IOS rejecting it -
005942: Apr 11 12:13:06.006: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
Result=NO_MATCH(-1) After All Match Rules Attempt

Is this on a ISR-4k ? Also, did you check with "sh ccm-manager" once in srst if the fallback did trigger correctly ?

[Maren Mahoney]

It looks to me like there is a loop on matching the 40000 dial peer in the full debug.

You are showing your SRST config. Can you also show the part of your config where you configure mgcp fallback? The section will start with "call-manager fallback-mgcp".

[Joshua Falso]

The problem ended up being with the way I failed over my CIPC. I used a windows firewall rule to block communication to the Call Managers which allowed my CIPC to failover to the router and register. Even though my CIPC registered to the router and could dial, I could not ping the phone itself from the router which is why I can't dial out. No idea how the phone can register to the gateway but can't be pinged.

[R0g22]

That's why I mentioned to check through "sh ccm-manager" if SRST triggered correctly or not. With MGCP, the gateway needs to lose connectivity with the CUCM so that fallback get's triggered. This is a common mistake that I have seen a lot of people do to test SRST. It works if your GW is H.323 or SIP but does not with MGCP.

[Maren Mahoney]

Next time you want to test like this, put an ACL on your remote gateway that blocks the IP addresses for CUCM inbound and outbound. That will cause the router as a whole to fail over.

[Joshua Falso]

Do you have an example list? I have tried ACL's before and have not had success. My goal is to test SRST with a single phone before doing a cluster wide test.

[Maren Mahoney]

Your underlying problem was not that the phone did not failover to SRST, because it did. The problem was that the MGCP process on the router did not failover. So the easiest thing is do a test failover for the entire remote site, perhaps during a maintenance window or over the weekend.

Block CUCM to the entire remote site:
access-list 100 deny ip any host <ip.of.cucm>
access-list 100 deny ip host <ip.of.cucm> any
access-list 100 permit ip any any

interface gi 0/0 (inbound WAN interface at the remote site)
 ip access-group 100 in
 ip access-group 100 out
(You'd think you would not need both directions for the ACL, but in my lab it's the only way to make it work.)

It is possible to block CUCM to just the phone, but to block it to the MGCP process requires that MGCP is bound to a specific IP on the remote router as is call-manager-fallback. Using a loopback for both is a good idea.
access-list 101 deny ip host <ip.of.phone> host <ip.of.cucm>
access-list 101 deny ip host <ip.of.cucm> host <ip.of.phone>
access-list 101 deny ip host <ip.of.loopback> host <ip.of.cucm>
access-list 101 deny ip host <ip.of.cucm> host <ip.of.loopback>
access-list 101 permit ip any any

A third possibility is to create a CMG with just one call processing node in it, create a new device pool with that CMG (and the SRST reference, etc.), assign that DP to the MGCP router and to the phone (which will require an apply-config on both), and then stop the Cisco CallManager Service on just that one CUCM server. This will cause both to failover to SRST.

[R0g22]

You cannot do that with MGCP. What you are trying to achieve is possible with H.323 or SIP. With MGCP, the gateway needs to be released of the CUCM control. Your IP phones will register to the GW but your ISDN L3 will still be back hauled. You won't be able to make calls in that scenario.

Do it in a lab that's your best bet.

[Maren Mahoney]

Then the CMG/DP option is your best bet.