Вы здесь

DTMF и его настройка. Часть1. Теория

DTMF (Dual-Tone MultiFrequency) - это тональный сигнал, генерируемый при нажатии на кнопки телефона.
DTMF широко применяется в работе автоответчиков (IVR), для различных интерактивных систем. В приложении к VoIP, при работе с различными кодеками DTMF требует довольно пристального внимания, поэтому его работу нужно четко понимать.

По умолчанию Gateway отсылает DTMF в потоке RTP (in-band), это прекрасно работает при использовании кодека high-bit-rate G.711, т.е. если голосовой поток не подвергается сжатию.
Основная проблема с DTMF возникает при использовании алгоритмов сжатия, например кодека G.729. Дело в том, что при сжатии качество голового потока заметно ухудшается, и хотя это почти не сказывается на способности абонентов понимать друг друга, DTMF тон уже не достаточно четкий и воспринимается неправильно.
dtmf_i_ego_nastroyka_dtmf_g729_ciscomaster.ru.jpg

Данная проблема решается с помощью DTMF Relay, при котором сигналы DTMF транспортируются отдельно от потока RTP или out-of-band.

Рассмотрим несколько примеров.
dtmf_i_ego_nastroyka_cucm_h.323_dtmf_ciscomaster.ru_0.jpg
На рисунке изображена схема подключения телефонии через шлюз H.323.

На участке PSTN DTMF отдается in-band, т.е. там даже нет понятия DTMF Relay, поскольку это аналоговая линия.

DTMF relay становится нужным только на участке VoIP, где возможно применения методов компрессии.
Также можно сказать, что:
- in-band DTMF relay будет идти внутри потока RTP, т.е. на рисунке по красной линии RTP.
- out-of-band DTMF relay будет идти вместе с сигнализацией, т.е. по зеленым линиям на рисунке.

На участках телефон-CUCM и CUCM-H.323Gateway используется разная сигнализация, и значит различные методы DTMF relay. Со стороны телефона приходит SCCP messages, содержащие DTMF в своей кодировке, со стороны H.323 gateway сигнализация вместе с DTMF идет H.245 messages.
CUCM в нашем случае выступает как DTMF Forwarder между различными типами сигнализаций.

На участке телефон-CUCM у нас будет возможна только out-of-band, поскольку SCCP-шный телефон не поддерживает in-band.
На участке CUCM-H.323Gateway возможны методы как in-band, так и out-of-band. При этом в случае SCCP-шного телефона, для включения in-band потребуется использование MTP.

Также нужно понимать, что настройки DTMF для H.323 Trunk - это есть настройки для работы этого транка с Dial-peer на физическом H.323 Gateway.

В зависимости от протокола сигнализации (H.323, SIP, MGCP, SCCP), существуют различные методы для осуществления DTMF Relay. В любом случае, Call Manager CUCM изначально пытается некоциировать общий для всех метод. Если ощий метод найден не был, предпринимается попытка использовать MTP.

H.323 DTMF Support

Cisco Gateways поддерживает следующие методы DTMF Relay:

  • Cisco proprietary: - in-band DTMF relay. DTMF отсылается в том же потоке RTP как и голос, но тоны DTMF кодируются несколько иначе, что позволяет их успешно отличать и принимать на той стороне. Семплы DTMF идентифицируются как RTP payload type 121. Метод работает только если на обоих сторонах оборудование Cisco, а также тот же метод

    Дебаг:
    В одном из источников рекомендуется debug voice rtp session named-event, но у меня не сработало.
    Результат дал только этот дебаг: debug h245 asn1

  • H.245 Alphanumeric: -Out-of-band DTMF relay. Отделяет DTMF от потока RTP и шлет их через H.245 User Input Indication messages. При этом методе не отсылается tone length: всегда считается что длина тона 500msec.
    В этом примере мы нажали на "5".

    Дебаг: debug h245 asn1

  • H.245 Signal: -Out-of-band DTMF relay. Этот метод способен отсылать длину тона (tone length).

    Дебаг: debug h245 asn1

  • NTE: - in-band DTMF relay. Работает подобно Cisco proprietary, DTMF отсылается в том же потоке RTP как и голос, с использованием RTP payload type. Другая payload не позволяет сэмплы DTMF подвергать сжатию. В отличие от Cisco proprietary, NTE использует стандарт RFC 2833.

    Дебаг: debug h245 asn1

