что такое dtmf команда

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

По умолчанию 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.

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

H.323 DTMF Support

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

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

Дебаг: debug h245 asn1

Дебаг: debug h245 asn1

Дебаг: debug h245 asn1

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

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

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

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

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

MGCP DTMF Support

Для 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 следующей командой:

Если мы выставим на 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, но мы можем использовать следующие опции:

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

Источник

Команды DTMF на клавиатуре телефона или софтфона

Удержание вызова
Чтобы поставить текущий вызов на удержание, наберите на клавиатуре телефона или софтфона команду ##. В режиме удержания ваш собеседник услышит мелодию ожидания и не будет слышать вас. Для снятия с удержания повторно наберите ##.

Чтобы совершать перевод вызов на произвольный внешний номер разрешите перевод вызова на внешние номера в настройках.

Прием факса
Для приема факса во время разговора наберите на клавиатуре телефона или софтфона команду #0. После этого вы услышите мелодию ожидания, а ваш собеседник – факсимильный вызов. Когда он нажмет кнопку Start на факсимильном аппарате, Виртуальная АТС примет факс. После окончания приема факса Виртуальная АТС возвращает собеседников в режим разговора (если никто из абонентов не повесил трубку).

Для приема факса с помощью команды #0 необходимо включить данную опцию в разделе личного кабинета Дополнительные настройки/Факс:

Подробнее о настройке опций приема факса вы можете прочитать в разделе « Прием факсов».

Запись разговора
Чтобы записать текущий разговор наберите на клавиатуре телефона или софтфона команду #5. Запись начнется сразу же и будет вестись до окончания разговора. Чтобы эта команда работала, необходимо, чтобы сервис записи разговоров был подключен (подробнее см. раздел « Запись разговоров»).

Источник

Что такое dtmf команда

Тональный набор, тональный сигнал (англ. Dual-Tone Multi-Frequency, DTMF) — двухтональный многочастотный аналоговый сигнал, используемый для набора телефонного номера, а также для различных интерактивных систем, например голосового автоответа. По используемой полосе частот сигнал соответствует телефонии. Сигнал DTMF является суммой отрезков двух гармонических колебаний, частоты которых соответствуют номеру строки и столбцу цифры номеронабирателя обычного телефона. А попросту говоря, нажимая на цифры номеронабирателя, каждая кнопка издает звук разной тональности, по этому звуку на другом конце определяют, какая цифра нажата например когда предлагается «Нажмите кнопку 1, если вы хотите…, кнопку 2 если вы хотите…, для возврата в предыдущее меню нажмите 0»…

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

DTMF Decoder: Эта опция содержит переключатели External, Internal, Disabled при помощи которых можно выбрать тип DTMF-декодера или отключить его.

External: Внешний аппаратный DTMF-декодер реализован в i-link интерфейсах конструкции WB2REM или VA3TO. Если используется именно такой тип интерфейса, можно выбрать эту функцию, если вы убедились в надежности аппаратного декодирования применительно к вашему управляющему трансиверу.

Подключение по номеру ноды осуществляется простым набором DTMF-команды.

Источник

DTMF (тональный набор)

Какие функции DTMF в АТС Zadarma существуют?

В АТС Zadarma сигнал DTMF используется для работы с IVR (голосовым меню) во время входящих звонков.

Функции DTMF в АТС:

Перевод звонка

Для перевода входящего или исходящего звонка нажмите # затем внутренний номер абонента и снова # например #101#

Перевод с голосовым уведомлением

Для перевода звонка с голосовым уведомлением нажмите * внутренний номер и # например *101#

Перевод звонка на сценарий АТС

Для перевода звонка на сценарий (сценарий может содержать несколько внутренних номеров, чаще всего сценарии используются для отдельных отделов или подразделений в компании) наберите номер сценария в голосовом меню, например #1#

Перехват звонка

Для перехвата входящего звонка наберите 40 и нажмите кнопку вызова.

Мне нужно набрать # либо *

Если вы звоните с SIP (а не с внутреннего номера АТС) # либо * в тональном режиме передается обычным способом (так как на SIP нет перевода звонка).

Если вы совершаете звонок с внутреннего номера АТС, для донабора клавиши # либо * во время DTMF в голосовых меню, наберите 00# либо 00*. Нули будут удалены и система передаст только # или *.

Сигналы DTMF могут передаваться тремя методами:

При подключении к виртуальной АТС необходимо использовать метод RFC2833. Если виртуальная АТС не активна, для передачи DTMF в сторону Zadarma может использоваться любой метод, с нашей стороны мы передаем тоны только в формате RFC2833.

Источник

