04-05-2007 08:30 PM - edited 03-14-2019 08:51 PM
It seems like there's been several posting regarding bugs observed in the latest IOS version on MGCP gateways. Symptoms are channels not registering, one-way audio, or inbound calls immediately dropping. Today, I was hit by all three of these running 12.3(11)T11 on a 2821 w/ VWIC-2MFT-T1s. Resetting, re-configuring MGCP from scratch, and even rebooting failed to resolve it. Downgrading to 12.3(11)T10 magically fixed everything.
At this point I thinking of switching over to 12.3(14)T7 based on the top post, but before doing that does anybody have a bug-free version that they've been using and would recommend? I've used 12.4(8) on a 2811 with no troubles, but that was H.323.
This seems fairly widespread, happening on the 2600XM, 2800, and 3800 platforms, both 12.3T, 12.4, and 12.4T. However, I've yet to see a specific bug on this issue.
04-05-2007 09:02 PM
Johnny, Why dont you try mainline 12.4 ? Its definitely a lot better than buggy versions of 12.3.
04-06-2007 06:16 AM
That's what logic would dictate, and like I said I've run 12.4(8) on an H.323 gateway with no trouble at all.
However, if you scan the postings I've linked to, you'll see mention of undocumented bugs in both 12.4T and 12.4 Mainline. I've been watching this since January and still don't see a firm resolution, which is why I stuck with 12.3(11)T rather than move to 12.4. I had upgraded to 12.3(11)T11 to address bug CSCse15025.
04-06-2007 07:05 AM
A few tips i can give about these mgcp issues. I have noticed these in 12.4 IOS a lot.
a. Configure ccm-manager config and ccm-manager config-server
mgcp
mgcp call-agent
mgcp dtmf-relay voip codec all mode out-of-band
mgcp rtp unreachable timeout 1000 action notify
mgcp modem passthrough voip mode nse
mgcp ip qos dscp cs3 signaling
mgcp package-capability rtp-package
no mgcp package-capability res-package
mgcp package-capability sst-package
no mgcp package-capability fxr-package
no mgcp timer receive-rtcp
mgcp sdp simple
no mgcp fax t38 ecm
mgcp rtp payload-type g726r16 static
mgcp bind control source-interface FastEthernet0/0
mgcp bind media source-interface FastEthernet0/0
!
mgcp profile default
b. Bind media and control source addresses to a interface whose ip address is reachable from callmanager, unity, phones etc. There is a bug related to this, where mgcp process resets and the binding is some how lost even though the commands to bind the address are still there in the config.
c. Configure no mgcp timer receive-rtcp. Without this command if a phone puts the call on mute, after a few minutes the call gets disconnected. Again step a should automatically add this command to the config.
d. I have found this bug in 12.4 without any fixes yet. If using SRST on the router and when MGCP fallsback to H323, you can place calls just fine. But if you reboot the router in srst mode, the pris doesnt come back up when the router has booted back up completely.
HTH
Sankar.
04-06-2007 07:45 AM
Very helpful, thanks. Honestly though, I'd be more inclined to stay on 12.3T or just convert to H.323 rather than deal with these issues on several gateways deployed in multiple locations. I have a go-live for a Hospital next month, so everything needs to be as solid as possible by then. Will be interested to hear what TAC has to say on this.
04-06-2007 09:09 AM
Also try pushing the TAC engineer to check if there are any dspware issues that may be causing this. H323 is so solid, i have never had any problems with it, except for the amount of configs you got to put in place.
04-09-2007 04:39 PM
Interestingly enough, even after downgrading to 12.3(11)T10, I was hit with another outage the next morning, although this was different in that after rebooting, no PRIs would even register. Moved to 12.4(7e) and that fixed one of the gateways, but the other still would not register any PRIs.
On the gateway that was having problems, we'd actually had a bad T1 off it for the last few days. The telco had done tested and said it was our equipment. I did a "shutdown" on the T1 controller, and everything immediately registered and worked fine. After finally convincing them to send a technician out, they found a loose wire at the demarc point.
So the root cause was actually a bad wire on the T1, however the fact that it hosed the MGCP backhaul on multiple gateways is pretty scary. I'm thinking until this risk can be elimated, I'll just use H.323
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: