Cisco Voice Gateway Protocol Choices: H323 vs SIP vs MGCP

“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 http://ucguerrilla.com 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.