[SR-Users] rare impossibility to send requests to TLS connected peer

[Vasiliy Ganchev]

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-to-TLS-connected-peer-tp144986p145048.html
Sent from the Users mailing list archive at Nabble.com.