Installing the Media Server

The Media Server is the component that lets a telephony or IVR platform reach the Capacity Private Cloud speech services over MRCP — the standards-based protocol most contact-center platforms use to drive automatic speech recognition (ASR) and text-to-speech (TTS). It sits between the MRCP client (your application platform) and the ASR and TTS resources, terminating the SIP or RTSP signaling, managing the media legs, and translating each request into the platform’s API calls. You install it only when you are integrating over MRCP.

Do you actually need the Media Server?
If your platform already integrates with the speech services at the API level, MRCP — and therefore the Media Server — is unnecessary. Install it only when your platform communicates over MRCPv1 (RTSP) or MRCPv2 (SIP). If you are uncertain, confirm with your platform provider or Technical Support before proceeding. For the architectural background, see the Media Server Overview.

How the Media Server is deployed

The Media Server ships as a containerized service — the MRCP-API — that runs alongside your Capacity Private Cloud deployment. Rather than a standalone download and installer, it is pulled as a Docker image and configured through environment variables. This keeps it consistent with the rest of the containerized platform, makes upgrades a matter of changing an image tag, and lets you scale channel capacity through configuration alone. A single Media Server can front both MRCPv1 (RTSP) and MRCPv2 (SIP) clients at the same time.

Installation

The authoritative, step-by-step installation procedure — host preparation, pulling the image, the .env configuration, and launching the container — lives in Setup of MRCP API Server. Follow that guide end to end. The two settings below are the ones that most often determine whether a fresh install actually carries calls, so confirm both before your first integration test.

1. Advertise the correct host IP address

To negotiate media correctly, the Media Server must advertise the real IP address of the host it runs on — not the default loopback address. This value is written into the SDP and MRCP packets the client receives and tells the client where to send audio. If it is left at loopback, signaling can appear to succeed while media fails or flows only one way, which is the single most common cause of a “connected but silent” first test. Set it explicitly. For the exact parameter, see Media Server Specific Parameters and Media Server Configuration.

2. Size channels and ports together

The maximum number of simultaneous calls the Media Server will carry, and the host port ranges it draws from, are governed by MEDIA_SERVER__NUM_CHANNELS and the associated MRCP and RTP port-base settings. These values, the ports: block in your Docker configuration, and your firewall rules must all agree with one another — an inconsistency here surfaces later as intermittent “out of ports” failures under load rather than at install time. For sizing guidance and the exact relationships, see MRCP Ports and Channels.

After installation: verify, then connect

Before wiring up your production platform, confirm the Media Server is reachable and processing speech on its own:

  • Smoke-test the install with the SimpleMRCPClient. Driving a recognition or synthesis request directly isolates the Media Server from your telephony platform and tells you immediately whether the install itself is sound.
  • Review the connectivity model — protocols, ports, and codecs — in Media Server Connectivity when planning firewall and network configuration.
  • Tune behavior through MRCP, VXML, and API properties as described in Properties in MRCP/VXML/API.
  • Configure your specific platform — Avaya, Cisco, Asterisk, Genesys, and others — using the platform-specific guidance in Working with Voice Platforms.

Related articles


Was this article helpful?