На маршрутизаторе Cisco доступны следующие команды:

router(config-dial-peer)#dtmf-relay ?
  cisco-rtp          Cisco Proprietary RTP
  h245-alphanumeric  DTMF Relay via H245 Alphanumeric IE
  h245-signal        DTMF Relay via H245 Signal IE
  rtp-nte            RTP Named Telephone Event RFC 2833
router(config-dial-peer)#   

Лучшая практика:
На диалпире лучше всего давать команды следующим образом:

dial-peer voice 3000 voip
 description Long calls
 destination-pattern [6-7].[1-5]..
 session target ipv4:192.168.0.11
 dtmf-relay h245-signal h245-alphanumeric cisco-rtp rtp-nte
 codec g711ulaw
 no vad

В этом случае обе стороны могут негоциировать подходящий метод dtmf-relay между собой.

Для определения выбранного DTMF relay method:
show call active voice

router#show call active voice
...........
PeerAddress=5001
...........
tx_DtmfRelay=rtp-nte

Таким образом, CUCM автоматически проверяет какой метод DTMF подойдет обоим сторонам.
Касательно H.323 Gateway в CUCM, там настроек DTMF нет. CUCM принимает настройку другой стороны.

MGCP DTMF Support

Для MGCP доступны следующие методы DTMF Relay:

  • Cisco proprietary: DTMF отсылается в том же потоке RTP как и голос, но тоны DTMF кодируются несколько иначе, что позволяет их успешно отличать и принимать на той стороне. Семплы DTMF идентифицируются как RTP payload type 121. Метод работает только если на обоих сторонах оборудование Cisco и выбран аналогичный метод (ничего не негоциируется).
  • NSE: NSE - это по сути Cisco Proprietary NTE. Метод работает только если на обоих сторонах оборудование Cisco и выбран аналогичный метод (ничего не негоциируется).
  • NTE: в свою очередь может работать в двух режимах:
    - Gateway-controlled mode (NTE GW): Gateways договариваются друг с другом о DTMF самостоятельно, обмениваясь capability information в SDP messages. Этот процесс прозрачен для Call Agent. При этом у обоих шлюзов запущен MGCP и оба они подключены к одинаковому CUCM.
    - Call agent–controlled mode (NTE CA): В негоциации используется Call Agent, т.е. выступает от имени MGCP-шлюза (сообщения SDP отсылаются на Агента). Данная mode может быть использована в случае когда второй шлюз не является MGCP-Gateway. После негоциации Call Agent инструктирует шлюз, о принятых с другой стороной RTP-NTE values.
  • Out-of-band: Тоны отсылаются на CUCM с использованием сообщений MGCP, т.е. вне потока RTP (Out-of-band). CUCM в свою очередь принимает DTMF и передает другой стороне.

MGCP использует DTMF relay только для low-rate codecs (G729, iLBC, GSM, etc). Для bit-rate codecs G711 DTMF будет отослано in-band.

В случае с MGCP мы можем выбрать будут ли настройки DTMF диктоваться Call Agent-ом (CUCM) или же будут использованы те что выставлены на Gateway.
Зайдем на CUCM: Device > Gateway, выбираем соответствующий MGCP Gateway.
Нас интересует раздел Type of DTMF Relay.
dtmf_i_ego_nastroyka_cucm_mgcp_dtmf_ciscomaster.ru.jpg

При выборе Current GW Config, будет использована настройка которая стоит на шлюзе.
На IOS Gateway мы можем выставить DTMF следующей командой:

