Радиосвязь: практическое применение
Supplementary User Data DMR Tier III: вызов может продолжиться без запрошенного дополнения
Успешный разговор не подтверждает все сопутствующие данные
К голосовому вызову DMR Tier III приложение добавляет служебную информацию. Разговор устанавливается, и интегратор считает дополнение доставленным. Однако процедура допускает продолжение вызова без запрошенных supplementary user data.
Если TSCC не поддерживает дополнение или не желает принять его в данный момент, он может продолжить установление основной услуги либо отказать всему вызову. Поэтому основной результат и результат сопутствующего обмена должны иметь отдельные подтверждения.
Как определить требование приложения
Предположим, оперативному разговору сопутствует согласованная карточка события. Владелец процесса должен решить, допустим ли разговор без карточки. Это проектное требование, которое затем сопоставляется с поведением конкретной реализации.
Нельзя объявлять передачу произвольной структуры совместимой лишь по поддержке supplementary data. Формат и число добавленных блоков заранее согласуются между системой и конфигурацией станции. Получатель должен понимать именно переданный состав.
Что проверить на приёмке
Первый опыт выполняют при поддерживаемом дополнении. Сохраняют запрос, исходящую передачу данных, их получение и дальнейшее установление вызова. На прикладной стороне проверяют содержание карточки, а не только протокольный ответ.
Второй опыт покрывает согласованный случай отсутствия поддержки или непринятия дополнения. Проверяют, продолжился ли основной вызов или завершился отказом, и соответствует ли это проекту. Пользовательский интерфейс должен понятно объяснять неполный результат.
Такая проверка особенно важна для интеграции: внешне успешная голосовая связь может скрыть отсутствие информации, ради которой вводилось дополнение.
Подтверждение данных имеет ограниченный смысл
В приведённом спецификацией примере получатель отвечает на сопутствующие данные ещё до получения адреса вызывающей стороны в Channel Grant. Поэтому этот ответ нельзя автоматически трактовать как осознанное принятие вызова от уже известного конкретного пользователя.
Если приложение требует решения с учётом инициатора, его обеспечивают предусмотренными механизмами и подтверждают отдельно. Смысл одного подтверждения не следует расширять по удобству отчёта.
Как оформить итог
В акте сохраняют формат дополнения, его результат, результат основной услуги и поведение при отсутствии поддержки. Для каждого указывают наблюдаемый источник подтверждения.
Итогом становится проверенная связка данных и разговора. Инженер видит, какая часть прошла, а эксплуатация не получает ложное обещание полной карточки по одному успешному вызову. Такой подход помогает строить интеграцию на реальных подтверждениях и заранее определить, как работать, когда голосовая служба доступна, а сопутствующий обмен не выполнен в требуемом объёме.