Cisco Voice Gateway Protocol Choices: H323 vs SIP vs MGCP

William Bell
Vice President, Solutions and Products

“Should I use MGCP or H.323 for my gateway protocol?”

The answer to a question like this will always be: “it depends”. There are a ton of threads on this topic all over the CSC forum.

The first thing you should do before putting pen to paper on a design is to understand the requirements. Technical requirements will most directly contribute to you finding an answer. However, non-functional/quality/business requirements are also important. Once you get requirements, you can start working out the design. You don’t get into protocol choices until some time in your detailed design, but they may be self-evident earlier in the process.

 That being said, some areas I look at when making the choice:

1. Identify operational capabilities.

In short, how talented is your staff? A related question: how saturated are your resources? Can they cope with a complicated configuration. Especially if there are multiple devices in play?

As a general rule, my opinion is that MGCP is easier to configure and maintain. That isn’t to say H.323 or SIP is hard, but there is more opportunity for human error here and that is what this question is after.



2. Identify telephony integration points.

Are you connecting your Cisco UCM environment to another PBX? If so, do you have a need to leverage QSIG?


Both protocols can facilitate integration with another PBX using T1/E1/analog. Features are transparent for the most part.  However, QSIG may require the use of MGCP (depending on feature requirements).

 3. Identify Branch Office requirements.

Are you planning on using SRST at branch/remote offices? What are your requirements for user experience with failover and failback? Will branch office CO connections be ISDN or analog?

With MGCP, TDM connections are backhauled to the CUCM, while H.323 allows the gateway to act autonomously. For analog circuits, H.323 and MGCP will basically offer the same user experience. With ISDN connections, the MGCP failback comes with a hit as the B+D channels are brought down temporarily while the backhaul connection is re-established. This bothers some people and is a reason to use H.323.

 4. Identify any special call behaviors.

Do you have a requirement to maintain a “black list” of callers into your system? Do you have a need to run any special call treatment based on calling party? Are you using Unified Mobility Mobile Access? Do you have a need for CVP (call center)?

 If you have any special treatments like the ones listed, you are likely looking at a H.323 deployment. Not because of the protocol per se, but because of the backhaul nature of MGCP. MGCP routers can’t “act on” the ISDN Q.931 information elements.

NOTE: With CUCM 8.0 and later, "black listing" can be supported without relying on the gateway. That is
a separate blog entry.


Other Considerations

There are other operational considerations that will be version dependant.  For instance, if you have a requirement for T.38 fax and you are running an older version of CUCM, you will need to use H.323 because MGCP+T.38+CUCM didn’t work until I think CUCM 6.1 (though I could be fuzzy here).

 You will also want to consider the complexity of your TDM call path selection. If you are in an organization that does the old school allocation of one trunk group for local, one for LD, one for this, and another for that then you may want to use MGCP. H.323 can do this, but you have to be crafty with the dial-peers and you will want to leverage CUCM 7.1 or later (so you can leverage transformation patterns). Otherwise it is a hot mess and harken back to item #1 above (i.e. balancing talent/workload).

In general, dial plan management is easier with MGCP. But I also found that if you define a logical and consistent dial-peer configuration, you can make H.323 configuration management straightforward. This gets into the realm of proper planning and operational discipline, not technical requirements.

NOTE: I wrote a blog entry on my blog site that covers consistency with dial-peer
conventions. Granted, it was for CCIE preparation but the logic is borrowed from my approach to production
designs. You can explore that topic here.



Call preservation is one thing that people throw out as an advantage for MGCP. However, it is no longer a differentiating factor. You can configure call preservation with a Cisco IOS router running H.323 and CUCM. Though, you will want to test behaviors diligently in a lab to make sure you have the proper configuration on the H.323 gateway.  Not hard, just another thing to test.

I used to be biased to MGCP and I still go to MGCP unless the requirements or customer direction leads me to believe H.323 will be better. You can also run both on the same router, at the same time. I have done this successfully.

 Oh, some folks will say that doing H.323 prepares the router config for a future adoption of SIP. Somehow  the perception is it will be a easier migration. I disagree. My opinion is that in the event you switch from PSTN-TDM to SIP, you will often find yourself in a position to rethink your platform, design standards, and configurations. IOW, you are going to be touching your gateway config in a big way in either case.

What about SIP?

My “canned” response didn’t include much on SIP. My opinion is that I don’t configure SIP on voice gateways where the upstream connection is a TDM connection to a PBX or PSTN provider. I reserve SIP for Session Border Controllers or Cisco Unified Border Elements (CUBE) as we affectionately refer to them today. Of course, I am all about SIP trunks to other call processing systems.

5 responses to “Cisco Voice Gateway Protocol Choices: H323 vs SIP vs MGCP

  1. Great post Bill,

    One thing that often leads me to use H.323 is where the customer has a fractional E1 circuit – e.g. they only have 10 of 30 channels enabled.

    MGCP can sort of cope with this using a Service Parameter cludge but you are limited to (I think) five gateways. H.323 copes with this far better.

    BTW what is the Black List feature in CUCM 8.0 that you refer too?

  2. James,

    Good point. Since the D+B is backhauled to CUCM, you have to rely on a service parameter mechanism. Very clunky and yes, as you pointed out, not very scalable. Thanks for bringing that up.

    Thanks for asking about "black listing" on CUCM. The ability to implement "black listing" or blocking on calling party number in CUCM 8.0 and later comes by way of another feature "Hotline". Translation patterns have a new route directive/parameter that can be used to make routing decisions on calling party number. I did a write up on it (and the traditional method) here:


  3. I think the best way to go is H.323.
    The telephone system I use, Ozeki Phone System Xe, transfers data with H.323 as well and it is reliable and completely good for transferreing voice and video.

Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.