Somewhat off-topic here, but since there's plenty of interest and documentation around using the CVP VXML Server Tomcat instance as the Media Server, and IMHO there's all sorts of advantages to doing so, especially for a "retentive" guy like myself who thinks things like "why would I want to install an IIS instance on this server if I don't need to??"...I gotta ask again to this group since I have yet to receive an answer with any specific technical details:
 
Does anyone know why there is a caveat when running CVP on UCS in VMWare that you cannot use the Tomcat instance for a Media Server - instead, you must load an *additional* component with IIS??
 
Other than some possible multi-threading thing that Micro$oft has figured out better than the Apache Tomcat developers that is exploited in a VMWare setting, this makes no sense to me whatsoever.
 
Anyone have any insight on this? Paul?
 
 - Bill

Fair enough, so let me offer what I think the good reasons are, with the following caveats/assumptions, because I'm also pretty set in my ways:

- All CVP Servers are combo Call Server/VXML Server/Media Server, because I don't like the distribution of individual components. Redundancy comes from multiple servers.

- All gateways are combo ingress/VXML, for same reasons noted above

- All interaction done with Studio apps (we established in that other thread that I'm no fan of microapps! ;-)

So with that said, a call comes into a gateway, and through dial-peers and a local SRV record finds a CVP Server (because I'm over H.323 and I don't see much of a need for SIP proxies - also another thread!).

ICM does the Send to VRU, and CVP uses Send to Originator to call bootstrap on the ingress gateway. ICM script uses Call.RoutingClient or the new ECC "cvp_server_info" to set hostname/IP of the CVP combo box that the gateway is already talking to - http://[hostname/IP]:7000/CVP - and calls first Run External Script.

In the Studio app, the default audio path is (by default) "/CVP/audio", which means if you use Tomcat, your audio path entries can just be "en-us/main_menu.wav". No need to pass in parameters to the app and do an Application Modifier to set another full URL string for an IIS media server - you simply change directories to get to the audio files, so all references can be relative paths.

I'll give you that IIS is a little easier to configure for expirations and such because it has a GUI tool, but I'll give that up any day for the convenience that Tomcat provides in simplifying my Studio apps, and to some extent, even my ICM scripting (or at least freeing up ECC space, since I don't have to pass in a media server URL as a parameter to my app.

The other piece from me comes before all of this, which is the fact that if I have a base Windows Server install, I run the CVP installer and I'm done - I have all the components I need. This might be where some more esoteric performance characteristics come into play somehow, which leads into that VM/UCS recommendation, but until proven otherwise, I look at like this - Tomcat is already running for VXML Server anyway, and using it to fetch audio from a subdirectory in between VXML fetches doesn't seem like it would cause a lot of additional load. On the other hand, loading IIS, even minimally, means at least a few more processes running on the server. Maybe this is akin to a Formula 1 tech shaving a control arm to save a few ounces, but hey, I get into that kinda stuff... ;-)

- Bill

Definitely the biggest "it depends" statement with CVP finishes with "on the architecture"...!

I am curious, though, of your big deployment. Was it with an older version? The largest ones I've been involved with were:

A deployment that started at CVP 4.1 and H.323, but was architected even slightly before that with a scalability number of I think 300 ports per server. The initial deployment was 32 servers - 16 per side - but that has since been cut in less than half and is probably still somewhat oversized based on actual usage numbers. That one did use a dedicated pair of Media Servers, one per side, and ran IIS because I recommended it, knowing it would be easier to configure! ;-)

And the other big one was similarly scaled, but was more recent (CVP 7) using SIP and architected around the 850 port/server limit at that time, so it was only 8 servers total (4 per side).

The point here is that my conviction with the architecture I described has grown with the product allowing that architecture to "fit" more often. At the current 1200 port/server limit (on standard hardware) or even the 900/instance on VM/UCS, I think it is safe to say that deployments with more than 4 CVP Servers *should* become fewer and further between. Ok, maybe "the cloud" concept will breathe new life into massive SP architectures and I'll be proven wrong, but when/if they do come around, they are of a scale that will easily absorb a load balancer or five and other "accessories" to make the whole thing work. Gateways seem to be in the same boat - the two examples above both used separate ingress and VXML gateways also, but I'm not sure the same systems designed today with new gateways would do the same again.

And yes - all good stuff all the way around, and why I frequent these forums more than most any others!!

- Bill

Just to add. I was initially more inclined towards using Tomcat as the default choice for deploying audios. However as we introduced the https architecture where there was more load put on the gateways, we switched to the IIS model and I must say that it works very well and much eacsier to configure. I now use Tomcat only for certain audios and most of audios get deployed on IIS.
I had several issues with Tomcat caching on old CVP deployments. I do not see any of these now.
Hemal

From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Thursday, April 12, 2012 11:09 PM
To: cdicuser@developer.cisco.com
Subject: New Message from Bill Webb in Customer Voice Portal (CVP) - General Discussion - All Versions: RE: New Message from Bill Webb in Customer Voice Portal (CVP) - General Dis

Bill Webb has created a new message in the forum "General Discussion - All Versions":

--------------------------------------------------------------
Definitely the biggest "it depends" statement with CVP finishes with "on the architecture"...!

I am curious, though, of your big deployment. Was it with an older version? The largest ones I've been involved with were:

A deployment that started at CVP 4.1 and H.323, but was architected even slightly before that with a scalability number of I think 300 ports per server. The initial deployment was 32 servers - 16 per side - but that has since been cut in less than half and is probably still somewhat oversized based on actual usage numbers. That one did use a dedicated pair of Media Servers, one per side, and ran IIS because I recommended it, knowing it would be easier to configure! ;-)

And the other big one was similarly scaled, but was more recent (CVP 7) using SIP and architected around the 850 port/server limit at that time, so it was only 8 servers total (4 per side).

The point here is that my conviction with the architecture I described has grown with the product allowing that architecture to "fit" more often. At the current 1200 port/server limit (on standard hardware) or even the 900/instance on VM/UCS, I think it is safe to say that deployments with more than 4 CVP Servers *should* become fewer and further between. Ok, maybe "the cloud" concept will breathe new life into massive SP architectures and I'll be proven wrong, but when/if they do come around, they are of a scale that will easily absorb a load balancer or five and other "accessories" to make the whole thing work. Gateways seem to be in the same boat - the two examples above both used separate ingress and VXML gateways also, but I'm not sure the same systems designed today with new gateways would do the same again.

And yes - all good stuff all the way around, and why I frequent these forums more than most any others!!

- Bill
--
To respond to this post, please click the following link:

<http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/5446828>

or simply reply to this email.