3CX Broken NAT Rewrite for Subscribe/Notify/Refer over TCP & TLS Transport

[ltctech]

Server: Build 16.0.4.493 Windows

Previous thread describing issue:
https://www.3cx.com/community/threads/3cx-sends-notify-to-local-ip-address.57955/

Essentially unless a phone knows exactly what its external IP and port(s) are then any form of Subscribe (VM, BLF) or Refer (transfer) will fail if TCP transport is used. UDP appears to work? It's maddening when Invites are sent and received correctly along with RTP regardless of Contact headers. However, when a Notify needs to be sent, 3CX blindly follows the Contact header regardless of where the Subscribe or Refer actually came from.

Why is the implementation inconsistent across SIP requests? Are there any future plans to fix this?

 

[JohnS_3CX]

I assume you are referring to a STUN scenario?

 

[ltctech]

The SIP client is on the internet sitting behind a home router. SIP server (3CX) is sitting behind an enterprise router. There is no SBC, ALG, VPN, etc.

STUN is not being used for NAT Traversal.

This issue is reproducible in MicroSIP (soft client based on PJSIP) with default settings. MicroSIP is able to overcome this issue by checking "Allow IP Rewrite" in settings. This setting tells it to sniff its public IP as sent to it by the server in the Register response and use it in the Contact header going forward.

The issue is also reproducible on Polycom VVX 600 running UC 5.9.5.0614 with no workaround. Provisioning is done via a separate custom HTTPS provisioning server. I realize that 3CX considers them "legacy".

The SIP server should be intelligent enough to realize that the Contact header is NATed for Subscribe/Refer and should fall back to the source port/ip of the TCP packet as it already does for Register/Invite. Asterisk at least in its ChanSIP implementation does this.

 

[JohnS_3CX]

The short answer is that you need to use a supported device or make your device appear as local because there are no plans for now to change the way the SIP engine handles this.

Unfortunately the scenario you wish to use is not supported at the moment because the VVX device has no STUN support as it is under the legacy devices like you have noted https://www.3cx.com/sip-phones/polycom-vvx/#h.6chpwcv5ucba