Поделиться через

Устранение неисправностей вызовов через ТСОП в службах связи Azure

При устранении неполадок сбоев вызовов ТСОП в Службе коммуникации Azure рекомендуется включить ведение журнала. Затем можно использовать значения ResultCategories, ParticipantEndReason, ParticipantEndSubCode, чтобы определить, почему завершился вызов и обнаружила ли система какие-либо сбои.

Использование категорий результатов для устранения неполадок

Массив ResultCategories является свойством схемы Call Summary Log Schema. Он содержит список общих причин, описывающих окончание вызова:

  • Success
  • Failure
  • UnexpectedClientError
  • UnexpectedServerError

Эти сведения помогут определить, почему вызов закончился без создания подробного журнала ошибок.

Устранение неполадок с помощью ParticipantEndReason и ParticipantEndSubCode

Если уровень детализации ResultCategories недостаточен при устранении неполадок вызовов ТСОП, можно использовать ParticipantEndReason и ParticipantEndSubCode, чтобы понять причины, по которым вызов закончился более подробно. ParticipantEndReason и ParticipantEndSubCode также являются свойствами схемы сводного журнала вызова.

УчастникEndReason

ParticipantEndReason — это трехзначный код, показывающий общее состояние вызова. В этом коде объясняется, почему вызов закончился и группирует сбои по категориям. Например, ParticipantEndReason 404 означает, что вызывающий или вызываемый абонент не найден. ParticipantEndReason 500 означает, что произошла ошибка службы.

Этот код основан на ответных кодах протокола SIP. Дополнительные сведения см. в списке кодов ответа SIP в Википедии.

УчастникEndSubCode

ParticipantEndSubCode — это более конкретный код ответа, который обычно составляет шесть цифр. Он объясняет более подробно, почему возникла проблема с вызовом.

Ключевым фактором при устранении неполадок Службы коммуникации Azure для вызовов ТСОП является определение того, является ли окончательный код ответа SIP для вызова результатом обработки Майкрософт или пограничного контроллера сеанса (SBC) пользователя или оператора. Простой способ определить, откуда изначально произошел код, это посмотреть на ParticipantEndSubCode ответ.

ParticipantEndSubCode Если значение начинается с 560 или 540, оно указывает, что SBC пользователя или оператора создал код ответа. Это полезно для устранения неполадок с вызовами прямой маршрутизации, так как подкод может помочь определить, исходит ли ошибка из вашего SBC или службы Microsoft. Вложенный код, начинающийся с 560, представляет исходящий вызов, а подкод, начиная с 540, представляет входящий вызов. В любом случае проверьте журналы SBC.

Например, если ParticipantEndSubCode значение равно 560403, это означает, что он был исходящим вызовом, SBC создал окончательный код ответа, а код ответа SIP из SBC составил 403. Начните устранять неполадки с вызовами, проверяя журналы SBC.

Для ParticipantEndSubCode ответов, которые не начинаются с 560 или 540, служба Майкрософт создала окончательный код ответа.

Связанный контент