Hi,
To my knowledge this is working as designed. As of CVP 11.5 microapps run off the VXML Server service. So I believe this would be applicable to either running a simple microapp (PM, Menu, etc..) as well as attempting to call a VXML application/Studio app.
What you'll see in the VVB logs (assuming same as in IOS VB though I've not looked there), is that the voice browser will attempt to fetch the VXML application from whatever IP and/or whatever mediaserver IP resolves to, fails, and then builds the backup media server URL as <primary cvp call server hostname>-backup.
For example, I have my VXML server defined in CVP ops with a primary call server of CVPA01. When we call an application we had the media_server ecc variable to "mediaserver" and have corresponding entry on VVB to point mediaserver to 192.168.1.10.
So VXML server is shut down on that 192.168.1.10. In VVB logs you'll see it try to fetch the application first at http://192.168.1.10:7000/CVP/Server and throw a message about "Couldn't contact IVR service". Then we'll see it build the backup URL of http://CVPA01-backup:7000/CVP/Server.
So as long as on your VVB and/or IOS VB you have the appropriate settings for host-to-ip or ip host <CVP Call Server hostname>-backup then this will failover properly to the backup VXML server.
Long story short, the mediaserver and mediaserver-backup comes into play for media fetches and will use that accordingly, but not for actually calling the applications on VXML Server. Why - I wish I knew, but this is what I've found though it would make more sense to use media or mediaserver (or however you define your default media servers etc..). Simple solution would be to add in the corresponding host-to-ip and/or ip host entries on each side. I.E. A side VVB has host-to-ip for <A side CVP hostname>-backup pointed to the IP of the B side CVP hostname, and vice versa.
