Проблемы, влияющие на вызовы прямой маршрутизации входящего трафика

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

Нет тон обратного звонка, когда Teams получает звонок из конечной точки ТСОП

Эта проблема возникает в следующем сценарии:

Когда клиент Microsoft Teams получает звонок, он сначала отправляет сообщение SIP 180 Ringing, а затем отправляет сообщение о ходе выполнения сеанса SIP 183 вместе с предложением мультимедиа (SDP).

В соответствии со стандартами RFC 3261 и RFC 3960, когда конечная точка, используемая вызывающим абонентом, получает сообщение SIP 180, оно должно создать тон кольца локально. Если устройство вызывающего абонента получает сообщение о ходе выполнения сеанса SIP 183 с SDP, оно позволяет целевому объекту (клиенту Teams в этом сценарии) воспроизводить звук или кольцевой тон перед принятием вызываемым пользователем сеанса. Такой звук известен как ранний носитель.

Однако некоторые вызывающие устройства и операторы перестают создавать тон кольца локально при получении сообщения о ходе выполнения сеанса SIP 183. Это происходит, даже если устройства и операторы должны продолжать генерировать тон кольца до получения фактических пакетов мультимедиа.

Решение

Чтобы устранить эту проблему, необходимо обновить конфигурацию пограничного контроллера сеанса (SBC) для обработки нескольких сообщений SIP 18x.

Большинство SBCs предлагают один из следующих вариантов устранения рисков:

• Пересылайте только первое сообщение SIP 18x и игнорируйте последующие сообщения до тех пор, пока вызов не будет ответен или завершен. Этот параметр предлагается контроллерами SBCs AudioCodes, например.
• Удалите сведения SDP из сообщения о ходе выполнения сеанса SIP 183, а затем измените сообщение на сообщение SIP 180 Ringing. Этот параметр предоставляется контроллерами SBC Metaswitch, например.

Инструкции по обновлению правил обработки SIP в SBC см. в документации, относящуюся к модели SBC, и обратитесь к поставщику SBC для других рекомендуемых вариантов.

Несколько уведомлений о пропущенных звонках

Когда Teams получает звонок и отклоняет его, так как пользователь занят или не хочет принимать звонок в то время, оператор ТСОП или SBC может повторить вызов несколько раз. Teams интерпретирует каждый из повторных вызовов в виде отдельных вызовов и отображает несколько пропущенных уведомлений.

Эта проблема возникает из-за различных стандартов связи, таких как СТАНДАРТ RFC 4497 и NICC standard ND1017:2006/07, сопоставляют один и тот же код ответа SIP с различными кодами причин Q.850.

Например, RFC 4497 сопоставляет код ответа SIP 486 с Q.850 причиной кода 34 и ND1017:2006/07 (который использует прямая маршрутизация) сопоставляет код 486 с Q.850 причиной кода 17. Из-за этого различия поставщики ТСОП, использующие стандарт RFC 4497, интерпретируют причину неправильного вызова Teams. Поэтому поставщики ТСОП повторяют вызов несколько раз.

Решение

Чтобы устранить проблему, обновите правила манипуляции SIP в SBC, чтобы удалить код Q.850, сопоставленный с кодом ответа SIP 486, или измените код причины с 34 на 17. Инструкции по обновлению правил обработки SIP см. в документации, относящуюся к модели SBC.

Если обновление правил не устраняет проблему, скорее всего, SBC, сетевое устройство в пути связи или поставщик ТСОП повторяет вызов после получения кода ответа SIP 4xx . Это поведение не рекомендуется. В этой ситуации обновите конфигурацию SBC и сетевых устройств или попросите поставщика ТСОП обновить конфигурацию, чтобы убедиться, что они не повторяют вызов после получения ответа SIP 4xx для завершения вызова.

Неверный идентификатор вызывающего объекта (CLI) отображается для входящих вызовов

Когда Teams получает звонок, отображается номер вызывающего объекта, указанный в заголовке From в сообщении SIP INVITE. Однако некоторые поставщики ТСОП могут использовать P-Asserted-Identity заголовок вместо From заголовка для хранения номера вызывающего объекта. В этой ситуации сведения, отображаемые пользователю Teams, неверны.

Решение

Чтобы устранить эту проблему, проверьте, использует P-Asserted-Identity ли поставщик ТСОП заголовок. В этом случае настройте SBC для перезаписи содержимого заголовка From с информацией из заголовка P-Asserted-Identity .

Чтобы переписать From заголовок, см. документацию, относящуюся к модели SBC, чтобы получить инструкции.

Примечание.

Если заголовок From содержит "Анонимный" в качестве сведений, Teams иногда преобразует его в число и отображает 266696687 вместо этого.

Входящие вызовы помечены неправильно как "Спам вероятно"

Если включена фильтрация нежелательной почты для звонков , идентификаторы вызывающих всех входящих вызовов проверяются и назначаются оценки нежелательной почты. Если оценка для идентификатора вызывающего абонента выше определенного порогового значения, Teams отображает уведомление о том, что звонок может быть спамом.

Решение

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

Входящие вызовы не блокируются должным образом

Вы настраиваете Teams для блокировки вызовов идентификаторов вызывающих устройств, удовлетворяющих предопределенным определенным критериям. Тем не менее, вы продолжаете получать звонки от таких номеров телефонов.

Эта проблема обычно вызвана несоответствием между форматом идентификатора вызывающего объекта, который ожидается выражением, которое используется для экрана входящих вызовов и формата идентификатора вызывающего объекта в From заголовке сообщения SIP.

