RFC 3261 s18.2.2 specifies the procedure to select a port for sending a response:
- if the request was received over a reliable transport with rport in the Via header the stack correctly sends the response over the same connection
- if the connection has dropped, however, the stack tries to open a new connection to the rport instead of the port advertised by the sender in the Via header
The rport should only be used for unreliable transports (UDP)
TransportSelector.cxx:1115 onwards tries to work out where to send the response (which transport and port to use), maybe it should do a check to see if the connection is still active or not?
the stack checks if the connection has gone away and at this point it tries to use data->destination (including the port number of the original connection from the peer) and doesn't try to revise the port number.
Helper::getPortForReply() appears to correctly decide the preferred port number for those cases where the original connection is still active.