DTMF (Dual-Tone MultiFrequency) - это тональный сигнал, генерируемый при нажатии на кнопки телефона.
DTMF широко применяется в работе автоответчиков (IVR), для различных интерактивных систем. В приложении к VoIP, при работе с различными кодеками DTMF требует довольно пристального внимания, поэтому его работу нужно четко понимать.
По умолчанию Gateway отсылает DTMF в потоке RTP (in-band), это прекрасно работает при использовании кодека high-bit-rate G.711, т.е. если голосовой поток не подвергается сжатию.
Основная проблема с DTMF возникает при использовании алгоритмов сжатия, например кодека G.729. Дело в том, что при сжатии качество голового потока заметно ухудшается, и хотя это почти не сказывается на способности абонентов понимать друг друга, DTMF тон уже не достаточно четкий и воспринимается неправильно.
Данная проблема решается с помощью DTMF Relay, при котором сигналы DTMF транспортируются отдельно от потока RTP или out-of-band.
Рассмотрим несколько примеров.
На рисунке изображена схема подключения телефонии через шлюз 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.
Cisco Gateways поддерживает следующие методы DTMF Relay:
Дебаг:
В одном из источников рекомендуется debug voice rtp session named-event, но у меня не сработало.
Результат дал только этот дебаг: debug h245 asn1
Дебаг: debug h245 asn1
Дебаг: debug h245 asn1
Дебаг: 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 Relay:
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.
При выборе 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 in-band, но мы можем использовать следующие опции:
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 выводит только ошибки? или он будет отображаться только через консольное подключение? А то через телнет и ссх не выводятся никаких сообщений. Или debug на какой-нибудь сис-лог должен сливаться?
конкретно этот дебаг выводит
конкретно этот дебаг выводит сообщения.
Для отображения в tty, введите terminal monitor
Подробнее см. Настройка логирования
а как можно просмотреть rtp
а как можно просмотреть rtp запрос, т.к проблема при звонке на определнные номера в город не сылшут на той стороне нас!
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:
Это проблема one-way RTP: Смотрите ACL, постарайтесь избавиться от NAT
Попробуйте снять такой же дамп с внутреннего интерфейса.
И очень странно что такое наблюдается только с определёнными номерами, обычно такое если происходит то со всеми.
спасибо
спасибо
тут ошибка:Call Manager CUCM
тут ошибка:Call Manager CUCM изначально пытается некоциировать общий для всех метод.
нужно заменить на:Call Manager CUCM изначально пытается негоциировать общий для всех метод
Добрый день, умеет ли СUCME
Добрый день, умеет ли СUCME отправлять DTMF inband?
Да, но DTMF это свойство
Да, но DTMF это свойство диалпира, не CUCME.
IP телефоны отдают DTMF не в голосе, поэтому понадобится MTP или Trascoder.
Вам нужно поднять transcoder на CUCME, он позволит менять DTMF в соответствии с тем, что выставлено на диалпире.
Добавить комментарий