MCPTT: цепочка немедленных переадресаций ограничена, а no answer не даёт бесконечного поиска
Личный вызов MCPTT перенаправляется от одного сотрудника к другому, у которого тоже включено forwarding. Такой маршрут не должен превращаться в бесконечный обход настроек. ETSI TS 123 379 V19.11.0 отдельно описывает ограничение последовательных переадресаций и более узкое правило для no answer и ручного перенаправления.
Немедленная последовательность
Если у нового целевого пользователя также включена переадресация, дополнительные forwarding в общем случае выполняются последовательно. Для немедленных перенаправлений в конфигурации службы определяется предел.
Сервер отслеживает количество переадресаций. При превышении предела вызов освобождается. Цель описанного ограничения — предотвратить чрезмерное число переходов и бесконечные петли.
Конкретное числовое значение нельзя взять из самого слова limit. Оно является настройкой внедрения и должно быть известно при подготовке маршрутов дежурных сотрудников.
Отсутствие ответа и ручной выбор
Для forwarding no answer либо forwarding на основании ручного действия разрешено только одно перенаправление. Если на первом перенаправленном направлении ответа нет, сервер освобождает вызов.
Поэтому набор профилей «если не ответил первый, искать второго, затем третьего» нельзя обещать как универсальное следствие нескольких включённых no-answer правил. Для такого рабочего требования нужно отдельно проверить, какой механизм реализации действительно его обеспечивает.
Это различие также мешает считать любую цепочку одинаковой. Основание перехода важно не меньше, чем конечный список имён сотрудников.
Как проверить маршрут
В тестовой конфигурации фиксируют каждый переход: чей профиль действует, какое основание forwarding и кто следующий адресат. Для немедленной цепочки сохраняют эффективный предел службы.
Затем выполняют согласованный тест штатного завершения и контролируемый тест ограничения. Для no answer отдельно проверяют отсутствие ответа у первого перенаправленного получателя и фактическое освобождение вызова.
Петлю не создают незаметно в действующей рабочей группе. Проверка должна оставаться частью согласованного сценария с понятным восстановлением утверждённых настроек.
В отчёте нужны фактические переходы и причина окончания, которую позволяет наблюдать продукт. Простого сообщения «переадресация не сработала» недостаточно для разбора достигнутого предела.
Так дежурная схема остаётся объяснимой. Оператор знает ожидаемый результат отсутствия ответа, а инженер отличает ограничение числа переходов от сетевого отказа и не выдаёт цепочку профилей за неограниченный автоматический поиск свободного исполнителя MCPTT.
После изменения дежурных маршрутов повторяют затронутый путь контрольным вызовом. Обновлённые имена в профилях не подтверждают отсутствие петли или соблюдение эффективного ограничения службы.
