SRST router stucks in fallback mode when WAN is up

Unanswered Question

Hi,

CCM 5.1.1 at center office, two remote sites have Cisco 2821 with T1/PRI configured with standard SRST in one site, and CME-srst in another site. IOS is ipvoice 12.4(15)T1.

When wan is down, the inbound/outbound calls for ip phones can work fine as expeected; while when WAN is up, from both voice gateways, we saw the gateways are still in fallback mode, even I issued "no mgcp" and "mgcp", while on CCM webpage, it shows the voice gateway are registered. but inbound/outbound calls can not go through.

The only work around for me at this moment is that we reboot the voice gateways when WAN is up, then both voice gateways are registered to CCMs and all calls can go through.

Is there anyone experenced this problem of SRST router stucks in fallback mode and how to solve the problem?

thanks,

JJ

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
pcameron Wed, 01/16/2008 - 03:50

Generally this problem occurs when the D channel command 'isdn bind-l3 ccm-manager' is missing after the router restores the connection to the CCM after coming out of SRST mode.

When the router detects it has lost the connection to the CCM and it goes into SRST, it is supposed to automatically remove the 'isdn bind-l3 ccm-manager' command from the D channel to enable local ISDN call processing. When the router re-establishes the MGCP session , the command should be automatically added back to the D channel.

Assuming you are using the config download option, when you reboot the router the CCM will rebuild the entire config and download it to the gateway, restoring normal operation.

Normally this works well ... but there is a condition when it can fail based on a combination of circumstances. It's caused by having a POTS dial peer referencing a PRI port that has 'service mgcpapp' configured on it.

For MGCP operation on PRI, you only need the following commands -

controller t1 0/0/0

pri-group timeslots 1-24 service mgcp

and

interface serial 0/0/0:23

isdn bind-l3 ccm-manager

If you configure 'service mgcpapp' under a POTS dial peer , it sets up a competing MGCP stack that conflicts with the above commands. This prevents the router from re-adding the 'isdn bind-l3 ccm-manager' command to the the D channel, so the D channel backhaul fails after the MGCP session has been restored from SRST.

Confirm if you have 'service mgcpapp' configured under any POTS dial peers that reference the D channel.

dial-peer voice 1 pots

service mgcpapp <----remove this !!!

port 0/0/0:23

If this does not help, do a SH RUN after the WAN has dropped to confirm the bind command has been removed, then restore the link to the CCM and do another SH RUN after a minute or so to see if the bind command has been re-added. If it is not restored, we will need to do more debugging.

CHRISTINE BERNS Fri, 02/15/2008 - 12:32

We are experiencing a similar situation with ISR 3845 routers running IOS 12.4(11)T4. Can you post the bugid and/or what you had to do to solve the problem?

CHRISTINE BERNS Mon, 02/18/2008 - 07:09

Thank you... We are already running 12.4(11)T4, so I suspect we are experiencing a slightly different condition that is causing our PRI backhaul to fail. Our PRI backhaul fails whenever the router reboots due to a power failure at the site or power cycle of the router at the site. But, a "no mgcp" followed by "mgcp" always restores the backhaul. Interestingly, when we do a manual reload of the router, the PRI backhaul is established correctly without us having to do the "no mgcp" and "mgcp".

webstd.design Mon, 02/18/2008 - 08:10

How can I test SRST function without get down WAN link?

can you give me the real example of ACL ?

thank you

Example:

LAN--Remote Router1(Serial0)--_WAN---HQ(Router)-CCM(10.1.1.1, 10.1.1.2)

On remote site router1 serial0 interface put the following inbound ACL:

access-list 10 deny host 10.1.1.1(ccm1)

access-list 10 deny host 10.1.1.2(ccm2)

access-list 10 permit any

you need make sure that on remote site, there is no any other routes to learn the CCM subnets otherwise, you also need put the same ACL on that interface.

Hope it helps.

Michael Owuor Mon, 02/18/2008 - 09:47

Another option that may work is to add a static route that references the host addresses of the CCM servers and point them to the null interface thus:

ip route 10.1.1.1 255.255.255.255 null0

ip route 10.1.1.2 255.255.255.255 null0

Regards.

Actions

This Discussion