Как использовать SIP-INFO для передачи DTMF-сигналов в реальном времени — практическое руководство

Содержание

Как использовать SIP-INFO для передачи DTMF-сигналов в реальном времени — практическое руководство

Вы настраиваете телефонную систему, и вам нужно, чтобы пользователь мог вводить цифры — например, номера меню, PIN-коды или команды для IVR — прямо во время разговора, без пауз и сбоев. Вы пробовали RFC 2833 (RTP DTMF), но он лагает, теряет сигналы на слабом соединении или не работает с некоторыми старыми шлюзами. Вы слышали про SIP-INFO, но не понимаете, как его правильно настроить, чтобы он работал надёжно. Или, может быть, вы уже используете SIP-INFO, но сигналы пропадают, и клиенты жалуются, что система их не слышит.

В этой статье я расскажу, как SIP-INFO действительно работает в реальной жизни — не теоретически, а как это выглядит на практике, когда вы сталкиваетесь с реальными устройствами, провайдерами и проблемами в продакшене. Я не буду объяснять, что такое SIP или DTMF. Вы уже знаете. Вы здесь, потому что вам нужно, чтобы цифры дошли до сервера, когда нужно, и без ошибок.

Почему SIP-INFO — это не «альтернатива», а нужный инструмент

DTMF-сигналы — это тональные сигналы, которые вы слышите, когда набираете цифры на телефоне. Они передаются двумя основными способами:

RFC 2833 — через RTP-пакеты, как отдельный поток. Работает хорошо, если сеть стабильна и оборудование поддерживает.
SIP-INFO — передаётся как SIP-сообщение внутри управляющего канала, параллельно с голосом.

Проблема с RFC 2833 в реальных условиях: если сеть перегружена, пакеты RTP могут теряться, задерживаться или приходить в неправильном порядке. А DTMF-сигнал — это не голос. Это команда. Если вы набираете «1» для перехода в меню, а пакет потерялся — вы получаете молчание. Или, хуже — система считает, что вы набрали «2».

SIP-INFO решает это иначе: он не зависит от RTP-потока. Сообщение отправляется по SIP-каналу, который обычно надёжнее — он использует TCP или надёжный UDP (SIP over TLS, или TCP-сессии), и его приоритет выше, чем у голоса. Даже если голос лагает, DTMF-сообщение может дойти.

Это особенно важно, когда:

Вы работаете с мобильными сетями (3G/4G/5G) — там RTP часто теряется;
Используете VoIP-шлюзы с устаревшим ПО — они плохо поддерживают RFC 2833;
Ваша система — это call-центр с IVR, где каждая цифра — это переход между этапами;
Вы передаёте чувствительные данные — PIN-коды, пароли — и не можете позволить себе сбои.

Но SIP-INFO — не волшебная таблетка. Он требует правильной настройки. И если вы его настроите неправильно — он будет работать хуже, чем RFC 2833.

Как SIP-INFO передаёт DTMF: шаг за шагом

Вот как это выглядит на уровне сообщений, когда вы набираете цифру «5»:

Телефон (или IP-телефон) определяет, что вы нажали клавишу «5».
Он формирует SIP-сообщение INFO с телом в формате application/dtmf-relay.
В теле сообщения указано: Digit: 5, Duration: 100 (мс), Signal: 1 (начало сигнала).
Сообщение отправляется по существующей SIP-сессии — той же, по которой идёт голос.
Сервер (PBX, IVR, шлюз) получает INFO, извлекает цифру, обрабатывает её и отправляет подтверждение — 200 OK.
Когда вы отпускаете кнопку, телефон отправляет ещё одно INFO с Signal: 0 — это сигнал окончания.

Важно: каждая цифра — это два сообщения. Одно — при нажатии, второе — при отпускании. Если вы отправляете только одно — система может не понять, что вы закончили ввод.

Пример тела сообщения:

INFO sip:server@pbx.example.com SIP/2.0
Via: SIP/2.0/UDP client.example.com:5060
From: <sip:caller@example.com>;tag=12345
To: <sip:server@pbx.example.com>
Call-ID: abc123@client.example.com
CSeq: 10 INFO
Content-Type: application/dtmf-relay
Content-Length: 45

Digit: 5
Duration: 100
Signal: 1

После отпускания:

Digit: 5
Duration: 100
Signal: 0

Это не сложнее, чем отправить SMS. Но только в SIP.

Что нужно, чтобы SIP-INFO работал

Вот что должно быть в вашей системе, чтобы SIP-INFO работал без сбоев:

