Asterisk не работают исходящие факсы.
 

Доброго времени суток.
Ситуация следующая:
Провайдер отдает в SIP транке с 711а кодеком несколько номеров, все отлично, все работает, но, какая то магия с исходящими факсами (к слову входящие работают 10 из 10), причем исходящая передача факса с одного номера компании на другой (в пределах этого провайдера) - работает. Как только пытаюсь передать на любой другой городской номер, все, сразу отбой после старта.
Кусок лога:
-- Executing [s@macro-dialout-trunk:22] Dial("SIP/101-00000031", "SIP/sip_trunk/2213550,300,") in new stack
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
-- Called SIP/sip_trunk/2213550
-- SIP/sip_trunk-00000032 is making progress passing it to SIP/101-00000031
-- SIP/sip_trunk-00000032 is making progress passing it to SIP/101-00000031
-- SIP/sip_trunk-00000032 is ringing
-- SIP/sip_trunk-00000032 answered SIP/101-00000031
-- Executing [h@macro-dialout-trunk:1] Macro("SIP/101-00000031", "hangupcall,") in new stack
-- Executing [s@macro-hangupcall:1] GotoIf("SIP/101-00000031", "1?theend") in new stack
-- Goto (macro-hangupcall,s,3)
-- Executing [s@macro-hangupcall:3] Hangup("SIP/101-00000031", "") in new stack
== Spawn extension (macro-hangupcall, s, 3) exited non-zero on 'SIP/101-00000031' in macro 'hangupcall'
== Spawn extension (macro-dialout-trunk, h, 1) exited non-zero on 'SIP/101-00000031'
== Spawn extension (macro-dialout-trunk, s, 22) exited non-zero on 'SIP/101-00000031' in macro 'dialout-trunk'
== Spawn extension (from-internal, 2213550, 6) exited non-zero on 'SIP/101-00000031'
***
И все, больше ничего не происходит.
К слову, факс 2 разные железки (Панас и МФУ Хьюлетовая) подключены к Линксисовскому fxs порту. Провайдер говорит что кодеки нормально согласуются и т.д. типа все должно работать, куда копать хз...
Если у кого либо есть мысли - подскажите.

если память не подводит, еще в 2008 годе наш ip-телефонический человек расковырял баг в линксисах, и именно с факсами, что-то там с синхронизацией хендшейка вроде, линксис косяк признал, но уже 5 лет прошло

Спасибо за наводку, почитаю. Самое обидное что в логе даже на максимальном уровне дебага (то что привел) - пусто, никаких ошибок. Правда есть одна непонятка, при перерегистрации пира консоль кажет следующее:
<------------->
--- (13 headers 0 lines) ---
Sending to 192.168.1.3:5160 (no NAT)
Reliably Transmitting (no NAT) to 192.168.1.3:5160:
OPTIONS sip:101@192.168.1.3:5160 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bK05abb027
Max-Forwards: 70
From: "Unknown" <sip:Unknown@192.168.1.2>;tag=as51ff3587
To: <sip:101@192.168.1.3:5160>
Contact: <sip:Unknown@192.168.1.2:5060>
<вырезано>
Date: Fri, 22 Feb 2013 16:17:48 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0
***
192.168.1.2 - Asterisk
192.168.1.3 - LinkSys
И самое интересное - время, когда это записалось было 19:17, то есть, откуда то появляется UTC 0, хотя и на шлюзе и на астере время синхронизировано и одинаково. В общем меня терзают смутные сомненья, откуда эта разница появилась...

Скорее всего ваш провайдер отдает вызовы на другие городские номера тоже по IP. И вот тот кому он это отдает, когда слышит тоны факса, делает reinvite на T.38. В этот момент связь и рвется.

коли задачу на подзадачи: линксис или пров?

сделай тестовый экстеншн, допустим, 333, и отправляй по звонку на 333 тестовую tiff-ку на заданный номер. Так ты избавишься от железного факса и линксиса из цепи.
ПС СПАшки лично у меня вызывают легкий баттхерт, но и с провами доводилось бадаться,так что может быть все перечисленное и что-нибудь сбоку.

0-KpblcuK > ОфФ: прикололся я с того, что ты кинул , эпизод 4 )
traceroute -m 254 216.81.59.173

для винды видимо
tracert -h 254 216.81.59.173

или на венде не катит, описание от автора: [url]http://beaglenetworks.net/[/url]
и ещё немного тут [url]http://blogerator.ru/page/traceroute-do-2168159173-prikol-shutka-trassirovka-tracert-hop-trejsrout-vkljuchit-telnet-windows[/url]

имена в обратной зоне видимо, как-то сложно замучено, имхо проще просто попробывать подделать ответы :)
и это не серчайте за офф )

Проблема решена, у мну был включен симметричный ртп, что в моем случае и с моим провайдером не нужно было. Оказывается в настройках сип в астере значение нат=нет это значит нат=да но с отключенным режимом симметричного ответа.