IP-телефония: от медных проводов до цифровой обработки сигнала

Если в один прекрасный день вам придется на скорую руку разобраться, что есть VoIP (voice over IP) и что значат все эти дикие аббревиатуры, надеюсь, эта методичка поможет. Сразу замечу, что вопросы конфигурирования дополнительных видов обслуживания телефонии (такие как перевод вызова, голосовая почта, конференц-связь и т.п.) здесь не рассматриваются.

1. Базовые понятия телефонии

В общем виде схема подключения локального абонента к телефонному провайдеру по обычной телефонной линии выглядит следующим образом:

На стороне провайдера (АТС) установлен телефонный модуль с портом FXS (Foreign eXchange Subscriber). Дома или в офисе установлен телефон или факс с портом FXO (Foreign eXchange Office) и модуль номеронабирателя.

По внешнему виду порты FXS и FXO никак не отличаются, это обычные 6-выводные RJ11-разъемы. Но с помощью вольтметра отличить их очень просто — на FXS-порте всегда будет какое-то напряжение: 48/60 В, когда трубка положена, или 6–15 В во время разговора. На FXO, если он не подключен к линии, напряжение всегда 0.

Для передачи данных по телефонной линии на стороне провайдера нужна дополнительная логика, которую можно реализовать на модуле SLIC (subscriber line interface circuit), а на стороне абонента — с помощью модуля DAA (Direct Access Arrangement).

Сейчас довольно популярны беспроводные DECT-телефоны (Digital European Cordless Telecommunications). По устройству они аналогичны обычным телефонным аппаратам: в них тоже есть FXO-порт и модуль номеронабирателя, но еще добавлен модуль беспроводной связи станции и трубки на частоте 1,9 ГГц.

Абоненты подключаются к PSTN-сети (Public Switched Telephone Network) — телефонной сети общего пользования, она же ТСОП, ТфОП. PSTN-сеть может быть организована с использованием разных технологий: ISDN, оптики, POTS, Ethernet. Частный случай PSTN, когда используется обычная аналоговая/медная линия — POTS (Plain Old Telephone Service) — простая старая телефонная система.

С развитием Интернета телефонная связь перешла на новый уровень. Стационарные телефонные аппараты все реже используются, в основном по служебным нуждам. DECT-телефоны немного удобнее, но ограничены периметром дома. GSM-телефоны еще удобнее, но ограничены пределами страны (роуминг — дело дорогое). А вот для IP-телефонов, они же cофтфоны (SoftPhone), никаких ограничений, кроме доступа к интернету, нет.

Skype — самый известный пример софтфона. Он может много чего, но имеет два важных недостатка: закрытая архитектура и прослушка известно какими органами. Из-за первого нет возможности создать свою телефонную микросеть. А из-за второго — не очень приятно, когда за вами подсматривают, особенно при личных и коммерческих разговорах.

К счастью есть открытые протоколы для создания своих коммуникационных сетей с плюшками — это SIP и H.323. Софтфонов на SIP-протоколе несколько больше чем на H.323, что можно объяснить его сравнительной простотой и гибкостью. Но иногда эта гибкость может вставлять большие палки в колёса. Оба протокола SIP и H.323 используют RTP-протокол для передачи медиаданных.

Рассмотрим базовые принципы протокола SIP, чтобы разобраться, как происходит соединения двух абонентов.

2. Описание связки SIP/SDP/RTP-протоколов

SIP (Session Initiation Protocol) — протокол установления сессии (не только телефонной) — это текстовый протокол поверх UDP. Также есть возможность использовать SIP поверх TCP, но это редкие случаи.

SDP (Session Description Protocol) — протокол согласования типа передаваемых данных (для звука и видео это кодеки и их форматы, для факсов — скорость передачи и коррекция ошибок) и адреса их назначения (IP и порт). Это также текстовый протокол. Параметры SDP передаются в теле SIP-пакетов.

RTP (Real-time Transport Protocol) — протокол передачи аудио/видеоданных. Это бинарный протокол поверх UDP.

Общая структура SIP-пакетов:

Вот пример двух SIP-пакетов для одной частой процедуры — установления вызова:

Слева изображено содержимое пакета SIP INVITE, справа — ответ на него — SIP 200 OK.

Основные поля выделены рамками:

SDP-сообщение состоит из строк, содержащих пары ПОЛЕ=ЗНАЧЕНИЕ. Из основных полей можно отметить:

RTP-пакеты содержат аудио/видеоданные, закодированные в определенном формате. Данный формат указывается в поле PT (payload type). Таблица соответствия значения данного поля конкретному формату приведена в https://en.wikipedia.org/wiki/RTP_audio_video_profile.

