Разрывы т38 при SIP->E1

[Ferrum]

Пытаюсь послать факс с устройства (Panasonic KX-FT21) подключенное к VoIP шлюзу
(AddPac AP-200) далее по SIP T38 на Asterisk 10.4 на котором стоит плата потока
Parabel Quasar-M.
Передача прерывается на 80% листа А4.
Притом работу T38 можно увидеть командой udptl set debug on
(видна передача пакетов)
Проблема в том что на 80% переданного листа, пакеты перестают идти и через 2 секунды удаленный факс (на который посылаем сообщение) завершает соединение.
При передаче я использую spandsp
sip.conf

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

t38pt_udptl=yes
faxdetect=t38

extensions.conf

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

exten => _X.,1,NoOp()
exten => _X.,n,Set(FAXOPT(gateway)=yes)
exten => _X.,n,Dial(DAHDI/g1/${EXTEN},60)

P.S. использовал шлюзы различных производителей со всеми аналогичная проблема.
Если отключить t38 и слать факс по G711 все великолепно проходит.

[ded]

Вам надо дебажить pri debug на порту Е1 платы потока Parabel Quasar-M а не VoIP плечо Т38.
Отключать например эхоподавление на нём, ибо это и вредит передаче факса в первую очередь.

http://asterisk.ru/knowledgebase/foip

[Ferrum]

Вам надо дебажить pri debug на порту Е1 платы потока Parabel Quasar-M а не VoIP плечо Т38.
Отключать например эхоподавление на нём, ибо это и вредит передаче факса в первую очередь.

http://asterisk.ru/knowledgebase/foip

Да но есть еще одна проблема, пытаюсь слать факсы по такой системе
(Panasonic KX-FT21) подключенное к VoIP шлюзу
(AddPac AP-200) далее по SIP G711 на Asterisk 10.4 на котором настроен SIP транк T38, с организацией у которой стоит АТС на стороннем железе с поддержкой Т38 и повторяется эта-же проблема, пакеты udptl debug на 80% перестают бежать и через 2 секунды от них приходит завершение вызова что хорошо видно в sip debug.
Притом тех-персонал той организации заверяет что T38 у них работает идеально.
P.S. в 10% случаев факсы проходят нормально как по E1, так и в данной ситуации.

[ded]

пакеты udptl - это транспорт. Смотрите на дебаг Т30 сообщений,там факсы переговариваются, может что-то разумное промелькнёт на 80%?

[ys1797]

Пытаюсь послать факс с устройства (Panasonic KX-FT21) подключенное к VoIP шлюзу
(AddPac AP-200) далее по SIP T38 на Asterisk 10.4 на котором стоит плата потока
Передача прерывается на 80% листа А4.
Притом работу T38 можно увидеть командой udptl set debug on
(видна передача пакетов)
sip.conf

Что происходит на приемной стороне? Факс "выползает"?
ECM включен/выключен?
Помимо передачи надо смотреть еще T38/T30 дебаг, он обычно живет в full логе.

Если отключить t38 и слать факс по G711 все великолепно проходит.

В связке SIP ->E1 это самый лудший вариант. Если толщина IP канала позволяет использовать 711, то зачем все эти бубны с T30/t38?
В звуковом канале E1 по сути ходит тот-же 711 кодек, т.е. в данном случае шлюз преобразовал пищания факса в 711 и дальше с минимальными преобразованиями все это "уезжает" в поток E1.

[Ferrum]

Что происходит на приемной стороне? Факс "выползает"?
ECM включен/выключен?
Помимо передачи надо смотреть еще T38/T30 дебаг, он обычно живет в full логе.

Да выползает на 80 процентов и разрывает связь
ECM включен
NAT - нет.
Как правильно смотреть T38/T30 дебаг ? я в logger.conf

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

full => notice,warning,error,debug,verbose,dtmf,fax

добавил но все равно ничего связанное с факсами мне в файл не сыпет.

[Ferrum]

Еще ошибка возникает при отправки факса в самом начале, сори сразу не написал

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

[2012-06-13 13:11:38] ERROR[4433]: astobj2.c:110 INTERNAL_OBJ: user_data is NULL

Так-же

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

core set debug 9

Выявило такую ошибку.

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

UDPTL (SIP/888-0000e35e): packet from 192.168.1.150:23014 (seq 581, len 58)
[2012-06-13 12:53:05] DEBUG[3893]: res_rtp_asterisk.c:1323 ast_rtp_write: No remote address on RTP instance '0x402ba88' so dropping frame
[2012-06-13 12:53:05] DEBUG[3893]: res_rtp_asterisk.c:1323 ast_rtp_write: No remote address on RTP instance '0x402ba88' so dropping frame


[ys1797]

Да выползает на 80 процентов и разрывает связь
ECM включен

Оо. Добро пожаловать в клуб пожирателей кактусов в режиме с включенным ECM.
Возможно кол-во повторных попыток отправить "неправильные линии" документа превысило лимит и сессия закончилась.
Тут стопудов надо курить логи.

[Ferrum]

Подскажите как эти логи корректно снимать, в стандартных дебагах минимум информации про факс.