Contribute in GitHub:

Solving common problems in Voice Gateway

Tip: You can use the Voice Gateway system messages information to help resolve error and warning messages. Each message includes an explanation of the problem and details of any action that you can take.

Calls are failing: Calls can fail for many reasons, including misconfiguration of one of your Watson services, IP routing issues, firewall issues, etc.

First, check that both the SIP Orchestrator and the Media Relay containers are running and that the Watson services are properly configured.
Next, look at the SIP Orchestrator logs to see if the SIP INVITE message that initiates the call is reaching the container. If it does, follow the flow of the call in the trace to the point where the error occurs, which is where the SIP error response is sent back to the caller.
If the SIP INVITE isn't reaching the voice gateway (that is, it does not appear in the logs), your firewall might be blocking the SIP port (5060), or the SIP trunk might not be properly configured to route to the correct IP address of the SIP Orchestrator container.

I hear Watson, but Watson does not hear me: This problem is almost always a firewall issue or a problem with the SIP trunk or SIP client you're using. Because audio media can flow over such a wide range of ports, it's possible that your firewall isn't configured to receive media over the configured port stream. Check the configuration of the Media Relay to see what the media port range is, and make sure that your firewall is configured to accommodate that port range. If you're trying to use a SIP client to connect with the gateway, also check for port conflicts.
There is a lot of latency between caller questions and Watson answers: This problem is most likely coming from latency that is caused by one of the Watson services. You can look at the audit logs to determine which service is misbehaving.
Call transfers are failing: Call transfers are supported by the voice gateway, but they require an entity that understands SIP REFER messages to stay in the call path and anchor the call for the life of the call with Watson, such as a session border controller (SBC). If you want to support call transfer, you need to use a SIP trunking vendor that supports SIP REFER messages (for example, Twilio) or provide your own call anchor that can handle SIP REFER messages.
I got a CWSMR0050E or CWSMR0048E error that says the connection closed with a unexpected server response (401) error: Voice Gateway likely can't contact the specified Watson service because the credentials are not accepted. Verify that the credentials for the Watson service are configured correctly. For information about how to find Watson service credentials, see Service credentials for Watson services in the Watson documentation.
I am experiencing many vgwPostResponseTimeouts or high latency in calls: Enabling RTCP network reports can help indicate whether the cause of the timeouts or latency is a VoIP issue or a speech recognition issue. If RTCP network reporting is enabled, warnings are printed; for example:
```
  CWSMR0035W: The inbound RTP audio stream packet loss of 9 percent exceeds the maximum packet loss threshold of 5 percent.
```
A CWSMR0048E error message says that the Watson Speech to Text service closed because of an error with the self-signed certificate in the certificate chain: The problem is likely a firewall issue in the infrastructure. The firewall is probably intercepting the request and putting in its own certificate. Since the certificate isn't trusted by the deployment, a self-signed certificate error occurs.

To check for this situation, complete the following steps:
1. Issue a curl command to the Watson service from the VM where that IBM Voice Gateway is running.
  
  Use the following example command:
```
curl --insecure -v https://<Watson Speech-To-Text endpoint hostname>/speech-to-text 2>&1
```
  Substitute the https://<Watson Speech-To-Text endpoint hostname> text in the command with the URL for your Watson Speech-To-Text instance, such as the https://stream.watsonplatform.net/speech-to-text/api URL.
2. Search for a section in the output that says Server Certificate. If the text in the output does NOT match the following text, then the firewall is intercepting the connection:
```
* Server certificate:
*  subject: C=US; ST=New York; L=Armonk; O=INTERNATIONAL BUSINESS MACHINES CORPORATION; CN=*.watsonplatform.net
*  start date: Jan  9 00:00:00 2018 GMT
*  expire date: Mar  9 12:00:00 2020 GMT
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=GeoTrust RSA CA 2018
*  SSL certificate verify ok.
```
You might be able to resolve the problem in one of the following ways:
- Contact your firewall administrator to whitelist the hostname so that the firewall won't intercept the certificate.
- Configure Voice Gateway to trust the certificate exchanged by the firewall. For more information, see Configuring SSL and TLS encryption.