Hi Ray,
The "tcp_accept_aliases" should be harmless if there is no "alias" param
received in the incoming requests. If no such parameter is pushed by the
end-devices, there is 0 impact.
And indeed, this has a really ugly side effect for the (CG)NAT'd
devices. But let's give it a try,
Hi Bogdan,
Yes, we have the following enabled in our config:
tcp_accept_aliases=1
I assume this is the culprit then and we are inadvertently sending calls
down the wrong TCP socket here to the wrong user due to this being
enabled? This is quite a nasty setting to have enabled when we are
Hi Ray,
Do you use any TCP aliasing options in your cfg ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 9/2/23 3:17 AM, Ray Jackson wrote:
Hi all,
I'm facing a weird issue which I think is related to broken TCP
Hi, again,
Did this work any time before?
I have force_rport(), fix_nated_register() active and as follows:
if (nat_uac_test("diff-ip-src-contact")) {
if (is_method("REGISTER")) {
fix_nated_register();
setbflag("NAT");
} else {
fix_nated_contact(); <
setflag("NAT");
Hi Ray,
I am interested the solution or comments you receive. I have a similar problem.
I have no voice or oneway voice on one of the clients. But I could work around
it as I am using softphones on iphones as client. My work around was to turn
wifi off on one of the clients, so this client
Hi all,
I'm facing a weird issue which I think is related to broken TCP socket
reuse logic where the wrong client is receiving incoming calls due to
the wrong socket being used for the incoming INVITE.
The scenario is when I have 2 clients registering using TLS behind NAT
at the same Public
