Establish connection when no peer allows connect

I wondered how P2P programs can connect two peers.
Given are two peers, A and B, which are both located behind firewalls which expose no open ports and allow for no TCP-SYN packet to pass through. Both peers connect to a hub server, which subsequently connects both peers' sockets to each other. Now A and B are connected over a socket; the connection doesn't involve the hub server any more.
How is this done? Does it have a name?
Thanks for helping,
Dennis

Do you have a particular protocol in mind? The scenario as you describe it is not the case in the clients I've used. ZoneAlarm firewall will prevent Kazza/FastTrack from working properly, so there's some connectivity in play there. The Azureus BitTorrent client will report errors if one does not open ports in one's firewall (in the 6990-6999 range, IIRC), so there's definately some "server" functionality on that client/protocol.
If you have a particular protocol in mind, you could look at the documentation (if it is indeed documented, FastTrack is closed for the most part) and look at how it negotiates connections.
I am not an expert, just a user in this subject matter.
Good starting point: Wikipedia: Peer to Peer.

I've noticed that this works with Soulseek (slsknet.org), eMule, and maybe others. My firewall is in full stealth mode, allowing no TCP-SYN packets to come in.
My friend's configuration is the same, but we're still able to communicate with each other directly. Netstat on my machine shows my friend's IP address and labels it "ESTABLISHED". He sees my IP in his netstat list.

I admit I'm lazy - I could go through the code of emule etc., but I'm just curious and thought maybe it rings someone's bell; if someone knows a name for this technique I would already be happy.

That's pretty clever ... everyone is a client, nobody is a server.

Now A and B are connected over a socket; the connection doesn't involve the hub server any more.

I can't think of any way to make that happen, tho. Wouldn't traffic still go through the 3rd party server for a quick echo to the other partner?

Maybe it's some friendly sort of IP spoofing. The hub server manipulates one client's IP packets once both have connected to the hub, like this:
1. client A and B both establish a TCP connection to the hub
2. the hub changes the first subsequent packet coming in from client A so that the destination IP is now B's IP. Then it sends the manipulated packet to B
3. B will acknowledge, but this time to A, because that's where it thinks the incoming packet came from
4. A and B now communicate directly

Seems to work so far, but it means both the IP and TCP stack on the hub machine need to be changed to expose the behaviour described above. However, I'm afraid there would be problems with the TCP sequence numbers - A and B determine the initial sequence numbers because they initiate the connection. Or am I wrong, and it works because the hub knows both peers' connections sequence numbers?

This is all wildly guessed. Maybe it works in a completely different way. All further hints appreciated!