Da ist nichts Magisches dabei. In der Via-Zeile gibt es einen Parameter "rport". Dieser besagt, dass die Empfangsadresse gleich der Senderadresse ist. Für den Empfänger der Nachricht heißt das, dass er seine Rückantwort auf dieses INVITE nicht an die Adresse im Via sendet, sondern dorthin, von wo der Request herkam. Folglich geht die Antwort an die öffentliche IP-Adresse zurück. Zusätzlich muss im Response nachher der Port und die IP-Adresse angegeben werden, an welche Adresse die Response ging.
Das kannst du in RFC 3581 nachlesen.

Responses kommen also normalerweise problemlos zurück durch NAT. Das eigentliche Problem ist dann jedoch RTP. Dafür wird ein eigener UDP-Socket verwendet - und somit beim NAT auch ein anderes Mapping. Den öffentlichen Port dazu bekommt man nicht gesagt. Die Folge sind deshalb meistens "einseitige Sprachverbindungen". Der Teilnehmer hinter NAT hört halt nichts.

Mittels STUN oder UPnP kann man aber auch sowas umgehen - leider nicht immer.

Es gibt jedoch auch Gegenstellen, welche davon ausgehen, dass der andere Teilnehmer auch den gleichen RTP-Port zum Senden und Empfangen nimmt. Deshalb schicken manche die RTP-Pakete auch nicht an die im SDP angegebene Adresse, sondern dorthin, von wo die RTP-Pakete des anderen herkommen. Das ist aber leider nur eine Vermutung, welche jedoch meistens zutrifft

Ich habe mal deine Screenshots von Wireshark gelöscht. Das Bild war einfach zu groß.
In diesem Fall kommt RFC 5626 zum Einsatz. Wenn PhonerLite NAT erkennt (siehe Via-Header im Response), dann versendet PhonerLite STUN-Requests an den SIP-Port der Gegenstelle. Nach Rufaufbau wird auch ein solcher STUN-Request über den RTP-Port an den RTP-Port der Gegenstelle geschickt. In der STUN-Antwort steht dann ja die öffentliche IP-Adresse und Port. Weicht diese Adresse von der bisher verwendeten ab, dann schickt PhonerLite ein Re-INVITE mit den neuen Daten. Kein Hexenwerk. Hauptsache es geht
In deinem Wireshark-Trace wurden die STUN-Paket nicht richtig erkannt, sondern ein "falsches" RTP-Paket.