Создание MC-группы с предложенным ID: почему итоговый идентификатор нужно читать из ответа
Интеграция диспетчерского рабочего места создала группу и сохранила локальное имя, заранее сформированное для неё. Если приложение при этом считает предложенный идентификатор окончательным, дальнейшие обращения могут уйти к неверной записи. В общей процедуре MC-связи сервер управления группами участвует в выборе итогового MC service group ID.
Раздел 10.2.3 ETSI TS 123 280 V19.10.1 допускает включение предложенного идентификатора в запрос создания. Если его нет, GMS формирует идентификатор сам. Если предложение приемлемо, сервер использует его. Если неприемлемо, сервер может изменить значение, сформировать другой ID либо отклонить запрос.
Проверка интеграции при создании
На стенде задают авторизованного инициатора, известные идентификаторы пользователей и включаемые MC-службы. Рассматриваемая процедура относится к случаю, когда необходимые компоненты и участники находятся в одной MC-системе. Переносить её без уточнений на межсистемное создание не следует.
После отправки запроса проверяют не только общий успех, но и конкретный результат выбора ID. Ответ различает успешное использование предложенного значения и успешное создание с идентификатором, предоставленным GMS. Клиент должен затем обращаться к фактически созданной группе средствами, предусмотренными продуктом.
Полезно согласовать несколько случаев: создание без предложенного значения, приемлемое предложение и вариант, который сервер не принимает. Для последнего нельзя заранее требовать единственного исхода «обязательно отказ»: стандарт перечисляет также изменение и генерацию другого идентификатора. Конкретную политику проверяют по поставке.
Идентификатор и отображаемое имя
В акте полезно хранить отдельно предложенный ID, итоговый ID и видимое человеку название. Это редакционная рекомендация для диагностики. Она помогает разобраться, если интерфейс продолжает показывать привычную подпись, хотя системный идентификатор оказался другим.
После создания проверяют получение конфигурации именно итоговой группы и одну согласованную рабочую операцию. Наличие локальной карточки не является достаточным доказательством: интеграция могла сохранить первоначальное предложение до получения окончательного ответа.
Стандарт допускает предварительно согласованные правила формирования предложения, но способ получения таких правил находится за пределами рассматриваемого документа. Поэтому интегратор должен описать собственный договорённый порядок, а не ссылаться на универсальную формулу ID из общей архитектуры.
Хороший результат испытания — прослеживаемая цепочка от запроса до фактической группы. Поддержка видит, какое значение предлагалось, что принял сервер и какой идентификатор используется дальше, без догадок по похожим названиям.
Источник: ETSI TS 123 280 V19.10.1 (2026-05), 3GPP TS 23.280 Release 19, 10.2.3, печатные страницы 112–113.