Kenneth Burgener wrote: >Andrew Suffield wrote: >> I subscribe only to the "NAT is awkward" school, not the "NAT is evil" >> one, but SIP's a pretty stupid protocol even without NAT. There's just >> no good excuse for the way it scatters traffic through unrelated ports >> - it would have worked just as well if it had used only one port. Even >> without NAT, it's a nuisance for stateful firewalls. > >Good thing there is IAX!
At the risk of starting a war ... SIP does stuff that IAX can't - specifically, SIP was designed to have the data and control as separate channels. That way, your registrar/pbx/whatever you want to call it does NOT have to also pass all the traffic. Eg, you can have your control in one places, but the voice (or video, or ...) traffic does not have to go through it. I would see this as essential if (for example) deploying VoIP across a WAN with limited bandwidth. It would allow you to have calls between people in the same office NOT traversing the WAN, or to have calls between people in two offices not having to go via the main site. All this without having an exchange in each site. With IAX2, there is only one route the data can go - and that's to/from the box doing the control. Don't forget that it's quite possible for there to be more than one call routing device between end users - eg phone a could be logged into one VoIP provider, while phone b is logged into another, and in between the two providers have peered by going through a third. So the call setup control in this case could well go through three providers, while the voice/video/whatever data need only go direct between end users. Remove NAT and SIP works quite well - even through firewalls as long as each end will allow outbound traffic and the corresponding inbound traffic. The outbound traffic from phone a to phone b will open up the firewall at a, while the outbound traffic from b to a will open up the firewall at b. After the first two packets are exchanged, the link is complete and voice will flow. As long as both firewall can a) cope with the concept of "udp traffic is flowing (or did so very recently) = connection in use" and b) only allow traffic from the outside that is the exact reverse path for an outbound flow, then there is little security risk. What screws it up bigtime is phone a being told to talk to phone b at 192.168.27.5:8003 ! That's my 2d anyway. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