Также в RTP-пакетах указывается уникальный SSRC-идентификатор (определяет источник RTP-потока) и метка времени (timestamp, используется для равномерного проигрывания звука или видео).

Пример взаимодействия двух SIP-абонентов через SIP-сервер (Asterisk):

Как только запускается SIP-телефон, первым делом он регистрируется на удаленном сервере (SIP Registar), отправляет ему сообщение SIP REGISTER.

При вызове абонента отправляется сообщение SIP INVITE, в теле которого вложено SDP-сообщение, в котором указываются параметры передачи звука/видео (какие кодеки поддерживаются, на какой IP и порт отправлять звук и др.).

Когда удаленный абонент поднимает трубку, нам приходит сообщение SIP 200 OK также с параметрами SDP, только удаленного абонента. Используя отправленные и полученные SDP-параметры можно устанавливать RTP-сессию передачи звука/видео или T.38-сессию передачи факсов.

Если полученные параметры SDP нас не устроили, или промежуточный SIP-сервер решил не пропускать через себя RTP-трафик, то выполняется процедура повторного согласования SDP, так называемый REINVITE. Кстати, именно из-за этой процедуры у бесплатных SIP-прокси-серверов есть один недостаток — если оба абонента находятся в одной локальной сети, а прокси-сервер находится за NAT’ом, то после перенаправления RTP-трафика ни один из абонентов не будет слышать другого.

После окончания разговора, абонент положивший трубку, отправляет сообщение SIP BYE.

3. Передача информации о нажатых кнопках

Иногда после установления сессии, во время разговора, требуется доступ к дополнительным видам обслуживания (ДВО) — удержание вызова, перевод, голосовая почта и т.п. — которые реагируют на определенные сочетания нажатых кнопок.

Так, в обычной телефонной линии есть два способа набора номера:

Во время разговора импульсный способ неудобен для передачи нажатой кнопки. Так, на передачу «0» требуется приблизительно 1 секунда (10 импульсов по 100 мс: 60 мс — разрыв линии, 40 мс — замыкание линии) плюс 200 мс на паузу между цифрами. К тому же во время импульсного набора будут часто слышны характерные щелчки. Поэтому в обычной телефонии используется только тоновый режим доступа к ДВО.

В VoIP-телефонии информация о нажатых кнопках может передаваться тремя способами:

Передача DTMF внутри аудиоданных(Inband) имеет несколько недостатков — это накладные ресурсы при генерации/встраивании тонов и при их детектировании, ограничения некоторых кодеков, которые могут исказить DTMF-коды, и слабая надежность при передаче (если потеряется часть пакетов, то может произойти детектирование двойного нажатия одной и той же клавиши).

Главное различие между DTMF RFC2833 и SIP INFO: если на SIP-прокси-сервере включена возможность передачи RTP непосредственно между абонентами минуя сам сервер (например, canreinvite=yes в asterisk), то сервер не заметит RFC2833-пакеты, вследствие чего становятся недоступными сервисы ДВО. Передача SIP-пакетов всегда осуществляется через SIP-прокси-серверы, поэтому ДВО всегда будут работать.

4. Передача голоса и факсов

Как уже упоминалось, для передачи медиаданных используются RTP-протокол. В RTP-пакетах всегда указывается формат передаваемых данных (кодек).

Для передачи голоса существует много разнообразных кодеков, с разными соотношениями битрейт/качество/сложность, есть открытые и закрытые. В любом софтфоне обязательно есть поддержка G.711 alaw/ulaw-кодеков, их реализация очень простая, качество звука неплохое, но они требуют пропускной способности в 64 кбит/с. Например, G.729-кодек требует только 8 кбит/с, но очень сильно загружает процессор, к тому же он не бесплатный.

Для передачи факсов обычно используется либо G.711-кодек, либо T.38-протокол. Передача факсов по G.711-кодеку соответствует передаче факса по T.30-протоколу, как будто факс передается по обычной телефонной линии, но при этом аналоговый сигнал с линии оцифровывается по alaw/ulaw-закону. Это также называется передачей факса Inband T.30.

Факсы по T.30-протоколу выполняют согласование своих параметров: скорости передачи, размера дейтаграмм, тип коррекции ошибок. T.38-протокол базируется на протоколе T.30, но в отличие от Inband-передачи, происходит анализ генерируемых и принятых T.30-команд. Таким образом передаются не сырые данные, а распознанные команды управления факсом.

Для передачи команд T.38 используется UDPTL-протокол, это протокол на базе UDP, он используется только для T.38. Для передачи комманд T.38 можно ещё использовать протоколы TCP и RTP, но они используются гораздо реже.

