On Mon, 19 Jan 2004 16:17:55 -0800 "Michel Py" <michel@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Iljitsch van Beijnum wrote: > > These protocols require that at least one > > side in each transfer is capable of > > receiving inbound sessions. > > This is not true. Kaaza does not require to open any ports nor > configure anything in the NAT box. Here is how the Kaaza Skype proprietory VoIP network gets around NAT (from http://www.skype.com/skype_p2pexplained.html) : "Firewall and NAT (Network Address Translation) traversal: Non-firewalled clients and clients on publicly routable IP addresses are able to help NAT?ed nodes to communicate by routing calls. This allows two clients who otherwise would not be able to communicate to speak with each other. Because the calls are encrypted end-to-end, proxies present no security or privacy risk. Likewise, only proxies with available spare resources are chosen so that the performance for these users is not affected. Several new techniques were also developed in order to avoid end-user configuration of gateways and firewalls, whose non-intuitive configuration settings typically prohibit the majority of users from communicating successfully. In short, Skype works behind the majority of firewalls and gateways with no special configuration." Of course, if the non-NATted peer goes off line, the phone call dies. Also, at least here in Australia, were ADSL/broadband plans are typically download capped (eg. I have 4000MB per month download), the non-NATted peer ends up paying for Skype VoIP traffic for phone calls they are not even part of. Nice (said with typical Australian sarcasm). What makes it worse is that most people who would use Skype are likely to be technology or networking neophytes, and those who are the non-NATted peers are unlikely to be able to easily workout where their additional traffic is coming from. They will call up their ISP, complaining about wrong billing, the ISP will spend time investigating. The ISPs support costs will increase, which will be passed onto all customers, increasing the cost of the Internet service. This is one example of a hidden cost of NAT. Further more, the effectiveness of the Skype NAT solution becomes less and less as NAT becomes more prevalent, which is probable with the perceived "security" of NAT, and the use of IPv4 address "scarcity" by ISPs to differentiate between residential and business products. This Skype solution, in the longer term, is a dead end street solution. That's assuming the big telcos don't set up "public" NAT exchange points for the Skype network, which I'm sure they (as they can then bill calls), and the various government intelligence agencies would love (as they may be able then tap phone calls, or at least perform traffic anaylsis.). Of course, it also breaks the end-to-end model, but that is inherent in NAT anyway. (As Skype apparently does encrypt the phone calls, so man-in-the-middle attacks from the non-NATted peer are not a problem, unless the implementation has bugs.) The latest versions of SIP using STUN don't > either. > Does SIP with STUN use similar techniques to Skype to get around two NATted VoIP peers ? Regards, Mark.