На сколько я понял из всего выше сказанного, что PAP2T стоит где то не в локальной сети явно (NAT присутствует потому что). Как таковой NAT думаю ну никак не влияет на прохождение факсов, а вот качество канала влияет ибо PAP2T не поддерживает T.38. Значит шлём в войс режиме... А тут потеря покетиков возможна...

P. S. Кто мне уточнит, а если уменя шлюз udptl=yes и поддерживает T.3. Ну скажем SPA2102 и поток E1. Факс как будет идти до * и наоборот если идёт приём факса, как оно всё будет?

Решил проблему следующим образом - провел аналоговую линию под отправку факсов =)

Подозреваю что был включен echo canceller на ZAP канале.

Дак оно ж по CED/CNG кэнселер выключает, проблем с этим (по крайней мере на Zaptel) не было. Голосую за кодеки на оконечке, куда был воткнут факсЪ :)

baho_76:

P. S. Кто мне уточнит, а если уменя шлюз udptl=yes и поддерживает T.3. Ну скажем SPA2102 и поток E1. Факс как будет идти до * и наоборот если идёт приём факса, как оно всё будет?

Как голос. Если шлюз не заупрямится о того, что астериск его отобьет с 488 not acceptable here. Для того чтоб было t.38 есть app_faxgateway, но оно пока слабо работоспособно

Дык вот у меня в жизни не получилось отправить факс когда одна из сторно udptl=no и шлюз не поддерживающий T.38, а с другой стороны udptl=yes и T.38 включен на шлюзе. Ходят факсы при таком раскладе только в одну сторону (уже не помню в какую). В целом выве для себя, что либо ВСЁ T.38 либо НИЧЕГО.
Так они и жили...

Да ну? Что-то я такого не замечал. Сталкивался с такой проблемой - лечилась она именно отключением echo canceller'а (echocancel=no)