Поддержка на клиенте — IP-телефон, softphone, шлюз. Проверьте документацию: не все устройства умеют отправлять DTMF через INFO. Например, Grandstream, Yealink, Snom — поддерживают. Cisco IP-телефоны — тоже, но требуют включения в настройках.
Поддержка на сервере — PBX (Asterisk, FreeSWITCH, 3CX, Avaya) или IVR-платформа. FreeSWITCH включает это по умолчанию. Asterisk — требует dtmfmode=info в sip.conf для каждого пользователя или контекста.
Совместимость с провайдером — если вы используете SIP-транк от провайдера, уточните: поддерживает ли он INFO для DTMF? Многие провайдеры по умолчанию используют RFC 2833. Если вы включите INFO на своей стороне, а провайдер его игнорирует — вы получите тишину.
Надёжный транспорт — SIP-INFO лучше работает по TCP или TLS. Если вы используете UDP без ретрансмиссии — пакеты могут теряться. Особенно на мобильных сетях.

Если вы настраиваете Asterisk, вот минимальная конфигурация для пользователя:

[user123]
type=friend
host=dynamic
dtmfmode=info
context=from-internal

Если вы используете FreeSWITCH — в диалплане просто укажите:

<action application="set" data="dtmf_mode=info"/>

Это всё. Никаких сложных настроек. Но если вы забудете про провайдера — всё сломается.

Сравнение: SIP-INFO vs RFC 2833 vs In-Band

Вот как они ведут себя в реальных условиях:

Критерий	SIP-INFO	RFC 2833 (RTP DTMF)	In-Band (голосовой канал)
Надёжность при потере пакетов	Высокая (SIP-канал надёжнее)	Низкая (теряются RTP-пакеты)	Очень низкая (шум, компрессия искажают сигнал)
Задержка передачи	Минимальная (10–50 мс)	Умеренная (50–150 мс)	Высокая (200+ мс, зависит от кодека)
Поддержка в мобильных сетях	Отличная	Плохая	Плохая
Совместимость с шлюзами	Требует настройки	Широко поддерживается	Работает, но не рекомендуется
Требования к кодеку	Не зависит	Не зависит	Только G.711 (A-law/U-law)
Безопасность	Работает поверх TLS	Требует SRTP для шифрования	Нет шифрования — сигнал слышен

Как видите, SIP-INFO выигрывает в надёжности и безопасности, особенно если вы работаете с мобильными клиентами или передаёте чувствительные данные. RFC 2833 — это «рабочая лошадка», но только если сеть стабильна. In-Band — это устаревший способ, который стоит использовать только если ничего другого не работает.

Что ломает SIP-INFO в реальной жизни

Вот реальные ошибки, которые я видел десятки раз — и каждая из них ломала систему:

Провайдер игнорирует INFO — вы включили dtmfmode=info на своей стороне, но провайдер пересылает трафик как есть, без обработки. Результат: цифры не доходят. Решение: позвоните провайдеру и спросите: «Поддерживаете ли вы DTMF через SIP-INFO?» — не пишите, а позвоните.
Нет подтверждения (200 OK) — клиент отправляет INFO, но сервер не отвечает. Клиент может повторять отправку, но если сервер не отвечает — это считается ошибкой. Некоторые шлюзы не отправляют 200 OK по умолчанию. Решение: включите логи SIP на сервере и проверьте, приходят ли ответы.
Слишком короткая длительность — если вы отправляете Duration: 10 мс, система может не успеть распознать сигнал. Минимум — 50 мс. Оптимально — 80–120 мс. Пример: Yealink T46S по умолчанию отправляет 100 мс — это нормально.
Отсутствие сигнала окончания (Signal: 0) — клиент отправляет только нажатие, но не отпускание. Система считает, что цифра всё ещё нажата. Результат: вы набрали «1», а система думает, что вы держите кнопку — и ждёт следующую цифру. Это частая ошибка в кастомных скриптах.
Неправильный Content-Type — вместо application/dtmf-relay отправляют text/plain или application/sdp. Сервер просто игнорирует сообщение. Проверяйте заголовки в логах.

Если вы видите, что цифры не доходят — включите SIP-логи на сервере и найдите сообщения INFO. Если их нет — проблема на клиенте. Если есть, но нет ответа — проблема на сервере. Если есть и ответ — но система не реагирует — проблема в приложении (IVR, ACD).

Когда использовать SIP-INFO — и когда нет

Не все ситуации требуют SIP-INFO. Вот когда он нужен:

