DTMF через SIP шлюз: как отличить событие клавиши от слышимого тона
Диспетчер нажимает клавишу, слышит тон и ожидает переключения тестового меню. Однако шлюз может передавать звуковой сигнал, отдельное телефонное событие или другой поддерживаемый механизм. Слышимый звук не подтверждает получение нужного формата командой на принимающей стороне. Для хозяйства это особенно существенно, если одинаковый интерфейс используется в разных маршрутах связи с отличающимися согласованными возможностями.
Зафиксировать способ передачи
RTP telephone-event описывает передачу телефонных событий отдельно от обычного кодирования звука. Формат, поддерживаемые события и медиапараметры должны быть согласованы соответствующим образом. Событие клавиши не следует считать обычным аудиосэмплом, а слышимый тон — универсальным доказательством доставки события. Offer/answer помогает согласовать возможности, но сам по себе не подтверждает выполненное действие обработчика. (IETF — RFC4733 RTP Telephony Events) (IETF — RFC3264 SDP Offer Answer)
Запишите способ передачи на каждом участке, фактическое согласование и ожидаемый интерфейс принимающего приложения. Если один шлюз преобразует событие в звук или обратно, покажите эту границу отдельно. Не ограничивайтесь общей галочкой «DTMF включён»: она может скрывать несовместимые режимы. Для проверки выбирайте исключительно изолированный обработчик, который показывает полученное событие и не управляет полевым оборудованием.
Прокручивайте увеличенную схему по горизонтали. С клавиатуры: перейдите к схеме и используйте стрелки.
Сопоставить нажатие и получение
Выполните заранее согласованную последовательность тестовых нажатий с различимыми одиночными событиями. Сравните действие оператора, наблюдаемый медиапакет и запись тестового обработчика. Отдельно проверьте удержание клавиши, завершение события и повторное нажатие после паузы. Эти сценарии помогают увидеть, где длительность события или его повторная передача ошибочно превращаются в несколько прикладных действий.
Затем повторите проверку после разрешённого изменения медиамаршрута либо транскодирования, если такое поведение предусмотрено проектом. Не подавайте тестовые последовательности в действующие исполнительные устройства, системы доступа или аварийное управление. Перечень реальных команд и права на их выполнение устанавливает владелец объекта; диагностическая статья не назначает командные коды и не подтверждает безопасность стороннего обработчика без испытания.
Принять совместимый маршрут
В результате сохраните карту способов передачи, полученные события и число действий тестового приложения. Приёмка подтверждает конкретный маршрут и поддерживаемые сценарии, а не сам факт слышимого тона. Если преобразование не проверено, обозначьте ограничение до включения в рабочую схему. Тогда обслуживание связи сможет локализовать несовпадение форматов, а диспетчер получит достоверный признак приёма события вместо ошибочного вывода о выполнении команды только по звуку в своей гарнитуре.
