asterisk.ru

Факс, до того как его распознал астериск, что это факс, представляет из себя обычный телефонный звонок, который роутится по вашим настройкам входящей\исходящей маршрутизации.
Модуль поинсталированный вами нужен для того, чтобы принимал\оправлял факсы сам астериск при помощи не хитрых приспособлений, но можно, конечно, и космический корабль на Марс запускать!

Так оно и есть, в логах я вижу, что факс принимается просто как обычный звонок. По логике, для того, чтобы диалплан сработал для факсов, нужно включить faxdetect=both в chan_dahdi.conf, и дописать диаплан. Но в других темах для транзита факсов советуют вообще не трогать faxdetect, что-то не могу однозначно понять, что делать.

Как-то надо всё таки однозначно понять!
faxdetect придуман для автоматического опередения писка факса, чтобы отключать эхоподавление, подавление тишины и комфортный шум (если таковые присутствуют, ибо схем соединений может быть много), и для автоматизировнного приёма факсов средствами Астериска (для последующей отправки по эл. почте например). В последнем случае должен присутствовать экстеншн fax в текущем контексте, который принимает с помощью аппликации App_fax or ReceiveFAX или с помощью IAX modem.
А вот для транзита - дейсвительно, faxdetect не нужно.

Отключил все, что касается эхоподавления и детекции факсов, теперь факсы хотя бы приобрели читаемый вид, но ошибки все равно очень часто появляются, в виде только половины факса, а также сообщений в логах типа:

[Apr 26 11:30:09] VERBOSE[1704] sig_pri.c: -- Span 1: Channel 0/2 got hangup request, cause 111
[Apr 26 11:30:09] VERBOSE[2032] chan_dahdi.c: -- Hungup 'DAHDI/i1/XXXXXX-2b'
[Apr 26 11:30:09] VERBOSE[2032] pbx.c: == Spawn extension (from-ipldk, XXXXXX, 1) exited non-zero on 'DAHDI/i2/YYYYYY-29'
[Apr 26 11:30:09] VERBOSE[2032] chan_dahdi.c: -- Hungup 'DAHDI/i2/YYYYYY-29'
[Apr 26 11:31:23] VERBOSE[1704] sig_pri.c: -- Span 1: Channel 0/7 got hangup request, cause 16

Как можно отловить обмен ответами между факсом и передающей стороной? На форумах видал, что это прям в логах можно смотреть, но set verbose 10 не дает такого, так как факсы для астера теперь просто как звонки.

К тому же, после непродолжительной стабильной работы опять идет рассинхрон с провайдером:

[Apr 26 11:44:37] NOTICE[3314] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1
[Apr 26 11:44:38] NOTICE[3314] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1
[Apr 26 11:44:39] NOTICE[3314] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1
[Apr 26 11:44:40] NOTICE[3314] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1

Для борьбы с этим мой /etc/dahdi/system.conf приобрел вид:

# Span 1: TE2/0/1 "T2XXP (PCI) Card 0 Span 1"
span=1,1,0,ccs,hdb3
# termtype: te
bchan=1-15,17-31
hardhdlc=16
#echocanceller=mg2,1-15,17-31

# Span 2: TE2/0/2 "T2XXP (PCI) Card 0 Span 2"
span=2,0,0,ccs,hdb3
bchan=32-46,48-62
hardhdlc=47
#echocanceller=mg2,32-46,48-62

loadzone = ru
defaultzone = ru

но и это уже не помогает.

Картина такая что некоторый момент времени все идет нормально, потом начинается жуткий рассинхрон.

Теперь это обычный звонок со всеми прелестями.
Вам в явном виде указывается причина завершения: cause 111, например.

мочите оператора на предмет проверки потока анализатором
ставите шлейф со своей стороны они анализируют
процедура занимает обычно 15 минут

Cause-коды почитал, Cause No. 111 - protocol error, unspecified. лично мне ни о чем не говорит, это итак понятно, что ошибки в протоколе.

Vlad1983 писал(а):мочите оператора на предмет проверки потока анализатором
ставите шлейф со своей стороны они анализируют
процедура занимает обычно 15 минут

Нельзя ли поподробнее, что еще за анализатор, и какой мне ставить шлейф и куда

Если, "И так понятно, что ошибки в протоколе", то зачем вы сюда пишите?
И так понятно, что с этим делать.

я не это хотел сказать, а то, что в этом коде ошибок - никакой конкретики.