Patrick's Blog(2)

Let’s say you have an Asterisk server that listens on the standard UDP port 5060 and want to use the VoIP client on for example your shiny new Nokia N900. You configure the VoIP client and everything works as advertised via your local WiFi link.

Next you also want to use the 3G/3.5G Internet link on your phone. Security conscious as you are you run into a small problem. Using the standard UDP port 5060 is not a smart thing to do as the usual evil suspects are scanning boxes across the Internet for port 5060 so they can try to hack into it and make free calls. So you need to use a different UDP port. Here’s were the problem starts.

Asterisk can only listen on one port and one IP address. Pretty silly I know but that’s the way it is (unless you switch to FreeSWITCH). Your VoIP client also supports only one UDP port. You could create two profiles in your VoIP client but that’s ugly and not what we want.

We really just want to use a UDP port that is not 5060 that can be used on the local LAN and on the 3G/3.5G link while Asterisk is still listening on UDP port 5060. The solution is simple: on the box running Asterisk add one IPtables port forwarding rule to your firewall. Here’s how to do it:

You need root privileges for all steps.

Make sure your firewall is running before continuing with the next steps:

# service iptables start

Next add the portforwarding rule to IPtables where:

INTERFACE = the interface of your Asterisk box (example: eth0)
IP = the IP address of your Asterisk box (example: 192.168.43.157)
OTHERPORT = the port you configured in the VoIP client (anything but 5060, example 12345)

# cd /etc/sysconfig
# cp iptables iptables.backup
# iptables -t nat -A PREROUTING -p udp -i <INTERFACE> -d <IP> –dport <OTHERPORT> -j DNAT –to <IP:5060>
# service iptables save
# service iptables restart

Now check your shiny new IPtables portforwarding rule:

# service iptables status

And you should see something like this (IP addresses are just examples):

Table: nat
Chain PREROUTING (policy ACCEPT)
num target prot opt source     destination
1   DNAT   udp  --  0.0.0.0/0  192.168.43.157 udp dpt:12345 to:192.168.43.157:5060

To enhance security I would recommend to limit the IP ranges from which the VoIP client can connect by adding IP restrictions to your VoIP client’s profile in /etc/asterisk/sip.conf:

deny=0.0.0.0/0.0.0.0
permit=<IP range1 of GSM provider>/<netmask>
permit=<IP range2 of GSM provider>/<netmaks>
permit=<IP range3 of GSM provider>/<netmaks>

Testing the various codecs using the 3G/3.5G link on my N900 it seems that the iLBC codec at 40ms gave the best results (allow=ilbc:40 under the VoIP client’s profile in /etc/asterisk/sip.conf). Alaw was the clearest but every second letter of words I spoke were dropped. Same for AMR and G.729. This seems to be caused by high packet loss. On the N900 I ran mtr-tiny and saw packet loss as high as 49% and about 30% consistently (WTH?). This might be caused by shaping and prioritizing of UDP by the Telco. Once I have replaced Asterisk with FreeSWITCH I will test again using UDP and TCP to see if using TCP makes a difference.

For even more security use TLS with self-signed client certificates. TLS is supported on Asterisk 1.6.x but I do not know if Asterisk 1.6.x also supports authorization based on client certificates. Again, if you want advanced secure functionality like that you should probably look at FreeSWITCH.

I was going through some really old stuff and found a picture of my first car. A silver-grey metallic Renault 5 GTL with bright orange upholstery which I bought in The Hague from a friend of a friend for FL 125 Guilders (less than 60 euros). Here is a picture:

My first car: a Renault 5 GTL

I have fond memories of this car. Obviously the freedom it provided. It drove well too except that the engine would always overheat. The car had a temperature meter and it even worked so I knew when to stop which was after about 20km. To get going again I had to release some of the pressure by carefully opening the cap of the cooling system. Since I had little experience with car engines I couldn’t figure out what was causing it. It took me quite a while before I understood that it was a broken pressure valve in that same cap… Nevertheless this didn’t bother me as I had a car that took me places, albeit with some stops on the way.

At some point the water pump decided to pump the water on the street instead of through the system. That really needed fixing so I got a replacement pump at the car junkyard for 10 Guilders (less than 5 euros) and in the midst of winter removed the old pump and installed the new one. At freezing temperatures this wasn’t fun but in the end I succeeded and I was mobile once again.

After about a year of being my partner in crime the elements won. Due to extensive rust the left rear suspension pretty much detached from the chassis and that was the end of it. I remember driving her on a beautiful day to the junkyard where my little Renault met her final resting place.

So Nokia finally announced the N900. It’s an impressive phone already getting positive reviews. Reading the specs I miss two things: FLAC and Ogg support. How is it that a Linux & Maemo based phone does not have support for FLAC and Ogg?! Let’s hope Nokia fixes that in new firmware releases.

The Linux Foundation just released their annual ‘Who Writes Linux’ report. A fascinating read worth your time if you are interested in the numbers behind Linux’ relentless progress. And guess which company is totally absent in the report? Canonical. No suprise there. All I hear from Shuttleworth is rhetoric about how the Community would benefit from synced releases. Yeah right.

Tonight I was updating a laptop to F11, did some tab completion and almost had a heart attack from the way too loud beep that hammered my ears. Obviously this should never happen again so next step was disabling this deafening beep.

In the good ol’ days you disabled the beep from hammering your ears during tab completion by adding or uncommenting “set bell-style none” in /etc/inputrc. Since I don’t know if that still works I figured I might as well prevent the pcspkr module from loading in the first place with:

# echo “blacklist pcspkr” > /etc/modprobe.d/pcspkr.conf
# rmmod pcspkr

Enjoy the peace and quiet!