Вызов функционального адреса у партнёра: разрешение alias ещё не устанавливает связь
Адрес роли должен превратиться в адрес пользователя
Диспетчер хочет связаться с дежурным специалистом партнёрской организации по функциональному адресу. Преимущество понятное: не требуется узнавать фамилию сотрудника каждой смены. Однако для установления личного вызова системе нужно определить, какой MC service ID сейчас соответствует этому адресу.
В межсистемной процедуре участвуют серверы управления функциональными адресами обеих сторон. Между ними заранее должно быть установлено защищённое соединение. Разрешение alias является отдельным этапом, после которого клиент направляет новый запрос личного вызова уже по полученному служебному идентификатору.
Три результата, которые нужно различать
Если роль активировал один подходящий пользователь, сервер может вернуть его идентификатор. Если адрес никто не активировал, ответ предусматривает значение NONE. Такой результат следует отличать от недоступности сервера разрешения адресов: причины и действия оператора различаются.
При одновременной активации одной роли несколькими пользователями нельзя заранее обещать вызов всех сотрудников или выбор первого ответившего. Выбор подходящего MC service ID оставлен реализации; возможен и отказ, если подходящего адресата выбрать не удалось. Правило поставленной системы требуется описать до эксплуатации.
Кроме того, проверяется разрешение вызывающего пользователя использовать функциональный адрес и инициировать личную связь с определённым адресатом. Наличие адреса в телефонной книге не заменяет этих проверок.
Программа испытаний для сменной роли
Создают тестовый адрес дежурного и последовательно проводят три опыта: никто не активировал роль, активировал один пользователь, активировали несколько пользователей в допустимой конфигурации. Для каждого заранее определяют ожидаемый ответ и понятную диспетчеру индикацию.
В положительном опыте сохраняют результат разрешения и следующий запрос личного вызова. Это помогает отделить ошибку определения адресата от отказа самой связи. Если идентификатор определён правильно, а последующий вызов запрещён политикой, исправлять справочник роли бессмысленно.
Для нескольких активных пользователей поставщик показывает применённый критерий выбора. Проверку повторяют после смены дежурного, чтобы выявить устаревшее состояние. При этом тестовая конфигурация не должна вмешиваться в реальный аварийный адрес.
Что считать готовностью
В акте нужны правило выбора при множественной активации, обработка отсутствующей активации и доказательство прохождения полного пути до связи. Отдельно фиксируют доступность защищённого межсистемного взаимодействия. Так функциональный адрес становится управляемым способом обращения к роли. Оператор понимает, почему роль может быть известна справочнику, но сейчас не иметь адресата, и куда передать проблему, если адресат определён, а личный разговор всё равно не устанавливается.
