The VIA is used to show the paths that the messaging took along with certain attributes so that the devices in the path know how to communicate with one another as well as keep track of calls - branch (as many could be taking place). So, for instance, if a call originated from your provider the VIA might have their IP as would the Contact Header. When it hits 3CX and gets relayed, then a new VIA is added showing 3CX and the aforementioned attributes which are then relayed to the phone. The VIAs continue to build as the paths are added to get to the desired destination....but each path inserts a CONTACT.
So, in a way, yes, you are correct in that ultimately the VIA IP will be where the messaging will be received, but there are some obstacles that stand in the way.
As you noted, you see a non-routable IP so to get around this, the CONTACT header can be manipulated such that it will show the IP (public) so that the forwarding can be accommodated. This same functionality is also in the SDP headers so that audio streams can find their way to the correct media server and port and the media server may not be the same as the SIP server, so it may very well have a different public IP in the SDP.
So, look at the CONTACT header in the INVITES,
.