Just because there is no good answer I wanted to chime in.
One way to do this would be to add an IP option which specifies the port extension. The option must be designed to fit within the optional portion of the IP header and would be skipped by unknown hops.
You would use this option and it's information information to extend the source, destination or both port numbers.
The limitations are not going to automatically work in existing software just by adding the option anyway, they will have to be rewritten to take advantage of the option no matter how it's implemented, existing software and firewalls will either ignore the packet or process it as usual using the value in the source and destination port fields.
In short it is not easy to do and would be better done using a single reusable listener and data contained in the payload of the packet.
You can also more easily allow port reuse in the software, which can help to overcome this limitation by reusing ports of the server for multiple client connections.
Rtsp for example can use the SessionId header in conjunction with various other headers in the payload of the IP packet to determine what connection the request was issued for and act accordingly e.g. if the socket from which the message was delivered is not the same as the socket's remote address to which the session corresponds then then one can either allow a session to be updated with the new socket for processing, deny the message or a variety of other actions depending on the application.
An Http server can also do this or any other type of server.
The key thing to remember when allowing reuse of ports is that you must also take into account the source IP address.