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
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 tc
Hello,
so practically all registration appear to come from 127.0.0.1:xyz, where
xyz is some port value.
My guess is that the connection to the tcp proxy is cut and the kamailio
tries to open one.
Is the tcp proxy routing traffic to other apps? Why not using another
Kamailio that does bridging fr
Hi Daniel, thanks for quick reply!
e.g.
10.100.1.24 - sip phone
10.100.1.85 - server
- sip phone is configured to register to 10.100.1.85:443
- tcp proxy listen on 443
- when SIP request comes, tcp proxy open connect to Kamailio 127.0.0.1:5061,
and send request there
- tcp proxy does not modify s
Hello,
can you make a diagram of how the tcp proxy is involved in the sip
traffic routing? From where it receives the traffic and where it sends
it? Does it open connections towards kamailio?
Kamailio is using source IP and port at the moment of opening the tcp
connection to identify the tcp conn
Hi folk!
Have a rare issue with tls connections.
Have a server with 100+ active tls connections, that are connected to
separate TCP proxy, that listen on port 443.
TCP proxy send sip traffic to Kamailio via localhost:5061. In this way all
connections in Kamailio are considered from Localhost.
I
