Felsöka PSTN-samtalsfel i Azure Communication Services
När du felsöker PSTN-samtalsfel i Azure Communication Services rekommenderar vi att du aktiverar loggning. Sedan kan du använda ResultCategoriesvärdena , ParticipantEndReasonoch ParticipantEndSubCode för att avgöra varför ett enskilt anrop avslutades och om systemet identifierade några fel.
Använda ResultCategories för att felsöka fel
Matrisen ResultCategories är en egenskap för schemat för anropssammanfattningsloggen. Den innehåller en lista över allmänna orsaker som beskriver hur samtalet avslutades:
SuccessFailureUnexpectedClientErrorUnexpectedServerError
Den här informationen kan hjälpa dig att avgöra varför ett anrop avslutades utan att generera en detaljerad fellogg.
Använda ParticipantEndReason och ParticipantEndSubCode för att felsöka fel
Om detaljnivån i ResultCategories inte räcker när du felsöker PSTN-anrop kan du använda ParticipantEndReason och ParticipantEndSubCode förstå orsakerna till att ett samtal avslutades mer detaljerat. ParticipantEndReasonoch ParticipantEndSubCode är också egenskaper för schemat för anropssammanfattningsloggen.
ParticipantEndReason
ParticipantEndReason är en tresiffrig kod som visar den allmänna samtalsstatusen. Den här koden förklarar varför anropet avslutades och grupperar fel efter kategori. Det innebär till exempel ParticipantEndReason 404 att anroparen eller anroparen inte hittades. ParticipantEndReason 500 innebär att ett tjänstfel uppstod.
Den här koden baseras på SIP-svarskoder (Session Initiation Protocol). Mer information finns i Wikipedias lista över SIP-svarskoder.
ParticipantEndSubCode
ParticipantEndSubCode är en mer specifik svarskod som vanligtvis är sex siffror lång. Det förklarar mer detaljerat varför det uppstod ett problem med anropet.
En viktig faktor vid felsökning av PSTN-anrop för Azure Communication Services är att avgöra om den slutliga SIP-svarskoden för samtalet kom från en Microsoft-process eller användarens/operatörens sessionsgränskontrollant (SBC). Ett enkelt sätt att avgöra var koden kommer ifrån är att titta på ParticipantEndSubCode svaret.
Om värdet ParticipantEndSubCode börjar med 560anger det att användarens/operatorns SBC genererade svarskoden. I så fall bör du kontrollera SBC-konfigurationen.
Om värdet ParticipantEndSubCode till exempel är 560403innebär det att SBC genererade den slutliga svarskoden och att koden är 403. I så fall bör du börja felsöka anropen med hjälp av SBC-loggarna.
För ParticipantEndSubCode svar som inte börjar med 560genererade Microsoft-tjänsten den slutliga svarskoden.
Relaterat innehåll
- Allmän felsökningsinformation finns i Felsökning i Azure Communication Services.
- Detaljerad information om vanliga felkoder och föreslagna åtgärder finns i Felsöka svarskoder för samtalsslut för samtals-SDK, Call Automation SDK och PSTN-anrop.