C'mon - this is what you wanted for a Tuesday afternoon, wasn't it? ;-)


I've heard there is concern about moving from Windows for flexibility reasons for custom Classes, JARs, etc. I'd throw IP-IVR up again as an example, since it offers the same ability (fully custom classes, etc.) and seems to be handling the VOS transition ok...! Let's get CVP there!


A box is a box is a box in my book. I suppose VMs can "disappear" more easily, but distributing the architecture, as "old" CVP once did, seems like a backwards move to me. HUGE disclaimer: I'm also referencing CVP 8.x and up, SIP only, no SSL...so I'm seeing 4 or more physical/virtual CVP Servers as a pretty huge deployment.


But now your Default Audio Path references either an IP address, or, more likely, a DNS alias/hostname. So now you have to configure that ip host entry on every gateway, or enter it in DNS if you're that brave. Then, even if you do some config across your gateways with the local ip host entry to "load balance", you're always arbitrarily pounding a single media server unless it fails. Sure, you can add ACS or something, but IMHO, why would you complicate your deployment like that? That's like adding in a SIP Proxy! (hehe - poke the bear)
 
I'm a fan of keeping everything local (more on that below - Cisco seems to be moving in that direction also), and in a standard deployment, the gateway gets the IP address of the CVP Server when it connects, so your Studio apps are always using local media. You're all but guaranteed "fault tolerance", because if you've connected to the CVP Server in the first place, you know your media files are going to be available on that same server.


True enough, but check the CVP 9.0 Release Notes:
 
"In Unified CVP 9.0(1), the Call Server, VXML Server, and Media Server are combined as one installation. Installing the CVP Server will install all three components. In the earlier versions, Call Server, VXML Server, and Media Server could be installed on different machines."
 
Like it or not (I happen to like it a lot!), the convergence of scalability, etc. is leading everything towards consolidation. The fact that "Media Server" is included in this tells me I might be barking up the right tree. Again, disclaimer same as above - I know there are plenty of old deployments out there (I just spoke to a customer last week running 3.1 - I shuddered a little...), but let's face it: We need to talk 8.0 and up, and SIP.

Agreed - the preference is certainly towards "smaller" deployments, at least in terms of # of CVP Servers. The reason I think it is becoming more relevant is that even "larger" deployments of CVP should be smaller in terms of Call Servers with later releases.

Take your 8 Server 7.0 and H.323 deployment - the capacity on each CVP was only 500 on physical hardware, so up to 2000 fully redundant sessions was the max for that deployment. With CVP 8.5 and SIP, even on UCS, the capacity is 900 per server VM instance, even with VXML - an 80% increase in capacity. Even if you want some serious headroom, you're still in need of no more than 6 CVP VMs on UCS hardware. On physical servers, the number goes up to 1200 per server, which means half as many servers (4) would give you the same capacity with room to grow...but I would venture to guess most customers are going to jump on the VM/UCS bandwagon.

My point is that as capacities have increased and likely will continue to increase, large deployments in terms of number of CVP Server instances will decrease in size and complexity. Are there going to be customers out there with a need for 12,000 or more fully redundant CVP ports/sessions? Sure, but I would take the leap to say that those customers will be the exception, and not the rule. I'm open to be proven wrong...! ;-)

- Bill

That does seem high, but the "base" numbers for UCS are 900 simultaneous sessions with a call arrival rate of 10cps, which your example BHCA goes over slightly. That, coupled with some level of redundancy must be the reason for 10 servers. Still does seem high, but I would guess the tool is conservative!!

Looking at the new PCCE, there is some throttling going on there, too, but I think that's also considering a worst-case scenario in terms of overall platform (UCS) load as well as features (Agent Greeting enabled, EIM/WIM, etc.). They list 30K BHCA, so slightly under the 10cps, with every agent active. The 4 CVPs in that solution are intended for a normal load of up to 450 sessions per sever, but supporting up to 900 each in case of failover (so 1800 fully redundant).

But I digress - you hate Tomcat, I hate IIS, let's call the whole thing off! (that's a lame song reference, not an angry statement)!! ;-)

Always great to have your perspective, Geoff!

- Bill

Perhaps the wording isn't clear enough around media servers, but the CVP 9.0(1) installer automatically installs IIS on CVP Server components if that has not already been done. However, there's nothing preventing you from immediately uninstalling it if you hate IIS. Cisco recommends using IIS over Tomcat to server media files for the following reasons (that I know of):
1) Tomcat is not optimized for serving static files (such as media files), whereas IIS is, so using IIS should give you better performance.
2) The files in Tomcat are managed by CVP. If you upgrade or install an ES, any custom changes may be wiped out. Avoiding this requires backing up the custom changes and having a plan to restore them afterwards.

Hmm - you didn't address #1, Geoff! ;-)

I'll definitely go along with #2, but I gotta poke the bear one last time (maybe) on the first point around performance:

http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-always-use-apache-httpd-front-apache-tomcat-improve-perform

This is specific to Apache httpd versus Tomcat for static content, but there are similar posts comparing IIS to Apache and/or Tomcat...

I think the whole "performance" argument is a little misleading, honestly, considering the narrowed view of the use of Tomcat in CVP with VXML Server and CVP Studio apps.

I make that distinction because who would ever want to use microapps unless you absolutely had to?? ;-)

- Bill (IIS and microapp Hater-boy)