TCP Handshake and port numbers

No, there's no truth to the other statement. What you're probably mistaking this for is active FTP.

http://slacksite.com/other/ftp.html

First, the basics - a socket is the 4-tuple of (srcip, srcport, dstip, dstport). If any of these values change, it's a different socket. When a given host opens a TCP (or UDP, for that matter) socket its source IP is already known, the source port is selected randomly from the ephemeral range (greater than either 1023 or 1024 - forget which) and the destination IP and port are supplied to the stack by the calling process.

On the server side, a connection is set up and seen coming from the srcip and srcport given and bound to the dstport and dstip. This entry (again - some 4-tuple) is held in the host's connection table which will then allow incoming packets to be associated with the appropriate connection.

TCP handshaking is the process by which the TCP stacks on the respective sides negotiate the parameters for sequence numbers, window sizes and such. By the time this occurs the port numbers have already been determined.

Again - if any of the values in these tuples changes after the initial connection then, by definition, the packets are no longer associated with the original socket.

There are certain circumstances in which other port numbers may be specified by the application in use (i.e. FTP, RPC) but in all cases this calls for the establishment of a separate socket, not the renumbering of an existing one. In the FTP case this would correspond to the initial connection on port 21 (control) from host -> server and then the subsequent connection on port 20 (data) - which, depending on the mode in use, may be set up in either direction. I can't emphasize enough, though, that this constitutes two separate sockets. Referring back to the OSI stack, this would very much be a layer-5 issue.