The problem in doing this is that further packets from port 49xxx
wouldn't be recognized as belonging to the same connection. If another
packet was sent to the same destination conntrack would treat it as
a new connection, rewrite the source port number, notice the clash and
drop the packet.
The same problem exists with your current patch, packets from port
5060 to the same destination won't be recognized as belonging to the
connection that sent the REGISTER and thus won't be able to modify the
timeout or unregister.
Basically we would need three-legged connections to handle this
situation correctly. I've actually done some work to move one of
the conntrack tuples to a ct_extend since in most situations
(all except IPv4 NAT and ICMP packets) the tuples are symetrical
and the second one can easily be derived, but I never managed
to finish it - not sure what the problem was anymore, I'll see
if I can still find those patches. With this we could simply
attach a third tuple to a connection.
--
