I'm having the exact same issue. May I ask how you solved the problem with $fs?
I have tried with force_send_socket() but haven't been able to resolve it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ka
Yes, I have solved the problem by using $fs.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2033#issuecomment-671864731___
Kamailio (SER
Closed #2033.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2033#event-3642376652___
Kamailio (SER) - Development Mailing List
sr-dev@l
There were couple of enhancements done lately to listening sockets, among them
the ability to associate names, so one can enforce sending socket by name and
record route will also take that in cosideration.
If this issue is still not solved, then open a new item here with data
collected from Ka
The situation with the latest master is worse than it is with 5.2.
My setup is:
```
listen=udp:10.28.80.1:5060
listen=udp:192.168.9.103:5060
listen=tcp:10.28.80.1:5060
listen=tcp:192.168.9.103:5060
```
192.168.0.185 (2600) sends UDP call to Kamalio (192.168.9.103:5060). Ref.
packet 94 in the tcp2.
Thank you for following up.Regarding my server networking configuration. This
is an LXD server where Kamailio and rtpproxy are running on the host and
several containers with Asterisk. The Asterisks are running behind of lxdbr0
NAT. This is an example of server configuration:
```
3: eno1: mtu 1
Back to this one, somehow it got on the side with busy end of summer and autumn
...
I tried to reproduce, but I couldn't get the same result. In my case it worked
fine with the current master branch. I made the following minimal config:
```
#!KAMAILIO
debug=3
children=4
mhomed=1
listen=tcp:1
It also doesn't work.
So, it looks like that the presence of the 'listen' parameters only affects the
Kamailio behavior. According to the LAN traces, when the "listen" parameters
are NOT defined then Kamailio uses an "old" existing TCP connection.
For example:
```
Endpoint sends a REGISTER requ
If you try with `tcp_connection_match=0`, does it work?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2033#issuecomment-523519983___
Ka
I just tried the current master (commit: 4efe19f64d8).
I see that the request is not sent out by Kamailio at all.
tcpdump and syslog: http://updates.xorcom.com/~xorcom/tcp-4efe19f64d8.tar.gz
Ref. OPTIONS request (packet 67 in the tcpdump-4efe19f64d8.cap, line 2869 in
syslog-4efe19f64d8)
The expe
Can you try with latest master branch? There were couple of commits related to
connection match and maybe they help here as well. You have to set a new core
parameter:
```
tcp_connection_match=1
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email direct
Bingo! It works correct once I reversed the 'listen' parameters order as you
suggested:
```
INVITE sip:2601@192.168.0.178:47566;transport=tcp SIP/2.0
Record-Route:
Record-Route:
Via: SIP/2.0/TCP
192.168.9.103;branch=z9hG4bK25a.491f2e3a37e082ce56aae708a46851e9.0;i=3
Via: SIP/2.0/TCP 10.28.80.47:
Now that I see the order of listen and what is in via/record-route -- can you
change the order of listen parameter to IP for leg B first and test to see the
result? Like:
```
listen=tcp:192.168.9.103:5060
listen=tcp:10.28.80.1:5060
```
Like I said on the sr-users, my guess is that the OS finds a
### Description
Kamailio server has two legs that are connected to different networks.
I'm using Kamailio v.5.2.3 and the "enable_double_rr" is implicitly set to "1".
The leg "A" IP address is 10.28.80.1
The leg "B" IP address is 192.168.9.103
The call is initiated from 10.28.80.47
According to t
14 matches
Mail list logo
