Changed the logic for matching a listening TCP/TLS-socket in tcp_reuse_port scenario, now it considers local port as well. With 'tcp_reuse_port' option enabled, the local port is meaningful and helps to differentiate between sockets on the same IP but different ports.

Pre-Submission Checklist

Commit message has the format required by CONTRIBUTING guide
Commits are split per component (core, individual modules, libs, utils, ...)
Each component has a single commit (if not, squash them into one commit)
No commits to README files for modules (changes must be done to docbook files
in doc/ subfolder, the README file is autogenerated)

Type Of Change

Small bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds new functionality)
Breaking change (fix or feature that would change existing functionality)

Checklist:

PR should be backported to stable branches
Tested changes locally
Related to issue #XXXX (replace XXXX with an open issue number)

Description

In our installation Kamailio runs multiple SIP-trunks, including TCP/TLS, which may be bound to the same local IP address but different local ports, and it's crucial for us to know exactly which trunk, i.e. local socket/port, was used to receive a SIP message.
Additionally, the option "tcp_reuse_port" is also enabled in our environment to start outbound connections from the same TCP/TLS ports that we are listening at.

The problem we hit is that identifying a trunk receiving a SIP message by $Rn(Received socket name) $Rp(Received port), which works perfectly fine for UDP trunks, not working for TCP/TLS with "tcp_reuse_port": wrong port and sockname are reported in preudovars.
Investigation showed that it always reports the first listening socket (in the order defined in config file) which matches IP and transport protocol. Port is being ignored here

e.g. if kamailio is listening on:
listen=tcp:192.168.0.11:5060 name "int_tcp_5060"
listen=tcp:192.168.0.11:5062 name "int_tcp_5062"
listen=tcp:192.168.0.11:5063 name "int_tcp_5063"
it will always report $Rn: int_tcp_5060 and $Rp: 5060 for incoming SIP-messages regardless of the actual socket/port being used, even if it's 5062 or 5063
This applies for both TCP and TLS.

Additionally we noticed that the issue happens only in case if an incoming SIP message from remote SBC is coming via the tcp-connection which was initially opened as outbound with well-known ports (rather than via a new incoming tcp-connection with ephemeral src/remote port)

This pointed us to the function core/tcp_main.c:tcp_do_connect() which handles outbound connections.
While opening a new outbound connection to remote SBC, it ignores local/src port while matching it to a listening socket and saves that incorrect info for future use.
This behavior makes sense if tcp_reuse_port is disabled as matching ephemeral port would not give any result.
But with tcp_reuse_port enabled, we need to take the port into consideration as well.

With suggested changes applied we get correct values in $Rn(Received socket name) $Rp(Received port) for inbound messages via all sockets.
Tests with tcp_reuse_port disabled show no change in behavior, as expected.

You can view, comment on, or merge this pull request online at:

https://github.com/kamailio/kamailio/pull/4120

Commit Summary

145aab3 tcp: fix for local TCP/TLS socket matching with 'tcp_reuse_port' enabled

File Changes

(1 file)

M src/core/tcp_main.c (12)

Patch Links:

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.