I know that the statement from Cisco is that they do not support inbound caller-id when using FXO ports with MGCP, however, this is a really big safety issue for a lot of clients. I have many schools running Cisco voice systems with only FXO connectivity to the PSTN (PRI is far too expensive for their deployments). In a school environment, caller-id is an important safety feature when faced with things like bomb threats, etc. Most school systems in this area can not/do not employ staff with enough skills/knowledge to be able to manage an IOS environment. This makes an H.323 gateway configuration problematic, particularly when talking about needing to route calls to different end points based upon port, when connecting PA systems to the voice system via FXO, etc. Is there ANY way to make the inbound caller-id work with MGCP? This seems like a MAJOR flaw in Cisco's product. All phone systems have had this capability for years. Why would Cisco feel that they have no obligation to make this work? It's simply a matter of updating software. Isn't that one of the benefits of a VoIP system (the fact that it can be modified with new software updates)? This is a particularly annoying problem for me, as I have yet to find a TAC engineer that can help me to put an H.323 configuration in place that functions as one particular client needs it to. Each time a TAC engineer attempts to help with the process, we experience a long outage of PSTN connectivity, and the end result is that I have to delete the H.323 configuration, and then reconfigure everything back to MGCP. WHAT CAN BE DONE TO RESOLVE THIS?!?!?
Thank you for any assistance that you might be able to provide.
TAC engineers generally do a good job. MGCP is what it is. It was designed to work with t1-e1s and make configuring them simpler. 323 is more robust, and once you get it configured for the first time you won't have to touch it again. What exactly are you having problems with on the 323 config? Lets start from there.
Well, to be honest, they had trouble getting inbound calls to route properly. Calls are routed differently depending upon which port the call comes in on. Some route to a Call Handler in Unity, others route directly to a phone, and others route directly into a Subscriber's mailbox in Unity. They also had trouble configuring the system to allow calls from IP phones on the network to the building's PA system, which is connected via an FXO port.
My understanding of MGCP was that it was the "preferred" protocol by Cisco, given the fact that it allows for more control of the gateway.
Your experience with TAC seems to be better than mine. My experience has been VERY hit or miss. I actually find this forum to be a more useful resource than TAC most of the time. I find that all too often I get no response from a TAC engineer until after I have already solved the problem myself (with help from this forum and Google). This seems to be the case even when I open a case with a network down emergency. When I do get through to an engineer, I often have to argue with the engineer about the issue, and often get a response of "we don't know why it won't work/why the problem happened. Let's wait and see if it happens again".
In this particular case, I have sent the existing MGCP configuration with a description of the desired end result to several TAC engineers, and get no working H.323 configuration back. Even when they work remotely via my laptop, they cannot get things to function properly.
When I initially opened the case (almost a year ago), they told me to wait until July of 2008, as they would be releasing a new IOS version that would fix the problem. As it turns out, the new IOS only supports CCM version 7x, and my client is running version 4x. It's rather hard to sell a customer upgraded CCM software when the rationale is to fix a problem in something that they already bought.
Again, I have to ask, why would Cisco not release new software to fix what is clearly an oversight/bug in their product.
I don't mean to rant, and I appreciate any and all assistance. It's just that I am about at wit's end with this process.
It all depends on who you talk to. I have never talked to anyone that was "seasoned" in cisco voice that perfered MGCP over 323. 323 gives you way more control over call flow. MGCP is the first choice for some because of the ease of configuration. I have done a bunch of call manager express deployments so I tend to lean toward 323 because I understand its ins and outs.
With that said. TAC is like any other big support company. You will get some engineers with little field experience and some that are just on top of thier game. If your not happy with the response you get then ask them to re-que the case to another engineer. I'm not saying they are perfect, but they will try to get your config working for you.
As far as your actuall config, 323 is really strait forward in the way that you want to use it. If you want to send a call coming in on a specific port to a specific extension you would use connection plar command within the port configuration. For instance if your auto attendant is ext 5000 then you would go to the port that you want and put the connection plar 5000 in and it would send it there. If you need any more specific info I can paste some examples. But for what it sounds like you are wanting I would lean toward going with 323 because of the fact that it gives you more control of your dial plan at the router / port level.
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...