Шаг 12. Звонок из одного домена в другой

Поиск маршрута происходит на DC по запросу из B2BUA. Номерной план настраивается с помощью набора правил маршрутизации – сущностей типа route и vectorrule. Номер привязывается к учетной записи sipuser через ее атрибут phonenumber с требованием уникальности в домене. Сначала среди маршрутов (route) по маскам (номер From, номер To, направление), ищется самый приоритетный и подходящий по расписанию. Затем среди правил (vectorrule), относящихся к найденному маршруту, по маскам (номер From, номер To и направление) ищется самое приоритетное и подходящее по расписанию. Действие найденного правила принимается за основу. В качестве действия может быть указан запрет на вызов, внутреннее направление, перевод ответственности в другой домен с модификаторами From и To, а также ряд других направлений.

Перед передачей ответственности в другой домен B2BUA производит модификацию номеров From и To. Далее с помощью них производится поиск маршрута в новом домене, полученном в результате прошлой итерации поиска.

Настройка правил маршрутизации в разных доменах независима и проводится администраторами этих доменов в ходе CRUD-операций над сущностями route и vectorrule. Чтобы вызов из Домена_А в Домен_Б мог произойти, администраторы в обоих доменах создают стыкующиеся правила маршрутизации. В Домене_А создается правило для перехода в Домен_Б, а в Домене_Б – правило для приема такого перехода из Домена_А. Правила маршрутизации в разных доменах могут существенно различаться. Но если принимается единый сквозной номерной план по всем доменам, то правила маршрутизации могут быть сгруппированы и их количество резко сокращено. Примером такого сквозного номерного плана является классическая 10-значная телефонная нумерация с кодами областей, городов и абонентов. Чтобы в каждом домене не настраивать правила для перехода во все другие домены, применяется многоэтапная передача ответственности между доменами. Например, маршрутизация из каждого домена только к непосредственным дочерним и к родительскому с соответствующим преобразованием номера. Либо создание специального домена для обеспечения полной маршрутизации и выделение туда администратора, ответственного за нумерацию.

Принимающий вызов абонент видит имя звонящего в соответствии с тем, как оно установлено в поле name учетной записи sipuser. Инициирующий вызов абонент видит имя вызываемого только после снятия им трубки. В качестве значений поля name могут применяться константы и поля подстановки. Например, при name "Соколов_\{D}" система подставит вместо {D} значение From:DisplayName из поступившего от абонентского устройства SIP-запроса INVITE. Таким образом можно настроить отображение "Соколов_Рабочий" и "Соколов_Домашний".

Номер телефона инициатора для отображения вызываемому вычисляется с помощью правил представления (сущность representative). Необходимость этого может быть обусловлена сложными кросс-доменными правилами преобразования номеров. Например, чтобы попасть в другой домен, настроено правило для номеров вида код_абоненской_функции+номер_домена+номер_абонента_в_домене. Так, внутри домена достаточно набрать только номер_абонента, а из других доменов этого может быть недостаточно в связи с настроенными в них правилами маршрутизации. Чтобы произвольный звонок оставил в памяти телефона верный номер вызывающего абонента из другого домена и возможность перезвонить ему кнопкой REDIAL, администратор может создать правило представления, а B2BUA применит его при создании SIP-диалога стороны Б.

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

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

ВАЖНО: при передаче звонка в другой домен речь идет лишь о процедурах поиска маршрута, представлений и регистраций. Обслуживание вызова и передача трафика продолжает происходить на тех же самых серверах SG, B2B и MG, что и при звонках внутри домена. При передаче звонка в домен, обслуживающийся на другом сайте, DC проксирует поисковый запрос на тот сайт, но результат применяется в B2BUA на сайте инициатора. Таким образом в рамках всей системы ни при каких обстоятельствах не возникает длинных цепочек SIP-соедниений.