SIP‑INFO для передачи DTMF: как это работает и когда действительно нужен

Если вы настраиваете VoIP-телефонию и столкнулись с тем, что ввод цифр при звонке не работает — не проходит в голосовое меню, не попадает на АТС, пропадает после переключения — скорее всего проблема в способе передачи DTMF. Популярное решение — использование протокола SIP‑INFO. Разберемся, что это за протокол, как он работает и когда его стоит применять.

С какой проблемой мы реально имеем дело

DTMF-тоны — это те самые звуки, которые телефон издает при нажатии цифр. Они нужны проходить через голосовые меню (IVR), вводить PIN-коды, управлять записью, переводить вызов. В аналоговой телефонии всё просто: тон идет по тому же каналу, что и голос. В SIP-телефонии — сложнее.

Канал передачи медиа и канал сигнализации разделены. Голос идет через RTP, а сигнализация — через SIP. Возникает вопрос: куда положить DTMF? Если отправить их как обычный звук, кодек может их исказить. Если не отправить — приложение их не увидит. Протокол SIP‑INFO — один из способов решить эту проблему, передавая информацию о нажатии клавиш через SIP, а не через голосовой поток.

SIP‑INFO: суть и механика

SIP‑INFO (определен в RFC 2976) позволяет передавать информацию о вводе цифр в теле сообщения SIP INFO, то есть внутри сигнального канала, не затрагивая RTP-поток. Вместо того чтобы генерировать звук DTMF и отправить его как аудио, телефон или софт-телефон формирует SIP INFO сообщение с телом application/dtmf-relay.

Пример содержимого такого сообщения:

Signal = 1
Duration = 160

Это означает: нажата клавиша «1», длительность сигнала — 160 миллисекунд. Принимающая сторона (другая сторона, софт-телефон, АТС, медиaserver) прочитывает это сообщение и локально генерирует DTMF-тон нужной длительности.

Важный момент: по умолчанию DTMF Relay отправляет два сообщения — одно в начале нажатия, другое в конце. Поэтому длительность считается как разница между временем начала и окончания. Это отличает его от RFC 2833, где длительность передается напрямем.

Когда SIP‑INFO — правильный выбор

Есть ситуации, когда другие методы не подходят или работают хуже.

Сценарий 1. На транспорте между абонентам нет надежного кодека или пакет с DTMF в голосовом потоке теряются. Если весь RTP проходит через транскодирование, тон DTMF может быть просто удален. В этом случае передача DTMF через SIP‑INFO полностью обходит медиа-путь и доставляет информацию о нажатии надежно.

Сценарий 2. Проблемы с джиттером или потерей пакетов в голосовом канале. Звуковой сигнал DTMF в RTP может не дойти или дойти с искажением. SIP‑INFO идет по TCP (или UDP, но с подтверждениями) и не зависит от качества медиа-соединения.

Сценарий 3. Ваше оборудование или софт не поддерживает RFC 2833. Это бывает с некоторыми legacy-телефонами или старыми АТС. Если выбора нет, SIP‑INFO остается единственным способом.

Сценарий 4. Вы строите систему, где DTMF должен обрабатываться именно на уровне SIP-сигнализации, без генерации звука на промежуточных узлах. Например, при работе с B2BUA или сессионным пограничным контроллером (SBC).

Как настраивать на разных платформах

Asterisk

В Asterisk способ передачи DTMF задается в настройках канала. В extensions.conf или в конфигурации драйвера (например, chan_sip.so или pjsip):

• Для старого chan_sip в SIP.conf: dtmfmode=info
• Для PJSIP в ps_endpoints.conf: dtmf=rfc4733 это RFC 2833, а для SIP‑INFO: dtmf=sipinfo или dtmf=info (в зависимости от версии).

Важно: убедитесь, что обе стороны используют согласованный метод. Если одна сторона шлет RFC 2833, а другая ждет SIP‑INFO — DTMF не пройдет.

FreeSWITCH

В FreeSWITCH параметр задается в профиле или в диалплане:

<param name="dtmf-type" value="sip-info"/>

Можно переключать на лету через переменную dtmf_type в -channelе.

Cisco CallManager / CUCM

В Cisco терминалы могут быть настроены на использование SIP‑INFO для DTMF в настройках SIP-профиля или в конфигурации устройства. Проверьте параmetro SIP DTMF Settings — там есть выбор между RFC 2833, SIP‑INFO и «no DTMF».

Софт-телефоны (MicroSIP, Linphone, Zoiper и др.)

В настройках аккаунта ищите раздел DTMF и выбирайте «SIP‑INFO» или «SIP INFO». В некоторых клиентах это может называться «SIP INFO (application/dtmf-relay)».

