Дублирование DTMF

[repp.sv]

Добрый день, коллеги. После перехода на нового оператора возник плавающий глюк. При наборе добавочного номера asterisk воспринимает одну цифру как две и соответственно звонок уходит на совершенно другой внутренний номер.

Лог звонка. Внутренний набирали 5194

Код: Выделить всё

[2018-03-22 09:04:05] VERBOSE[2970][C-00001e24] pbx.c: Executing [s@ivr:4] BackGround("SIP/RT-00001e24", "/var/lib/asterisk/sounds/ivr/IVR-1") in new stack
[2018-03-22 09:04:05] VERBOSE[2970][C-00001e24] file.c: <SIP/RT-00001e24> Playing '/var/lib/asterisk/sounds/ivr/IVR-1.gsm' (language 'ru')
[2018-03-22 09:04:09] DTMF[2970][C-00001e24] channel.c: DTMF begin '5' received on SIP/RT-00001e24
[2018-03-22 09:04:09] DTMF[2970][C-00001e24] channel.c: DTMF begin ignored '5' on SIP/RT-00001e24
[2018-03-22 09:04:09] DTMF[2970][C-00001e24] channel.c: DTMF end '5' received on SIP/RT-00001e24, duration 325 ms
[2018-03-22 09:04:09] DTMF[2970][C-00001e24] channel.c: DTMF end passthrough '5' on SIP/RT-00001e24
[2018-03-22 09:04:09] DTMF[2970][C-00001e24] channel.c: DTMF begin '1' received on SIP/RT-00001e24
[2018-03-22 09:04:09] DTMF[2970][C-00001e24] channel.c: DTMF begin ignored '1' on SIP/RT-00001e24
[2018-03-22 09:04:10] DTMF[2970][C-00001e24] channel.c: DTMF end '1' received on SIP/RT-00001e24, duration 495 ms
[2018-03-22 09:04:10] DTMF[2970][C-00001e24] channel.c: DTMF end passthrough '1' on SIP/RT-00001e24
[2018-03-22 09:04:10] DTMF[2970][C-00001e24] channel.c: DTMF end '1' received on SIP/RT-00001e24, duration 495 ms
[2018-03-22 09:04:10] DTMF[2970][C-00001e24] channel.c: DTMF end passthrough '1' on SIP/RT-00001e24
[2018-03-22 09:04:10] DTMF[2970][C-00001e24] channel.c: DTMF begin '9' received on SIP/RT-00001e24
[2018-03-22 09:04:10] DTMF[2970][C-00001e24] channel.c: DTMF begin ignored '9' on SIP/RT-00001e24
[2018-03-22 09:04:11] DTMF[2970][C-00001e24] channel.c: DTMF end '9' received on SIP/RT-00001e24, duration 370 ms
[2018-03-22 09:04:11] DTMF[2970][C-00001e24] channel.c: DTMF end passthrough '9' on SIP/RT-00001e24
[2018-03-22 09:04:11] VERBOSE[2970][C-00001e24] pbx.c: Executing [5119@ivr:1] Dial("SIP/RT-00001e24", "IAX2/DC/5119") in new stack
[2018-03-22 09:04:11] VERBOSE[2970][C-00001e24] app_dial.c: Called IAX2/DC/5119
[2018-03-22 09:04:11] VERBOSE[28053][C-00001e24] chan_iax2.c: Call accepted by 10.10.1.251:4569 (format gsm)
[2018-03-22 09:04:11] VERBOSE[28053][C-00001e24] chan_iax2.c: Format for call is (gsm)
[2018-03-22 09:04:11] VERBOSE[2970][C-00001e24] app_dial.c: IAX2/DC-25793 is ringing
[2018-03-22 09:04:11] VERBOSE[2970][C-00001e24] app_dial.c: IAX2/DC-25793 is ringing
[2018-03-22 09:04:11] DTMF[2970][C-00001e24] channel.c: DTMF begin '4' received on SIP/RT-00001e24
[2018-03-22 09:04:11] DTMF[2970][C-00001e24] channel.c: DTMF begin passthrough '4' on SIP/RT-00001e24
[2018-03-22 09:04:12] DTMF[2970][C-00001e24] channel.c: DTMF end '4' received on SIP/RT-00001e24, duration 530 ms
[2018-03-22 09:04:12] DTMF[2970][C-00001e24] channel.c: DTMF end accepted with begin '4' on SIP/RT-00001e24
[2018-03-22 09:04:12] DTMF[2970][C-00001e24] channel.c: DTMF end passthrough '4' on SIP/RT-00001e24
[2018-03-22 09:04:14] VERBOSE[2970][C-00001e24] chan_iax2.c: Hungup 'IAX2/DC-25793'
[2018-03-22 09:04:14] VERBOSE[2970][C-00001e24] pbx.c: Spawn extension (ivr, 5119, 1) exited non-zero on 'SIP/RT-00001e24'

