I just wanted to explain what 3cx is looking at and reporting here. It isnt the RTP information. That is a given that this will be different as none of us put our soft switches in our PSTN data centers.
3cx is looking at the HOST addresses, specifically the INVITE, FROM, CONTACT (and if used REMOTE PARTY AND P-ASSERTED ID) and is trying to ensure that it is not spoofed so checks that they match the IP that sent the invite. This would indicate someone is possibly spoofing or they could potentially be a firewall/nat mis match and the audio or responses may not go through.
In our case we use DNS SRV records for our sip trunks and have multiple soft switches in multiple data centers all replicating real time. This ensures extremely high availability automatically. So all our header HOSTs have our DNS SRV FQDN information (depending on which main data center it came from). So they will never match the IP we send from as it changes each call depending on the actually soft switch processing this call.
In theory 3cx could do a lookup of this host and check if it matches, but the cost of another lookup outweighs the gains.
So if you have any issues sending responses back then this could be an area to investigate, but if your calls are all going through (which they do in 99% of these cases) then it is just a situation such as ours and is no problem.
