MCData ad hoc по критериям: проверяют правило, которое применил сервер, а не только исходный запрос
Диспетчер выбрал критерий состава временной MCData-группы, а фактические приглашения оказались уже ожидаемого набора. Для объяснения нужно сопоставить исходное правило и правило, применённое сервером. В ETSI TS 123 282 V19.10.0 предусмотрено поле call resulting criteria, отражающее результат такой обработки.
Почему исходный критерий не всегда окончательный
В процедуре создания ad hoc коммуникации с серверным определением состава сказано, что сервер может изменить полученные критерии с учётом локальной политики. Подробное содержимое и способ определения участников оставлены реализации.
Поэтому понятная метка, выбранная оператором, сама по себе не описывает все условия отбора. Например, рабочее географическое условие может применяться вместе с предусмотренными системой дополнительными ограничениями.
Из этого не следует право сервера игнорировать любое требование произвольно. Для приёмки нужна согласованная политика конкретного внедрения и объяснимое соответствие между запросом и применённым результатом.
Что возвращается инициатору
В описанной процедуре ответ об установлении коммуникации содержит resulting criteria, использованные сервером для определения приглашённых. Такие сведения предусмотрены также в уведомлениях о составе, направляемых в соответствующем порядке.
Это помогает проверить не только факт создания группы, но и основание выбора людей. При этом приглашённый список и фактически присоединившиеся участники различаются: получающий клиент может принять или отклонить запрос.
Следовательно, отсутствие сотрудника среди участников требует двух отдельных вопросов. Соответствовал ли он применённому правилу отбора и завершилось ли его приглашение присоединением? Один исходный критерий не отвечает на оба.
Практическая проверка
В тесте сохраняют исходный критерий инициатора, действующую локальную политику и возвращённые resulting criteria. Затем сопоставляют с ними определённые приглашения и фактические ответы клиентов.
Если интерфейс не показывает правило в понятном виде, поставщик должен объяснить доступный способ его проверки. Не следует обещать одинаковую текстовую расшифровку во всех приложениях: формат и смысл критериев зависят от реализации.
Для рабочей инструкции выбирают понятное описание ожидаемого состава и способ убедиться в его достаточности. Технические сведения сохраняют в протоколе настройки.
Так оператор получает объяснимый результат отбора, а инженер может отделить действие политики от отказа приглашённого или ошибки доставки. Проверка остаётся привязана к текущей процедуре ad hoc MCData и не подменяется предположением, что выбранная метка всегда применяется без изменений.
