MGCP Across the WAN Not Working

[dpaige10460]

Here is the story:

One of our remote offices went SRST a few weeks back. The remote office has 70 phones and a 3845 router connecting to a call manager across 128K WAN link. Calls aren't crossing the WAN. The only voice traffic going across the way is for signaling back to call manager. SRST had been in place for 2 weeks.

All of a sudden our PRI was not able to register to call manager. We were getting no D-Channel. The PRI keep registering and unregistering from Call Manager. We had the carrier come out with a t-bird and everything tested clean. After testing we still couldn't get the PRI to register. Layer 1 was good but we couldn't get layer 2 or 3. CiscoTAC thought it might be IOS bug so we upgraded the to 12.4.8c IOS code which was supposed to resolve this "bug" but of course it didn't. We also tought it was bad hardware so the shippied a replacement 3845. I explain more on the the replacement later.

Funny thing is when we physically disconnected the WAN link the PRI would register to the router when SRST kicked in via H.323. We continued to test by unplugging and plugging in the WAN connection. And every time we pulled the cable the PRI would register via H.323 and everytime we plugged it back in the PRI would never register via MGCP.

Because we were without phones for a full day and couldn't take the additional loss of business we removed SRST and went back to the onsite call managers which we had never removed when we transitioned to SRST. Now that the remote office is running off their pre-SRST local call managers the PRI is registering the is registering to call manager.

We were on the phone with DiData Support and 3 different Times Zones of Cisco TAC before we desided to remove teh SRST configuration.

Anyone have an idea why the PRI wouldn't register across the WAN via MGCP?

 

[ptdog]

from what you described, it seems like the wan link is the real culprit, especially if SCCP and MGCP registration packets are not making it across your WAN link to the CCM, or not even making it back. You just proved that the PRI is good by having it fallback to SRST with H323 and with the CCM locally there. Your issue is with the WAN. Check to make sure the traffic for registration, SCCP and MGCP, goes over the link and actually make it across. Access list can help with this to determine if the traffic makes it across.

Also, i would definitely, if you haven't already, make sure the call control gets enough bandwidth for the phones and gateway. Make sure you have QOS for call control at least. It does not seem like you really send and rtp traffic across the link, especially if it is a 128k circuit.

 

[dpaige10460]

Thanks ptdog. I think its the WAN also. But we have the worst WAN group I've have ever seen. They feel because this project was done by DiData its not their problem. So we have been fighting with them internally. Our Cisco SE just got back to us and he is claiming its the WAN.

Believe it or not there is no QOS. The vendor had enabled QOS but we had to disable it because they used a form of QOS that wouldn't burst above 128. Traffic Shapping? Our CIR of 128 can burst to 512. And after the SRST implmentation we found out there were occasional delay issues with the WAN going back across the WAN before SRST was in place. I'm wondering why no body noticed this before hand.

SCCP traffic was making it across the wan because during this outage the phones were registered to call manager when the wan was up and registered to the Router when SRST was enabled.


Your access-lists senerio...how would I test that?

 

[ptdog]

for the access list scenerio to see if some traffic is making across the WAN, you can put something like below, but be more granular to pin point the specific ports and ip.

access-list 100 permit tcp 10.1.1.10 255.255.255.255 192.168.1.30 255.255.255.255 eq 2428
access-list 100 permit udp 10.1.1.10 255.255.255.255 192.168.1.30 255.255.255.255 eq 2427
access-list 100 permit ip any any

Apply this to the side where CCM is, and do a show access-list. You should see the counters going up for the top 2 access-list for MGCP traffic to ccm. In the above example, ccm would be 192.168.1.30, and the VG would be 10.1.1.10.

 

[jneiberger]

By the way, you don't want voice traffic to burst over your CIR even if the link can technically burst above it. The DiData guys who implemented your QoS were correct.