VoIP debugging

I have been fighting againt a problem with my VoIP calling setup. The problem presented itself last week and was not accompanied by any software upgrades or network changes on my end. I should first explain a little about my current setup. I use Asterisk as a software PBX. This handles outbound and inbound calls, voicemail and termniation of my London and German and US telephone numbers. Last week I noticed that when I made outbound calls via SipDiscount I would receive no ringing signal and also the call would never be fully setup.

Or so I though. After looking through my logs I discovered that the calls were actually being setup. At first I though that SipDiscount had changed their supported codecs. After searching on the internet it seemed that nobody really knew which were supported codecs. So I setup a list of all codecs that I could support and relied on the SIP negotiation phase to choose the correct one. Unfortunately the symptoms persisted.

On a hunch I then started tcpdumping and analysing the traffic on port 5060 (the SIP signalling port). All this seemed fine too. I saw a common codec being selected and the call setup and tear down completing without a problem.

I banged my head more and then decided to double check my firewall log. This seemed unnecessary since my VoIP calls had all been completing fine for the last year.

Mar  1 19:07:15 bunker DENY2: IN= OUT=ppp0 MAC= xsrc=62.245.233.186 DST=194.120.0.163 LEN=200 TOS=10 PREC=0x00 TTL=64 ID=693 DF PROTO=UDP SPT=17820 DPT=57344 LEN=180
Mar 1 19:07:15 bunker DENY2: IN= OUT=ppp0 MAC= xsrc=62.245.233.186 DST=194.120.0.163 LEN=200 TOS=10 PREC=0x00 TTL=64 ID=694 DF PROTO=UDP SPT=17820 DPT=57344 LEN=180
Mar 1 19:07:15 bunker DENY2: IN= OUT=ppp0 MAC= xsrc=62.245.233.186 DST=194.120.0.163 LEN=200 TOS=10 PREC=0x00 TTL=64 ID=695 DF PROTO=UDP SPT=17820 DPT=57344 LEN=180
Mar 1 19:07:15 bunker DENY2: IN= OUT=ppp0 MAC= xsrc=62.245.233.186 DST=194.120.0.163 LEN=200 TOS=10 PREC=0x00 TTL=64 ID=696 DF PROTO=UDP SPT=17820 DPT=57344 LEN=180



That seemed odd since my firewall script read:

iptables -A INPUT    -p udp -s 0.0.0.0/0 -d $VOIPIP --dport 10000:20000  -j accept-log
iptables -A OUTPUT -p udp -s $VOIPIP -d 0.0.0.0/0 --dport 10000:20000 -j accept-log



Hmmm. What had happened is that SipDiscount changed their reception port range to something outside the normal range for SIP calls. Normal SIP port ranges are 10000-20000. A quick change of my rules fixed the problem and I now have telephone calls with audio.

iptables -A INPUT    -p udp -s 0.0.0.0/0 -d $VOIPIP --dport 10000:20000  -j accept-log
iptables -A OUTPUT -p udp -s $VOIPIP -d 0.0.0.0/0 --sport 10000:20000 -j accept-log

VoIP debugging


I have been fighting againt a problem with my VoIP calling setup. The problem presented itself last week and was not accompanied by any software upgrades or network changes on my end. I should first explain a little about my current setup. I use Asterisk as a software PBX. This handles outbound and inbound calls, voicemail and termniation of my London and German and US telephone numbers. Last week I noticed that when I made outbound calls via SipDiscount I would receive no ringing signal and also the call would never be fully setup.

Or so I though. After looking through my logs I discovered that the calls were actually being setup. At first I though that SipDiscount had changed their supported codecs. After searching on the internet it seemed that nobody really knew which were supported codecs. So I setup a list of all codecs that I could support and relied on the SIP negotiation phase to choose the correct one. Unfortunately the symptoms persisted.

On a hunch I then started tcpdumping and analysing the traffic on port 5060 (the SIP signalling port). All this seemed fine too. I saw a common codec being selected and the call setup and tear down completing without a problem.

I banged my head more and then decided to double check my firewall log. This seemed unnecessary since my VoIP calls had all been completing fine for the last year.