Вы используете мобильные приложения — VoIP-клиенты на Android/iOS, где сеть нестабильна.
Вы передаёте PIN-коды, пароли, номера карт — SIP-INFO не зависит от кодека и не искажается шумом.
У вас старые шлюзы — например, Cisco VG350 или Avaya G450, где RFC 2833 работает с перебоями.
Вы интегрируете с системами, требующими точного тайминга — например, системы голосового банкинга, где каждая цифра должна быть распознана за 200 мс.

А вот когда SIP-INFO — лишний шаг:

Вы работаете только в локальной сети с надёжным IP-соединением — RFC 2833 проще и стабильнее.
Ваша система — это простой голосовой ответ — например, «нажмите 1 для поддержки» — и клиенты используют стационарные телефоны.
У вас нет контроля над клиентами — например, вы подключаетесь к стороннему IVR, и вы не знаете, как он настроен.

Если вы не уверены — начните с RFC 2833. Он проще. Если начнёте с SIP-INFO — и он не заработает — вы потратите день на отладку. Если RFC 2833 ломается — переходите на SIP-INFO. Это не «лучше» — это «нужнее в вашей ситуации».

Как правильно настроить — пошаговый план

Вот что делать, если вы хотите внедрить SIP-INFO:

Проверьте, поддерживает ли ваш клиент — посмотрите документацию на IP-телефон или softphone. Включите DTMF через SIP-INFO в настройках (обычно в разделе «Advanced» или «DTMF»).
Настройте сервер — в Asterisk: dtmfmode=info в sip.conf. В FreeSWITCH: <action application="set" data="dtmf_mode=info"/> в диалплане.
Проверьте провайдера — позвоните в техподдержку и спросите: «Поддерживаете ли вы DTMF через SIP-INFO?» Если нет — попросите включить. Если отказывают — используйте RFC 2833.
Используйте TCP/TLS — не UDP. SIP-INFO надёжнее на надёжном транспорте.
Проверьте длительность — убедитесь, что клиент отправляет Duration: 80–120 мс. Не меньше 50.
Включите логи SIP — на сервере и на клиенте. Ищите INFO сообщения с application/dtmf-relay и ответы 200 OK.
Протестируйте — наберите цифры разного типа: 1, 2, 3, 0, #, *. Проверьте, что каждая цифра обрабатывается. Используйте тон-генератор на телефоне, если нужно.

Настройка занимает 15–30 минут. Тестирование — ещё 10–20. Если всё работает — вы получаете стабильную передачу DTMF даже на слабом соединении.

Что выбрать — и как не ошибиться

Вот простое решение, которое работает в 90% случаев:

Если вы настраиваете систему для мобильных пользователей, банков, call-центров — выбирайте SIP-INFO. Это ваша страховка от потерь.
Если вы работаете в локальной сети с хорошим качеством, и клиенты используют стационарные IP-телефоны — выбирайте RFC 2833. Проще, быстрее, меньше головной боли.
Если вы не знаете, что использовать — начните с RFC 2833. Если появятся пропущенные цифры — переключайтесь на SIP-INFO. Не пытайтесь «сразу сделать идеально» — делайте по шагам.

Не пытайтесь «включить всё и сразу». Не смешивайте методы. В одной сессии должен быть один метод DTMF. Если вы включите и INFO, и RFC 2833 — это может вызвать дублирование, двойные команды, и клиент будет получать ошибки.

Итог: что делать прямо сейчас

Если вы читаете это — значит, у вас есть проблема с DTMF. Вот что делать:

Откройте логи SIP на вашем сервере.
Наберите цифру на телефоне.
Найдите в логах сообщение INFO с application/dtmf-relay.
Если его нет — проверьте настройки клиента: включён ли SIP-INFO?
Если есть — есть ли ответ 200 OK?
Если нет — проверьте провайдера.
Если есть — проверьте, как сервер обрабатывает цифру. Возможно, проблема в IVR, а не в транспорте.

Если вы сделаете это — вы найдёте проблему за 15 минут. Не ищите «сложные решения». Ищите, где пропадает сообщение. Это всегда одно из трёх: клиент не отправляет, провайдер не пропускает, сервер не обрабатывает.

SIP-INFO — не магия. Это просто надёжный способ передать цифры. Когда он работает — вы даже не замечаете, что он есть. Когда он не работает — вы понимаете, что без него ваша система ломается. Используйте его, когда нужно. Не используйте, когда не нужно. Просто.

Информация в этой статье носит ознакомительный характер. Настройка телефонных систем требует понимания вашей инфраструктуры и требований к безопасности. Перед внесением изменений в продакшен-среду проконсультируйтесь с инженером, ответственным за вашу телекоммуникационную инфраструктуру.