Difference between H.323/MGCP/SIP/SCCP

[daniel.tanch]

Hi,

Can somebody explain to me what the difference between these protocol and when to use it:

1) H.323

2) MGCP

3) SIP

4) SCCP

I read thorugh the documentation but still does not understand it.

[Paul Jones]

H.323 and SIP are both referred to as "call control" protocols.  They allow a device, such as a desk phone, softphone, or videoconferencing system to place a call to another person over IP.  H.323 was created by the ITU-T and was primarily focused on videoconferencing. SIP was developed by the IETF and was primarily focused on serving as a replacement for the desktop desk phone.  While the initial focus of each protocol was slightly different, they are both used for voice phones and videoconferencing today.  SIP is now extensively used in carrier networks today as a replacement of legacy PSTN ("Public Switched Telephone Network", i.e., "the old phone system") protocols.

MGCP refers to Media Gateway Control Protocol.  It was adoped by Cable Labs as a standards in PacketCable and published as an informational RFC in the IETF.  What MGCP does is allow a "Call Agent" to interface with "Media Gateways", allowing a PSTN gateway to effectively be decomposed into a control function (the Call Agent) and more or more media functions (the Media Gateways).  The idea was to make it simple to scale out the number of PSTN gateway ports a call agent could support.  Cisco's Communications Manager can act as the "Call Agent" and control the MGCP gateways directly.  Another protocol like MGCP is called H.248 (or "Megaco").  This is a standard created jointly by the IETF and ITU and is a superset of the functionality found in MGCP, though the signaling protocol is quite different. Today, continued development of H.248 takes place exclusively in the ITU, I believe, and it is extensively used in carrier networks.  (Both SIP and H.248 are core protocols in the 3GPP IP Multimedia Subsystem (IMS) used by legacy carriers to replace PSTN protocols.)

SCCP (sometimes referred to as "Skinny") is a Cisco proprietary protocol used for line-side control of phones connected to Communications Manager.  SCCP was created because it was important to be able to control various buttons on the phone (e.g., hold, transfer, park, pick-up) and the standard call control protocols (H.323 and SIP) do not have a means of controlling buttons on phones.  Cisco has been moving to replace SCCP with SIP in most instances for actual call establishment, while physical keys, soft keys, and UI elements are managed through other proprietary mechanisms.

I hope that helps.

[cnscisco]

Paul, I arrived here because I was researching the current state of MGCP development.

Currently, MGCP does not support caller-id on fxo ports, and this to me is one of the greatest drawbacks of an otherwise feature rich protocol.

SIP and H323 do not provide as much reporting information as MGCP from a Call detail Record standpoint as they are both "peer" protocols, while MGCP is a client server protocol. 

So the question is, is there any further work being done on MGCP, and if so, is support for caller-id on fxo ports likely in a future release? Who do we need to speak to to get this deficiency in the protocol addressed?

Looking forward to your response. Thanks much.

[Paul Jones]

Presently, I'm not working on gateways and so I might not be the best person to ask.  However, I'm unaware of any development happening on MGCP at the moment.  Any discussion on progressing MGCP would take place on the IETF's "megaco" mailing list (https://www.ietf.org/mailman/listinfo/megaco).

However, with respect to caller ID or other signaling information that is outside of bearer control, this should be backhauled to the Call Agent.  See https://tools.ietf.org/html/rfc3435#section-2.1.1.1.  That talks about backhauling signaling information and the work done in SIGTRAN (https://datatracker.ietf.org/wg/sigtran/documents/).  Depending on the PSTN signaling protocol, it might be SS7 or ISDN signaling that is backhauled to a Call Agent.  The caller identification information would be in that backhauled signaling.  It puts burden on the Call Agent to digest the Q.921 or MTP2/3 and higher layer stack information.

This design is rather deliberate, since there is a lot of information in SS7 and ISDN, some of which overlaps and some does not. It's best not to pollute the simple gateway control protocol with all of the legacy signaling information.  Additionally, there are some use cases where that signaling simply is not needed (e.g., connecting two IP legs through a media processing function controlled via MGCP where call control for either side is via H.323 or SIP, or in other words a distributed session border controller).

[Dennis Mink]

I personally like to avoid SCCP and MGCP. SCCP because it is proprietary, MGCP because it  lacks granularity and is not easy to trouble shoot. PLus if you want SRST on an MGCP controlled gateway, there is a big change that you need to rely on H323 as fallback anyway

[cnscisco]

Dennis, please elaborate on your comment that MGCP lacks granularity. From my (focused) perspective, looking at the CDR (call detail record)  information provided by a MGCP gateway vs a SIP gateway, the MGCP provides more granularity. For example if you have a PRI terminated on both a (CUCM controlled) MCGP gateway and on a SIP gateway and outgoing calls to the PSTN were hunting from channel 23 up to channel 1, the cdr (call detail records) from the MGCP gateway would show exactly which channel on the PRI the call originated on, whereas with the SIP gateway the CDR would just say that a call was made on the PRI trunk. Same applies to an H232 gateway, you wouldnt be able to tell from the CDR which channel the call originated from.

So from the perspective of CDR, MGCp provides more granular info.

I believe you are referring to other areas of operation but from your post I cannot tell.

[Dennis Mink]

