Hole punching technique (lobby server/client):

[will probably not work in LAN mode, especially if combined with
 players from the internet]

Non-host perspective:
---------------------
When joining a battle, client should first acquire his udp source port
from the server before sending JOINBATTLE command. Once he has done that
and joined the battle, he should keep sendings some udp packets to server
on regular intervals, just to make sure router doesn't forget about it 
and remove it from translation table (some routers have timeout as short
as 20 seconds, so this should also be the minimum refresh interval). Once
the game actually starts, lobby should stop sending udp packets to server
since OS will not allow it anyway (won't be able to bind same source port
as it will already be binded by spring.exe), also there is no need for it
since spring.exe will keep sending the packets and so keeping the port
open instead of the lobby. Once lobby detects client has return from
the game, it should continue sending the udp packets in order to keep
the "connection" alive. Another thing to note is that lobby doesn't need
to "punch through" like it has to when hosting, since spring.exe will do 
that anyway.
Just before starting the game, server will send you a HOSTPORT command
containing host's public udp source port. Lobby should replace battle's
port with this one as it will have to connect to this port and not the
original one (acquired by BATTLEOPENED command).

Host-perspective:
-----------------
Before sending OPENBATTLE command, host should try to acquire his udp
source port from the server, just to make sure it can acquire it at all
(better to find out it doesn't work before hosting than right before
starting the game). Nevertheless, lobby does not need to keep to refresh 
this port, since it won't be really used to host the game (this is just 
a test to see if it works, not to actually acquire port for hosting).
Each time new client joins the battle, server will send CLIENTPORT command
telling the host about this client's public udp source port. Host should
remember this information as he will have to use it when starting
the game. Right before starting the game, host should try to acquire his
source port again. This time he will actually use this port to host the
game. Upon starting the game, server will notify all clients participating
in his battle about his port using HOSTPORT command. Host does not need
to keep refreshing his connection to keep the port open, as spring.exe
will do that for him. Also, upon returning from the game, he doesn't
need to start refreshing it either (as non-host would have to) since when
he will start a new game, he will have to acquire new source port anyway
(this is mostly because some people could play "single-player" game with bots
before opening the battle to other players and spring.exe would of course 
not keep connection alive in that case, and upon returning from game the 
port would already be timed-out long before. This is why host has to acquire new
port each time it starts a battle).