Вызов заканчивается 410/3112
Причина, по которой вызов заканчивается ошибкой 410/3112, заключается в том, что клиент не может обратиться к другой конечной точке, и кандидаты ретранслятора не собираются. Этот код ошибки 410/3112 может произойти, если не удается установить путь к мультимедиа из-за проблем с сетью, ограничений брандмауэра или неправильных параметров конфигурации. Поэтому одноранговые узлы не смогли установить прямое или ретрансляторное подключение.
Кандидаты ретранслятора не нужны, если клиент может установить прямое подключение к другому однорангового узла. Однако, если WebRTC не удается собрать кандидатов ретранслятора, это часто указывает на проблему с конфигурацией сервера NAT (обходы ретрансляторов по протоколу NAT) или ограничениями сети. Кандидаты ретранслятора имеют решающее значение для установления подключений в ограничивающих сетевых средах.
Обнаружение с помощью пакета SDK
Вы можете узнать причину завершения вызова с помощью следующего фрагмента кода.
call.on('stateChanged', () => {
if (call.state === 'Disconnected') {
if (call.callEndReason.code === 410 && call.callEndReason.subCode === 3112) {
// show error message
}
}
});
Сведения о кодах и вложенных кодах см. в разделе "Общие сведения о кодах вызовов" и ошибках подкодов.
Если не удается установить путь к мультимедиа, вызов завершается кодом 410 и подкодом 3112.
Пакет SDK также активирует событие UFD сетиRelaysNotReachable.
Ниже приведен фрагмент кода, показывающий, как записать 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 на странице обзора вызова.
Кроме того, на странице проблем с вызовом можно также найти событие UFD networkRelaysNotReachable UFD .
Чтобы понять время действий или событий пользователя, можно проверить сведения на странице временной шкалы.
В этом примере пользователь получил networkRelaysNotReachable UFD событие в 16:41:47 и событие изменения состояния вызова в 16:41:49.
Средство диагностики вызовов предоставляет общие сведения и необходимые сведения для отладки одного вызова. Если вы хотите понять, сколько пользователей сталкиваются с этой проблемой или как часто пользователи сталкиваются с этой проблемой, вы можете использовать средство Log Analytics для получения аналитических сведений об этой проблеме.
Например, если вы хотите получить идентификатор вызова, который был отключен с подкодом 3112 за последние семь дней, можно выполнить этот запрос:
ACSCallSummary
| where ParticipantEndSubCode == 3112
| project TimeGenerated, CorrelationId, ParticipantId, Identifier, CallType
Вы также можете отобразить диаграмму времени, чтобы понять ежедневное число звонков, заканчивающееся подкодом 3112
ACSCallSummary
| where ParticipantEndSubCode == 3112
| summarize count() by bin(TimeGenerated, 1d)
| render timechart
Диаграмма времени предоставляет только общие сведения о пользователях с тем же идентификатором ресурса ACS. Выполняя более конкретные запросы, вы можете определить закономерности или аномалии, которые не сразу очевидны в диаграмме времени, помогая определить первопричину любых проблем более точно.
Например, если вы видите всплеск числа вызовов, заканчивающегося подкодом 3112, это может быть связано с большим объемом вызовов, в то время как коэффициент вхождения проблемы остался прежним. Кроме того, пик может быть связан с конкретным пользователем, который повторно пытался много раз, и все попытки были неудачными с подкодом 3112.
В этом запросе мы анализируем данные на основе идентификаторов пользователей, предполагая, что приложение поддерживает один и тот же идентификатор пользователя для каждого отдельного пользователя.
ACSCallSummary
| summarize Total = count(), SuccessCount = countif(ParticipantEndSubCode == 0), SubCode3112Count = countif(ParticipantEndSubCode == 3112) by Identifier
| where SubCode3112Count > 0
| order by SubCode3112Count desc
В этом примере один пользователь имел в общей сложности 180 вызовов, из которых 160 вызовов были успешными, и только два вызова завершились сбоем с подкодом 3112. В этом шаблоне предполагается временная сетевая проблема, которая может быть устранена путем повторных попыток. С другой стороны, у другого пользователя было всего шесть вызовов, все из которых завершилось сбоем подкода 3112. Эта согласованность в значении подкода указывает на скорее всего проблему конфигурации сети для этого пользователя, где повторная попытка вряд ли поможет.
Устранение или устранение неполадок
Если пользователь постоянно испытывает ошибку 410/3112, рекомендуется проверить параметры брандмауэра. Пользователи должны следовать руководству по настройке брандмауэра, указанному в документе рекомендаций по сети. Убедитесь, что пользователь или администратор проверяет параметры преобразования сетевых адресов (NAT) и проверяет, блокирует ли политика брандмауэра пакеты протокола UDP. Параметры брандмауэра не ограничиваются компьютером пользователя; Если пользователь находится в корпоративной среде, может потребоваться также настроить брандмауэр компании.
Кроме того, если приложение использует пользовательские серверы TURN, убедитесь, что указанный IP-адрес, порт и протокол не блокируются брандмауэром.
Для приложения важно обрабатывать события из функции диагностики пользователей и уведомлять пользователей соответствующим образом. Таким образом, пользователь знает о проблеме и может устранить неполадки в сетевой среде.
В редких случаях этот код ошибки появляется случайным образом, даже если параметры брандмауэра пользователя верны. Если тот же пользователь ранее смог подключиться и вызвать его, эта проблема может возникнуть из-за изменений в условиях сети. Это может быть временная проблема. Попробуйте снова начать или присоединиться к вызову.