It goes without saying that SIP solutions are impacted by NAT. So much that some scenarios required integration to RFC 3261, e.g. with RFC 3581, which defined the 'rport' attribute to be added in the Via header (integrating the 'received' attribute): with that information, responses could be routed to the source port of the related request, and not on the advertised port in the original Via.
That was called Symmetric Response, and applied to connection-less transports (UDP), while, as mentioned in RFC 6314, it's not necessary when using reliable transports (TCP in most cases): SIP responses can be sent back on the same connection on which the request arrived.
Also from RFC 3261, chapter 18, Transport layer, client behaviour:
"For reliable transports, the response is normally sent on the connection on which the request was received."
"[...] the transport layer MUST also be prepared to receive an incoming connection on the source IP address from which the request was sent and port number in the "sent-by" field."
"If a request is destined to an IP address, port, and transport to which an existing connection is open, it is RECOMMENDED that this connection be used to send the request, but another connection MAY be opened and used."
"The SIP protocol includes the notion of a persistent connection[...], which is a mechanisms to insure thatresponses to a request reuse the existing connection that istypically still available, as well as reusing the existingconnections for other requests sent by the originator of theconnection."
"Unlike TCP, TLS connections can be reused to send requests in the backwards direction since each end can be authenticated when the connection is initially set up."
"The act of reusing a connection needsthe desired property that requests get delivered in the backwardsdirection only if they would have been delivered to the samedestination had connection reuse not been employed."
"[...] Persistent connections do notimply connection reuse."