В sip.conf прописывал все варианты dtmfmode, relaxdtmf = yes тоже прописан, ничего не помогает.
Провайдер говорит, что проблема на нашей стороне. его ответ "Кроме того отмечена проблема, что оборудование клиента отвечает не сразу на входящие Invite. При этом отвечает несколько раз. Повторные Invite в сторону клиента отправляются через 1 сек." При звонках на старого оператора DTMF обрабатывается корректно.
Подскажите куда копать?
Всем заранее спасибо.

[virus_net]

Копать в сторону записи дампа трафика и разбора его в wireshark`е.

[repp.sv]

Сделал tcpdump.
Подскажите если кто знает. При звонке на номер где DTMF отрабатывает нормально Wireshark DTMF пакеты собирает в одну запись http://prntscr.com/jd8fb0,
а с номера где DTMF работает некорректно пакеты с DTMF отображаются по отдельности http://prntscr.com/jd8dp7
Это нормальное поведение?

[virus_net]

https://www.voip-info.org/asterisk-sip-dtmfmode/
оставьте только alaw кодек на этом пире
так же смотреть в sdp секцию инвайт пакета

[repp.sv]

А что в sdp секции инвайт пакета смотреть?
И еще у нас от этого же оператора есть еще один городской номер, если звонить на него то DTMF вроде отрабатывает корректно, а при звонке на номера 8-800 косячит.
Получается что Asterisk обрабатывает звонки от одного оператора, но с разных номеров по разному?

[awsswa]

Я больше скажу - есть больные на голову операторы у которых DTMF со стационарных номеров тип один
с сотовых - другой

PS дом.ру одно время страдал этой фигней. После третьего раза за год когда они сменили тип DTMF они меня уже по голосу узнавали.

[repp.sv]

У нас оператор Ростелеком. Они утверждают что DTMF отдают по rfc2833.
Достучаться до их техподдержки крайне сложно приходится самому все ковырять, но с этой проблемой зашел в тупик.

[ded]

У нас оператор Ростелеком. Они утверждают что DTMF отдают по rfc2833.

Это же проверяется на вашей стороне?
Рассмотрите ответ на инвайт, где SDP (RFC 2327),, и найдите там - правду они утверждают, или врут?

[repp.sv]

Рассмотрите ответ на инвайт, где SDP (RFC 2327),, и найдите там - правду они утверждают, или врут?

Извините. а где конкретно смотреть, что-то я найти не могу.

[ded]

SIP/2.0 200 OK
Via: SIP/2.0/UDP 62.96.232.20:5060;branch=z9hG4bK0279dbe3;received=62.96.232.20
From: " repp.sv" <sip:123@10.96.232.3>;tag=0011215a1e270e57b305b8a3-cc408353
To: <sip:12345678@10.96.232.3>;tag=as144567ce
Call-ID: 0011215a-1e27001b-1b126763-88e5fd13@10.96.232.20
CSeq: 102 INVITE
Server: SomePBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:12345678@10.96.232.3:5060>
Content-Type: application/sdp
Content-Length: 262

v=0
o=root 1678888987 1678888987 IN IP4 10.96.232.3
s=MetPBX 13.13.1
c=IN IP4 10.96.232.3
t=0 0
m=audio 10738 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:150
a=sendrecv

RFC 2327:

a=rtpmap:98 L16/16000/2

The general form of an rtpmap attribute is:

a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
parameters>]

For audio streams, <encoding parameters> may specify the number of
audio channels. This parameter may be omitted if the number of
channels is one provided no additional parameters are needed. For
video streams, no encoding parameters are currently specified.

Additional parameters may be defined in the future, but
codecspecific parameters should not be added. Parameters added to
an rtpmap attribute should only be those required for a session
directory to make the choice of appropriate media too to
participate in a session. Codec-specific parameters should be
added in other attributes.

Up to one rtpmap attribute can be defined for each media format
specified. Thus we might have:

m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2

RTP profiles that specify the use of dynamic payload types must
define the set of valid encoding names and/or a means to register
encoding names if that profile is to be used with SDP.

RFC 2833:

DTMF digits and named telephone events are carried as part of the
audio stream, and MUST use the same sequence number and time-stamp
base as the regular audio channel to simplify the generation of audio
waveforms at a gateway. The default clock frequency is 8,000 Hz, but
the clock frequency can be redefined when assigning the dynamic
payload type.