First-to-answer через IWF: как подтвердить выбранного ответившего, а не общий обзвон
Диспетчеру нужен один доступный исполнитель из нескольких возможных адресатов. Если система показывает только факт отправки вызова группе кандидатов, она ещё не подтвердила результат first-to-answer. Важно знать, с кем действительно установлена связь и в каком режиме.
Раздел 10.15 ETSI TS 123 283 V19.5.0 описывает межсистемный first-to-answer через IWF. Адресование может использовать MCPTT IDs или функциональный псевдоним. Для вызываемой стороны допускается набор потенциальных ID, тогда как поле functional alias содержит один псевдоним. Ответ возвращает фактического адресата и выбранные медиапараметры.
Стенд с различимыми кандидатами
Для проверки выбирают двух известных тестовых адресатов LMR и задают согласованный набор. Инициируют вызов из MCPTT, после чего один кандидат принимает его предусмотренным способом. На вызывающей стороне проверяют, какой ID оказался в результате и кому реально поступает дальнейший обмен.
Затем меняют доступного ответившего и повторяют испытание. Это помогает выявить ошибку, когда интерфейс всегда показывает первого из исходного списка, независимо от фактического результата. Сам список кандидатов не должен подменять выбранного собеседника.
Если используется псевдоним, отдельно проверяют актуальную связь с его исполнителями и разрешённость обращения. Видимое название роли не является достаточным доказательством, что вызов направлен к нужному текущему составу. При этом способ внутренней обработки адресатов на LMR-стороне поставщик должен объяснить отдельно.
Отмена и изменённые условия
Информационные потоки предусматривают first-to-answer cancel. Конкретные сценарии отмены, близких по времени ответов и отображения у остальных кандидатов нужно согласовать и испытать в реализации. Из наличия названия процедуры нельзя придумать универсальные таймеры или интерфейс каждого терминала.
Также сохраняют итоговые параметры медиа и управления передачей. В описанном обмене возможны альтернативы, приемлемость которых влияет на продолжение вызова. Поэтому успешная связь с найденным сотрудником должна соответствовать согласованному рабочему режиму, а не только факту ответа.
Практический итог — адресный результат поиска исполнителя. Диспетчер видит, кто ответил, и может продолжить разговор с подтверждённым собеседником. В протоколе остаются исходные кандидаты, выбранный пользователь, режим и проверенные отрицательные случаи.
Если требуется подтверждение выполнения поручения, оно остаётся отдельным шагом рабочего процесса. First-to-answer подтверждает установление связи с ответившим участником, но само по себе не означает, что он принял или завершил последующую задачу.
