I am about to bring up our next hospital on a UC HA pair. There is a 7.x CUCM cluster in place that is just used for wireless phones today. We're going to be moving 50 or so of the existing Nortel desk phone users into a newly constructed area and are moving them to Cisco to accomodate IPCCE functionality. The nortel's VM system is a 3rd party product and the integration between Nortel & Cisco is via multiple PRIs configured as QSIG. The bulk of the few thousand users are going to be staying on nortel for some time. We are intent upon replacing the legacy VM for all users as step 1... -That's the background in case it matters..
We've installed our first couple of hospitals unity connection as SCCP and our CVP integration as H323. More & more we're hearing to move things towards SIP on the line side esp.. And are planning to do so for our CVP integration shortly. What I'm curious to understand is the 'decision point' around SIP vs SCCP for Unity Connection. Found a couple of feature matrix documents that pretty much looked like a wash but want to know if there's any solid reason NOT to integrated UC & CUCM via SIP instead of SCCP? I've done some preliminary testing of the SIP integration in my lab that seemed to work very easily but wanted to hear from some of you that are 'living the dream'
Right now, a lot of what you're going to get is personal preference. It's probably as close to "6 in one hand, half dozen in the other" as you'll find. The whole "move to SIP" banter has been going for a while. The truth is, IMO, that on the line side Cisco simply hasn't yet reached full 100% feature parity. They are very close as there are newer phones being released that are SIP only. However, it's still not completely there and I don't see SCCP going anywhere right now. Personally, I use SCCP exclusively for VM integrations on both Unity Connection and Unity. In the past there were only a few things that didn't work with SIP and that list may have shortened (to a "wash" as you put it) but give the bug scrub a dip and you tend to find more bugs on the SIP side (i.e., SIP only) vs. the SCCP side. My 2 cents.
Well, I think you often have 2 "camps" if you will. The first camp is those that are experienced and, while they like to be cutting edge, the main priority is often what is best for the customer. In my case, that is often stability and lack of issues. The second "camp" is those that may have some experience under their belt (or could be very experienced) but they get too caught up in keywords and terms...one of those is "SIP". So, I've had other engineers say "why would you use SCCP, why not just use SIP"? My response is often, "go look up how many SCCP bugs there are and compare them to SIP and you'll see why" OR "i've done this for x customers with no issues, what's your track record?". But often the premise for the second "camp" is not necessarily track record and results but often a prevailing thought of "newer must be better".
That's funny to me as I think that SIP and SCCP are roughly the same age. Actually, SIP may be a little older if you go back to its beginnings.
Anyway, I agree with Big H on this one (+5 to my brother Hailey). All things being equal, I go with SCCP for Unity integration.
Actually, this reminds me of a certain customer in California that asked us the same exact question. I believe the response NetCraftsmen provided at that time would still hold true, though I have not researched CUC 8.x to any depth. I'll paraphrase to protect the innocent:
As to the broader topic of why NetCraftsmen still leads with SCCP in our CUC-CUCM design template I can tell you that Hailey and I reconsider SIP vs. SCCP on every new release of CUCM/CUC/Unity and any project using these new releases. We still settle on SCCP for the time being. In general, they are basically equal with only a few considerations with SIP, including:
1. With SIP, you can’t have MoH play out to a caller when CUC is performing a transfer. The weight of this depends on how you want to use CUC. An example we had with a customer is that for their automated attendants they wanted to play marketing music while they tried to transfer a call to a user. In this particular case, that customer had calls hunt all over God’s creation for a human being and they didn’t want the caller listening ring back during the hunt. So, if MoH play out on transfers isn’t important to a customer then this isn’t a big deal. From a design team’s perspective, requirements like the one I describe above aren’t discovered until an end user says “hey, can we…”. So, we like to have the option of saying yes to that question.
2. According to the CUC SIP integration guide (7.1x) there is a little blurb that “best practice” is to have all stations running SIP if CUC is SIP integrated. The reason for a statement like this is that if you have any phone stations/gateways/etc. that do not support RFC-2833 for DTMF then you must enable a MTP on the CUC SIP trunk to allow calls originating from or going through these stations to interact with the IVR menu on CUC (e.g. logging in, automated attendant, etc.). Cisco phones that don’t support RFC-2833 include: 7902G, 7905G, 7910G, 7912G, VoWLAN phones, and 7985. If you are using these stations then you may need to leverage MTP resources on the CUC SIP trunk and take a second look at your media resource design/allocation.
In addition to these items, the other considerations Hailey and I apply to our recommendation are based on experience. It isn’t that SIP is bad or that SCCP is better. You can actually run both on CUC. In the example I am thinking of, we ran SIP for TIMG/PIMG integration and SCCP for CUCM integration. We have just found SCCP to be a more mature protocol stack in Cisco-land and why go looking for software bugs when they already have an easy enough time finding you?
Oh, BTW just in case you were curious, using CUC with SCCP does not mean you can’t have SIP phones. CUC supports RFC-2833 in SCCP or SIP mode. I have tested this out a few times and we have customers that use a mixture of SCCP/SIP phones and SCCP on Unity VM.
I think that about covers the NetCraftsmen position on SIP vs. SCCP. Granted, we are just one small voice in a sea of talented Cisco engineers. Well, actually Hailey has quite a big voice. Go Great ..er Big.. Escape!
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.