MGCP vs H.323 vs SIP Gateways

I have a question when to use the following gatways. In our environment we are heavy on MGCP Gateways. Everything is done via CUCM and then local SRST config is completed.

I have plenty of SIP trunks, but what about H.323 gatways and SIP gateways? What would be a realistic scenerio to use these instead of MGCP?

For example, what if someone wanted to use a layer 3 switch as their gateway or an ASA? These are not MGCP options so what would be the optimal solution?

Find more posts tagged with

SAVE $250 on Your CISCO Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View CISCO Boot Camps

Comments

shodown

It depends on what you are trying to accomplish. I'll give you some guide lines.

1. MGCP. If the customer is not ready for the complexity of dial-peers on the gateway and there are no plans to move to SIP trunks and no need for TCL or VXML applications use MGCP as long as there aren't multiple PRIs

2. H323. Solid customer skill level. If they have sharp guys or girls this is my go to. If they plan on moving to SIP trunks most of the configuration is already here and the customer will have a smoother transition to SIP. Also if you are using the router in a MPLS environment with VRF's on the gateway and need VXML or TCL script's this is the way to go. Also no need to worry about double the work since the dial-peers and vocie translation rules are already there. My preferred method for PRI's.

3. Preferred method for SIP trunks. Closer configuration to H323, however depending on the carrier and the SIP design this may require a voice engineer with a decent amount of routing experience or a routing engineer with the basics of voice if you are trunking over MPLS and have redundant paths through multiple carriers. Using SIP we can get a lot more calls over a T1 circuit and the best way to have centralized dialing out of a data center.

Using a layer 3 switch or a ASA as a gateway is not a good idea. These device are made for other functions than a voice gateway. Even if using a SIP trunk you still have Dial-peers that are needed and you do not have the IOS voice security feature set on those devices so you would have to use ACL to protect your network. Also what about DSP's you need those right

flipmad

1. Ironically we have several MGCP gateways with multiple PRI's. We never have any issues with our PRIs. I noticed you did not recommend this solution. We are going to be converting to SIP trunks, but what are the concerns with having MGCP gateways with multiple PRIs?

2. I really need to lab more with H.323. it is sad tha I have so little experience with these gateways.

3. I have a bit of route.switch experience, but not much with SIP gateways. Once we convert our network to SIp trunks I should get more experience with them

I agree with your Layer3 switch and ASA information. In a scenerio for a completely private WAN network with distributed Subscribers throughout and site to site calling is G.711 since we have bandwidth can handle it without issues. Can these transcoding and conference bridge resources be offloaded to another site to avoid the useage of DSP's? As for a recommendation, I think it is not a good idea, but for a solution i'm trying to brainstorm my options.

Thanks again for the information. This site has always been helpful. I noticed the CCNP Voice forum isn't as popular as it once was. Seems rather quiet around here.

shodown

I've had customers gateways just lock up on me with MGCP. It happens at least once a month since I've been doing voice, but thats spread across customers. You may have had the problem, but just rebooted the gateway instead of stopping and restarting MGCP. The concern is that if this happens with multiple gateways you have to drop all the calls. We had this happen on a gateway with 96 PRI's before. We had to shut all of them down and move the route groups to other gateways just so we could restart the MGCP process since we were a service provider we couldn't knock down that many calls.

When you convert to SIP trunks you will be fine. Just play around with dial-peers and voice translation rules they aren't hard. Just new.

flipmad

Thanks Shodown. I really appreciate the information. Hopefully I can start being more active myself

aaron0011

I can't add much as Shodown already provided an excellent summary. A little about the environment I run in a medium-large enterprise.

SIP through a CUBE is the most flexible and cost effective design when aggregating call routing to the PSTN. It is my preferred method and always my go to if one of our two providers can get DIDs in the area required.

H.323 for all PRI sites and SRST gateways. Slowly converting these to SIP but leaving at least a partial PRI or a POTS line active for SRST E.911 requirements. With critical sites dual WAN is in place with MPLS and IPSec GRE to multiple CUBE routers for a SIP trunk continuity. Local gateway PSTN access could probably be eliminated. The emergency requirement keeps it around for now.

MGCP gateways no longer exist. Previous lead Voice guy had a few out there at larger PRI sites. All of those 28xx have been replaced with 29xx and converted to H.323 with router refresh. It is more complex to configure but it's more reliable, an open standard, and provides more flexibility.

I welcome configuring dial-peers. Translation rules at the gateway are nearly eliminated when you go to an E.164 dial plan.

pitviper

Like sho, I've had a lot of issues with MGCP gateways. It's all H.323 for analog/PRIs and SiP via CUBE for me. Also, my brain thinks in CLI, so H.323 is a piece of cake to setup, advanced features included.

JeanM

Very good thread, thanks for good examples!

megatran808

Shodown, aaron0011, and pitviper hit everything dead on.

SIP and H.323 is most common in all our deployments with CUBE 2900/3900 routers with PRI cards for voice gateways. MGCP is way easier to configure but not practical.

Legacy User

shodown wrote: »

Using a layer 3 switch or a ASA as a gateway is not a good idea. These device are made for other functions than a voice gateway. Even if using a SIP trunk you still have Dial-peers that are needed and you do not have the IOS voice security feature set on those devices so you would have to use ACL to protect your network. Also what about DSP's you need those right

Correct me if I'm wrong or if I misunderstood what you are saying but why wouldn't having a ASA as a gateway work? If lets says the topology is ISP-> ASA->ISR Router running Voice->LAN

On the ASA can't you just set up the ACL's to let only the SIP/media traffic from the provider in and set Static Nat to map that traffic to the ISR Router. Then make a static route from ASA going to the Router running voice and another for Router to ASA.

shodown

The OP question was use the ASA or layer 3 switch as the "gateway" is how I read it. You could still use those devices, but you would have to route that traffic to the voice router anyway.

Legacy User

Gotcha and understood

shodown

The other thing that I forgot is that the IOS feature set for the ASA or a Layer 3 switch can't do voice commands. So you have no dial-peers, no MGCP, no SIP profiles, no way to do VXML, and SRST. Those are the reasons those device's can't be gateway's. Well Voice Gateways if you want to be correct.