what I meant by lack of granularity in mgcp is that all MGCP related parameters are configured in CUCM, what CUCM offers in terms of configurable items is pretty much all there is.   If you compare that with for instance configureing H323 and SIP on a voice gateway or CUBE, you have way more bells and whistles available to configure, not to mention that it is easier to troubleshoot, because you can easily run debugs on a voice gateway. compared too the cumbersome way in which you collect CUCM logs.  

[tandris]

Thank you for taking the time to explain the differences among MGCP, H.323. SIP and SCCP.

Re MGCP - you mention that Communications Manager acts as the call agent and controls the gateways directly.I've also read that with MGCP, we have the advantage of centralized gateway administration and scaling Telephony networks.

What I am not understanding is the "as opposed to" scenario. With MGCP, what does the network look like, and conversely, what does the network look like *without* it? A network diagram may help solidify my understanding of the VALUE of MGCP, as well as an explanation of a world without it.

Thank you!

[Paul Jones]

Think of MGCP as a "device control" protocol. You can interface that gateway to what is referred to in the standard as a "call agent".  CUCM is that call agent in Cisco enterprise voice/video networks.  You can obviously log into the gateway and do some configuration, but you also configure its use inside CUCM.  The gateway can only communicate with its call agent and cannot communicate with anything else.  You cannot have another softswitch, SBC, or other device direct calls to the MGCP gateway: it's doesn't talk to anything except its call agent.

Conversely, a SIP or H.323 gateway can be deployed on the network and configure it entirely independently of CUCM or any other "agent".  Any number of CUCM devices can be configured to direct calls to that gateway.  Likewise, if you had other softswitches, SBCs, or other SIP or H.323 equipment on the network, you could configure those other devices to send calls directly to those SIP/H.323 gateways.  They work autonomously and are not under the exclusive control of CUCM.

So, MGCP is like a master/slave type of protocol, where there is a "call agent" that controls what it does.  SIP or H.323, on the other hand, are more intelligent call signaling protocols that operate independently and are not controlled by a particular entity.

Does that help or make it more confusing?  I'm happy to try to add more clarity if it's still confusing.

[tandris]

Thanks Paul, I'm getting there but not quite yet :).

We're discussing the many features that MGCP has to offer -  the exclusive call-agent relationship with CUCM, direct and centralized gateway administration, etc. What I'm missing is the "so what".

"So what" if MGCP is controlled by the CUCM, whereas SIP and H.323 operate independently? Is one better than the other, and why? Or, what benefits does one offer that the other doesn't?

Ultimately I'm trying to get to the value proposition of each, especially b/c most of what I read touts MGCP as "better" but it's not very clear to me as to why. Or, am I reading it wrong, and both offer equal benefits, which makes it simply a matter of preference when choosing?

Thanks!

[Paul Jones]

From the user's perspective, there's really no difference. They make a call and it goes out to the PSTN.

The administrator sees a difference, though. The most significant difference is that with SIP or H.323, one can use a single gateway that interconnects with a number of different call control agents. You can even have SIP/H.323 gateways call other SIP/H.323 gateways directly.  For example, a call could come in from the PSTN and then routed out to another PSTN gateway in order to reduce toll charges over long distances.  Service providers (e.g., prepaid calling card services) have done that sort of thing for years.

With MGCP, the gateway is associated with one device (e.g., CUCM) and it is more-or-less permanently bound to that.  That's not necessarily a bad thing.  It just depends on your particular needs.

If all you have in the network is a CUCM node and a gateway, MGCP would work just fine.  You would not see any advantages using SIP or H.323 in that case.

But, suppose calls come into your office and are always directed to a Brand X IVR system. With a SIP or H.323 GW, could could configure it to direct calls there without first passing through CUCM. The IVR system could send messages back to the GW to re-route the calls to CUCM or to a Brand Y voicemail system. In these flows, CUCM only gets in the picture if the result of the IVR interaction is to direct calls there. That might be a bit messy, especially if 99% of the calls go to CUCM anyway, but I can only offer this as an example to try to illustrate the utility of more intelligent call control protocols in gateways.

To illustrate call control flexibility another way, let's say you have an MGCP gateway connected to a switched circuit provided by the service provider.  Perhaps in a few years, your service provider replaces that with a SIP interface.  In that case, you might need to replace that GW with a Cisco Unified Border Element (CUBE) that does H.323 and SIP in and out.  If you had started with an SIP GW from the start, you could swap out the PSTN gateway with a CUBE and not have to make config changes on CUCM. You might even be able to re-use the gateway and just load the CUBE software on it.

It really boils down to this "where is the call control functionality?" With H.323 or SIP, some call control logic can exist outside of CUCM. Gateways can do a lot in terms of call handling on their own (digit manipulation, SIP/H.323 call initiation, call transfer/forward, etc.). With MGCP, all call control logic comes from CUCM and the gateway just does what CUCM tells it to do.

I would say if you need more flexibility in call control outside of CUCM, consider deploying a SIP/H.323 GW. If you rely entirely on CUCM for call management functions and do not expect to be using CUBE (or other SBC anytime soon), then you can go with either MGCP or H.323/SIP.  In the latter case, it likely makes no bit of difference. In simple deployments where CUCM is used exclusively for call control, I cannot think of an advantage of using one protocol over the other.

[tandris]

Thanks Paul! Very helpful :)