Всем привет!
Возникла задача доказать возможность сервера asterisk держать 30 факсов по E1 одновременно. Для этого взяли 2 сервера, в каждый воткнули по TE110P, в каждую воткнули по потоку от телекома. Настроили TxFax и RxFax из пакета spandsp. Прием факсов из города чудесный, но вот принять факс от второго астериска не можем. Asterisk'и оба 1.0.9, spandsp на одном pre20, на другом pre21. Логи в следующем посте.

Лог отправляющего asterisk'a:

*CLI>
*CLI>
-- Attempting call on ZAP/g1/069798100 for application TxFax(/var/spool/asterisk/python.tiff|caller|debug) (Retry 1)
> Channel Zap/1-1 was answered.
> Launching TxFax(/var/spool/asterisk/python.tiff|caller|debug) on Zap/1-1
Slow carrier up
Slow carrier down
Slow carrier up
<<< DIS: 80 00 ce f4 80 80 81 80 80 80 18
DIS with final frame tag
In state 10
DIS:
Prefer 256 octet blocks
Can receive fax
Supported data signalling rates: V.27ter and V.29
R8x7.7lines/mm and/or 200x200pels/25.4mm
2D coding
Scan line length: 215mm
Recording length: Unlimited
Receiver's minimum scan line time: 0ms at 3.85 l/mm: T7.7 = T3.85
R8x15.4lines/mm
Minimum scan line time for higher resolutions: T15.4 = T7.7
North American Letter (215.9mm x 279.4mm)
North American Legal (215.9mm x 355.6mm)
DCS:
Can receive fax
Selected data signalling rate: V.29, 9600bps
2D coding
Scan line length: 215mm
Recording length: A4 (297mm)
Minimum scan line time: 20ms
Minimum scan line time for higher resolutions: T15.4 = T7.7
Start sending document
Changed from phase 2 to 4
>>> DCS: 83 00 86 80 80 80 00
HDLC underflow in state 3
Changed from phase 4 to 6
Changed from phase 6 to 3
T4 timeout in state 4


Лог принимающего asterisk'a:

*CLI>
*CLI>
*CLI>
-- Accepting call from '69197773' to '69798100' on channel 0/2, span 1
-- Executing Wait("Zap/2-1", "3") in new stack
-- Executing Answer("Zap/2-1", "") in new stack
-- Executing NVFaxDetect("Zap/2-1", "10|dn") in new stack
Dec 15 19:28:50 NOTICE[12380]: app_nv_faxdetect.c:215 nv_detectfax_exec: Redirecting Zap/2-1 to fax extension
-- Executing RxFAX("Zap/2-1", "/tmp/1.tiff|debug") in new stack
FLOW Changed from phase 1 to 4
FLOW ???:
FLOW Real-time Internet fax (T.38)
FLOW V.8 capable
FLOW Prefer 64 octet blocks
FLOW Reserved: 0x90
FLOW Supported data signalling rates: V.27ter fallback mode
FLOW 2D coding
FLOW Scan line length: 215mm
FLOW Recording length: A4 (297mm)
FLOW Receiver's minimum scan line time: 20ms at 3.85 l/mm: T7.7 = T3.85
FLOW Reserved: 0x1
FLOW Minimum scan line time for higher resolutions: T15.4 = T7.7
FLOW Character mode
FLOW Reserved: 0x10
FLOW >>> DIS: 80 00 ce f4 80 80 81 80 80 80 18
FLOW HDLC underflow in state 9
FLOW Changed from phase 4 to 3
FLOW Slow carrier up
FLOW <<< DCS: 83 00 86 80 80 80 00
FLOW DCS with final frame tag
FLOW In state 9
FLOW ???:
FLOW Prefer 256 octet blocks
FLOW Reserved: 0x80
FLOW Supported data signalling rates: V.27ter fallback mode
FLOW 2D coding
FLOW Scan line length: 215mm
FLOW Recording length: A4 (297mm)
FLOW Receiver's minimum scan line time: 20ms at 3.85 l/mm: T7.7 = T3.85
FLOW Get at 9600bps, modem 1
FLOW Changed from phase 3 to 5
FLOW Fast carrier up
FLOW Fast carrier down
FLOW Fast carrier up
FLOW Fast carrier trained


