Сеть вернула адрес переадресации DMR Tier III: будет ли клиент выполнять новый вызов

Полученный адрес ещё не разговор с заместителем

Вызывающий клиент DMR Tier III получил сведения о переадресации, но новый разговор не начался. Это не обязательно потеря сообщения сетью. Описанная процедура позволяет вернуть адрес назначения инициатору как результат исходной транзакции.

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

Результат транзакции — Получен адрес — переадресации; Вариант клиента — Показать адрес — В свободное состояние; Другой вариант — Отправить новый запрос — к указанному назначению. Вторую попытку подтверждают отдельным событием журнала. — Получение адреса переадресации завершает один этап обмена. Дальше клиент может сообщить адрес пользователю или отправить отдельный новый запрос. Фактическую ветвь определяют по поведению терминала и записи обмена.

Как понять результат на интерфейсе

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

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

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

Приёмочный сценарий

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

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

Отдельный опыт предусматривает недоступность нового адресата. Он показывает, различает ли интерфейс факт перенаправления и дальнейший отказ. Недоступный заместитель не должен автоматически превращаться в ложное сообщение, что исходная diversion не была получена.

Что записать в регламент

Пользователю объясняют, требуется ли дополнительное действие после получения нового адреса. Название команды берут из фактического интерфейса. Общая спецификация не задаёт одинаковую кнопку всем моделям.

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

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

Все разборы