<story><title>Peer-to-Peer Communication Across Network Address Translators (2005)</title><url>http://www.brynosaurus.com/pub/net/p2pnat/</url></story><parent_chain></parent_chain><comment><author>jmartrican</author><text>We been doing this at Vonage since 2001.  This was our &amp;quot;secrete sauce&amp;quot;, since at the time there wasn&amp;#x27;t a well documented or an industry standard on how to do this.  Eventually SIP through NAT papers and RFC&amp;#x27;s did appear, but we already had our way of doing it that was just as effective.&lt;p&gt;We found that renewing the NAT entry at a rate of once per 20 seconds was good enough.  This made it work through all the routers and gateways we came across.&lt;p&gt;EDIT:  SIP is short for Session Initiation Protocol.  Its the protocol used to connect VOIP phone calls.  We used UDP.  SIP&amp;#x27;s standard port is 5060 and 5061.  We had to switch to port 10,000 (any port other than the standard) because too many high end routers and gateways would manipulate our packets.  These routers were trying to implement SIP through NAT on their own.  I applauded their efforts but it caused problems for us.  I still remember the day that I took it upon myself to change production to use port 10,000.  I was really scared I was going to break something but everything worked out in the end.</text></comment>
<story><title>Peer-to-Peer Communication Across Network Address Translators (2005)</title><url>http://www.brynosaurus.com/pub/net/p2pnat/</url></story><parent_chain></parent_chain><comment><author>jamesblonde</author><text>Strange to see this relatively old article appear. NATs are still with us. The main progress has been WebRTC. Otherwise, researcher who looked at TCP at the time (e.g., stunt) for simiulataneous TCP Syn packets failed. It was too hard to synchronize timing. 
Most middleware still ignores NATs and hopes it will go away (it won&amp;#x27;t). NATs are the reason REST won over CORBA et al.</text></comment>