Господа, есть вопросик. Есть SIP провайдер, он использует Asterisk. Нам необходимо передавать факсы по T.38, но со слов провайдера для передачи факсов по T.38 необходимо включить Reinvite(что вобщем то звучит логично), но при включенном Reinvite возникает следующая проблема "голосовой" трафик начинает бегать непосредственно между оконечными устройствами с неизвестными IP адресами. А нам необходимо чтобы весь голосовой и сигнальный трафик с наших устройств шел на один ипишник и получался с него же.
Можно ли после Reinvite определить на транспорте что установлено FAX соединение (например для этих соединений использовать определенный диапазон портов).

Это незаконный провайдер. Гоните его в шею. Астериск в России несертифицирован

Опция canreinvite не запрещает Астериску делать реинвайты на T38, она какраз звпрещает пускать трафик напрямую. Digium сам признал что название ее дурацкое, неудачное, и они ее переименовали уже так что в следующем релизе у нее новое имя. (http://www.venturevoip.com/news.php?rssid=2183)

Мораль - canreinvite=no НЕ запрещает работу факса и реинвайт на T38.
А вот t38pt_udptl=no например - запрещает...

Тогда тут неправда написана или чего то непонимаю.

Параметр файла sip.conf: canreinvite

Это параметр для клиентов, которые описаны в файле конфигурации sip.conf, используется для информирования сервера Asterisk о том, что для данного клиента не использовать reinvite процедуру. Запрещение этого метода может потребоваться для корректной работы с некоторым "кривым" аппаратным обеспечением, которое зависает, если у него запрашивают повторный invite, как пример, это ATA 186.

Если инициируется вызов по протоколу SIP, тогда в сообщении INVITE содержиться информация, куда должен отправляться медиапоток. Пользователи или устройства, подключенные к Asterisk, сами по себе являются конечными пунктами этого потока голосовых или видео данных, когда они устанавливают соединение между собой. Когда соединение было подтверждено, сервер Asterisk отправляет еще одно сообщение (re)INVITE, обоим клиентам с информацией, необходимой для того, чтобы медиапотоки, между этими двумя клиентами, шли между ними напрямую.

Если хотя бы для одного из клиента установлен параметр canreinvite=NO, сервер Asterisk никогда не будет производить процедуру re-invite.
Если клиенты используют различные кодеки, Asterisk не производит процедуру re-invite.
Если команда Dial() содержит параметр t или T, Asterisk не производит процедуру re-invite.

'canreinvite=no' блокирует отправку сообщений (re)INVITE, когда соединение уже установлено. Исходя из архивов сообщений рассылок и источника в "Asterisk handbook", точно известно, что Cisco ATA-186 неправильно обрабатывает сообщения (re)INVITE. Также, этот параметр необходим, если клиент и сервер Asterisk находятся по разные стороны маршрутизатора с NAT.

Замечания
параметр reinvite=yes/no неправильный, учтите это, если вы это где-либо встретите в примерах файлов конфигурации. Правильный синтаксис - это canreinvite=yes/no
Соединение медиапотоков, если два устройства находятся по разные стороны NAT, не очень удачная мысль. Особенное, если оба устройства находятся за NAT. Вы можете использовать связку с SER nathelper, с тех пор, как nathelper.so может подменять приватный IP адрес в поле SDP, которое является частью SIP сообщения re-invite.

вы, конечно, ссылку что я дал почитали?

Да почитал, спасибо! Просто когда представители оператора которые работают с Asteriskом уверяют тебя в обратном начинаешь сомневаться во всем.

ну нас знающие люди долгое время уверяли что Земля плоская.

вы попробуйте а потом расскажите как там дела :)

Я бы гнал в шею невежд - советчиков.

Вообще-то это чушь. Можно установить программно-аппаратный комплекс и сдать узел, только нужно постараться.
О претендентах мне рассказывали.

О прецедентах...