Есть TrixBox v2.6.2.3 с уже работающей платой TDM2400P. Есть странность в отправке вызовов через GSM-шлюзы. А таких там стоит несколько штук. Странность заключается в том, что * показывает отправку номера в порт шлюза ( считает длительность разговора и т.п., только самого разговора в принципе не существует), а тулза, которая работает со шлюзом, ничего не показывает на входе, либо показывает часть цифр из набранного номера. Однако, если поставить во входящую линию шлюза обычный телефон в тоновом режиме, то тулза начинает показывать набранный номер , да и сам вызов идет в нужном направлении. Получается, что * не может корректно передать набранный номер?
Эти же самые GSM-шлюзы ранее стояли с Pаnasonic TDM на CO-транковых портах и работали без проблем
Подскажите, pls, где копать, чтоб пофиксить проблему.

диалплан покажите
что вы там и куда набираете.
может быть громкость дтмф подкрутить надо где-нить

Краткое содержание файла extensions_additional.conf:

[outbound-allroutes]
include => outbound-allroutes-custom
include => outrt-007-MTS_050
include => outrt-008-MTS_066
include => outrt-009-MTS_095
include => outrt-010-MTS_099
include => outrt-011-KS_067
include => outrt-012-KS_096
include => outrt-013-KS_097
include => outrt-014-KS_098
include => outrt-015-Life_063
include => outrt-016-Life_093
include => outrt-017-Intercity_other
include => outrt-018-International
exten => foo,1,Noop(bar)

............. Skipped..........

[outrt-016-Life_093]
include => outrt-016-Life_093-custom
exten => _093.,1,Macro(user-callerid,SKIPTTL,)
exten => _093.,n,Set(_NODEST=)
exten => _093.,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _093.,n,Macro(dialout-trunk,3,${EXTEN},,)
exten => _093.,n,Macro(dialout-trunk,2,${EXTEN},,)
exten => _093.,n,Macro(dialout-trunk,4,${EXTEN},,)
exten => _093.,n,Macro(outisbusy,)

; end of [outrt-016-Life_093]

Согласно этому правилу звонок должен перебрать два GSM-шлюза (trunk3 && trunk2), а затем только пробовать SIP-trunk4. По аналогии с этим правилом прописаны остальные GSM-маршруты, которые точно так же не работают.

Собственно - ВСЕ.
Никаких манипуляций руками окромя WEB-интерфейса не делалось. Потому все стандартно.
Где тогда надо поиграть с настройками DTMF-а?

switch:

диалплан покажите
что вы там и куда набираете.
может быть громкость дтмф подкрутить надо где-нить

А можно каким-то образом отдавать в линию цифры из всего номера по одной с задержкой в 0.5-1.0 секунды?
Может, шлюз не успевает принять корректно все цифры от * и потому часть глотает, а так он бы по одной циферке все бы и принял. Что скажете, Гуру?

switch:

диалплан покажите
что вы там и куда набираете.
может быть громкость дтмф подкрутить надо где-нить

Всё это можно сначала визуально прикинуть на глаз, посмотрев в zap monitor во время набора
ztmonitor 1 -v
1) не слабый ли сигнал по уровню?
2) можно даже записать и разложить как сигнал там набирается по одной циферке.

Перебрал диапазон значений для txgain от -15.0 до 15.0.
Визуально набор в шлюзы начал уходить только в случае, когда txgain=15.0.
По крайней мере, параметры TX начали хоть что-то отображать.
При этом имеем картинку в наборе:
набираем 050-313-39-79, а дозваниваемся на 050-392-29-78
Налицо "путаница" цифр. А каким образом можно записать и разложить сигнал поцифирьно, чтбобы узнать наверняка, в каких цифрах проблема?
И, если прблема будет найдена, каким образом ее лучше локализовать?
Можно вообще не для всех каналов в zapata.conf указывать общие txgain && rxgain, а индивидаульно каждому сказать его уровни?

ded:

Всё это можно сначала визуально прикинуть на глаз, посмотрев в zap monitor во время набора
ztmonitor 1 -v
1) не слабый ли сигнал по уровню?
2) можно даже записать и разложить как сигнал там набирается по одной циферке.

txgain=15.0 - это запредельно.
С таким уровнем может быть что угодно, но не то, что нужно.
Моё субъективное, а потому абсолютно неправильное мнение - в платный суппорт.

Ded, а вторую часть вопроса про отслеживание набранных цифирей можете прокомментировать?

ded:

txgain=15.0 - это запредельно.
С таким уровнем может быть что угодно, но не то, что нужно.
Моё субъективное, а потому абсолютно неправильное мнение - в платный суппорт.

Monitor or MixMonitor > tmp.wav file.
Там будут искажения вследствие задранного уровня. Думаю, что Вы не верно освоили команду
ztmonitor 1 -v (тут указан первый порт, а Вы может через 11-й пускали?)
Там ясно прыгают столбики TX & RX.

Ded, понимаю Ваше желание всех загнать в платный суппорт :-)
Но, хочу заметить, что в *NIX-ах работаю не первый десяток лет, потому команду man не пропускаю, а именно с нее начинаю. Естественно, что сначала я говорю man ztmonitor, а уж потом пытаюсь тулзу попользовать. И файлик там создается не .wav, а .raw. Мне смысла работать с первым каналом просто нету, поскольку на нем сидит обычный юзер на внутренней нумерации, а шлюзы включены в FXO-порты, которые начинаются с номера 13. Соответственно, натравливал я монитор на те каналы, с которыми пытался работать. Вопрос в том, как не только выследить искаженные ( задранные) уровни, но и исправить их.
Есть у Вас бесплатный ответ на сей вопрос?

ded:

Monitor or MixMonitor > tmp.wav file.
Там будут искажения вследствие задранного уровня. Думаю, что Вы не верно освоили команду
ztmonitor 1 -v (тут указан первый порт, а Вы может через 11-й пускали?)
Там ясно прыгают столбики TX & RX.