Configure MRCP IVR Proxy with Cisco CVP

Assumptions & Prerequisites

• IVR Proxy is running, on TCP port 8060 and transport = tcp only (no UDP) - see unimrcpserver.xml file

• IVR Proxy’s media engine (RTP) is configured for port range 5001–5050.

• CVP version supports MRCPv2 / “Speech” mode via the Ops Console.

• You have administrative access to the Voice Gateway (IOS/ASR) and the CVP Ops Console.

• Firewalls / NAT rules allow traffic: SIP on TCP 8060, MRCP v2 messages on TCP 1544, and  RTP(UDP) 5001–5050 (bidirectional) between gateway and UniMRCP.

Step 1: Adjust UniMRCP to accept only TCP (disable UDP)

For Cisco CVP + MRCPv2, you should set the sip-transport to tcp in your unimrcpserver.xml, ensure:

<sip-transport>tcp</sip-transport>

Remove udp setting if present. This ensures SIP signaling over MRCPv2 uses TCP consistently, which is what Cisco gateway is better aligned with (when you configure transport tcp in dial-peer).
This avoids having mixed transport confusion or fallback to UDP.

Step 2: Add ASR (speech) server entry in CVP Ops Console

In the CVP Ops Console:

• Go to Automatic Speech Recognition Server Configuration (or similar menu).

• Click Add New (if not already present).

• Server Name: a friendly hostname, e.g. unimrcp-asr-1

• IP / Host: the IP or DNS of the IVR Proxy server

• Port: 8060 (your SIP listener port)

• Protocol / Transport: Choose TCP / SIP (if there is such option)

• Save and verify its Status is “Reachable” (CVP will send SIP OPTIONS to check connectivity).

Step 3: Configure VoiceXML Gateway / App Mode to “Speech”

In CVP / Call Studio / the Ops UI:

• In the VoiceXML Gateway settings, where you might see "Nuance", “Cisco DTMF”, or “Speech” options, select “VoiceXML 2.1 with Speech” (or equivalent).

• This ensures the VXML applications will direct ASR calls through the MRCPv2 “speech” path rather than a proprietary driver.

Step 4: Verify VXML/Voice Gateway (IOS) Configuration

Log Into the Voice Gateway
Use SSH or console access to get into the IOS CLI of the VXML/Voice Gateway:

ssh admin@<gateway-ip>
enable

You need privileged exec mode (i.e. # prompt), because you’ll be using show run.

Verify the MRCP Client Settings

Run:

show run | section mrcp

You should see something like:

mrcp client rtpsetup enable
mrcp client timeout connect 5
mrcp client timeout message 5

Check for:

• mrcp client rtpsetup enable — required for proper RTP session setup

• Reasonable timeouts (usually 5 seconds is fine)

• No MRCPv1‐only settings (e.g., no RTSP references)

If these lines are missing → Ops Console didn’t push MRCP settings properly.

Verify ASR Server Configuration

Run:

show run | section ivr

You should see only an MRCPv2 ASR server URI (IP here is just an example):

ivr asr-server sip:unimrcp-asr@10.10.10.100

Check for:

• sip: prefix — this indicates MRCPv2.

• Correct UniMRCP server IP or hostname.

• No rtsp: line — if you see one, that’s MRCPv1 and can break MRCPv2 recognition.

If the ASR server URI doesn’t point to your UniMRCP server or uses RTSP, you’ll need to fix it manually or adjust the Ops Console settings.

Verify the MRCPv2 SIP Dial-Peer

Run:

show run | section dial-peer

Look for a dial-peer with a description or session target pointing to your UniMRCP server. It should look roughly like this:

dial-peer voice 200 voip
 description MRCPv2 to UniMRCP ASR
 session protocol sipv2
 session target ipv4:10.10.10.100:8060
 transport tcp
 dtmf-relay rtp-nte
 codec g711ulaw
 no vad

Check for:

• session protocol sipv2 — must be SIP v2

• session target ipv4:<UniMRCP IP>:8060 — correct IP & port (8060 default)

• transport tcp — MRCPv2 requires TCP

• A G.711 codec (usually g711ulaw)

• no vad — VAD should be disabled for ASR

• No other dial-peers with conflicting targets for MRCP

If this dial-peer is missing, or points to the wrong IP, the Ops Console push may have failed or you may need to edit manually.

Confirm Gateway Knows About UniMRCP Hostname

If the ivr asr-server uses a hostname (e.g., unimrcp-asr), run:

show hosts

or check the config:

show run | include ip host

Check for:

ip host unimrcp-asr 10.10.10.100

If missing, name resolution will fail. Ops Console sometimes doesn’t add this automatically; many deployments just use the IP directly in ivr asr-server to avoid dependency on ip host.

Check for Duplicates or Conflicts

Sometimes Ops Console can push both MRCPv1 and MRCPv2 configs (especially after upgrades). Run:

show run | include ivr asr-server

If you see both sip: and rtsp: URIs, remove the RTSP one. MRCPv1 and MRCPv2 can’t coexist cleanly for the same service.

Step 5: Ensure RTP & Media Alignment

Because UniMRCP’s RTP port range is 5001–5050, you must ensure:

• The gateway allows those ports, and routes media through that range.

• The 200 OK from the IVR Proxy MRCP server should advertise an RTP port within your server’s configured range (e.g., 5001–5050). If you see ports outside that range, recheck UniMRCP RTP settings and firewall/NAT.

• There is no NAT / firewall blocking those ports.

• The codec in the SDP (e.g. G.711 µ-law) matches what your UniMRCP ASR plugin supports.

If you see media outside that range (e.g. 16384+), that suggests a mismatch.

Step 6: Test & Debug

1. SIP OPTIONS check: the gateway/CVP may send SIP OPTIONS to the IVR Proxy MRCP server on port 8060 and expect 200 OK.

2. Place a test call: Use a simple VXML app that triggers an ASR prompt / recognition.

3. Debug logs on gateway:

   debug ccsip messages
   debug voip mrcp v2
   debug voip rtp session named-event
   show mrcp client session active
   show mrcp client session history

   Watch for SIP INVITE, MRCPv2 commands (RECOGNIZE), and responses.

4. IVR Proxy logs: On the server, check relevant logs to see that MRCP sessions are arriving, resources allocated, recognition happening.

5. Packet capture (Wireshark): Capture the traffic between gateway and UniMRCP, verify:

   • SIP over TCP on port 8060

   • MRCPv2 messages inside the SIP bodies

   • RTP flows from gateway to UniMRCP in ports 5001–5050

Look for anomalies—missing ACKs, incompatible SDP, “no resource” errors, etc.