Это последние сообщения, выдаваемые астериск; после них - ничего. Asterisk работает, все хорошо, каналы висят.
С факсами только начинаем разбираться, прошу помощи у сообщества!

1) Если 30 факсов по E1 одновременно, то нет нужды поднимать Т.38, с ним всё время засада. То есть писали, что в полной мере * не поддерживает Т.38 как факс сервер, а только в режиме прозрачного бриджинга.
Переведу по-русски. 2 сценария: Отправка факсов и Прием факсов. И каждый из двух сценариев может быть в транзитном варианте передающий узел Т.38-Астериск-принимающий узел Т.38 (это и есть бриджинг), и терминирующем/оригинирующем - передающий узел Т.38-Астериск (как виртуальный факс аппарат, способный принять факс). Судя по логам - как раз тот случай. ТЫ ЕЩЁ ОДИН, КТО НЕ СМОГ ЕГО ЗАСТАВИТЬ ПРИНИМАТЬ ПО Т.38!
2) Я поднимал (и работает) Т.38 на версии 1.0.7, он мне на каждый проходящий звонок дает статус t38 disable, если не распознает, что там он есть, а на отправку надо было бы ставить SetVar(__T38=yes).
3) Шпуляй по g711 passthru если Е1, чего химичить? по g711 прекрасно принимает и посылает по почте, мы просто один за другим виртуальные факс-машины нарезаем хоть под каждого юзера. Я дебаг и не включал, принимается не так -
-- Executing RxFAX("Zap/2-1", "/tmp/1.tiff|debug") in new stack
а через macro-faxreceve,

[macro-faxreceive]
exten => s,1,SetVar(FAXFILE=/var/spool/asterisk-fax/${UNIQUEID}.tif)
exten => s,2,DBGet(EMAILADDR=extensionemail/${MACRO_EXTEN})
exten => s,3,rxfax(${FAXFILE})

4) Встречные вопросы: принимались хорошо, а хорошо-ли в город уходили факсы?
5) Отправляющий астериск ни намёка на Т.38 при отправке, почему принимающий астериск говорит, что он Т.38?

С пионерским приветом...

привет, Господа.

2litnimax
а не хотите ли вы поставить задачей Dial-UP соединения с аналоговых модемов ваших внутренних абонентов на модемный пул, находящийся в PSTN (у вас это вроде "телеком")??? ;)

2ded
может вы и тут подскажите - работают ли модемы на g711 в той схеме как я обрисовал ???

спасибо

PS сам бы попробовал да карточки нету :(:(:(
Господа, может кто подскажет где на Украине можно купить потоковые Wildcard от Digium??? Не могу найти ....:(

Ded, ну какой T.38!? Я же факсы по E1 получаю/отправляю.
То, что RxFax/TxFax пишет слова T.38 - вижу, но с чем это есть - не знаю.
Я видел T38-bits в пакете spandsp-0.0.3, но не нашел там RxFax/TxFax, а с теми, что в пакете 0.0.2 он не собрался. Доп. для поддержки T38 я ничего не делал.
Еще раз говорю, прием и отправка факсов идет по E1 линиями.
Запросил помощи у Стива, разработчика spandsp.

Вот его ответ:

This indicates the sending side sent the training (TCF) data, listened for a response and timed out.

HDLC underflow in state 3
Changed from phase 4 to 6
Changed from phase 6 to 3
T4 timeout in state 4

This indicates the receiving side listened for the training (TCF) data, synchronised to the carrier, and got stuck there.

FLOW Changed from phase 3 to 5
FLOW Fast carrier up
FLOW Fast carrier down
FLOW Fast carrier up
FLOW Fast carrier trained
Strange. It looks like the receiving side went wrong. However, there is something else strange in the receiving side. The following received message looks OK:

FLOW >>> DIS: 80 00 ce f4 80 80 81 80 80 80 18


but the decoded version contains rubbish. It looks like the version of spandsp used on the two machines is different. Is that right? If so, can you put spandsp-0.0.2pre21c on both machines and try again?

Steve

Там на самом деле версии pre20 и pre21. Попробую поднять одинаковые версии.

P.S. Кстати, на asterisk-1.2.1 и последнем spandsp астер падает на отправке.

Я болею! Мне кустомеры выпили кров своими факсовыми траблами, поддерживая разные системы мне везде мерещица совместимость-несовместимость т38!

сколько за поддержку t38 в h323 ? :)))