Например, идентификатор вызывающего объекта может быть указан в международном формате, включая знак "плюс" (+) и международный префикс. Однако выражение проверяет наличие только чисел, указанных в национальном формате. Ситуация также может быть отменена.

Решение

Чтобы устранить эту проблему, обновите выражение, используемое для проверки входящих вызовов, добавив знак плюса (+) в качестве необязательного символа. Это измененное выражение охватывает несколько форматов идентификаторов вызывающего абонента и особенно полезно, если вы используете как прямые маршруты, так и планы звонков, в которых номера представлены в разных форматах.

Задержка при ответе на вызовы ТСОП в Teams

Когда Teams получает звонок из конечной точки ТСОП, вы либо испытываете задержку в ответе на звонок, либо не услышите звук в течение нескольких секунд после того, как Teams ответит на звонок.

Как правило, эти проблемы вызваны несколькими повторами SIP, которые отправляются между SBC и SIP-прокси до успешного подключения вызова. Это особенно распространено в сценариях, связанных с обходом мультимедиа или оптимизацией локальных носителей, для которых требуется несколько повторений по проектированию. Кроме того, в такой ситуации, как если SBC не предлагает соответствующий IP-адрес мультимедиа в исходном приглашении, SBC должен отправить повторное приглашение с правильной информацией. Если повторное приглашение из SBC получено прокси-сервером SIP в неправильном порядке или в неправильное время (тем самым вызывая состояние гонки), повторное приглашение может занять больше времени для согласования. Эта ситуация может привести к задержкам звука.

Решение

Чтобы устранить эти проблемы, обновите конфигурацию SBC. Убедитесь, что он предлагает наиболее вероятный IP-адрес мультимедиа по умолчанию, чтобы свести к минимуму количество повторов. Например, если большинство вызовов ожидается от внутренних пользователей, настройте SBC, чтобы сначала предложить внутренний IP-адрес. Подробные инструкции по настройке SBC см. в документации, относящуюся к модели SBC.

Удаление вызовов после определенной длительности

В Teams вызовы, которые выполняются и входящие вызовы, которые по-прежнему пытаются подключиться, могут удаляться по различным причинам.

На основе длительности времени, после которого удаляется вызов, попробуйте разрешения, которые работают для вашего сценария.

Вызовы будут удаляться примерно через четыре секунды

Эта проблема обычно вызвана плохим подключением или проблемой связи, которая существует между SBC и прокси-сервером SIP. Например:

• SBC может не получить сообщение SIP 100 Trying, так как сообщение заблокировано брандмауэром или не отправляется из-за проблем с сетью.
• SBC получает сообщение SIP, но не подтверждает его, отправляя сообщение SIP ACK.

Решение

Чтобы устранить эту проблему, обновите конфигурацию SBC и сети, чтобы разрешить трафик и из всех диапазонов IP-адресов, которые функция прямой маршрутизации использует для сигнала SIP. Кроме того, убедитесь, что SBC отправляет сообщения в соответствии со стандартным процессом, который используется для передачи сигналов SIP.

Подробные инструкции по настройке SBC см. в документации, относящуюся к модели SBC.

Вызовы удаляются примерно через 10 до 20 секунд

Если входящие вызовы удаляются в диапазоне от 10 до 20 секунд при попытке подключиться, и нет звука, причина может быть в том, что ни одна информация о мультимедиа не была получена в этом интервале времени, либо проверка подключения интерактивного подключения (ICE). В этой ситуации Teams удаляет вызов.

Решение

Чтобы устранить эту проблему, убедитесь, что правильные кандидаты ICE включены в сообщение SDP из SBC. Кроме того, обновите конфигурации сети и брандмауэра, чтобы убедиться, что они могут обрабатывать запросы и ответы от кандидатов ICE.

Вызовы отпадают через несколько минут

Текущий вызов удаляется без возврата кода ошибки после подключения и остается активным от 10 до 60 минут. Этот сценарий может произойти, если проблема влияет на механизм обновления сеанса или сеанса, указанный в SESSION-EXPIRES заголовке сообщения SIP INVITE. Вызов планируется завершить после времени, указанного в SESSION-EXPIRES заголовке, если не будет отправлено повторное приглашение для обновления сеанса до окончания времени.

В следующем примере заголовок указывает, SESSION-EXPIRES что вызов завершится через 1800 секунд (30 минут):

SESSION-EXPIRES : 1800;refresher=uac

Примечание.

• Повторное подключение обычно отправляется на полпути времени, указанного таймером сеанса.
• Если значение refresher параметра в заголовке имеет значение uac, сторона, отправляющая сообщение SIP INVITE, отвечает за отправку повторного входа для обновления сеанса.
• Если значение refresher параметра в заголовке имеет значение uas, сторона, получающая сообщение SIP INVITE, отвечает за отправку повторного приглашения на обновление сеанса.

Решение

Чтобы устранить эту проблему, обновите конфигурацию SBC, чтобы убедиться, что правильная сторона отправляет сообщение повторного входа в соответствующее время до истечения срока действия таймера сеанса.

Проблемы таймера сеанса также могут возникать в других частях вызова, таких как оператор ТСОП в пути связи. Если вызов завершается сбоем в операторе ТСОП, он отправляет сообщение SIP BYE в SBC. Затем это сообщение отправляется в прокси-сервер SIP, а прокси-сервер завершает вызов. Чтобы устранить эту проблему, определите источник сообщения SIP BYE, а затем устраните проблему в источнике.