Private Gallery?

Well, after almost 10 yeras of dumping photos here, its come to a point where I now have to split some of the gallery into publicly accessible images, and those I must keep private. What was over 7,500 images has been slightly reduced to around 6,000. They’re not all art, but some are useful – if you’d like to use the pictures ask me and I can send you a high-res.

Avast! SIP IPTables in mainline kernel

Well, following all the change logs out there for 2.6.18 Linux Kernel release shows that:

Add SIP protocol support to Netfilter (commit), a statistic match which is a combination of the nth and random matches (commit), a quota match (commit), and support for Call Forwarding to the H.323 netfilter module (commit)

Pretty obscure, so let me describe a problem with SIP.

SIP packets, like any other packet, has a header. This header has the standard IPv4 options, of which source address, source port, destination address and destination port are the most blindingly obvious ones. NAT is pretty well performed by most firewall boxes at tweaking these values and replaceing them on traversal of the gateway, and putting things back for responses. No surprises here.

However, the payload of a SIP packet by its design, has the IP address embedded in it. For example, the payload may have:


INVITE sip:3103 at 10.0.0.173 SIP/2.0
Via: SIP/2.0/UDP
10.21.99.221:5060;branch=z9hG4bK6caf7db4
From: "Someone"
<sip:3151 at 10.0.0.221>;tag=as23c4523c
To: <sip:3103 at 10.0.0.173>

The design is so that intermediate gateways can tack on their ‘Via’ headers and the call can be switched virtually between a chain of gateways, each one doing their bit. All well and good until you want to intrduce NAT, as the ‘Via’ then has information for networks the destination cannot necessarily get to.

This patch, I think, does the necessary bits to update the payload to make the payload be corrected as it passes through a NAT.

So, this will probably start to mean that Asterisk people will no longer have to set localnet definitions to be able to correctly operate their internal and external SIP connectivity behind their firewalls.

The implications are even bigger when hard ware vendors of DSL gateways that run Linux kernels also have this enabled – suddenly the Mom and Pop crowd can just plug SIP devices in at home and hey bringo, there goes the Telecomunications industry as we know it (is that good or bad?).

Juniper, hello, Netscreen product line? Your SIP ALG should be doing this?

Viva la revolution!