It sounds like you might be getting TCP and UDP mixed up. TCP is a connection-orientated protocol, easily understood by firewalls and routers, and requires one initiator (client) and one listener (server). If both client and server are behind firewalls or NAT, you cannot punch a hole through without having them both connect to some proxy server (which is not firewalled). The problem with this is that then the proxy would be responsible for relaying all of their traffic.
From your question, it sounds like you are more interested in UDP hole punching, which exploits the fat that UDP is stateless, and not connection-orientated. Therefore most state-tracking firewalls will make a "best guess" about the UDP data flow, and assume that traffic leaving on a given port will receive replies on the same port, and automatically route them back. If, using some out-of-channel means (such as a TCP server which simply passes addresses and not data), both peers can be transmitting data to each other on the same ports, their respective firewalls/NAT routers will open up holes allowing the traffic in.
As for how to do it, it all depends on how you are going to get the IP address of the peers to each other. Once you have it, simply start transmitting UDP packets on an agreed port, and wait for a reply.