Шаг 10. Присоединяем SIP-телефон

SIP-устройства работают по протоколу SIP (большой набор RFC, начиная с самой базовой 3261). Устройство в рассматриваемом кейсе генерирует только сигнальный трафик, собственно сам SIP. А именно, отправляет запрос REGISTER и ожидает получить ответ 200 OK, либо ответ с кодом ошибки 4xx-6xx. Регистрация устройства осуществляется на заданное время (как правило в пределах 1 часа), в течение которого устройство продлевает регистрацию отправкой следующего запроса REGISTER с тем же идентификатором, либо создает регистрацию с новым идентификатором. В качестве доменного имени выступает логическое имя домена, в котором создана учетная запись SIP-устройства., при этом это имя может и не существовать в DNS, если используется proxy-адресация.

Диаграмма вводит новые функциональные элементы. Она отражает наличие на границе системы SIP-Boundary, то есть необходимость наличия в одной из ролей системы на одном из серверов функционала, отвечающего за прием и стандартизованную обработку транзакций SIP-протокола. Функциональный элемент SIP-Server обрабатывает запрос REGISTER, проводя его аутентификацию (его задача похожа на рассматривавшуюся ранее задачу роли WS – там протоколу HTTP обрабатывались запросы из User-API, а здесь обрабатывается API стандартный для SIP-протокола, сейчас это запрос REGISTER). И Registrar_Storage – временно сохраняет регистрацию. DC решает вопросы с авторизацией способом, аналогичным авторизации пользователей при выполнении API на шаге 1, но для авторизации SIP-устройств используется другая сущность домена – учетная запись SIP-UA (sipuser). Именно она заранее создана администратором в одном из доменов, именно она содержит логин и пароль, введенные пользователем при настройке своего SIP-телефона.

Схема максимально упрощенная, концентрируется на необходимости выделения трех видов новой функциональности. На этом этапе следует прояснить суть SIP-Boundary, SIP-Server и Registrar_Storage, вернее необходимость их обособления, а также привязать их к конкретным ролям системы.

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

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

Мы обеспечиваем доступность сервисов и масштабирование. Если бы эти три функциональности нераздельно присутствовали лишь в одном месте, тогда не было бы потенциала масштабирования. А если бы они присутствовали нераздельно в нескольких экземплярах одной роли – часть пользователей регистрировалась бы на одном сервере, часть на другом. Звонки между ними были бы невозможны, или, в крайнем случае, необходимо было бы при каждом вызове производить поиск по всем серверам всей системы – регресс скорости и производительности. Таким образом обоснована необходимость выделения хранилища регистраций SIP-устройств. Это роль Registrar. Ее основная ответственность – безопасное хранение всех зарегистрированных SIP-устройств. Резервируется в режиме Active-Passive, разделяется на группы по доменным зонам (микросервисные доменные фасады, шаг 7), синхронизирует данные между сайтами, обслуживающими домен. Данные хранит в объектной БД, распределенной между серверами группы ролей.

Необходимость разделения SIP-Boundary и SIP-Server станет прозрачна после разделения между ними других функциональных ответственностей.

Оба они имеют SIP-интерфейсы, резервируются и масштабируется в режиме Active-Active.

Такая компоновка функциональности дает большую архитектурную маневренность. В частности, может быть разное количество серверов с ролью SG и с ролью B2BUA. Более подробно роли SG и B2BUA мы исследуем на шаге 11.

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

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