router(config)#mgcp dtmf-relay voip codec all mode ?
  cisco        Set mgcp dtmf-relay mode to be cisco
  disabled     Set mgcp dtmf-relay mode to be disabled
  nse          Set mgcp dtmf-relay mode to be nse
  nte-ca       Set mgcp dtmf-relay mode to be nte-ca
  nte-gw       Set mgcp dtmf-relay mode to be nte-gw
  out-of-band  Set mgcp dtmf-relay mode to be out-of-band

Если мы выставим на CUCM другой выбор, например cisco, соответствующая вышеприведенная команды будет введена автоматом (механизмами MGCP).

С MGCP был замечен баг:

CSCta69407 Bug Details (When using any type of inband DTMF signaling (RTP-NTE, NSE, or Cisco Proprietary) DSP's aren't turning off OOB dtmf signaling using mgcp packets. There fore duplicate digits will be seen on the terminating GW as one coming from rtp and other coming from CUCM)

Workaround: Use mgcp dtmf-relay type out-of-band.

SIP DTMF Support

По умолчанию SIP отсылает DTMF in-band, но мы можем использовать следующие опции:

  • RTP-NTE (NTE или RFC 2833) - in-band DTMF relay. Который для переноса информации DTMF использует вместо голосовых пакеты RTP Named Telephony Event (NTE). При этом SDP используется для негоциации между узлами значения payload type=NTE. Хотя формально это in-band, но реально тон в звуковом потоке слышен не будет, поскольку пакеты NTE не голосовые
    RTP-NTE не умеет работать с телефонами SCCP, поскольку телефоны SCCP используют только out-of-band DTMF relay. По этой причине совместно с RTP-NTE необходимо использовать MTP.
  • SIP INFO - out-of-band (OOB) DTMF relay. Информация DTMF отсылается в SIP-сообщениях INFO. Т.е. если шлюз получает сообщение INFO, он отдает соответствующий тон.
  • SIP NOTIFY - out-of-band (OOB) DTMF relay. или его еще называют NOTIFY-based out-of-band DTMF relay. Данный тип DTMF relay использует NOTIFY для передачи тонов. Данный метод совместим с телефонами SCCP, также его можно использовать при подключенных аналоговых телефонах к портам FXS на шлюзе.
  • KPML - out-of-band (OOB) DTMF relay. При использовании Key Press Markup Language телефон SIP отсылает номер по цифре digit-by-digit. Этот метод похож на SIP NOTIFY, с тем лишь отличием, что отдает каждую цифру отдельно.
router(config-dial-peer)#session protocol sipv2
router(config-dial-peer)#dtmf-relay ?
  cisco-rtp          Cisco Proprietary RTP
  h245-alphanumeric  DTMF Relay via H245 Alphanumeric IE
  h245-signal        DTMF Relay via H245 Signal IE
  rtp-nte            RTP Named Telephone Event RFC 2833
  sip-kpml           DTMF Relay via KPML over SIP SUBCRIBE/NOTIFY
  sip-notify         DTMF Relay via SIP NOTIFY messages
router(config-dial-peer)#  

Здесь мы видим несколько доступных методов, с для работы с CUCM годятся только
- RTP-NTE (NTE или RFC 2833);
- SIP-NOTIFY;
- SIP-KPML.

Дополнительные материалы.

Cisco Press: Session Initiation Protocol
MGCP DTMF Relay
H323 DTMF Relay
Configuring the Cisco IOS MGCP Gateway
Configuring DTMF Relay, Fax Relay, and Modem Relay
Cisco Unified Communications System 8.x SRND

Комментарии

Добрый день!

Столкнулся с такой задачей: есть VoIP провайдер, который принимает dtmf только в голосовом потоке (не rtp-nte) в кодеке G711. С SIP терминалами вопрос решен: есть опция отправлять dtmf как голос, но открытым вопросом остается SCCP-терминалы.

