MCPTT media multiplexing: Source identifier связывает управление floor с нужной коммуникацией
Один клиент MCPTT участвует в нескольких медиакоммуникациях, а запрос floor должен относиться к одной из них. Идентификатор пользователя отвечает на вопрос «кто», но сам по себе не объясняет, какой поток затронут. В форматах ETSI TS 123 379 V19.11.0 для применимого мультиплексирования предусмотрен Source identifier.
Назначение отдельного поля
В описании Source identifier сказано, что он идентифицирует коммуникацию, например медиапоток внутри media multiplex. Поле предусмотрено только при мультиплексировании медиа.
Оно встречается в запросах и ответах управления floor, а также в запросах остановки и возобновления unicast-медиа. Таким образом, привязка требуется не только голосовым данным, но и управляющим действиям в соответствующем контексте.
MCPTT ID при этом продолжает обозначать участника, например заявителя или сторону, получившую floor. Source identifier не следует автоматически заменять этим ID, названием группы или порядковым номером окна клиента.
Какую ошибку предотвращает привязка
Предположим, у диспетчерского клиента активны два согласованных обмена. Действие, рассчитанное на первый поток, не должно ошибочно изменить состояние второго только потому, что инициатор один и тот же.
В испытании фиксируют соответствие коммуникаций и применимых идентификаторов. Затем выполняют контролируемое действие в одном контексте и проверяют результат именно там. Вторую коммуникацию используют как отдельный контроль.
Такой сценарий важнее простого наблюдения, что после нажатия изменился какой-либо индикатор. Без привязки можно получить внешне правдоподобное подтверждение от неправильного обмена.
Граница требования
Рассматриваемые таблицы Stage 2 не задают здесь универсальный числовой формат поля или способ его отображения оператору. Эти детали берут из применимых протокольных описаний и документации реализации.
Отсутствие Source identifier в сценарии без media multiplexing также нельзя само по себе объявлять дефектом: условие присутствия связано с использованием мультиплексирования.
В рабочем протоколе сохраняют не только MCPTT ID участников, но и контекст коммуникации. Для технической проверки добавляют предусмотренные продуктом сведения о потоках, не заставляя оператора вводить внутренние идентификаторы вручную.
Так можно подтвердить адресность управления floor при параллельной работе клиента. Результат относится к проверенному варианту медиамультиплексирования и не превращается в обещание одинаковой внутренней нумерации всех MCPTT-продуктов или обязательного наличия поля в каждом обычном вызове.
При разборе нескольких журналов сохраняют это соответствие между потоками и действиями. Иначе одинаковый пользователь в разных коммуникациях может привести к ошибочному объединению событий.