I realize that an ALG is a hack in a router that is supposed to allow SIP packets to go through a NAT router. I also realize that for modern SIP equipment, ALG usually causes more problems than it solves, and that it's described in RFCs 2663, 3424, and others. What I can't find anywhere is what a SIP ALG actually does to the packets. Is that written down anywhere, or is it just network folklore?
If you look for "SBC" or "B2BUA" as synonyms for "SIP ALG", I expect you'll find lots of thing people think they're good for. On Wednesday, February 27, 2013, John Levine wrote:
I realize that an ALG is a hack in a router that is supposed to allow SIP packets to go through a NAT router. I also realize that for modern SIP equipment, ALG usually causes more problems than it solves, and that it's described in RFCs 2663, 3424, and others.
What I can't find anywhere is what a SIP ALG actually does to the packets. Is that written down anywhere, or is it just network folklore?
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <javascript:;> https://puck.nether.net/mailman/listinfo/voiceops
On Wed, Feb 27, 2013 at 4:33 PM, John Levine <johnl at taugh.com> wrote:
I realize that an ALG is a hack in a router that is supposed to allow SIP packets to go through a NAT router. I also realize that for modern SIP equipment, ALG usually causes more problems than it solves, and that it's described in RFCs 2663, 3424, and others.
What I can't find anywhere is what a SIP ALG actually does to the packets. Is that written down anywhere, or is it just network folklore?
I am unaware if there is any RFC stating exactly what a SIP ALG should do. Most likely, just like with SBCs it is a term that can mean different things to different people and there is not a "spec" to follow (although for SBCs there is RFC 5853 which has very general guide lines), but rather some general functionality that is expected from it.
From what I remember the Linux kernel for example has some SIP ALG functionality (which probably breaks more things than it fixes) which will modify the SDP to "fix" the IP addresses for the media streams, patching the IP when you're behind NAT (and using the public IP in the SDP), you can expect other routers (some incidentally based on Linux) to perform similar tricks.
I've never met someone who has good things to say about SIP ALGs :) *Moises Silva **Manager, Software Engineering*** msilva at sangoma.com Sangoma Technologies 100 Renfrew Drive, Suite 100, Markham, ON L3R 9R6 Canada t. +1 800 388 2475 (N. America) t. +1 905 474 1990 x128 f. +1 905 474 9223 **<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_cam...> Products<http://sangoma.com/products?utm_source=signature&utm_medium=email&utm_campai...> | Solutions<http://sangoma.com/solutions?utm_source=signature&utm_medium=email&utm_campa...> | Events<http://sangoma.com/about_us/events?utm_source=signature&utm_medium=email&utm...> | Contact<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_cam...> | Wiki<http://wiki.sangoma.com/?utm_source=signature&utm_medium=email&utm_campaign=...> | Facebook<http://www.facebook.com/pages/Sangoma-VoIP-Cards/43578453335?utm_source=sign...> | Twitter<http://www.twitter.com/sangoma?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>`| | YouTube<http://www.youtube.com/sangomatechnologies?utm_source=signature&utm_medium=e...>
On 2/27/13 1:33 PM, John Levine wrote:
I realize that an ALG is a hack in a router that is supposed to allow SIP packets to go through a NAT router. I also realize that for modern SIP equipment, ALG usually causes more problems than it solves, and that it's described in RFCs 2663, 3424, and others.
What I can't find anywhere is what a SIP ALG actually does to the packets. Is that written down anywhere, or is it just network folklore?
A lot of this depends on what the ALG vendor is selling, but it typically functions like a stateful packet inspection firewall for SIP. To make it more interesting, different vendors use their own proprietary terms to describe similar or identical functions making apples-to-apples comparisons challenging. Some ALG functions (not every ALG does all of these): * NAT including fixup of source IP address embedded in payload. * SIP proxy, B2BUA or some combination. * Registration pacing * Other header manipulation (which can break things that aren't broken as well as fix things that are). * Various flavors of QoS. * Various flavors of survivability including PSTN backup. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
Most ALG's cause one way audio. :) If you don't mind filling out a form there is a good doc from Acme Packet comparing SBC's to ALG's. http://lphs.acmepacket.com/comparing-sbcs-to-firewalls/ On Feb 27, 2013, at 4:33 PM, John Levine <johnl at taugh.com> wrote:
I realize that an ALG is a hack in a router that is supposed to allow SIP packets to go through a NAT router. I also realize that for modern SIP equipment, ALG usually causes more problems than it solves, and that it's described in RFCs 2663, 3424, and others.
What I can't find anywhere is what a SIP ALG actually does to the packets. Is that written down anywhere, or is it just network folklore?
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 27/02/13 21:33, John Levine wrote:
I realize that an ALG is a hack in a router that is supposed to allow SIP packets to go through a NAT router. I also realize that for modern SIP equipment, ALG usually causes more problems than it solves, and that it's described in RFCs 2663, 3424, and others.
What I can't find anywhere is what a SIP ALG actually does to the packets. Is that written down anywhere, or is it just network folklore?
The simple answer is `break stuff`. The marketing answer is `Sip is the next big thing, and we want to say we are "SIP READY" so we put an ALG in`. Technically. The OKish ALGs are passive and sniff the ports for Qos etc. Most NAT passing ones just search and replace the IP addresses in the SIP and SDP. Mainly though, I've seen them swap one IP, but not the other. Or misread the port number. Very basic search and replace rather than properly parsing the messages. Bad idea. -- Tim Bray tim at kooky.org | +44 7966 479015 | http://www.kooky.org Huddersfield, UK
How reliable and predictable an ALG is really varies vendor by vendor. Most standard firewalls' and routers' ALG do cause more problems (for example most Cisco stuff), but the SIP specific vendors usually do a much better job. My personal favorite is Edgewater Edgemarcs. Most generally what they do is provide layer 5+ (OSI) NAT, intelligently replacing addresses in the SIP and SDP headers. In most cases they will also handle RTP, doing things like making sure outside ports are unique and open based on following the SDP on the signaling side. -Scott -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Tim Bray Sent: Thursday, February 28, 2013 6:45 AM To: voiceops at voiceops.org Subject: Re: [VoiceOps] What does an ALG actually do? On 27/02/13 21:33, John Levine wrote:
I realize that an ALG is a hack in a router that is supposed to allow SIP packets to go through a NAT router. I also realize that for modern SIP equipment, ALG usually causes more problems than it solves, and that it's described in RFCs 2663, 3424, and others.
What I can't find anywhere is what a SIP ALG actually does to the packets. Is that written down anywhere, or is it just network folklore?
The simple answer is `break stuff`. The marketing answer is `Sip is the next big thing, and we want to say we are "SIP READY" so we put an ALG in`. Technically. The OKish ALGs are passive and sniff the ports for Qos etc. Most NAT passing ones just search and replace the IP addresses in the SIP and SDP. Mainly though, I've seen them swap one IP, but not the other. Or misread the port number. Very basic search and replace rather than properly parsing the messages. Bad idea. -- Tim Bray tim at kooky.org | +44 7966 479015 | http://www.kooky.org Huddersfield, UK _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Correct me if I'm wrong, but last time I looked, Linux's netfilter kernel module for SIP, ip_conntrack_sip, still is ignorant of SDP entirely. Scott Berkman <scott at sberkman.net> wrote:
How reliable and predictable an ALG is really varies vendor by vendor. Most standard firewalls' and routers' ALG do cause more problems (for example most Cisco stuff), but the SIP specific vendors usually do a much better job. My personal favorite is Edgewater Edgemarcs.
Most generally what they do is provide layer 5+ (OSI) NAT, intelligently replacing addresses in the SIP and SDP headers. In most cases they will also handle RTP, doing things like making sure outside ports are unique and open based on following the SDP on the signaling side.
-Scott
-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Tim Bray Sent: Thursday, February 28, 2013 6:45 AM To: voiceops at voiceops.org Subject: Re: [VoiceOps] What does an ALG actually do?
On 27/02/13 21:33, John Levine wrote:
I realize that an ALG is a hack in a router that is supposed to allow
SIP packets to go through a NAT router. I also realize that for modern SIP equipment, ALG usually causes more problems than it solves, and that it's described in RFCs 2663, 3424, and others.
What I can't find anywhere is what a SIP ALG actually does to the packets. Is that written down anywhere, or is it just network folklore?
The simple answer is `break stuff`.
The marketing answer is `Sip is the next big thing, and we want to say we are "SIP READY" so we put an ALG in`.
Technically.
The OKish ALGs are passive and sniff the ports for Qos etc.
Most NAT passing ones just search and replace the IP addresses in the SIP and SDP. Mainly though, I've seen them swap one IP, but not the other. Or misread the port number. Very basic search and replace rather than properly parsing the messages. Bad idea.
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully-fledged keyboard. Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
On Sat, Mar 2, 2013 at 5:17 PM, Alex Balashov <abalashov at evaristesys.com>wrote:
Correct me if I'm wrong, but last time I looked, Linux's netfilter kernel module for SIP, ip_conntrack_sip, still is ignorant of SDP entirely.
I just checked the latest stable tree (git:// git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git) It does parse the SDP finding session/media description rtp/rtcp ports and it does mangle the UDP packet. See net/netfilter/nf_nat_sip.c, function process_sdp() Cheers, *Moises Silva **Manager, Software Engineering*** msilva at sangoma.com Sangoma Technologies 100 Renfrew Drive, Suite 100, Markham, ON L3R 9R6 Canada t. +1 800 388 2475 (N. America) t. +1 905 474 1990 x128 f. +1 905 474 9223 **<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_cam...> Products<http://sangoma.com/products?utm_source=signature&utm_medium=email&utm_campai...> | Solutions<http://sangoma.com/solutions?utm_source=signature&utm_medium=email&utm_campa...> | Events<http://sangoma.com/about_us/events?utm_source=signature&utm_medium=email&utm...> | Contact<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_cam...> | Wiki<http://wiki.sangoma.com/?utm_source=signature&utm_medium=email&utm_campaign=...> | Facebook<http://www.facebook.com/pages/Sangoma-VoIP-Cards/43578453335?utm_source=sign...> | Twitter<http://www.twitter.com/sangoma?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>`| | YouTube<http://www.youtube.com/sangomatechnologies?utm_source=signature&utm_medium=e...>
participants (8)
-
abalashov＠evaristesys.com -
jay＠west.net -
johnl＠taugh.com -
mh＠markholloway.com -
moises.silva＠gmail.com -
richard.barnes＠gmail.com -
scott＠sberkman.net -
tim＠kooky.org