К нам часто обращаются с похожим вопросом: по какому принципу происходит переключение транка в исходящем правиле, если основной транк недоступен?

Мы подготовили исчерпывающий ответ на этот вопрос. Его можно разделить на 3 части:

  • Выбор и переключение маршрута / транка в исходящем правиле
  • Особенности обработки сообщений Early Media и Ringing
  • Особенности транков с авторизацией по IP (пиринговые транки без регистрации)

Введение


Как известно, 3CX может иметь до 5 разных маршрутов в исходящем правиле. Вы можете определить приоритет этих маршрутов. Если первый маршрут (по сути дела, транк или VoIP шлюз) не может проключить вызов, он передается по второму маршруту и т.д.

image

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

Выбор и переключение маршрута


  • В исходящем правиле 3CX опрашивает все доступные транки  и мосты (межстанционные транки) по порядку от 1 до 5
  • Если транк не зарегистрирован, он исключается автоматически
  • SIP сообщение Ringing (180 или 183) от оператора связи (или VoIP шлюза) не означает успешное проключение. Может быть выбран другой транк, либо перебор транков может завершиться в зависимости от полученных SIP сообщений в дальнейшем (см. ниже)
  • SIP сообщение Busy завершает перебор транков и передает сигнал “занято” вызывающему абоненту. Типы SIP сообщений Busy:

    • 486 Busy Here — абонент занят
    • 600 Busy Everywhere — вызываемый пользователь занят и не желает принимать вызов в данный момент
    • 1408 No Response — внутренний код ошибки 3CX

  • SIP сообщение об успешном проключении завершает перебор транков. Типы сообщений об успешном проключении:

    • 200 OK — успешное завершение проключения
    • Cancel — вызываемый абонент отклонил вызов, не подняв трубку

  • SIP сообщение об ошибке проключения начинает перебор транков (выбор следующего транка по приоритету). Список SIP сообщений об ошибках приведен в конце этой инструкции.

Параметры Early Media и Ringing


При использовании в исходящем правиле более одного транка, обработка сообщений Early Media и Ringing имеет свои особенности. Поскольку 3CX не может предсказать заранее, произойдет ли переключение на резервный маршрут, она меняет правила обработки сообщений Early media (как правило, 183 Ringing).

После получения SIP сообщения 183 Ringing, которые обычно используются при передаче специфических сообщений от оператора (например, служебных голосовых сообщений сети типа “ожидайте ответа абонента”), это сообщение конвертируется в SIP сообщение 180, и аудиопоток от оператора “заглушается”. Абонент на добавочном номере 3CX слышит не служебные сообщения оператора, а гудки дозвона SIP телефона (КПВ). Для справки:

  • 180 Ringing — местоположение вызываемого пользователя определено, выдан сигнал о входящем вызове
  • 183 Session Progress — используется для того, чтобы заранее получить описание сеанса информационного обмена от шлюзов на пути к вызываемому пользователю

Транки с IP авторизацией


Если оператор предоставил транк для сервера 3CX на публичный IP адрес этого сервера (транк с IP авторизацией), 3CX не регистрирует транк на SIP сервере оператора. Таким образом, 3CX не может определить, “работает” этот транк или нет. С точки зрения 3CX он всегда “работает” (в 3CX “светится” зеленым цветом). При обработке исходящего правила 3CX всегда будет пытаться использовать этот транк. Если транк “нерабочий”, это приведет к задержке 32 сек. перед переключением на следующий транк. К сожалению, это поведение нельзя изменить.

Коды SIP ошибок переключения транка


