dimas, верю , не верю - как у Станиславского ! "Как говорил великий мессир - не забирайтесь высоко....бойтесь мечтать - мечты иногда сбываются !" (к сожалению)

По делу
-- Я найду ту часть лога , где абонент sip звонит абоненту sip. Мотать долго - чуть позже ... надо поискать.

что у вас в качестве сип-терминалов? может быть это они распознавание делают а вовсе не астерис...

dimas, скажу конкретно - эксперимент проводился с dvg-5402S dlink - (не самый приличный шлюз)
умоляю - только не говорите про slmon - это было много раз и ничего- все чисто.

Вот они родимые кусочки....вызов с sip абонента1 ---> sip абонента2

Jan 20 14:48:45 VERBOSE [11559] logger.c: >> [ TYPE: DTMF End (1) SUBCLASS: C (67) ] [SIP/7997-b7c255a0]

Jan 20 14:48:45 VERBOSE [11559] logger.c: << [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/7997-b7c255a0]


14:48:45 VERBOSE [11559] logger.c: >> [ TYPE: DTMF Begin (12) SUBCLASS: C (67) ] [SIP/7997-b7c255a0]
при этом абонент слышит только замирание голоса и никакого тонового сигнала

Могу сказать больше , при звонках на мобильные в некоторых направлениях например +7904... тоже самое -- повторяю при плохом канале связи. При хорошем все отлично.Проблема живет при вызовах -> avaya-h323->asterisk->sip абонент или sip провайдер.

Все что я хочу сказать это то что я уже сказал :) Астериск НЕ делает распознавание DTMF в медиа потоке при SIP звонке. Точнее делает но только если dtmfmode это inband или auto. Что в случае rfc2833 равно НЕ делает.

Если у вас на консоли бегут такие мессаджи при sip-to-sip звонке, то я бы изначально считал что это НЕ Астериск гадит. Снимайте rtp dump и смотрите его - я практически верен что DTMF'ы идут уже от соурс устройства.

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

dimas,проверил еще раз и вот что получается (не очень синхронно конечно)
лог с астериска
Jan 22 10:47:15 VERBOSE [19678] logger.c: >> [ TYPE: DTMF End (1) SUBCLASS: A (65) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:18 VERBOSE [19678] logger.c: << [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:21 VERBOSE [19678] logger.c: >> [ TYPE: DTMF Begin (12) SUBCLASS: 4 (52) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:21 VERBOSE [19678] logger.c: >> [ TYPE: DTMF End (1) SUBCLASS: 4 (52) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:22 VERBOSE [19678] logger.c: << [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:27 VERBOSE [19678] logger.c: << [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:32 VERBOSE [19678] logger.c: << [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:36 VERBOSE [19678] logger.c: >> [ TYPE: DTMF Begin (12) SUBCLASS: 5 (53) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:36 VERBOSE [19678] logger.c: >> [ TYPE: DTMF End (1) SUBCLASS: 5 (53) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:37 VERBOSE [19678] logger.c: << [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:37 VERBOSE [19678] logger.c: >> [ TYPE: DTMF Begin (12) SUBCLASS: 5 (53) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:37 VERBOSE [19678] logger.c: >> [ TYPE: DTMF End (1) SUBCLASS: 5 (53) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:39 VERBOSE [19678] logger.c: >> [ TYPE: DTMF Begin (12) SUBCLASS: 1 (49) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:39 VERBOSE [19678] logger.c: >> [ TYPE: DTMF End (1) SUBCLASS: 1 (49) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:42 VERBOSE [19678] logger.c: << [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:46 VERBOSE [19678] logger.c: >> [ TYPE: DTMF Begin (12) SUBCLASS: A (65) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:46 VERBOSE [19678] logger.c: >> [ TYPE: DTMF End (1) SUBCLASS: A (65) ] [H323/ip$10.1.99.3:12222/17541]


Jan 22 10:47:47 VERBOSE [19678] logger.c: << [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [H323/ip$10.1.99.3:12222/17541]


лог полученный при помощи slmon во время разговора

0:46:45 [080794] 0: 7067=ACCEPT
10:46:45 [080794] 0: ==13:VoipAnswering
10:46:45 [080794] 0: 7067=CONNECTED
10:46:45 [080794] 0: RtpApiTalk[1,1], Peer=10.1.99.7:10936, PT=8, FC=2,
NewOOB=1
10:46:45 [080795] 0: ==14:Talking
10:47:11 [081058] 0: Get(A)
10:47:21 [081154] 0: Get(5)
10:47:21 [081157] 0: Get(4)
10:47:39 [081342] 0: Get(1)
10:47:47 [081423] 0: 7067=DISCONNECT
10:47:48 [081423] 0: Release Active Dlg
10:47:48 [081423] 0: ==15:PlayBusyTone
10:47:49 [081439] 0: Fxs Hangup
10:47:49 [081439] 0: ==3:Idle
10:47:49 [081439] 0: SetFax(0)=0

==========================
Момент , где происходит воспроизведение
тоновых - помех
10:47:11 [081058] 0: Get(A)
10:47:21 [081154] 0: Get(5)
10:47:21 [081157] 0: Get(4)
10:47:39 [081342] 0: Get(1)
==================================
Странно что dlink пишет Get !
В чем я точно не прав, так это то "что в slmon все чисто"

я пошел дальше и проделал еще один эксперимент.
сделал вызов от абонента avaya --> абоненту sip и посмотрел на астериск и на slmon, уже на хорошем канале.
Стал нажимать клавиши на телефонах попеременно , смотрю в slmon
никаких Get(A) или что то подобное не увидел, а asterisk показывал -какие клавиши я нажимал....

Вот откуда шлюз это Get берет -- для меня загадка ..!

погодите.
вы говорите что проблема есть и в случае SIP-to-SIP звонке. Я предлагал сфокусироваться только на них.
в том что вы приводите там явно H323. Мы на разных языках разговариваем?

dimas, да есть, но видно только в отладчике,а тонов-помех не слышно.За кем гоняться то ? Такие эксперименты -дело тяжелое. Посмотрите чуть выше , там тоже самое в отладчике, только с sip. Какая разница ? Так свихнуться можно, а это в мои планы никак не входит. Вот почему на dlink шлюзе
10:47:11 [081058] 0: Get(A)
10:47:21 [081154] 0: Get(5)
10:47:21 [081157] 0: Get(4)
10:47:39 [081342] 0: Get(1)
появляется - это вопрос . И что является источником этой гадости. Добиться такого простым нажатием клавишь мне не удалось - подтверждает то , что при rfc2833 тоны идут отдельно.
Если шлюз, что вероятно..., то где он это взял?

Как это "зачем гоняться"? Потому что за SIP-to-SIP я отвечаю что там астерис не виноват. А что там драйвер h323 в астериске делает я без понятия.

что значит "видно только в отладчике"? отладчик для меня это gdb например. Но я сомневаюсь что вы под ним Астериск запускаете. Если для вас этот термин значит что-то другое то имеет смысл пояснить.

логи длинка мне ничего не говорят - я их читать не умеею. я не знаю что значит Get(X) - это он с линии распознал или по сети получил. Так что для начала я бы это проверил - со стороны астериска нажимал бы 123 а с другой стороны - 456 и смотрел бы как это отразится в его логе.