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

Hi Daniel! Currently I have complete scheme of the issue (and at last time to describe it here): Issue logic (all mentioned functions from tcp_main.c): SIP phone (A-B) connected via TLS, on port 443 to tcp proxy: 192.168.1.24:3487 <--> 192.168.1.85:443 (connect A) 127.0.0.1:64935 <---> 127.0.0.1:5061 (connect B) Kamailio when receives connect, store in function "_tcpconn_add_alias_unsafe" 3 records (A-B), with following keys: hash1.1: (peer_ip, peer_port, 0 ,0) hash1.2: (peer_ip, peer_port, local_addr, 0) hash1.3: (peer_ip, peer_port, local_addr, local_port) In some moment of time, later, there is another connect (other phone), connected via TCP, on port 80 to tcp proxy: 10.100.253.14:42761 <--> 192.168.1.85:80 (connect C) 127.0.0.1:64935 <--> 127.0.0.1:5060 (connect D) for this connection, Kamailio also creates TCP aliases records (C-D), 2 out of 3 are the same as in (A-B) (peer_ip, peer_port, local_addr are the same for 2 connections) hash1.1: == hash2.1 hash1.2: == hash2.2 and only one key for alias record is different: hash1.3: != hash2.1: When phone C-D disconnects, kamailio removes 2 records from aliases table (for A-B, now only hash1.3 left). After this some SIP request has to be sent to phone A-B, Kamailio when make search using function "_tcpconn_find" use as a key (peer_ip, peer_port, local_addr, 0) (Here I wonder, why not (peer_ip, peer_port, local_addr, local_port) used, but making test series, local_port is always 0 ("tcp_addr_hash" called in "_tcpconn_find") And there is no corresponding alias record (it was removed before). I agree, the case is exotic, but it is reproducible in some deployment with kamailio behind "big NAT" (with port reuse as well) and 2 connections from outer world to ports 5060/5061 Digging sources I have not found easy way, how to fix such issue, cos it looks like need global changes... (for us, we avoided problem by switching off port reuse in TCP proxy) If I explained something not clear enough, please point out. Thanks in advance for responses and trying to find out what is wrong! 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.