通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

通话以 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 或通话诊断工具分析问题

当用户报告他们无法进行通话时，可使用通话诊断工具来分析失败原因。 若要调试用户通话，需要通话 ID。 如果由于防火墙阻止了中继连接，用户的通话失败，则你可在该通话的概述页面上发现最终代码和子代码为 410 和 3112。

通话诊断的屏幕截图，其中在通话的概述页面上包含子代码 3112。

此外，还可在通话问题页上找到 networkRelaysNotReachable UFD 事件。

通话诊断的屏幕截图，其中在通话问题页上包含 networkRelaysNotReachable UFD。

若要了解用户操作或事件的计时，可检查时间线页上的详细信息。 在此示例中，用户在 16:41:47 获得 networkRelaysNotReachable UFD 事件，并在 16:41:49 获得通话状态更改事件。

通话诊断的屏幕截图，其中在通话时间线页上显示了事件的计时。

通话诊断工具提供了用于调试单个通话的概述和必要信息。 如果想要了解遇到此问题的用户数或用户遇到该问题的频率，可使用 Log Analytics 工具获取对此问题的见解。

例如，如果要获取在过去七天内以子代码 3112 断开连接的通话 ID，可执行以下查询：

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 资源 ID 下的用户的概述。 通过运行更具体的查询，可识别仅从时间图表中无法立即发现的模式或异常，从而帮助你更准确地查明任何问题的根本原因。

例如，如果你看到以子代码 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。 此模式提示存在暂时性网络问题，可通过重试来解决。 另一方面，另一个用户总共有 6 个通话，所有这些通话都失败，且出现子代码 3112。 这种一致的子代码值指示该用户可能存在网络配置问题，此时重试不太可能有所帮助。

如何缓解或解决

如果发现用户一致遇到 410/3112 错误，你应建议他们检查其防火墙设置。 用户应遵循网络建议文档中提到的防火墙配置指南。 确保用户或管理员检查其网络地址转换 (NAT) 设置，并验证其防火墙策略是否阻止用户数据报协议 (UDP) 数据包。 防火墙设置不限于用户的计算机；如果用户位于企业环境中，则可能还需要配置公司的防火墙。

此外，如果应用程序使用自定义 TURN 服务器，请确保指定的 IP、端口和协议不会被任何防火墙阻止。

对于应用程序，务必处理来自面向用户的诊断功能的事件，并相应地通知用户。 通过执行此操作，用户便可意识到该问题，并可对其网络环境进行故障排除。

在极少数情况下，即使用户的防火墙设置正确，此错误代码也会随机显示。 如果同一用户以前能够成功连接并通话，则此问题可能是网络条件的变化造成的。 这可能是一个临时问题。 尝试再次开始或加入通话。

参考