What's so hard about p2p Hole Punching?
One problem is that the NAT mappings in Alice's NAT server will time out, either after a fixed time, or after a period of inactivity.
A second potential problem is that the NAT server could make the restriction that Alice's NAT mapping is only "good" for TCP connections established by Alice, or connections between Alice and the initial IP "she" connected to. (In other words, direct communication between Alice & Bob may be blocked.)
And so on.
The problem is that the behaviour of a NAT server is highly dependent on how the managing organization's configuration / policy decisions. Many of these decisions could mean that your particular P2P usage pattern won't work reliably ... or at all.
So then is my whole idea about hole punching wrong?
No. It just means that it won't always work.
Possibly the biggest problem in NAT holepunching is lack of port consistency. For your implementation to work, at least one of the two NATs must support it.
Port consistency is where the same (local ip, local port) is mapped to the same (external ip, external port) regardless of the target (destination ip, destination port). Without this, the port seen by the directory server is not helpful to the client since it will not be the same port the clients will need to talk to each other.
(Note that this is a weaker requirement than port preservation, where external port == local port.)
Unfortunately for P2P communication, most NATs are some flavor of Symmetric NAT and do not have consistent port mappings.
Firewalls are typically stateful. Bob (2) establishing communications with the outside directory server sets up a rule in his NAT server that allows Bob and the directory server to communicate. When the NAT server sees packets from Alice, it rejects/drops them because it hasn't seen Bob establish communications with Alice.