Обслуживание телефонного вызова

На этапе маршрутизации определяется вызываемая сторона, и возможность ее вызова.

Первый шаг маршрутизации - определение вызываемой стороны по входящему запросу. На выходе после первого шага получается список направлений вызываемой стороны (URI, маршрутов и правил их вызова). Это может быть как один, так и несколько пользователей, внешних номеров, сервисов, как одно, так и несколько устройств, как один, так и несколько URI.

Маршрутизация проходит каскадно, может выполняться несколько раз с изменяющимися входными параметрами. Сначала перебираются правила маршрутизации и обнаруживается конкретное правило по параметрам входящего запроса. Для повышения гибкости используется двухуровневая маршрутизация на базе классов:

В зависимости от его типа процесс проходит по одной из веток: вызов наружу, вызов внутреннего абонента, вызов сервиса или вызов другого домена. По каждому из этих направлений может происходить дальнейшее ветвление процесса. На этом шаге могут применяться классы:

Групповые номера, функциональные группы, переадресации, фичакоды - могут привести к проведению дополнительного процесса маршрутизации с новыми параметрами вызова. Недоступность абонента, недоступность провайдера - могут привести к применению следующего по приоритету подходящего правила маршрутизации или отказу. Запрет вызова направления, отсутствие направления, пустой список вызываемых абонентов - ведут к отказу без перехода на следующий этап. Также в некоторых случаях вызов может завершиться проксированием на другой целевой экземпляр B2B.

Второй шаг маршрутизации - представление вызывающего абонента для вызываемого. На выходе после второго шага получается номер From для каждого из направлений. Кроме случая, когда вызов происходит внутри одного домена, для вызываемого абонента Б номер абонента А может быть кастомизирован, используется класс:

Если в результате маршрутизации выявлено несколько вызываемых абонентов (направлений), то для каждого направления, ведущего в другой домен, представление осуществляется индивидуально (А → Б1, А → Б2).

На этапе вызова согласно плану осуществляется отправка исходящих INVITE-запросов (fork-INVITE).

Для каждого из отправляемых запросов формируется новый Call-Id, на медиа-шлюзе открывается порт для предполагаемого медиа-сеанса, формируется SDP. При этом сеансы с идентичными параметрами сливаются и не размножаются в рамках одного входящего вызова. Этап завершается тогда, когда будет получен первый финальный ответ 2ХХ на любой из отправленных INVITE-запросов.

Альтернативными ветвями являются:

В ходе вызова могут происходить переадресации. Ответы 3XX проверяются и могут инициировать новый выделенный процесс маршрутизации, результаты которого добавятся к текущему списку вызываемых направлений.

Также переадресации могут происходить при получении неудачных финальных ответов 4XX-6XX от абонентов (класс sipusers) в результате применения типизированных правил переадресации (класс redirectrules — правила переадресации)

Уже на этапе вызова могут поступать ответы 183 Session Progress, содержащие описание медиа-сеанса. Такие ответы запускают медиа-обмен с вызывающим абонентом. Поведение системы в случае множественного вызова с несколькими ответами 183 могут вести к коллизиям на абонентских устройствах. Этот случай нетиповой, существуют несколько концептуальных способов его обработки.

Отвеченный вызов становится диалогом.

Вызов дошедший до состояния диалога, имеет два плеча — одно для вызывающей стороны (А) и второе для вызываемой стороны (Б). (В отдельных случаях вызываемой стороной может быть перехватившая сторона, направившая в систему INVITE на специальный подходящий номер).

В момент старта диалога определяется его тип - внутридоменный или кросс-доменный.

Также на старте диалога определяется необходимость его записи перебором правил записи в порядке убывания приоритета (класс recordrules — правила записи). Для кросс-доменных вызовов правила записи применяются в обоих доменах. Правило записи может активировать запись средствами платформы и сохранение в указанное хранилище, а также запись внешними средствами SIPREC RFC 7866, 7865. Если хотя бы в одном обнаружено включение записи средствами платформы, то запись включается на обслуживающем медиа-контекст медиашлюзе. При этом для каждого из заказавших ее доменов определяется хранилище для дальнейшего размещения записи (класс storages — подключения к хранилищам и файловым хранилищам), а также применяются правила стенографирования (класс asrrules — правила стенографирования), в результате определяется будет ли после завершения диалога проводиться эта операция. В доменах, заказавших внешнюю запись, определяются эндпойнты серверов SRS, куда направляются специальные SRC-INVITE запросы с медиасеансами, копирующими трафик обоих участников диалога.

Во время диалога могут поступать DTMF-сигналы из любого плеча. Производится их пересылка в другое плечо с возможным преобразованием протокола (RFC-2833 или SIP-INFO).

Во время диалога может происходить постановка на удержание одним плечом (X) другого плеча (Y). Это re-INVITE, изменяющий характеристику медиа-сеанса.

Может происходить и встречная постановка на удержание. Для каждой из сторон снятие с удержания чередуется с постановкой на удержание. Звук в обе стороны ходит тогда, когда обе стороны сняты с удержания. Когда одна из сторон поставлена на удержание, система воспроизводит одну из мелодий удержания, которые можно настраивать в домене и в платформе в целом. Исключение составляет постановка на удержание сервисов - в их сторону мелодия удержания не воспроизводится. Встречные еще не отвеченные re-INVITE получают ответ 491 Pending с указанием случайного таймаута в диапазоне до 1 секунды.

Во время диалога может происходить перевод. Это REFER от плеча X, который система пересылает в другое плечо Y, в результате чего абонентское устройство Y инициирует новый вызовв указанном направлении. Информация о прогрессе нового вызова пересылается плечом Y в исходный вызов в виде запросов NOTIFY и транслируется в плечо Y. Уведомление об успешном ответе влечет прекращение плечом X исходного диалога. В то же время уведомление о финальном неуспешном ответе 4XX-6XX влечет продолжение диалога - для абонентских устройств это callback с дальнейшем снятием с удержания. По более сложному сценарию происходит двухшаговый перевод, в результате которого в поступающем из плеча X запросе REFER содержится идентификационная информация о третьем абоненте, уже находящимся в диалоге. В этом случае система не просто пробрасывает REFER дальше, а проводит согласующую модификацию идентификационных значений.

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

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

Запись также формируется новая, но после завершения диалога во время микширования записи сцепляются.

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

Если теряется сервер с текущим экземпляром B2B, то вызов переходит на обслуживание сервису докатки, который прервет медиаобработку только тогда, когда в ней перестанет идти медиа-трафик. Именно этот сервис запустит процесс пост-обработки.

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

Однако, если на диалог назначен сценарий оценки вызова PCS (Post-Call-Survey) в соответствующем направлении, то при получении запроса BYE из плеча X вместо завершения плеча Y будет осуществлен перевод на номер сценария PCS путем отправки запроса REFER.

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

После завершения диалога система уже за пределами обслуживающего вызов микросервиса B2B производит запланированную постобработку:

Все события callevents отправлялись брокерам, подписчикам, сервисам слежения, в сценарии контекста.

На этом обслуживание вызова в пределах платформы завершается.