Much of the information regarding UDP NAT Traversal involves an intermediate server to communicate the public end points to both clients. Is it possible to shortcut this if the public end points are pre-configured for the clients?
Can two clients behind NATs begin sending UDP traffic to each other's public IP:Port to punch a hole? Is the intermediate required for anything other than communicating the public endpoints?
I can't speak with authority (or provide sources), but from what I've gathered in the past month working with STUN and TURN protocols:
Some background
There are many ways for NATs to assign ports (see below). A full cone NAT is a one-to-one mapping so that once the NAT maps a port, any external host can send packets to the private host using the same mapping. However, for example, if the NAT type is symmetric, packets to different external IPs will have different port mappings.
With certain NAT types (eg. full cone), one can use a STUN server to determine the NAT port mapping. This STUN server is a popular example of the intermediate server you mentioned. Some more restrictive NAT types (eg. symmetric) make it impossible to use a STUN server, and direct peer to peer connections are impossible. This is because a STUN server assumes NAT port mappings do not depend on the external IP, but a symmetric NAT assigns different port mappings for different external IPs.
Can we remove the intermediate server?
The specific address translation (how a router maps port numbers) algorithm depends on the specific router (my speculation). Some routers use random port assignments, which makes it impossible for clients to beforehand make connections without an intermediate public server to make this determination (STUN).
In general, no, it is not possible to remove the intermediate server. Unless you have some internal knowledge of how the NAT works (this might depend on the specific model of router), an intermediate server must be used.