Partager via

Résolution des problèmes d’échecs des appels RTC d’Azure Communication Services

  • Article

Lorsque vous résolvez des problèmes d’échecs des appels RTC d’Azure Communication Services, nous vous recommandons d’activer la journalisation. Vous pouvez ensuite utiliser les valeurs ResultCategories, ParticipantEndReasonet ParticipantEndSubCode pour déterminer pourquoi un appel individuel s’est terminé et si le système a détecté des défaillances.

Utilisation de ResultCategories pour résoudre des problèmes d’échecs

Le tableau ResultCategories est une propriété du schéma de journal du résumé des appels. Il contient une liste de raisons générales qui décrit comment l’appel a pris fin :

  • Success
  • Failure
  • UnexpectedClientError
  • UnexpectedServerError

Ces informations peuvent vous aider à déterminer pourquoi un appel a pris fin sans générer de journal détaillé des erreurs.

Utilisation de ParticipantEndReason et ParticipantEndSubCode pour résoudre des problèmes d’échecs

Si le niveau de détail dans ResultCategories est insuffisant lors du dépannage des appels RTC, vous pouvez utiliser ParticipantEndReason et ParticipantEndSubCode pour comprendre plus en détail les raisons de la fin d’un appel. ParticipantEndReason et ParticipantEndSubCode sont également des propriétés du schéma de journal du résumé des appels.

ParticipantEndReason

ParticipantEndReason est un code à trois chiffres qui affiche l’état général de l’appel. Ce code explique pourquoi l’appel a pris fin et regroupe les échecs par catégorie. Par exemple, ParticipantEndReason 404 signifie que l’appelant et l’appelé n’a pas été trouvé. ParticipantEndReason 500 signifie qu’une erreur de service s’est produite.

Ce code est basé sur les codes de réponse du protocole SIP. Pour découvrir plus d’informations, consultez la liste des codes de réponse SIP de Wikipédia.

ParticipantEndSubCode

ParticipantEndSubCode est un code de réponse plus spécifique qui est généralement d’une longueur de six chiffres. Il explique de manière plus détaillée la raison du problème avec l’appel.

Un facteur clé dans la résolution des problèmes d’appels RTC Azure Communication Services détermine si le code de réponse final de l’appel provient d’un processus Microsoft ou du Session Border Controller (SBC) des utilisateurs/opérateurs. Un moyen simple de déterminer l’origine du code consiste à examiner la réponse ParticipantEndSubCode.

Si la valeur de ParticipantEndSubCode commence par 560, elle indique que le SBC de l’opérateur/utilisateur a généré le code de réponse. Dans ce cas, vous devez vérifier la configuration du SBC.

Par exemple, si la valeur de ParticipantEndSubCode est 560403, cela signifie que le SBC a généré le code de réponse final et le code est 403. Dans ce cas, vous devez commencer le dépannage des appels en utilisant les journaux SBC.

Pour toutes les réponses ParticipantEndSubCode qui ne commencent pas par 560, le code de réponse final est généré par le service Microsoft.

Contenu connexe