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:201@192.168.42.162: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:202@192.168.42.186: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
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
