There is some terminology confusion in chan_pjsip with respect to symmetric RTP, but in the strict sense (RFC 4961) it is what Asterisk normally does, which is to use the port that it sends in the SDP as the source port when sending RTP. I think that is necessary for the next interpretation.
I think chan_pjsip for the same meaning as comedia in chan_sip, which means that it will send RTP to the address and port from which it receives RTP, after a pause for learning. You can’t have a situation where both ends actually need this NAT workaround, as you would get a stalemate, but Asterisk resolves this when the reality is that the other side doesn’t need it by sending according to the SDP until it learns otherwise. I think it may lose a few frames at the start confirming the address details.
Asterisk will open the port before it sends the SDP nominating the port.
The port in the SDP offer (what I think you meant by the INVITE) is never a proposal as to the port that the other side should listen on but only ever a statement of the port that the local side intends to listen to (assuming that things like NAT don’t get in the way).