Steps to get IVR-Proxy sender running on Linux (inside Docker) – Voicegain

NOTE: The below described setup has been tested as working in a scenario where the IVR-Proxy sender is deployed on one machine and the tester (mrcp client, vxml platform, etc.) is on a different machine. Running the test client and the IVR-Proxy docker on the same machine may cause some issues with UDP traffic, depending on how the traffic is routed from the host to the docker and vice versa. Thus we do not recommend use on the same machine.

NOTE: This setup is meant mainly for testing and not recommended for scenarios with more than 5 concurrent sessions (generally not recommended for prod use).

Here is an overview (MRCP v1 and v2 versions)

Here are all steps needed to get the IVR Proxy running starting from creating Account with Voicegain.

Log into Voicegain Web Console
If you do not have an account, sign up for an account. Select the MRCP ASR feature to get access to the MRCP tools in the Web Console. You may also select additional features that you require.
Once logged into the Web Console, select a "default" Context in the drop down menu in the header. You may also create a new context, e.g. "ivr-testing"
Also in the side menu, go to ASR -> MRCP proxy.
Enter the external IP address of the machine where the proxy will be installed. This article has more details about what this IP should be - we suggest you check it out because if wrong IP is used then your MRCP Client will not be able to open the connection to the MRCP Server.
A link to download the IVR proxy bootstrap configuration should appear. Copy the link into a new browser tab and download the configuration file (.tar).
Install Docker the Linux machine if it is not installed already. Follow the instructions at: https://docs.docker.com/install/
1. You will also need Docker Compose. Please follow instructions at: https://docs.docker.com/compose/install/
After Docker and Docker compose are installed you can proceed to run IVR-Proxy.
Extract the contents of the IVR proxy file (.tar) into a desired location.
In a terminal, change directory into the extracted folder.
Once in the directory, you can launch the docker-compose in the background using this command (it will start tailing the log):
```
nohup docker-compose up > dc.log &
tail -100f dc.log
```
IVR-Proxy sender should now be running.

Once it connects successfully to the Receiver in Voicegain Cloud you should see the following in the log every 15 seconds:

ivr-proxy-sender_1 | 10-02-2020 03:47:34.433 [IVR-SenderHandler-Thread-1] INFO c.resolvity.ivr.proxy.SenderHandler.senderImpl - Sending keep-alive signal...
ivr-proxy-sender_1 | 10-02-2020 03:47:34.934 [IVR-SenderHandler-Thread-1] INFO c.resolvity.ivr.proxy.SenderHandler.senderImpl - Keepalive feedback received.

You will also see the following in the Web Console
You can check for RTP packet loss using:
```
 grep jitter dc.log
```
To stop the IVR Proxy run:
```
docker-compose down
```
Note: it is important to let the docker-compose start up fully before sending MRCP traffic to it.

The IVR Proxy uses the following ports:

Outbound traffic - to connect to Voicegain cloud. If these ports are not open you will see TCP timeout errors in the log under ivr-proxy-sender_1. You will see e.g. TCP connecting to ivr.voicegain.ai/35.227.29.237:9000 but there will be no indication that connection was successful.
- api.ascalon.ai (35.237.43.87) 443/TCP - for initial negotiations
- ivr.voicegain.ai (35.227.29.237) 9000/TCP - for command traffic
- ivr.voicegain.ai (35.227.29.237) 9000/UDP - for audio traffic
Inbound traffic - ports on which IVR proxy listens to MRCP client (e.g. VXML platform)
- MRCP v1:
  - 1554 TCP: for RTSP
  - 5001-5050 UDP: for RTP
- MRCP v2
  - 8060 TCP and UDP: for SIP - we strongly suggest using TCP SIP - with UDP sometimes the traffic from our MRCP to the client gets blocked and session is not established.
  - 1544 TCP: for RTSP
  - 5001-5050 UDP: for RTP

You can verify that MRCP and IVR Proxy is listening on all the ports buy running the following command:

netstat -apnt | grep -E ':(8060|1554|1544)

The output should be like this:

tcp6 0 0 :::8060 :::* LISTEN -
tcp6 0 0 :::1544 :::* LISTEN -
tcp6 0 0 :::1554 :::* LISTEN -

To check UDP ports run:

netstat -apnu | grep -E '(:8060|(:50[0-5][0-9] ))'

The output should be:

udp6 0 0 :::5001 :::* -
udp6 0 0 :::5002 :::* -
udp6 0 0 :::5003 :::* -
udp6 0 0 :::5004 :::* -
udp6 0 0 :::5005 :::* -
udp6 0 0 :::5006 :::* -
udp6 0 0 :::5007 :::* -
udp6 0 0 :::5008 :::* -
udp6 0 0 :::5009 :::* -
udp6 0 0 :::5010 :::* -
udp6 0 0 :::5011 :::* -
udp6 0 0 :::5012 :::* -
udp6 0 0 :::5013 :::* -
udp6 0 0 :::5014 :::* -
udp6 0 0 :::5015 :::* -
udp6 0 0 :::5016 :::* -
udp6 0 0 :::5017 :::* -
udp6 0 0 :::5018 :::* -
udp6 0 0 :::5019 :::* -
udp6 0 0 :::5020 :::* -
udp6 0 0 :::5021 :::* -
udp6 0 0 :::5022 :::* -
udp6 0 0 :::5023 :::* -
udp6 0 0 :::5024 :::* -
udp6 0 0 :::5025 :::* -
udp6 0 0 :::5026 :::* -
udp6 0 0 :::5027 :::* -
udp6 0 0 :::5028 :::* -
udp6 0 0 :::5029 :::* -
udp6 0 0 :::5030 :::* -
udp6 0 0 :::5031 :::* -
udp6 0 0 :::5032 :::* -
udp6 0 0 :::5033 :::* -
udp6 0 0 :::5034 :::* -
udp6 0 0 :::5035 :::* -
udp6 0 0 :::5036 :::* -
udp6 0 0 :::5037 :::* -
udp6 0 0 :::5038 :::* -
udp6 0 0 :::5039 :::* -
udp6 0 0 :::5040 :::* -
udp6 0 0 :::5041 :::* -
udp6 0 0 :::5042 :::* -
udp6 0 0 :::5043 :::* -
udp6 0 0 :::5044 :::* -
udp6 0 0 :::5045 :::* -
udp6 0 0 :::5046 :::* -
udp6 0 0 :::5047 :::* -
udp6 0 0 :::5048 :::* -
udp6 0 0 :::5049 :::* -
udp6 0 0 :::5050 :::* -
udp6 0 0 :::8060 :::* -

One way to test this setup is using Aspect Prophecy VMXL. See these instructions how to configure Prophecy.

You can also test it by running a GREG experiment.

Related articles