Проблемы c FAX

[ded]

Для реинвайта Т38 нужно чтобы
Т38 поддерживался устройством SIP/fxo1
был там объявлен (к примеру: все Cisco & Addpac шлюзы поддерживают Т38, но чтобы он работал нужно объявлять на диал пире
fax protocol t38 fallback g711alaw passthru - то есть принимать/отправлять по Т38, а если не получается - по 711)
t38pt_udptl=yes на SIP/fxo1 или в секции [global] sip.conf

[drTr0jan]

Напомню свою схему:
Астер через SIP-шлюз fxo1 звонит на удалённый факс; генерирует сообщение (SendFAX), по T.38 отдаёт его шлюзу; шлюз отправляет его по T.30 через PSTN удалённому факсу. Схема не работает - затык на T.38 negotiation.
Этот же шлюз прекрасно получает факсы с входящего звонка с PSTN и отправляет их через T.38 в Астер. Тут всё работает.

А зачем Вам t38pt_udptl=yes если всё равно уходит по g711alaw passthru?

Вообще, сегодня убедился, что по G.711 всё ходит прекрасно. Может так и оставлю.
Но почему-то посчитал, что T.38 кошерней будет (он ведь именно для этого предназначен). Да и возможно, моя ситуация поможет кому-нибудь решить аналогичную проблему. Больше преимуществ в T.38 для себя не нашёл.

Для реинвайта Т38 нужно чтобы
Т38 поддерживался устройством SIP/fxo1
был там объявлен (к примеру: все Cisco & Addpac шлюзы поддерживают Т38, но чтобы он работал нужно объявлять на диал пире
fax protocol t38 fallback g711alaw passthru - то есть принимать/отправлять по Т38, а если не получается - по 711)
t38pt_udptl=yes на SIP/fxo1 или в секции [global] sip.conf

T.38 по паспорту поддерживается железякой. D-Link DVG-4022S (прошивка от NSGate NS-3702) - довольная мерзкая, но всё, что нужно, кроме Т.38, я настроил.
t38pt_udptl=yes в sip.conf прописан. К тому же факсы успешно принимаются (ReceiveFax) по T.38.
Ковырялся сегодня в обмене пакетов SIP. И зашёл в тупик. Кто в моём случае должен инициировать re-INVITE?
Судя по картинке с Cisco Fax Services over IP Application Guide, re-INVITE в сторону Астера должен инициировать мой шлюз после получения CED и DIS?


В SIP Real-time Fax Call Flow Examples And Best Current Practices - 5.3 тоже говорится, что re-INVITE должен инициировать шлюз.

[ded]

По-моему наоборот, при исходящем (от Астериска) факсе послединий (т е *) должен инициировать re-invite T38 на шлюз после получения CED и DIS

Попробуйте снять tcpdump -s 1500 host <IP_ADDR_FXO_GATE> -w dump.pcap
и разложить его в Wireshark - Telephony - SIP call analyze

Но почему-то посчитал, что T.38 кошерней будет (он ведь именно для этого предназначен).

Т.38 предназначен для факсообмена, если нет локального FXO шлюза, например - всё общение через далёкого SIP провайдера по публичным сетям, где критична толщина канала, где, возможно, подсчёт мегабайтов трафика, может быть процент потерь пакетов. Т.38 помогает в этом.
Для локальной сети, гда ни полоса, ни потери (которые в основном то 0%) - нет нужды. Имеет плавники и чешую. То есть кошерно.
Аминь!

[drTr0jan]

Попробуйте снять tcpdump -s 1500 host <IP_ADDR_FXO_GATE> -w dump.pcap
и разложить его в Wireshark - Telephony - SIP call analyze

Разложил - особо ничего интересного. Удалённый факс пискнул (где-то в районе 11.5 s), Т.38 шлюза его перехватил (если T.38 на шлюзе отключаю, то писк продолжается). После этого Астер начинает слать приглашение факса в G.711.
Сам дамп прилкладываю к посту.

Для локальной сети, гда ни полоса, ни потери (которые в основном то 0%) - нет нужды. Имеет плавники и чешую. То есть кошерно.

Тоже верно.

[ded]

Мне не интересно смотреть дамп, поймите правильно, это Вам должно быть интересно. Это всё равно что в поликлинику принести анализы без направления, в лабораторию - "Посмотрите - вот собрал мочу с утра натощак и кал!"
Я почти каждый день смотрю на мочу и кал.

[drTr0jan]

ded
Прекрасно вас понимаю. Выложил, для тех, кто с подобным столкнётся. Просто с этим re-INVITE уже голову сломал. Нет его там, и ничего на него похожего там тоже нет.
Всё равно огромное вам спасибо за те мысли, которыми поделились.