У меня есть CUCM + Cisco VG с DSP-ресурсами, возможно ли настроить данную опцию? Есть подозрение, что Cisco это не поддерживает.

Добрый день,
Проблема DTMF и SIP достаточно известна, а ваше оборудование решить её позволяет. Методы её решения можно найти в статьях про DTMF на сайте:
Работа с медиа-ресурсами: Transcoder и MTP
DTMF и его настройка. Часть1. Теория
DTMF и его настройка. Часть2. Практические примеры

Более конкретно вам поможет статья с конкретными рекомендациями и настройками: SIP и Call Manager. Часть 3 Подключение Call manager CUCM к SIP ITSP, но она закрытая (платная) и "заточена" под провайдера SIP.

Подскажите где посмотреть информацию о том что получается двоение цифр в тональном наборе?

Подробнее опишите ситуацию. У вас не MGCP?

Как мне подсказывают инженеры нет не mgcp.

Подскажите пожалуйста!
У меня маршрутизатор неправильно обрабатывает тон "занято" от SIP провайдера. Т.е. если идет вызов и called абонент сбрасывает вызов - на calling телефоне идут короткие гудки. Если поднять трубку и повесить, то отбой проходит нормально. Сигнал занято тоже к дтмф относится? И как можно настроить параметры этого сигнала на маршрутизаторе?

Добрый день, то что вы описываете нормальное поведение.
Сигналы сброса и занято не являются DTMF, это служебные сигналы. DTMF - это Dual-Tone Multi-Frequency, сигналы тонов, используемые в голосовых меню.

А до установления соединения сигналы занято и сброса разные? Или провайдер подает один и тот же сигнал? Или это зависит от протокола сигнализации?

Сигналы конечно разные, но они стандартные сигналы SIP. Сигналы вы можете посмотреть через debug ccsip messages

а debug выводит только ошибки? или он будет отображаться только через консольное подключение? А то через телнет и ссх не выводятся никаких сообщений. Или debug на какой-нибудь сис-лог должен сливаться?

конкретно этот дебаг выводит сообщения.
Для отображения в tty, введите terminal monitor
Подробнее см. Настройка логирования

а как можно просмотреть rtp запрос, т.к проблема при звонке на определнные номера в город не сылшут на той стороне нас!

RTP сессию можно увидеть и даже прослушать голос через программу Wireshark.
1 Снимаете дамп на внешнем интерфейсе CUBE (это можно сделать программно с роутера).
2 Скармливаете файл дампа Wireshark
3 Анализируете наличие голоса в каждом направлении
Подробнее см. http://ciscomaster.ru/content/nastroyka-call-manager-cucm-s-nulya-podkly...

Дамп снял с роутера, но запроса с от нас в сторону провайдера нету, а от них есть, соотвественно нас не слышут. в Dail peer указан что " dtmf-relay rtp-nte". Благодарю за внимание!

Это проблема one-way RTP: Смотрите ACL, постарайтесь избавиться от NAT
Попробуйте снять такой же дамп с внутреннего интерфейса.
И очень странно что такое наблюдается только с определёнными номерами, обычно такое если происходит то со всеми.

спасибо

тут ошибка:Call Manager CUCM изначально пытается некоциировать общий для всех метод.
нужно заменить на:Call Manager CUCM изначально пытается негоциировать общий для всех метод

Добрый день, умеет ли СUCME отправлять DTMF inband?

Да, но DTMF это свойство диалпира, не CUCME.
IP телефоны отдают DTMF не в голосе, поэтому понадобится MTP или Trascoder.
Вам нужно поднять transcoder на CUCME, он позволит менять DTMF в соответствии с тем, что выставлено на диалпире.

Добавить комментарий

Filtered HTML

  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Допустимые HTML-теги: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и абзацы переносятся автоматически.

Plain text

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и абзацы переносятся автоматически.
CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.
Target Image