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?
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
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 !!!
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.
Thanks for your reply. This is very helpful.
We finally opened a TAC Case, the issue was related to an IOS bug when more than one redundant hosts configured for mgcp redundancy. When it has only one redundant host configured, the SRST voice gateway can register to CallManager soon when WAN is restored.
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?
The bug that you are running into is CSCsl78850. It affects some versions
of 12.4T. The plan is to downgrade your router to 12.4(11)T4, which the
developer said wouldn't have the problem.
The workaround (which will let you continue to use your current version is
to specify only one redundant host in your config.
from TAC Engineer
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".
How can I test SRST function without get down WAN link?
can you give me the real example of ACL ?
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.
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