Résolution des problèmes communs dans Voice Gateway

Astuce : Vous pouvez utiliser les informations sur les messages système de Voice Gateway pour vous aider à résoudre les messages d'erreur et d'avertissement. Chaque message comprend une explication du problème, ainsi que les actions détaillées permettant de le résoudre.

• Appels en échec : il peut y avoir de nombreuses raisons à l'échec des appels, notamment un problème de configuration de l'un de vos services Watson, des problèmes de routage d'IP, des incidents liés aux pare-feux, etc.
  1. Dans un premier temps, vérifiez que les conteneurs SIP Orchestrator et Media Relay sont bien en cours d'exécution et que les services Watson sont correctement configurés.
  2. Ensuite, consultez les journaux SIP Orchestrator pour voir si le message SIP INVITE qui initie l'appel atteint le conteneur. Si tel est le cas, suivez le flux de l'appel dans la trace jusqu'au point où se produit l'erreur, c'est-à-dire le moment où la réponse d'erreur SIP est envoyée à l'appelant.
  3. Si le message SIP INVITE n'atteint pas la passerelle voix (en d'autres termes, s'il ne figure pas dans les journaux), votre pare-feu bloque peut-être le port SIP (5060) ou bien la liaison SIP n'est peut-être pas correctement configurée pour le routage jusqu'à l'adresse IP correcte du conteneur SIP Orchestrator.
• J'entends Watson, mais Watson ne m'entend pas : Cet incident est presque toujours lié à un problème de pare-feu ou à un problème avec la liaison SIP ou le client SIP que vous utilisez. Parce que le média audio peut passer par une large plage de ports, il est possible que votre pare-feu ne soit pas configuré pour recevoir le média via le flux de port configuré. Vérifiez la configuration de Media Relay pour voir la plage de ports média utilisée, et assurez-vous que votre pare-feu est configuré pour s'adapter à cette plage de ports. Si vous essayez d'utiliser un client SIP pour vous connecter à la passerelle, recherchez également d'éventuels conflits de port.
• Le temps d'attente est particulièrement long entre les questions de l'appelant et les réponses de Watson : Ce problème vient généralement du temps d'attente qui est généré par l'un des services Watson. Vous pouvez consulter les journaux d'audit afin de déterminer le service dont le comportement ne convient pas.
• Les transferts d'appel échouent : Les transferts d'appel sont pris en charge par la passerelle voix, mais ils nécessitent une entité capable de comprendre les messages SIP REFER pour rester dans le chemin d'appel et ancrer l'appel pour la durée avec Watson, comme c'est le cas pour un contrôleur SBC. Si vous souhaitez prendre en charge le transfert d'appel, vous devez utiliser un fournisseur de liaison SIP qui prenne en charge les messages SIP REFER (par exemple Twilio) ou fournir votre propre point d'ancrage pouvant gérer les messages SIP REFER.
• J'obtiens une erreur CWSMR0050E ou CWSMR0048E indiquant que la connexion a été arrêtée avec l'erreur unexpected server response (401). Il est possible que Voice Gateway ne puisse pas contacter le service Watson spécifié car les données d'identification ne sont pas acceptées. Vérifiez que les données d'identification du service Watson sont correctement configurées. Pour en savoir plus sur la façon dont vous pouvez trouver les données d'identification du service Watson, voir Données d'identification de service pour les services Watson dans la documentation de Watson.
• Je rencontre de nombreux vgwPostResponseTimeouts ou des délais d'attente importants dans les appels : l'activation des rapports réseau RTCP peut permettre de déterminer si la cause de ces délais ou dépassements de délai est un problème de VoIP ou de reconnaissance vocale. Si la génération de rapports réseau RTCP est activée, des avertissements sont générés. Par exemple :

   CWSMR0035W: La perte de paquets RTP entrants de 9 pour cent dans le flux audio dépasse le seuil maximal de perte de paquet de 5 pour cent.

• Un message d'erreur CWSMR0048E indique que le service Watson Speech to Text a été fermé en raison d'une erreur au niveau du certificat auto-signé dans la chaîne de certificats : L'incident est probablement dû à un problème de pare-feu dans l'infrastructure. Le pare-feu intercepte probablement la demande et insère son propre certificat. Comme le certificat n'est pas considéré comme digne de confiance par le déploiement, une erreur de certificat auto-signé se produit.

  Pour vérifier cette situation, procédez comme suit :

  1. Emettez une commande curl dans le service Watson à partir de la machine virtuelle dans laquelle IBM Voice Gateway s'exécute. Utilisez l'exemple de commande suivant :

     curl --insecure -v https://<Watson Speech-To-Text endpoint hostname>/speech-to-text 2>&1
     

     Remplacez le texte https://<Watson Speech-To-Text endpoint hostname> dans la commande par l'URL de votre instance Watson Speech-To-Text, par exemple par l'URL https://stream.watsonplatform.net/speech-to-text/api.

  2. Recherchez une section indiquant Server Certificate dans la sortie. Si le texte de la sortie ne correspond PAS au texte suivant, cela signifie que le pare-feu intercepte la connexion :

     * 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.
     

  Vous pouvez résoudre le problème de l'une des manières suivantes :

  • Contactez votre administrateur de pare-feu pour placer sur liste blanche le nom d'hôte afin que le pare-feu n'intercepte pas le certificat.
  • Configurez Voice Gateway pour faire confiance au certificat échangé par le pare-feu. Pour plus d'informations, voir Configuration du chiffrement SSL et TLS.