Re: [Shorewall-users] OT SIP vs NAT (Was: How do I configure shorewall to work with VoIP SIP?)
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
Re: [Shorewall-users] OT SIP vs NAT (Was: How do I configure shorewall to work with VoIP SIP?)
On Wed, Oct 31, 2007 at 04:56:54PM +0100, Simon Hobson wrote: 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. This feature is not related to SIP's port scattering. It's called a reinvite, and what happens is: Phone A contacts the PBX, and sends a message asking to set up a call to a given extension. The PBX says Here's the IP address of your target. Go away. Phone A contacts the given IP address, which is the address of phone B, and sends another message asking to set up a call. It then proceeds as if phone A was given that address by the user in the first place, and the PBX is no longer involved. The entire control layer is transferred - you don't have control going to the PBX and audio going to the target phone. There's no reason why IAX couldn't do the same thing (although offhand I don't know if it does). 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. It 'works' FSVO 'works'. The problem is phones that implement silence-suppression: until both ends have generated noise, there are no first two packets, so the whole thing just sits there. This gives you a round of Hello? Hello? Can you hear me? at the start of each call. You have to configure the firewall to explicitly pass the inbound audio channel just to work around this. But this is meandering offtopic, so I'll leave it there. - 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
