MCPTT: отмена ожидающей заявки и отзыв floor у говорящего решают разные задачи
Увеличить схему
Диспетчеру нужно убрать лишнюю заявку MCPTT из ожидания либо остановить уже говорящего участника. Это два разных действия управления floor. В ETSI TS 123 379 V19.11.0 предусмотрены отдельные процедуры floor request cancellation и floor revoke.
Отмена ожидания
Floor request cancel используется для удаления запроса из очереди. Пользователь может отменять свою заявку; для отмены чужих заявок нужны соответствующие полномочия. Сервер проверяет авторизацию запрашивающей стороны.
В запросе управления чужими заявками указываются MCPTT ID затронутых участников. После завершения отмены инициатор получает ответ. Участникам, чьи заявки отменены уполномоченной ролью, направляется предусмотренное уведомление.
Текущая передача при этом не становится автоматически отозванной. Когда она завершится, сервер обрабатывает уже обновлённую очередь. Поэтому нажатие административной отмены ожидания не следует оценивать по тому, замолчал ли нынешний говорящий.
Отзыв действующего права
Floor revoke request адресован другой задаче: отзыву floor у текущего владельца. Он включает идентификатор участника, у которого требуется прекратить право передачи. Сервер отдельно проверяет право инициатора выполнять отзыв.
После предусмотренного решения говорящему направляется floor revoked. Другим участникам сообщается соответствующее состояние. Для multi-talker случая наличие оставшихся говорящих учитывается отдельно: освобождение одного права не обязательно означает общий idle.
Общее название кнопки интерфейса вроде «отмена» может скрывать эти различия. При настройке диспетчерского рабочего места необходимо установить, какую процедуру вызывает каждое действие.
Программа проверки
Используют согласованный тестовый разговор с одним действующим говорящим и хотя бы одним ожидающим участником. Сначала отменяют только ожидающую заявку и подтверждают, что текущая речь продолжается предусмотренным образом.
Затем в отдельном сценарии проверяют отзыв действующего права. В обоих случаях фиксируют инициатора, целевой MCPTT ID, полномочия и результат серверной проверки.
Если роли имеют разные права, отрицательные сценарии выполняют контролируемо. Пользовательский текст ошибки подтверждают по продукту, а не придумывают по названию процедуры.
Так памятка диспетчера связывает цель с правильным действием: убрать ожидание или прекратить уже разрешённую передачу. Проверка не смешивает очередь, состояние говорящего и завершение всего вызова, для которого применяются собственные процедуры управления MCPTT.
При проверке целевого действия особенно важно сохранять идентичность пользователя: отображаемое имя в диспетчерском списке должно соответствовать тому ID, который действительно обрабатывает сервер.
Запросы отправляются на наш e-mail из вашей почтовой программы.
