L’appel se termine par 410/3112
La raison pour laquelle l’appel se termine par une erreur 410/3112 est que le client n’est pas en mesure d’atteindre l’autre point de terminaison et qu’aucun candidat au relais n’a été obtenu. Ce code d’erreur 410/3112 peut se produire quand le chemin d’accès du média ne peut pas être établi en raison de problèmes réseau, de restrictions de pare-feu ou de paramètres de configuration incorrects. Par conséquent, les pairs n’ont pas pu établir de connexion directe ou de relais.
Les candidats au relais ne sont pas nécessaires si le client est en mesure d’établir une connexion directe avec l’autre pair. Cependant, quand WebRTC ne parvient pas à obtenir des candidats au relais, cela indique souvent un problème de configuration du serveur TURN (Traversal Using Relays around NAT) ou des restrictions réseau. Les candidats au relais sont essentiels pour établir des connexions dans des environnements réseau restrictifs.
La détection à l’aide du Kit de développement logiciel (SDK)
Vous pouvez connaître la raison de la fin de l’appel en utilisant l’extrait de code suivant.
call.on('stateChanged', () => {
if (call.state === 'Disconnected') {
if (call.callEndReason.code === 410 && call.callEndReason.subCode === 3112) {
// show error message
}
}
});
Pour comprendre les codes et les sous-codes, consultez Comprendre les erreurs des codes et des sous-codes des appels.
Quand le chemin d’accès du média ne peut pas être établi, l’appel se termine par un code 410 et un sous-code 3112.
Le Kit de développement logiciel (SDK) déclenche également l’événement UFD networkRelaysNotReachable.
Voici un extrait de code montrant comment capturer l’événement networkRelaysNotReachable UFD.
call.feature(Features.UserFacingDiagnostics).network.on('diagnosticChanged', (diagnosticInfo) => {
if (diagnosticInfo.diagnostic === 'networkRelaysNotReachable') {
if (diagnosticInfo.value === true) {
// show a warning message on UI
} else {
// The networkRelaysNotReachable UFD recovered, notify the user
}
}
});
Comment analyser le problème avec l’outil Log Analytics ou Diagnostics des appels
Quand un utilisateur signale qu’il ne peut pas passer un appel, vous pouvez utiliser l’outil Diagnostics des appels pour analyser la raison de l’échec. Pour déboguer les appels des utilisateurs, vous avez besoin de l’ID de l’appel. Si l’appel de l’utilisateur a échoué parce que le pare-feu a bloqué la connexion de relais, vous pouvez voir que le code et le sous-code de fin sont 410 et 3112 sur la page de vue d’ensemble de l’appel.
En outre, vous pouvez également trouver l’événement UFD networkRelaysNotReachable dans la page des problèmes d’appel.
Pour comprendre la chronologie des actions ou des événements de l’utilisateur, vous pouvez consulter les détails dans la page de la chronologie.
Dans cet exemple, l’utilisateur a reçu l’événement networkRelaysNotReachable UFD à 16:41:47 et l’événement de changement d’état de l’appel à 16:41:49.
L’outil Diagnostic des appels vous donne une vue d’ensemble et les informations nécessaires pour déboguer un appel. Si vous voulez comprendre combien d’utilisateurs rencontrent ce problème ou à quelle fréquence, vous pouvez utiliser l’outil Log Analytics pour obtenir des insights sur ce problème.
Par exemple, si vous voulez obtenir l’ID des appels qui ont été déconnectés avec le sous-code 3112 au cours des sept derniers jours, vous pouvez exécuter cette requête :
ACSCallSummary
| where ParticipantEndSubCode == 3112
| project TimeGenerated, CorrelationId, ParticipantId, Identifier, CallType
Vous pouvez aussi afficher un graphique temporel pour comprendre le nombre d’appels quotidien qui se terminent avec le sous-code 3112.
ACSCallSummary
| where ParticipantEndSubCode == 3112
| summarize count() by bin(TimeGenerated, 1d)
| render timechart
Le graphique temporel donne seulement une vue d’ensemble des utilisateurs sous le même ID de ressource ACS. En exécutant des requêtes plus spécifiques, vous pouvez identifier des modèles ou des anomalies qui ne sont pas immédiatement visibles à partir du seul graphique temporel, ce qui vous permet d’identifier avec plus de précision la cause première des problèmes.
Par exemple, si vous constatez un pic dans le nombre d’appels se terminant avec le sous-code 3112, cela peut être dû à un volume élevé d’appels alors que le pourcentage des occurrences du problème est resté le même. Le pic peut également être dû à un utilisateur particulier qui a réessayé plusieurs fois et dont toutes les tentatives ont échoué avec le sous-code 3112.
Dans cette requête, nous analysons les données sur la base des identifiants des utilisateurs, en supposant que l’application conserve le même identifiant utilisateur pour chaque personne individuelle.
ACSCallSummary
| summarize Total = count(), SuccessCount = countif(ParticipantEndSubCode == 0), SubCode3112Count = countif(ParticipantEndSubCode == 3112) by Identifier
| where SubCode3112Count > 0
| order by SubCode3112Count desc
Dans cet exemple, un utilisateur a passé un total de 180 appels, dont 160 ont abouti et seulement deux ont échoué avec le sous-code 3112. Ce modèle suggère un problème réseau transitoire, qui peut être résolu en effectuant une nouvelle tentative. D’autre part, un autre utilisateur a passé six appels au total, qui ont tous échoué avec le sous-code 3112. Cette cohérence dans la valeur du sous-code indique un probable problème de configuration réseau pour cet utilisateur, pour lequel il est peu probable que de nouvelles tentatives vont l’aider.
Comment atténuer ou résoudre le problème
Si vous constatez qu’un utilisateur rencontre systématiquement l’erreur 410/3112, vous devez lui recommander de vérifier ses paramètres de pare-feu. Les utilisateurs doivent suivre les instructions de configuration du pare-feu mentionnées dans le document Recommandations pour le réseau. Veillez à ce que l’utilisateur ou l’administrateur vérifie ses paramètres de traduction d’adresses réseau (NAT) et si sa stratégie de pare-feu bloque les paquets UDP (User Datagram Protocol). Les paramètres du pare-feu ne sont pas limités à l’ordinateur de l’utilisateur ; si l’utilisateur est dans un environnement d’entreprise, le pare-feu de l’entreprise peut également devoir être configuré.
En outre, si l’application utilise des serveurs TURN personnalisés, vérifiez que l’adresse IP, le port et le protocole spécifiés ne sont pas bloqués par un pare-feu.
Pour l’application, il est important de gérer les événements de la fonctionnalité Diagnostic accessible à l’utilisateur et de notifier les utilisateurs en conséquence. De cette façon, l’utilisateur est informé du problème et peut dépanner son environnement réseau.
Dans de rares cas, ce code d’erreur apparaît de façon aléatoire, même si les paramètres de pare-feu de l’utilisateur sont corrects. Si le même utilisateur était auparavant en mesure de se connecter et d’appeler, ce problème peut être dû à des changements dans les conditions du réseau. Il peut s’agir d’un problème temporaire. Réessayez d’initier l’appel ou de vous y joindre.