Mar  1 19:07:15 bunker DENY2: IN= OUT=ppp0 MAC= xsrc=62.245.233.186 DST=194.120.0.163 LEN=200 TOS=10 PREC=0x00 TTL=64 ID=693 DF PROTO=UDP SPT=17820 DPT=57344 LEN=180
Mar 1 19:07:15 bunker DENY2: IN= OUT=ppp0 MAC= xsrc=62.245.233.186 DST=194.120.0.163 LEN=200 TOS=10 PREC=0x00 TTL=64 ID=694 DF PROTO=UDP SPT=17820 DPT=57344 LEN=180
Mar 1 19:07:15 bunker DENY2: IN= OUT=ppp0 MAC= xsrc=62.245.233.186 DST=194.120.0.163 LEN=200 TOS=10 PREC=0x00 TTL=64 ID=695 DF PROTO=UDP SPT=17820 DPT=57344 LEN=180
Mar 1 19:07:15 bunker DENY2: IN= OUT=ppp0 MAC= xsrc=62.245.233.186 DST=194.120.0.163 LEN=200 TOS=10 PREC=0x00 TTL=64 ID=696 DF PROTO=UDP SPT=17820 DPT=57344 LEN=180



That seemed odd since my firewall script read:

iptables -A INPUT    -p udp -s 0.0.0.0/0 -d $VOIPIP --dport 10000:20000  -j accept-log
iptables -A OUTPUT -p udp -s $VOIPIP -d 0.0.0.0/0 --dport 10000:20000 -j accept-log



Hmmm. What had happened is that SipDiscount changed their reception port range to something outside the normal range for SIP calls. Normal SIP port ranges are 10000-20000. A quick change of my rules fixed the problem and I now have telephone calls with audio.

iptables -A INPUT    -p udp -s 0.0.0.0/0 -d $VOIPIP --dport 10000:20000  -j accept-log
iptables -A OUTPUT -p udp -s $VOIPIP -d 0.0.0.0/0 --sport 10000:20000 -j accept-log

MythTV

After 2 years of on and off attempts to get MythTV working, I can can now confirm that it has been running well for the last couple of months. It’s currently recording TV shows (via dual tuners) and playing back DVDs and videos that I’ve collected. Although I’ve enjoyed not having a TV for the last couple of years, sometimes it’s nice to come home to the latest Simpsons episode or a recent news broadcast.



I ended up building a diskless system that boots from my main server. This allows me to run a virtually silent system and utilises already avaliable managed disk space on the backend server. Although slightly more complicated to setup, I’m particuarly fond of running workstations disklessly. It allows snapshotting of the filesystem before a big upgrade of trying untested software and makes replication to other systems easy. I had a couple of hickups with the NFS mounts and optimising them but they seem to be working well so far. Eventually I plan on ditching NFS and moving everything to Samba or if I’m in a particualry machioistic mood, OpenAFS. Ideally all systems will use Kerberos for authentication of mounts but I am still a little way off that goal. Naturally the MythTV box is fully LDAPified.



MythTV comes with a neat feature that will scan recorded TV shows for commercials and insert skip markers where is thinks commercials are beginning and ending. Most of the time this works remarkably well (and when it doesn’t there is always the fast forward button). Another neat feature is the option to play back shows at up to 1.5x the original speed. I sometimes use this feature at 1.2x for Startrek episodes with too many repetitive “can you raise the shields” scenes.



To actually display videos and TV I hooked the MythTV box up to a LCD projector via a (30M long) HDMI cable. I have the MythTV box running at a fixed 1280x720 resolution and do all video scaling on that rather than trusting the projectors onboard scaler. I figure that a beefy video card GPU will do a better job than some integrated scaler. The results are rather impressive. NASA has loads of HDTV clips and, after a long download, I my initial sceptism of HDTV melted away. The details, like seeing the astraunauts through the shuttle windows at launch time, made me realise how much information SDTV throws away.



I’m still controlling the MythTV box with a keyboard although I have bought a Microsoft MCE remote and keyboard. One weekend I will get around to actually installing them.

search

Powered by Blogger.

Follow by Email

Should anyone ask, on building strong teams

My thinking about building strong teams My work goal is: work with smart people, on interesting problems, that improve our lives. So I start...