共用方式為


通話結束於 410/3112

呼叫以 410/3112 錯誤結束的原因是客戶端無法連線到其他端點,而且不會收集任何轉接候選專案。 當媒體路徑因為網路問題、防火牆限制或組態設定不正確而無法建立時,可能會發生這個 410/3112 錯誤碼。 因此,對等無法建立直接或轉接連線。

如果客戶端能夠建立與其他對等的直接連線,則不需要轉接候選專案。 不過,當 WebRTC 無法收集轉送候選專案時,通常會指出 TURN(在 NAT 周圍周遊使用轉送)伺服器設定或網路限制的問題。 轉接候選項目對於在限制性網路環境中建立連線至關重要。

如何使用 SDK 進行偵測

您可以瞭解呼叫結束的原因,其使用下列代碼段。

call.on('stateChanged', () => {
    if (call.state === 'Disconnected') {
      if (call.callEndReason.code === 410 && call.callEndReason.subCode === 3112) {
          // show error message
      }
    }
});

若要瞭解代碼和子程式代碼,請參閱 瞭解呼叫程式代碼和子程式代碼錯誤

無法建立媒體路徑時,呼叫會以代碼 410 和子碼 3112 終止。 SDK 也會觸發 networkRelaysNotReachable UFD 事件。 以下代碼段顯示如何擷取 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
       }
    }
});

如何使用Log Analytics或呼叫診斷工具來分析問題

當使用者回報他們無法撥打電話時,您可以使用 通話診斷 工具來分析失敗的原因。 若要對使用者呼叫進行偵錯,您需要 通話標識符。 如果使用者的呼叫失敗,因為防火牆封鎖了轉接連線,您可以在通話的概觀頁面上找到結尾代碼和子碼為 410 和 3112。

通話診斷的螢幕快照,其中包含通話概觀頁面上的子代碼 3112。

此外,您也可以在通話問題頁面上找到 networkRelaysNotReachable UFD 事件。

在通話問題頁面上具有 networkRelaysNotReachable UFD 的通話診斷螢幕快照。

若要瞭解使用者動作或事件的時機,您可以檢查時間軸頁面上的詳細數據。 在此範例中,使用者於16:41:47取得 networkRelaysNotReachable UFD 事件,並在16:41:49呼叫狀態變更事件。

通話診斷的螢幕快照,其中顯示事件呼叫時程表頁面的計時。

通話 診斷 工具提供您偵錯單一呼叫的概觀和必要資訊。 如果您想要瞭解有多少使用者遇到此問題,或使用者遇到問題的頻率,您可以使用 Log Analytics 工具來取得此問題的深入解析。

例如,如果您想要取得過去 7 天內與子代碼 3112 中斷連線的通話標識碼,您可以執行此查詢:

ACSCallSummary
| where ParticipantEndSubCode == 3112
| project TimeGenerated, CorrelationId, ParticipantId, Identifier, CallType

使用子碼 3112 呼叫的記錄查詢結果螢幕快照。

您也可以轉譯時間圖,以瞭解以子碼 3112 結尾的每日呼叫數目

ACSCallSummary
| where ParticipantEndSubCode == 3112
| summarize count() by bin(TimeGenerated, 1d)
| render timechart

時間圖的螢幕快照,其中顯示以子碼 3112 結尾的每日呼叫數目。

時程圖表只會提供相同 ACS 資源識別子下使用者的概觀。 藉由執行更特定的查詢,您可以識別單靠時程圖表無法立即發現的模式或異常,協助您更準確地找出任何問題的根本原因。

例如,如果您看到以子碼 3112 結尾的呼叫數目突然增加,可能是因為大量呼叫,而問題的發生比例維持不變。 或者,尖峰可能會歸因於重試多次的特定使用者,而且所有嘗試都失敗,且子碼為 3112。

在此查詢中,我們會根據使用者標識碼來分析數據,假設應用程式會為每個個人維護相同的使用者標識碼。

ACSCallSummary
| summarize Total = count(), SuccessCount = countif(ParticipantEndSubCode == 0), SubCode3112Count = countif(ParticipantEndSubCode == 3112) by Identifier
| where SubCode3112Count > 0
| order by SubCode3112Count desc

記錄查詢結果的螢幕快照,其中顯示以每個使用者標識碼 3112 結尾的呼叫數目。

在此範例中,一位用戶總共有180個呼叫,其中160個呼叫成功,只有兩個呼叫失敗,子碼為3112。 此模式建議暫時性網路問題,可藉由重試來解決。 另一方面,另一位用戶總共有六個呼叫,全部都因為子碼 3112 而失敗。 子程式代碼值中的這個一致性表示該使用者可能發生的網路設定問題,而重試不太可能有説明。

如何減輕或解決

如果您發現使用者一直遇到 410/3112 錯誤,建議您檢查其防火牆設定。 用戶應遵循網路建議檔中所述的防火牆設定指導方針。 確定使用者或系統管理員檢查其網路位址轉換 (NAT) 設定,並驗證其防火牆原則是否封鎖使用者數據報通訊協定 (UDP) 封包。 防火牆設定不限於用戶的計算機;如果用戶位於公司環境中,可能需要設定公司的防火牆。

此外,如果應用程式使用 自定義 TURN 伺服器,請確定任何防火牆都不會封鎖指定的 IP、埠和通訊協定。

針對應用程式,請務必處理來自 使用者面向診斷功能 的事件,並據以通知使用者。 如此一來,使用者就會知道問題,並可對其網路環境進行疑難解答。

在極少數情況下,即使使用者的防火牆設定正確,這個錯誤碼仍會隨機顯示。 如果同一位使用者先前能夠成功連線並呼叫,此問題可能是因為網路狀況的變更所造成。 這可能是暫時性問題。 請嘗試再次啟動或加入通話。

參考資料