Daniel-Constantin Mierla-6 wrote
Hello,
so practically all registration appear to come from 127.0.0.1:xyz, where xyz is some port value.
for devices connected to 443, yes it is (kamailio listen 5060/5061, and devices can connect also directly)
My guess is that the connection to the tcp proxy is cut and the kamailio tries to open one.
Did you mean that kamailio could cut it? netstat show both (phone<=>tcpproxy, tcpproxy <=> kamailio) connections are opened. Analysing tcpdump trace - I saw only attempt to open new connection from Kamailio to tcpproxy (this was when kamailio logged "/ no open tcp connection found, opening new one/".
Any other guess what can be the reason of possible connection cut?
Why kamailio could firstly log this: /_tcpconn_find(): tcpconn_find: 0 port 60286 / and after: /tcp_send(): tcp_send: no open tcp connection found/ (I mean why it could be firstly found, and after this it appear no open tcp connection)
Is the tcp proxy routing traffic to other apps? Why not using another Kamailio that does bridging from port 443 to internal kamailio? Should be simple outbound proxy config, using Path for registrations.
Cheers, Daniel
yes, tcp proxy also routes traffic to other apps (used e.g. when client have only 443 opened to the server). Using another kamailio instance - this is the architecture change, and not what we would like to do (current scheme is working on production servers for a long time)
Many thanks for the answers and ideas!
Cheers!
-- View this message in context: http://sip-router.1086192.n5.nabble.com/rare-impossibility-to-send-requests-... Sent from the Users mailing list archive at Nabble.com.