SOLVED DTMF не обнаруживается в IVR
- Thread starter extreen
- Start date
- Status
Вероятно, это проблема с обнаружением тона DTMF. Это может помочь, если я предоставлю небольшую справочную информацию.
В SIP существует три типа передачи DTMF: RFC 2833, Info и Inband. RFC 2833 стал наиболее часто используемым методом, хотя с технической точки зрения RFC2833 был заменен RFC 4733, но его по-прежнему обычно называют RFC 2833.
При использовании RFC 2833 DTMF отправляется в собственном потоке, определяемом типом полезной нагрузки RTP. Номера типов полезной нагрузки RTP 0–95 представляют записи статического типа, их можно найти на сайте iana.org (https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml).
Технически со статическими типами полезной нагрузки вам не нужны атрибуты a=rtpmap и a=fmtp (fmtp просто означает параметр формата) в SDP, потому что мы все знаем, что они из себя представляют. Например, полезная нагрузка RTP типа 8 — это PCMA со скоростью 8000 бит в секунду, поэтому атрибут a=rtpmap:8 PCMA/8000 не требуется (хотя вы всегда найдете его присутствующим).
Поскольку числовое пространство типа полезной нагрузки относительно невелико и не может вместить назначения для всех существующих и будущих кодировок, числа 96–127 выделяются как динамические. На практике это означает, что когда вы указываете один из этих динамических типов полезной нагрузки, вы также должны сказать, что это на самом деле, используя атрибуты в SDP.
Поэтому, когда вы видите 101, вы также видите атрибуты, описывающие, что такое 101. Например:
a = rtpmap:101 telephone-event/8000
Это говорит нам о том, что тип полезной нагрузки 101 — это телефонное событие со скоростью передачи данных 8000 бит в секунду. Телефонное событие может охватывать множество вещей, таких как снятие трубки, снятие трубки и т. д., а не только клавиши DTMF. Когда вы видите атрибут:
a=fmtp:101 0-15
Это говорит нам о том, что события 0-15 будут переноситься в полезной нагрузке, это события с именами DTMF:
Клавиши 0–9 закодированы как события 0–9
Ключ * закодирован как событие 10
Ключ # закодирован как событие 11
Ключи A - D кодируются как события 12 - 15
Метод Info заключается в том, что ключ DTMF передается не в виде аудио или в виде отдельного потока RTP, а в виде сообщения SIP INFO, пример ниже:
Внутриполосный, как следует из его названия, это именно то, что тоны DTMF отправляются в аудиопотоке вызова, в этой ситуации входящий аудиопоток должен постоянно сканироваться и реагировать на любые обнаруженные тоны.
У нас нет контроля над тем, что отправляется из PSTN. Передача DTMF преимущественно соответствует RFC 2833, но в Великобритании мы все еще видим внутриполосную сигнализацию. Внутриполосная сигнализация часто встречается при вызовах со старых аналоговых линий и с некоторых международных маршрутов. В некоторых случаях мы даже увидим сочетание RFC 2833 и Inband в одном вызове.
В тех случаях, когда IVR не реагирует на внутриполосный DTMF, вы можете использовать функцию dp_tools под названием start_dtmf в диалплане, чтобы включить обнаружение внутриполосного DTMF.
https://freeswitch.org/confluence/display/FREESWITCH/mod_dptools:+start_dtmf
Я успешно использовал следующую дополнительную группу условий на входящем маршруте, чтобы начать обнаружение DTMF, если я не вижу никаких признаков RFC 2833 в тексте SDP INVITE.
Я надеюсь, что все имеет смысл.
Adrian.
В SIP существует три типа передачи DTMF: RFC 2833, Info и Inband. RFC 2833 стал наиболее часто используемым методом, хотя с технической точки зрения RFC2833 был заменен RFC 4733, но его по-прежнему обычно называют RFC 2833.
При использовании RFC 2833 DTMF отправляется в собственном потоке, определяемом типом полезной нагрузки RTP. Номера типов полезной нагрузки RTP 0–95 представляют записи статического типа, их можно найти на сайте iana.org (https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml).
Технически со статическими типами полезной нагрузки вам не нужны атрибуты a=rtpmap и a=fmtp (fmtp просто означает параметр формата) в SDP, потому что мы все знаем, что они из себя представляют. Например, полезная нагрузка RTP типа 8 — это PCMA со скоростью 8000 бит в секунду, поэтому атрибут a=rtpmap:8 PCMA/8000 не требуется (хотя вы всегда найдете его присутствующим).
Поскольку числовое пространство типа полезной нагрузки относительно невелико и не может вместить назначения для всех существующих и будущих кодировок, числа 96–127 выделяются как динамические. На практике это означает, что когда вы указываете один из этих динамических типов полезной нагрузки, вы также должны сказать, что это на самом деле, используя атрибуты в SDP.
Поэтому, когда вы видите 101, вы также видите атрибуты, описывающие, что такое 101. Например:
a = rtpmap:101 telephone-event/8000
Это говорит нам о том, что тип полезной нагрузки 101 — это телефонное событие со скоростью передачи данных 8000 бит в секунду. Телефонное событие может охватывать множество вещей, таких как снятие трубки, снятие трубки и т. д., а не только клавиши DTMF. Когда вы видите атрибут:
a=fmtp:101 0-15
Это говорит нам о том, что события 0-15 будут переноситься в полезной нагрузке, это события с именами DTMF:
Клавиши 0–9 закодированы как события 0–9
Ключ * закодирован как событие 10
Ключ # закодирован как событие 11
Ключи A - D кодируются как события 12 - 15
Метод Info заключается в том, что ключ DTMF передается не в виде аудио или в виде отдельного потока RTP, а в виде сообщения SIP INFO, пример ниже:
Code:
INFO sip:0123456789@sbc2-eu-c2.a2es.uk:5061;transport=tls SIP/2.0
From: <sip:alice@a2es.uk>;tag=b5f428a
To: <sip:bob@a2es.uk>;tag=5543
Call-ID: s38764532938@10.11.12.13
CSeq: 3 INFO
Content-Length: 24
Content-Type: application/dtmf-relay
Signal=5
Duration=160Внутриполосный, как следует из его названия, это именно то, что тоны DTMF отправляются в аудиопотоке вызова, в этой ситуации входящий аудиопоток должен постоянно сканироваться и реагировать на любые обнаруженные тоны.
У нас нет контроля над тем, что отправляется из PSTN. Передача DTMF преимущественно соответствует RFC 2833, но в Великобритании мы все еще видим внутриполосную сигнализацию. Внутриполосная сигнализация часто встречается при вызовах со старых аналоговых линий и с некоторых международных маршрутов. В некоторых случаях мы даже увидим сочетание RFC 2833 и Inband в одном вызове.
В тех случаях, когда IVR не реагирует на внутриполосный DTMF, вы можете использовать функцию dp_tools под названием start_dtmf в диалплане, чтобы включить обнаружение внутриполосного DTMF.
https://freeswitch.org/confluence/display/FREESWITCH/mod_dptools:+start_dtmf
Я успешно использовал следующую дополнительную группу условий на входящем маршруте, чтобы начать обнаружение DTMF, если я не вижу никаких признаков RFC 2833 в тексте SDP INVITE.
Code:
<condition field="destination_number" expression="^(0123456789)$"/>
<condition field="${switch_r_sdp}" expression="a=rtpmap:(\d+)\stelephone-event/8000" break="never">
<action application="set" data="sip_h_X-dtmf_rtp_pstn_payload=$1"/>
<anti-action application="set" data="sip_h_X-dtmf_rtp_pstn_payload=None"/>
<anti-action application="start_dtmf" data=""/>Я надеюсь, что все имеет смысл.
Adrian.
- Status