Сравнение методов передачи DTMF

Чтобы понять, почему в некоторых случаях SIP‑INFO выигрывает, сравним три основных метода.

Характеристика	SIP‑INFO	RFC 2833 (telephone-event)	В голосовом потоке (In-band)
Где передается	В SIP-сигнализации (INFO)	В RTP (отдельные события)	В RTP (аудио-тоны)
Зависимость от кодека	Нет	Нет, но зависит от RTP	Да, кодек может исказить
Нагрузка на канал	Минимальная (текстовые сообщения)	Низкая (короткие RTP-пакеты)	Как обычный голос
Поддержка оборудованием	Широкая, но не универсальная	Стандарт де-факто для современного оборудования	Универсальная, но ненадежная
Совместимость с транскодированием	Полная	Полная	Проблемная
Точность длительности	Зависит от реализации (start/stop)	Высокая (передается явно)	Зависит от распознавания

Типичные ошибки при внедрении

Ошибка 1. Несогласованный метод на двух сторонах. Один телефон шлет DTMF через SIP‑INFO, а АТС ждет RFC 2833. Результат — тишина при нажатии цифр. Проверяйте настройки на обоих концах.

Ошибка 2. Использование SIP‑INFO там, где есть проблемы с доставкой SIP-сообщений. Если между участками стоит прокси, который не пропускает INFO-сообщения или модифицирует их, DTMF не дойдет. Проверьте, проходят ли INFO через все промежуточные узлы.

Ошибка 3. Игнорирование параметра duration. Некоторые реализации неправильно интерпретируют длительность, из-за чего короткие нажатия превращаются в длинные или наоборот. Тестируйте с разными длительностями.

Ошибка 4. Попытка передавать через SIP‑INFO не только цифры, но и буквы (A, B, C, D). Не все реализации поддерживают полный набор символов. Уточните поддержку на принимающей стороне.

Ошибка 5. Отсутствие резервного метода. Хорошей практикой является настройка приоритетов: например, сначала пробовать RFC 2833, а при неудаче переключаться на SIP‑INFO. В Asterisk это можно сделать через dtmfmode=rfc2833,info.

Практические рекомендации

1. Всегда проверяйте согласованность настроек на обоих концах вызова. Это самая частая причина проблем. Если вы администрируете только свою сторону — уточните настройки у контрагента или провайдера.
2. Тестируйте с помощью tcpdump или Wireshark. Перехватите трафик и посмотрите, какие сообщения реально идут. Фильтр: sip.Method == "INFO" или sdp contains "dtmf". Вы увидите, отправляются ли сообщения и какое тело в них.
3. Учитывайте промежуточные узлы. SBC, прокси-серверы, NAT-файрволы могут блокировать или модифицировать INFO-сообщения. Если у вас сложная топология — проверяйте прохождение на каждом участке.
4. Настраивайте длительность корректно. Минимальная рекомендуемая длительность — 100 мс, стандартная — 160–200 мс. Слишком короткие сигналы могут не распознаться, слишком длинные — замедлить ввод.
5. Документируйте настройки. Записывайте, где и какой метод DTMF используется. Это сэкономит время при отладке в будущем.

Что выбрать в зависимости от вашей ситуации

Если вы строите новую систему с современным оборудованием — начните с RFC 2833. Это стандарт индустрии, поддерживается практически всеми современными IP-телефонами и АТС. SIP‑INFO используйте только как запасной вариант.

Если у вас старое оборудование или проблемы с голосовым каналом — SIP‑INFO может быть основным методом. Он надежнее проходит через транскодеры и не зависит от кодека.

Если вы работаете с провайдером и не знаете его настройки — уточните у него, какой метод он поддерживает. Многие провайдеры явно указывают это в документации. Если провайдер требует SIP‑INFO — настраивайте SIP‑INFO.

Если у вас смешанная среда — настройте приоритет методов. Например, в Asterisk: dtmfmode=rfc2833,info. Система сначала попробует RFC 2833, а если собеседник не поддерживает — переключится на SIP‑INFO.

Заключение

SIP‑INFO — это простой и надежный способ передачи DTMF через сигнальный канал SIP. Он не требует генерации звука в голосовом потоке, не зависит от кодека и хорошо работает в условиях нестабильного RTP. Главное — убедиться, что обе стороны вызова настроены на один и тот же метод, и что промежуточные узлы не блокируют INFO-сообщения.

Если DTMF не проходит — начните с проверки согласованности настроек, затем смотрите трафик в Wireshark. В большинстве случаев проблема решается за несколько минут, если знать, что искать.