I guess the first question to ask, is whether or not the calls are working or failing? In an earlier post you indicated that the ports were correct and now, apparently not so, but there is not any mention of the impact to actual call activity.
The other post mentioned Yealinks, but one capture is showing a 3CX softphone. Not knowing how provisioned and/or if the provisioning matches that as in the extension settings for the softphone, is an unknown.
Some of other captures also seem to be related to the same extension as that of the softphone, but not enough info to tell.
A couple of things to look out for when using the softphone - the computer going to sleep or the NIC card using power saving features may cause issues with registration.
Also, did you check out anything about the firewall:
https://doc.pfsense.org/index.php/VoIP_Configuration
You will note that pfsense wants source port remapping enabled. I am uncertain how you have yours configured at either end, but you can use the link to learn more about what settings may be best. As you have separate SIP and RTP ports, there should be no need for source port remapping and it would normally be disabled.
I, like the others, suggest that a VPN may be your best bet to avoid the headaches involved in overcoming NAT issues. You will then need to re-provision the phones as if local. Also, if the internet connection is a normally available connection from a local ISP, a VPN does not lessen the hops nor provide any added QoS. In this case the VPN traffic is established over the open internet and the route is dictated by the providers who handle the traffic between the two points. The routing may change at anytime as the dynamics change - congestion, maintenance, outages, etc. QoS may be applied at the router level, but the second it hits the tunnel WAN to WAN, it is again on the open Internet and the providers not only treat the traffic (currently) as peer, but the data within the tunnel is encrypted so they would have no way to read the QoS tags anyway. However, the tagging may be preserved through the tunnel, so the receiving router may still be able to act upon it. No matter the technicalities, you should still examine the benefit of its use. Just be advised that if QoS is to be employed, the routers will not typically react to the tagging until such time as the router senses that the WAN side is becoming congested. So, sometimes, it may be better to simply leave it off and only consider its use if and when issues start to arise.