Основные достоинства T.38 — снижение нагрузки на сеть и большая надежность по сравнению с Inband-передачей факса.

Процедура передачи факса в режиме T.38 выглядит следующим образом:

Передавать факсы по интернету желательно в T.38. Если же факс нужно передать внутри офиса или между объектами, имеющими стабильное соединение, то можно использовать передачу факса Inband T.30. При этом перед передачей факса обязательно должна быть отключена процедура эхоподавления, чтобы не вносить дополнительные искажения.

Очень подробно про передачу факсов написано в книге «Fax, Modem, and Text for IP Telephony», авторы — David Hanes и Gonzalo Salgueiro.

5. Цифровая обработка сигналов (ЦОС). Обеспечение качества звука в IP-телефонии, примеры тестирования

С протоколами установления сеанса разговора (SIP/SDP) и методе передачи звука по RTP-каналу мы разобрались. Остался один немаловажный вопрос — качество звука. С одной стороны, качество звука определяется выбранным кодеком. Но с другой, необходимы еще дополнительные процедуры DSP (ЦОС — цифровой обработки сигналов). Данные процедуры учитывают особенности работы VoIP-телефонии: не всегда используется качественная гарнитура, в интернете бывают пропадания пакетов, иногда пакеты приходят неравномерно, пропускная способность сети тоже не резиновая.

Основные процедуры, улучшающие качество звука:

VAD (Voice activity detector) — процедура определения фреймов, которые содержат голос (активный голосовой фрейм) или тишину (неактивный голосовой фрейм). Такое разделение позволяет заметно снизить загрузку сети, поскольку передача информации о тишине требует гораздо меньше данных (достаточно лишь передать уровень шума или вообще ничего не передавать).

Некоторые кодеки уже содержат внутри себя процедуры VAD (GSM, G.729), для других же (G.711, G.722, G.726) нужно их реализовывать.

Если VAD настроен на передачу информации об уровне шума, то передаются специальные SID-пакеты (Silence Insertion Descriptor) в 13м RTP-формате CN (Comfort Noise).

Стоит заметить, что SID-пакеты могут быть отброшены SIP-прокси-серверами, поэтому для проверки желательно настраивать передачу RTP-трафика мимо SIP-серверов.

CNG (сomfort noise generation) — процедура генерации комфортного шума на базе сведений из SID-пакетов. Таким образом, VAD и CNG работают в связке, но CNG-процедура гораздо менее востребована, поскольку заметить работу CNG-можно не всегда, особенно при малой громкости.

PLC (packet loss concealment) — процедура восстановления звукового потока при потере пакетов. Даже при 50% потере пакетов хороший алгоритм PLC позволяет добиться приемлемого качества речи. Искажения, конечно, будут, но слова разобрать можно.

Простейший способ эмуляции потери пакетов (в Linux) — воспользоваться утилитой tc из пакета iproute с модулем netem. Она выполняет шейпинг только исходящего трафика.

Пример запуска эмуляции сети с потерей 50% пакетов:

Jitter buffer — процедура избавления от jitter-эффекта, когда интервал между принятыми пакетами очень сильно меняется, и что в худшем случае ведет к неверному порядку принимаемых пакетов. Также данный эффект приводит к прерываниям речи. Для устранения jitter-эффекта необходимо на принимаемой стороне реализовать буфер пакетов с размером, достаточным для восстановления исходного порядка отправления пакетов с заданным интервалом.

Эмулировать jitter-эффект также можно с помощью утилиты tc (интервал между ожидаемым моментом прихода пакета и фактическим может достигать 500 мс):

LEC (Line Echo Canceller) — процедура устранения локального эха, когда удаленный абонент начинает слышать собственный голос. Ее суть заключается в том, чтобы вычесть из передаваемого сигнала принимаемый сигнал с некоторым коэффициентом.

Эхо может возникать по нескольким причинам:

Выяснить причину (акустическое или электрическое эхо) несложно: абоненту, на чьей стороне создается эхо, необходимо отключить микрофон. Если эхо все равно возникает — значит оно электрическое.

Более подробно о VoIP и процедурах ЦОС написано в книге VoIP Voice and Fax Signal Processing. Предпросмотр доступен на Google Books.

На этом поверхностный теоретический обзор VoIP завершен. Если интересно, то пример практической реализации мини-АТС на реальной аппаратной платформе можно будет рассмотреть в следующей статье.

[!?] Вопросы и комментарии приветствуются. На них будет отвечать автор статьи Дмитрий Валенто, инженер-программист дизайн-центра электроники Promwad.

Источник