Коды SIP сообщений (ошибок), при котором происходит переключение транка:

  • 400 Bad Request — запрос не понят из-за синтаксических ошибок в нем; ошибка в сигнализации, скорее всего что-то с настройками оборудования
  • 401 Unauthorized — нормальный ответ сервера о том, что пользователь еще не авторизировался; обычно после этого абонентское оборудование отправляет на сервер новый запрос, содержащий логин и пароль
  • 402 Payment Required — требуется оплата
  • 403 Forbidden — абонент не зарегистрирован
  • 404 Not Found — вызываемый абонент не найден; нет такого SIP-номера
  • 405 Method Not Allowed — метод не поддерживается; может возникать, если пользователь пытается отправлять голосовую почту и т.п.
  • 406 Not Acceptable — пользователь недоступен
  • 407 Proxy Authentication Required — необходима аутентификация на прокси-сервере
  • 408 Request Timeout — время обработки запроса истекло; абонента не удалось найти за отведенное время
  • 409 Conflict — конфликт
  • 410 Gone — нет доступа к ресурсу; ресурс по указанному адресу больше не существует
  • 411 Length Required — для указанного ресурса клиент должен указать длину содержимого в заголовке запроса
  • 413 Request Entity too large — размер запроса слишком велик для обработки на сервере
  • 414 Request URI too long — размер SIP URI слишком велик для обработки на сервере
  • 415 Unsupported Media Type — звонок совершается неподдерживаемым кодеком
  • 416 Unsupported URI Scheme — сервер не может обработать запрос из-за того, что схема адреса получателя ему непонятна
  • 420 Bad Extension — неизвестное расширение; сервер не понял расширение протокола SIP
  • 421 Extension Required — в заголовке запроса не указано, какое расширение сервер должен применить для его обработки
  • 423 Interval too brief — сервер отклоняет запрос, так как время действия ресурса слишком короткое
  • 433 Anonymity Disallowed — анонимный вызов запрещен
  • 480 Temp Unavailable — временно недоступное направление, попробуйте позвонить позже
  • 481 Call Transaction does not exist — действие не выполнено; нормальный ответ при поступлении дублирующего пакета
  • 482 Loop Detected — обнаружен замкнутый маршрут передачи запроса
  • 483 Too many hops — запрос на своем пути прошел через большее число прокси-серверов, чем разрешено
  • 484 Address Incomplete — принят запрос с неполным адресом
  • 485 Ambiguos — адрес вызываемого пользователя неоднозначен
  • 487 Request Terminated — запрос отменен; обычно приходит при отмене вызова
  • 500 Server Internal Error — внутренняя ошибка сервера
  • 501 Not Implemented — в сервере не реализованы какие-либо функции, необходимые для обслуживания запроса; метод запроса SIP не поддерживается
  • 502 Bad Gateway — сервер, функционирующий в качестве шлюза или прокси-сервера, принимает некорректный ответ от сервера, к которому он направил запрос
  • 503 Service Unavailable — сервер не может в данный момент обслужить вызов из-за перегрузки или проведения технического обслуживания
  • 504 Server Timeout — сервер не получил ответа в течение установленного промежутка времени от сервера, к которому он обратился для завершения вызова
  • 505 Version Not Supported — версия не поддерживается; сервер не поддерживает эту версию протокола SIP
  • 513 Message Too Large — сервер не в состоянии обработать запрос из-за большой длины сообщения
  • 603 Decline — вызываемый пользователь не желает принимать входящие вызовы, не указывая причину отказа
  • 604 Does not exist anywhere — вызываемого пользователя не существует
  • 606 Not Acceptable — соединение с сервером было установлено, но отдельные параметры, такие как тип запрашиваемой информации, полоса пропускания или вид адресации недоступны
Поделиться с друзьями
-->

Комментарии (7)


  1. bravo-ej
    25.06.2017 12:20

    603 Decline — вызываемый пользователь не желает принимать входящие вызовы, не указывая причину отказа

    А чем это обусловлено? Ведь пользователь отменил получение приглашение поучаствовать в сессии? У меня наблюдался такой случай (и я уверен, до сих пор наблюдается), когда вызов приходит от мегафона, я его в программном сипфоне отбиваю (у меня не 3CX станция и клиент), отправляется 630 сообщение, и… вызов приходит снова). После повторного отклонения, он приходится опять… В общем Мегафон на мою ёмкость через 4 разных маршрута выходит и по всем я должен дать отбой, что бы вызов таки завершился.
    По хорошему, конечно, сипфон мог бы и 486 (User busy) отправить, но… это отдельный вопрос.


    1. snezhko
      25.06.2017 13:07

      В общем могу сказать, что разные реализации SIP софтсвитчей (и разные версии одного софтсвитча) по разному могут это интерпретировать. 603 может интрерпретироваться и как отказ в обслуживании звонка. Рекомендую уточнить это именно у Мегафона.


      1. bravo-ej
        25.06.2017 13:35

        С мегафоном всё понятно — им пофиг, я как то попытался обратиться) ну и мне не до того, что бы до них докапываться, когда это не мешает на текущем этапе.
        Но у вас в списке релизов для ухода на резерв тоже есть 603 сообщение. Причём из описания этого сообщения по сути понятно, что его генерирует именно пользователь, либо сервис, которым этот пользователь окружён (шлюз, ДВО). Т.е. нет абсолютно никакого смысла (на первый взгляд) заниматься обработкой резервных направлений.
        Причём почти никто из МгМн операторов, представленных в Москве, не обратил внимание, что voip шлюз _не_ в 17 ISUP RLS конвертит 603 ответ. МТС зацепились :)
        И вот потому, что МТС зацепись и попросили поправить релиз, тема для меня стала интересной -– очевидно многие коммутаторы 603 сообщение интерпретирует по разному, в том числе и подсистема маршрутизации отрабатывает. Для корректного завершения вызова при отказе от сеанс самим UA, им нужен был User busy, что мы в итоге и сделали заюзав таблицы конвертации релизов на voip шлюзе.

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

        PS: коммутаторы у МТС и Мегафона помоему разные, но если интересно, я поищу информацию в ТУ.


        1. snezhko
          25.06.2017 13:46

          Я понял ваш вопрос. Постараюсь дать точный ответ в понедельник.


        1. snezhko
          26.06.2017 13:42

          Дело в том, что в 603 Decline не уточняется, кто именно отклонил вызов — конечный получатель вызова (абонент), или промежуточный SIP сервер, через который может проходить SIP запрос. Поэтому 3CX пытается использовать альтернативный маршрут.


          1. bravo-ej
            26.06.2017 14:37

            21.6.2 603 Decline
            The callee's machine was successfully contacted but the user
            explicitly does not wish to or cannot participate. The response MAY
            indicate a better time to call in the Retry-After header field. This
            status response is returned only if the client knows that no other
            end point will answer the request.


            Да вот тут такое дело, что в описание конкретно написано, что "...successfully contacted but the user..."
            Хотя в
            7.2 Responses
            6xx: Global Failure — the request cannot be fulfilled at any server.

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

            вот и не понятно :)


            1. snezhko
              26.06.2017 14:39

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