We are experiencing intermittent issues with our FXO ports on all of our 2800 series routers. When we dial the 10-digit number associated to the specific FXO port, you can see it hit the router, it will ring twice and then give a dial tone. We are using c2800nm-spservicesk9-mz.124-22.T.bin. We are using MGCP and resetting the gateway from call manager does not resolve it. If we reload the router it fixes the issue. We route the call from the 10-digit to a 4-digit number that in a service partition. This 4-digit number is specific to the location. Is there a IOS change that fixes this or a config change that needs to be done. Any help would be greatly appreciated.
It sounds like MGCP is losing control of those ports, so it is falling back to the default call control and giving you two stage dialing. You could verify this is the problem by doing a 'debug mgcp packet' while they are in this state, and you probably won't see any activity. Show ccm-manager will probably still show you registered, and sh mgcp endpoints will probably still show the ports, but you might verify this. We have one thing that we see occasionally that can cause this, config-wise, and that is if you have SRST dial peers in the router, and they end up in the config on top of the mgcp dial peers - even though they should not, they grab the call first. This can happen if someone makes a change on the mgcp config in CM, and the config is redownloaded. So, we have to pull out the srst dial peers, sync the cm config, and then add the peers back in. If this were your problem, then I would not expect a reload of the router to fix it, unless someone added peers and did not write the config, so they disappear again. So then, if everything looks fine in the config and it is doing this, I would maybe try a different IOS, although I don't know of specific problems with the one you have. Unless your 'debug mgcp packet' shows the gateway actually sending mgcp packets, and then it would seem to be a problem in CM - where I have seen one bug that acted like this, but on CAS trunks, not fxo.
I've been coming across this issue recently as well, and it's really annoying!! It certainly didn't happen in previous versions of IOS; so I suspect it must be a bug of some sort.
Anyone else see this?
Hi Aaron! Well, we have seen it occasionally over the years, but I'll bet that it is one of those bugs that comes and goes then, they fix it in some versions and then it slips back in. Do you see the dial peer rearrangement, or just non-responsive mgcp?
People pick it up as one-way reachability (can dial the fax, but the fax can't dial out - typically after dialing 9, then one more digit they get a fail as the 9T h.323 peer is matched, and then rejects as the E1 it's linked to is down/controlled by active MGCP process).
Remove the H.323 dial-peers pointing to the FXS ports, and all is well.
Add them in a particular order, and all is well.. until something happens to reorder them.
Thank you all. That is correct, if I move the dial-peers around, the devices begin to work again. Some information I am finding points to the IOS of the router and how it handles the DSP resources. According to CISCO we should be able to run in a hybrid environment with H323 and MGCP, but when we do this, I am finding that at a given time one may work just fine and then the other has issues. Is there a known good IOS or should we just plan on going pure h323? We also noted that when we go into SRST mode, if the MGCP dial-peers are first, then 911 doesn't work.
Yeah, it's not good. I would raise a TAC case, get their angle on it and possibly a reliable fix...
I can't say I've experienced your specific issue but you can definitely run a hybrid MGCP/H323
config on the voice gateway/ISR. A colleague of mine has tested this quite a bit using IOS 12.4(24)T2 - which isn't far off from the code you're running. What our config is being used for is some specific requirements such as H323 used for inbound only (to accomodate blacklisting) and MGCP for outbound only. I haven't done a bug scrub between the 2 versions of code to see if there is anything that may be hindering you from a bug perspective, but the concept is definitely valid.
Please rate helpful posts!
Thanks for the an usable IOS version. I think I will open a TAC to see if there is any more information on this issue. We are planning to leave the FXO ports MGCP and the FXS H323, so it would be a little more complex then on direction. I will post what information I get from TAC if we are able to resolve the overall problem. Thanks again and will keep your version in mind to try if I get nothing better.
Sounds good, let me know what comes of it. I knew I wasn't going to solve your problem but just wanted to give you some context that it can be done and we've tested it on that specific code with success. Now, it could be that the configuration and Protocol to Port Type mappings is causing some underlying issues but I agree that TAC would be your best bet at this point. However, (I'm sure you know this) - if you feel like you're just getting the basic answers, just ask to escalate your case so you can get a more in-depth look at what you're doing so you can be sure you're getting the answers you need.
I would love it if you could address specifically the dial-peer out of order problem, which you can recreate reliably by starting out with a good config, which will have the MGCP dial peers first, and the srst h323 peers second, and then you make some change on the CCMAdmin page for the gateway, which will download new mgcp config to the router, and put the mgcp peers at the end, which breaks it. This is very frustrating, because it can work for months, even years, and suddenly stops! I can see a router reload also triggering it, since it will probably download mgcp config again, ...