Samtalet avslutas med 410/3112
Anledningen till att anropet slutar med 410/3112-felet är att klienten inte kan nå ut till den andra slutpunkten och inga reläkandidater samlas in. Den här 410/3112-felkoden kan inträffa när mediesökvägen inte kan upprättas på grund av nätverksproblem, brandväggsbegränsningar eller felaktiga konfigurationsinställningar. Därför kunde peer-datorerna inte upprätta en direkt- eller reläanslutning.
Reläkandidaterna är inte nödvändiga om klienten kan upprätta en direkt anslutning till den andra peer-peern. Men när WebRTC inte kan samla in reläkandidater indikerar det ofta ett problem med TURN-serverkonfiguration eller nätverksbegränsningar (Bläddring med reläer runt NAT). Reläkandidater är avgörande för att upprätta anslutningar i restriktiva nätverksmiljöer.
Så här identifierar du med hjälp av SDK
Du kan lära dig orsaken till att samtalet slutar med hjälp av följande kodfragment.
call.on('stateChanged', () => {
if (call.state === 'Disconnected') {
if (call.callEndReason.code === 410 && call.callEndReason.subCode === 3112) {
// show error message
}
}
});
Information om koder och underkoder finns i Förstå anropskoder och underkoder.
När mediesökvägen inte kan upprättas avslutas anropet med kod 410 och underkod 3112.
SDK utlöser också networkRelaysNotReachable UFD-händelse .
Här är ett kodfragment som visar hur du networkRelaysNotReachable UFD avbildar händelsen.
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
}
}
});
Så här analyserar du problemet med Log Analytics eller verktyget Samtalsdiagnostik
När en användare rapporterar att de inte kan göra ett anrop kan du använda verktyget Samtalsdiagnostik för att analysera orsaken till felet. Om du vill felsöka användaranrop behöver du samtals-ID :t. Om användarens anrop misslyckades på grund av att brandväggen blockerade reläanslutningen kan du se att slutkoden och underkoden är 410 och 3112 på översiktssidan för anropet.
Dessutom kan du hitta networkRelaysNotReachable UFD-händelsen på sidan med samtalsproblem.
Om du vill förstå tidpunkten för användaråtgärder eller händelser kan du kontrollera informationen på tidslinjesidan.
I det här exemplet fick networkRelaysNotReachable UFD användaren händelsen 16:41:47 och anropstillståndsändringshändelsen kl. 16:41:49.
Verktyget Samtalsdiagnostik ger dig en översikt och nödvändig information för felsökning av ett enda anrop. Om du vill förstå hur många användare som stöter på det här problemet, eller hur ofta användarna upplever problemet, kan du använda Log Analytics-verktyget för att få insikter om det här problemet.
Om du till exempel vill få det anrops-ID som var frånkopplat med underkod 3112 under de senaste sju dagarna kan du köra den här frågan:
ACSCallSummary
| where ParticipantEndSubCode == 3112
| project TimeGenerated, CorrelationId, ParticipantId, Identifier, CallType
Du kan också återge ett tidsschema för att förstå det dagliga antalet anrop som slutar med underkod 3112
ACSCallSummary
| where ParticipantEndSubCode == 3112
| summarize count() by bin(TimeGenerated, 1d)
| render timechart
Tidsdiagrammet ger bara en översikt över användarna under samma ACS-resurs-ID. Genom att köra mer specifika frågor kan du identifiera mönster eller avvikelser som inte är direkt synliga enbart från tidsdiagrammet, vilket hjälper dig att hitta rotorsaken till eventuella problem mer exakt.
Om du till exempel ser en topp i antalet anrop som slutar med underkod 3112 kan det bero på den stora mängden anrop medan problemets förekomstförhållande förblev detsamma. Alternativt kan toppen tillskrivas en viss användare som har försökt igen många gånger och alla försök misslyckades med underkod 3112.
I den här frågan analyserar vi data baserat på användaridentifierare, förutsatt att appen har samma användaridentifierare för varje individ.
ACSCallSummary
| summarize Total = count(), SuccessCount = countif(ParticipantEndSubCode == 0), SubCode3112Count = countif(ParticipantEndSubCode == 3112) by Identifier
| where SubCode3112Count > 0
| order by SubCode3112Count desc
I det här exemplet hade en användare totalt 180 anrop, varav 160 anrop lyckades och endast två anrop misslyckades med underkod 3112. Det här mönstret tyder på ett tillfälligt nätverksproblem som kan lösas genom att försöka igen. Å andra sidan hade en annan användare totalt sex anrop, som alla misslyckades med underkod 3112. Den här konsekvensen i underkodsvärdet anger ett troligt problem med nätverkskonfigurationen för användaren, där det är osannolikt att ett nytt försök kommer att hjälpa.
Så här åtgärdar eller löser du
Om du upptäcker att en användare konsekvent får 410/3112-fel bör du rekommendera att de kontrollerar sina brandväggsinställningar. Användarna bör följa riktlinjerna för brandväggskonfiguration som nämns i dokumentet Nätverksrekommendationer. Se till att användaren eller administratören kontrollerar sina NAT-inställningar (Network Address Translation) och kontrollerar om deras brandväggsprincip blockerar UDP-paket (User Datagram Protocol). Brandväggsinställningarna är inte begränsade till användarens dator. Om användaren befinner sig i en företagsmiljö kan företagets brandvägg också behöva konfigureras.
Om programmet använder anpassade TURN-servrar kontrollerar du dessutom att angivna IP-adresser, portar och protokoll inte blockeras av någon brandvägg.
För programmet är det viktigt att hantera händelser från funktionen användarinriktad diagnostik och meddela användarna om detta. På så sätt är användaren medveten om problemet och kan felsöka sin nätverksmiljö.
I sällsynta fall visas den här felkoden slumpmässigt även om användarens brandväggsinställningar är korrekta. Om samma användare tidigare kunde ansluta och anropa korrekt kan det här problemet bero på ändringar i nätverksvillkoren. Det kan vara ett tillfälligt problem. Försök att starta eller ansluta samtalet igen.