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, disable this option and try the
testing again, to see if the right conn is selected.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 9/22/23 5:03 AM, Ray Jackson wrote:
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 dealing with CGNAT'd customers who are sharing public IP addresses
but are completely unrelated users!
I will disable this setting and see if that clears up the issue for
us. We have in fact had another case just today of the same issue
happening (User A is receiving User B's incoming calls!)
Thanks for highlighting this and let me know if there is anything else
I should look at in our config.
Thanks,
Ray
On 19/09/23 9:30 pm, Bogdan-Andrei Iancu wrote:
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
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 IPv4 address and both clients are using the
same private port number. So client 1 registers and the Via and
contact header looks like:
Via: SIP/2.0/TLS
192.168.42.162:5062;branch=z9hG4bK1409895926;rport;alias Contact:
<sip:[email protected]:5062;transport=tls>;reg-id=2;+sip.instance="<urn:uuid:00000000-0000-1000-8000-C074AD928AC4>"
Client 2 registers from behind the same Public IPv4 address and the
Via and contact header looks like:
Via: SIP/2.0/TLS 192.168.42.186:5062;branch=z9hG4bK-aff1f3b3
Contact: <sip:[email protected]:5062;transport=tls>;expires=300
The location table shows Client 1 received field of 103.212.1.2:5062
and Client 103.212.1.2:23456
When a call comes in for Client 1 the location lookup seems to
return the correct 'received' address and port (e.g.
103.212.1.2:5062) and all the logs indicate that this is where the
SIP INVITE *should* be going to (in the $du field). However when
you check the SIP traffic it selects Client 2's socket and the
traffic goes to port 23456 instead of 5062.
I think this is related somehow to the TCP port reuse logic inside
Opensips. My suspicion is that Opensips is looking at the Contact
or Via port number (which is the same for both client 1 and 2) and
then somehow mapping this to the wrong TCP received socket.
Does anybody have any suggestions here? Should I be fixing the NAT
in the Contact header (using fix_nated_contact). I read somewhere
that you shouldn't rewrite the Contact header to avoid problems with
sending a different Contact URI to the client on calls. Or is this
issue more related to the Via header and the TCP port reuse logic
looking at this port instead of the actual received port when
choosing the outgoing socket?
FYI: I am using both force_rport() and fix_nated_register() for
incoming registrations from these clients and matching_mode of 0 in
usrloc. However, I am not using fix_nated_contact() for registrations.
Thanks,
Ray
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
