Solution to UDP Through Nats/Firewalls

Question

Hello to All,
I am currently developing software that entails the need to have live voice transmission to several clients. All of the audio comes into the server and is redirected out to the appropriate clients. I'm sure that by now many of you are aware of the issues inherent in using JMF, or more specifically UDP, across the internet : NAT routers don't deal with UDP packets very well and the clients behind them tend not to receive them. For my application I can't expect every client that is behind a NAT router to set up port forwarding to their machine; these are people who don't know how to unzip a file. Simplicity is of vital importance especially when trying to reduce the need for support calls.
After reading up on the different kinds of NAT' s and how they respond to incoming UDP packets I discovered a way that works. To start with the server needs to be publicly acessible, or it must appear to be. If the server is behind a NAT then port forwarding must be set up (no big deal). Let us say that the server is sending out audio on port S1 with control port S2 and the client wishes to receive the audio on port C1 with control port C2. The client, upon logging in, must send a UDP packet from local port C1 to server port S1 and from local port C2 to server port S2.
The server must accept these handshaking UDP packets and store the address and port that they come from. The client ports might not be C1 and C2 by the time they reach the server because the NAT router may have changed them. Indeed, they may not even be consecutive ports by the time they reach the server, it's all dependant on how the client's NAT chooses to map them.
The server, by examing the initial handshake, knows exactly where to send the RTP data for that client. Now when RTP data reaches the clients network it will be properly forwarded to the client since the network has already sent out a packet from those ports to those locations and thus a mapping has been established. If the clients ports are not consecutive ports by the time they are mapped and reach the server then the SessionAddress which typically sends out data on the port provided and the next consecutive one, does have a constructor where you can specify both the data and control port to be specific, non-consecutive ports.
By sending this initial handshake any NAT, even the most restricitve symmetric NAT, will now correctly foward any incoming UDP packets from server ports S1 and S2 from the same server as long as they are coming in to the client ports that initially sent out the handshake. One thing to keep in mind however is that the mappings aren't permanent, in fact they are very short lived (I learned the hard way after about 1 week of debugging). The way that I had my program setup before was that I had all of the UDP handshaking upon a client's connection, often minutes before the actual UDP audio transmission from the server would begin. This would cause many of the mappings to be lost since it had been minutes after the mapping had been established with no data coming through. I had to fix this by not implementing the handshake with the clients until right before the UDP audio transmission had begun in order to ensure fresh, working mappings for the beginning of the transmission.
Now you may be wondering how the server can be listening for handshakes on the same port that it is supposed to be sending out audio on. Well in my case no audio is transmitted until all of the expected clients have connected. If this was not desirable, if one wanted to allow clients to join after RTP data has already started transmitting then the handshake would need to be accepted on a different port than the one's that are transmitting RTP data. The tradeoff associated with this, however, is that clients that are behind symettric NAT's won't be able to receive audio, since the handshake must go to the exact server port that they wish to receive RTP data from; all of the other kinds of NAT's will allow this however.
The way I handle somebody who shows up late, after UDP audio transmission has already begun, is I stop the audio transmission for everybody, shake hands with the new client on the audio ports and then re-initialize the audio transmission. This is not ideal as there is now a break in the audio streaming everytime somebody shows up late. I'm wondering how other programs, like Scype, accomplish such seamless audio integration with UDP; the only way I can get consistency across networks is to implement these obscure workarounds that incur breaks in transmission when a new client joins and wishes to receive a UDP stream that has already started.
I know this post is long but I would have loved to have access to some of this information a couple of months ago; a lot of it was learned through painful trial and error so hopefully it's useful to someone. I'd love to have some input on ways to make things better or more reliable: particularily the aspect of clients showing up late and having the server temporarily stop the audio in order to establish a secure mapping towards the new client. On the bright side using the methods described above I can get consistent UDP audio transmission to and from all kinds of networks, including the most restrictive symettric NAT's that I have tested so far. Any questions/comment/ideas are welcome.

Answer 1

I was bored with you long overview of the issue. I suggest using TCP, as it is Internet native, is reliable, and is easier to secure through foreign NATs.
As a Design BluePrint for Building Network Applications: Never use port-locked Internet applications, as you cannot control the Internet. If needed, use VPN with L4 tunneling.
You are really working harder then you need to - even with the UDP implementation. Just have the client use dynamic ports, really that shouldn't cause you any problem on the link and NATs will be more likely to allow i/o traffic.
Your server should be publically available (a DMZ host, or port-forwarded) on the Internet.
A web server uses port 80, and many clients connect to it using a random open port on their local machine and the server machine. It almost always works without issue. Why do you need lock in to specific ports? Besides that, why use UDP when running a critical QoS app such as Multicast VoIP?