Wrong IP in Contact header on 200 OK in TLS mode

[dig1234]

In V14 when an extension is provisioned as a Remote STUN and using TLS, 3cx sends the local IP in the 200 OK message in the contact header instead of the external FQDN as it should. This causes the phone to send the ACK to the wrong IP and the call drops after 31 seconds.
The other messages (eg 180) correctly use the external FQDN in the contact header.

Can we get this fixed? Thanks!

I've attached screenshots of the 200 packet vs the 180, you can see the 200 has the local IP in of the 3cx in contact field vs the 180 which has the fqdn.

 

[NickD_3CX]

By default, SIP messages are UDP, when you enable TLS however the transport of the SIP messages are changed to TCP, so effectively, with TLS a TCP connection is established with the server.

As with all TCP connections, the receiving party has the ability to respond to the request over the established TCP connection, as opposed to UDP where this is not possible.

The reason why I write the above is to explain that STUN is not used for TLS/TCP connections as the other party can answer over the established TCP connection, so even though the 'contact' field does have the private IP, it is ignored if the connection transport type is TCP or TLS (in the first image you attached you can see transport=TLS).

We are currently working on a revised 'how-to' article on how to setup Secure SIP on 3CX Phone System and the endpoints. It's not quite finished yet, but I will paste a link here once it's done.

 

[dig1234]

Thank you NickD for your response. I understand what you're saying about TLS going over established TCP connection vs UDP which requires STUN/open ports etc. Unfortunately this does not help here. The problem occurs when 3cx sends wrong IP in Contact field of the 200 with SDP, this causes the phone to send the ACK to wrong IP address (local IP instead of FQDN)! The ACK never gets received by 3CX, so call drops at 31 seconds. It may depend on the specific phone if they respect the contact field or ignore it. Either way the contact field should be consistent through the SIP conversation and as you can see in my screenshots it is not.

I can do more testing with captures and screenshots if that's helpful. Thanks!

 

[NickD_3CX]

Could you share what phone make/model is receiving the 200 OK? Also what firmware it is running.

If it is one that is in our supported list I will try and test on my end as well.

 

[dig1234]

The phone is an Aastra 6731i (once upon a time was a recommended model for 3cx hence we have a large deployment of them)

The strange thing for me is that I have a Remote Extension with TLS/SRTP and HTTPS provisioning working flawlessly on our Yealink phones. Which obviously points to the phone.
The odd part is the problem message is coming from 3cx not the phone. I can't figure out what causes 3cx to send the local IP instead of the fqdn in the Contact field of 200 OK.

3CX sends the correct Contact field to the yealink and not to the aastra. I've done extensive capturing and the have verified this behavior. The call setup is almost identical, I have worked out NAT and RTP path etc. I have read thru the binary log viewer and verified that 3cx is sending different Contact field in 200 OK to aastra vs yealink. Everything else works great this is just one catch where 3cx sends wrong Contact in 200 causing phone to send ACK to nowhere.

Please don't advise me that this device is no longer supported. I know that. In the real world we work with what is available to us..

Any help/ideas would be greatly appreciated!