Potential NAT Solution, some issues

Question

Greetings,
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; I want the application to work without extra technical effort on their part. 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 will, in theory, work. To start with the server needs to be publicly acessible. 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 as long as they are coming in to the client ports that initially sent out the handshake. 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.
I implemented this into my application and it works, but inconsistently. In other words the clients aren't always receiving the ReceiveStream events from the server and I can't figure out why. I am running clients on machines that are apparently behind a port resticted NAT and after much debugging have establised that proper mappings aren't always being establised the way that they should be based on the definitions of NAT's. Is it possible that the router that I am testing the clients on isn't compliant with the 4 kinds of NAT's that supposedly exist? Or is there some error in the logic that I have used to set up the mappings (the handshaking?) Everything that I said above has been implemented correctly, I am postive because I have been going over it for weeks, puzzled as to why it won't work. The only other thing I can think of is that the server is behind the same NAT that the clients are behind for testing, the server just has certain ports mapped but the clients are treating it as if it was at a remote public location so I can't see how this would matter.
Does anyone have any ideas on what it might be? Does anyone see any logical problem with the the way I've tried to establish mappings? Or have any questions? As far as I can tell it should work, perhaps I am missing something obvious and if I am I know that there are a lot of intelligent people here who will spot it. Thank you very much.
Message was edited by:
Malcolm_F

Answer 1

Hi lagar,
Good stuff, I've made some additional progress as well. One thing that I discovered is that the mappings that you establish with the initial handshake are only kept by the client's NAT for a short period of time. In other words, it was working inconsistently for me because I was setting up the mappings early and then not sending the audio until a few minutes later; by that time some of the clients NAT's had lost the mappings that had been previously established and thus some of the clients weren't receiving the audio.
I modified my application so that right before it starts sending audio it shakes hands with all of the clients, establishing fresh mappings right before the audio is sent. This seems to be working consistently now, I just tested it with someone on a different network who is behind a symettric NAT (the ugly kind) and they were able to send and receive live audio consistently, we had a little online conference call. I tested it from several other remote locations and it has worked fine so far. I have just run into one issue while testing it with someone at a remote location but there might be an issue with their JMF installation.
Please keep me updated on the status of your project and let me know if you have any questions or ideas.