Wireshark вообще сказал, что нет SIP соединений :) зато доблестный Syslog сообщил много интересностей. Ответ от ТП Eltex:
*******************************************
Ясно судя по логу, происходит следующее:
-мы отдаем INVITE с тегом Supported: 100rel, в этом случае взаимодействующий шлюз по своему усмотрению может передавать предварительные ответы либо надежно, либо нет;
-взаимодействующий шлюз(%SIP_SERVER%) выбирает передавать предварительные ответы надежно, т.к в сообщении 183 присутствует тег Require: 100rel
-получив это сообщение, тау соответственно его подтверждает сообщением PRACK
-на которое затем ругается SIP провайдер сообщением 481 Call Leg/Transaction Does Not Exis
-и затем мы(тау) отбиваем вызов.
Варианты решения:
1) (НЕ РЕКОМЕНДУЕТСЯ)В настройках SIP профиля изменить опцию "100rel" в положение off. Тогда мы не будем передавать в INVITE тег Supported: 100rel и данная цепочка не повториться. Но тогда при поступлении входящего вызова с тегом Supported: 100rel или Require: 100rel
тау будет ругаться сообщением 420.
2)(РЕКОМЕНДУЕТСЯ) Узнайте у вашего SIP провайдера: "почему он сначала передает 183 с Require: 100rel, а затем ругается на наше подтверждение PRACK? ведь он сам говорит, что мол я поддерживаю подтверждение, поэтому тау и передает PRACK."
Если SIP сервер не поддерживает подтверждение предварительных ответов (RFC 3262), то он не должен передавать Require: 100rel в 183 сообщении.
*******************************************
Сделал по первому варианту, все заработало. У провайдера так и не получилось, что-либо выяснить.
Простой
