通話は 410/3112 で終了します

通話が 410/3112 エラーで終了する理由は、クライアントが他のエンドポイントに到達できず、リレー候補が収集されないことです。 この 410/3112 エラー コードは、ネットワークの問題、ファイアウォールの制限、または正しくない構成設定により、メディア パスを確立できない場合に発生する可能性があります。 そのため、ピアでは直接接続もリレー接続も確立できなかったということです。

クライアントが他のピアへの直接接続を確立できる場合には、リレー候補は必要ありません。 ただし、WebRTC がリレー候補の収集に失敗する場合、よくあるケースとして、TURN (Traversal Using Relays around 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 または通話診断ツールで問題を分析する方法

ユーザーが通話できないことを報告する場合、通話診断ツールを使用して、エラーの原因を分析できます。 ユーザーの通話をデバッグするには、通話 ID が必要です。 ファイアウォールによってリレー接続がブロックされたことが理由でユーザーの通話が失敗した場合は、[通話の概要] ページで、エンド コードが 410、サブコードが 3112 であることがわかります。

また、[通話の問題] ページの networkRelaysNotReachable UFD イベントにも表示されます。

ユーザーのアクションやイベントのタイミングを理解するには、[タイムライン] ページで詳細を確認できます。 この例では、ユーザーは 16:41:47 に networkRelaysNotReachable UFD イベントを、16:41:49 に通話状態変更イベントを受け取りました。

通話診断ツールにより、1 つの通話をデバッグするための概要と必要な情報が得られます。 この問題に遭遇するユーザーの数や、ユーザーがこの問題を経験する頻度などを理解するには、Log Analytics ツールを使用して、この問題に関する分析情報を取得することができます。

たとえば、直近の 7 日間にサブコード 3112 で切断された通話 ID を取得するには、次のクエリを実行します。

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

タイムチャートをレンダリングして、サブコード 3112 で終了する通話の 1 日当たりの数を把握することもできます。

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

タイム チャートでは、同一の ACS リソース ID 下のユーザーの概要のみが提供されます。 より特化したクエリを実行することで、パターンや、タイム チャートだけからではすぐには明らかにならない異常を特定することができます。これにより、問題の根本原因をより正確に特定できるようになります。

たとえば、サブコード 3112 で終了する通話の数にスパイクが検知される場合、問題の発生率は変わらないまま、通話の量が増大していることが理由である可能性があります。 あるいは、スパイクが、何回も通話を試みて、その試行がすべてサブコード 3112 で失敗した特定のユーザーに起因するものである可能性もあります。

このクエリでは、ユーザー ID に基づいてデータを分析します。ここでは、各個人について、アプリが同一のユーザー ID を保持していることを前提としています。

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

この例では、1 人のユーザーが合計 180 回の通話を行い、そのうち 160 回は問題なく、サブコード 3112 で失敗した通話は 2 回のみでした。 このパターンは、一時的なネットワークの問題を示唆しています。この問題は再試行で解決する可能性があります。 いっぽうで、別のユーザーは合計 6 回の通話を行い、それがすべてサブコード 3112 で失敗しています。 サブコードの値がこのように一定であることは、そのユーザーについてネットワーク構成の問題がある可能性が高いことを示しており、こういう場合は再試行では問題はまず解決しません。

軽減または解決する方法

あるユーザーが継続的に 410/3112 エラーを経験している場合、ファイアウォールの設定を確認するよう推奨するべきです。 ユーザーは、「ネットワークの推奨事項」ドキュメントに記載されている "ファイアウォールの構成" ガイドラインに従う必要があります。 ユーザーまたは管理者は、そのユーザーのネットワーク アドレス変換 (NAT) 設定を確認し、ファイアウォール ポリシーがユーザー データグラム プロトコル (UDP) パケットをブロックしているかどうかを確認します。 ファイアウォールの設定はユーザーのコンピューターに限られたものではありません。ユーザーが企業の環境内にいる場合、その会社のファイアウォールも構成する必要がある場合があります。

さらに、アプリケーションでカスタム TURN サーバーを使用している場合は、指定された IP、ポート、プロトコルが、いずれのファイアウォールでもブロックされていないことを確認します。

アプリケーションでは、ユーザー向けの診断機能からのイベントを処理し、それに応じてユーザーに通知することが重要です。 こうすることで、ユーザーは問題に気付き、自身のネットワーク環境のトラブルシューティングを行うことができます。

まれに、ユーザーのファイアウォール設定が正しいにもかかわらずこのエラー コードがランダムに表れることがあります。 同一のユーザーが以前は問題なく接続して通話できていた場合、この問題は、ネットワークの条件の変化が原因である可能性があります。 これは一時的な問題である可能性があります。 開始してみるか、または再度通話に参加してみてください。

関連情報

• ネットワークの推奨事項
• networkRelaysNotReachable UFD
• 通話トラフィックを強制的に独自のサーバー経由でプロキシされるようにする