Wednesday, May 28, 2008

Truth or Skype?

Recently I had to install Skype in order to be able to contact a job lead in the manner most convenient for them. After my recent successes with SIP VOIP I thought it was time to try Skype, I'd heard much good about it.

I went to their site, located the Linux build I needed, scanned the hardware requirements. I thought I saw the requirements say that it only needed a 400 MHz CPU and about 128 MB of memory. The installation on my desktop computer went smooth, a simple dpkg installation of a .deb package. When I finished and tried calling their echo test number, echo123, I was greatly disappointed. The incoming sound was fine, but I'd have to rate what I heard of my voice echoed back as one of the worst audio experiences of my life, that badly distorted.

I installed Skype on another computer, a much more powerful media server and found the performance was fine. The problem then was with my desktop. I went back to the download page, and noticed that the required CPU speed was 1 GHz, not the 400 MHz I remembered seeing. I searched around some and did find a page on Skype's support site that quoted the speed I remembered seeing. Whether they changed this after I downloaded the .deb or if I had chased off surface pages of their web sites looking for the information I can't recall. I'd heard so much about good about Skype I didn't expect any problem, especially after the SIP successes I'd had lately.

Shane on suggested some terms to google and after much flondering I found a couple of pages that gave older versions of Skype's client program.

After an abortive try at 1.4, I found a version 1.3 that seems to work fine. There were some comments that turned up indicating some people found versions after a 1.3 release to be incompatible with some Linux Distros. Whether this was because people using Slackware Linux had no other need to update their hardware or a genuine software incompatability I don't know.

I also thought I saw Skype claim their program works over 33.7 KHz dialup lines. I consider this conclusive evidence that they use some form of audio compression, which could explain why there is increased need for CPU speed. Probably not a problem on more modern computers, but one form of audio compression, encoding to .mp3, is definitly not a real time process on my computer so this probably backs the problem cause scenario.

Anyway, this might save someone some time.

Monday, May 26, 2008

A Phone Call From Ralf

Today I recieved a phone call from Ralf, a friend of me and some of my other acquantances. The thing that was unusual about the call was that it was the first I have recieved using Voice Over Internet Protocol (VOIP) / Session Initiation Protocol (SIP). I've placed many outgoing calls in the past but never recieved any till today. The call was using the services and accounts of the Gizmo Project ( by both of us.

One of the cool things I like about Gizmo's service is that if you are not logged in with it, and you recieve a call, they will email you a .wav file of any voice message a caller leaves for you, effectively turning your inbound email into an answering machine. I've played these wav files with mplayer while browsing my email's web interface with Lynx. I consider this an indication of keeping things interoperable by sticking with basic, universal protocols and formats.

I'd just gotten outgoing calls using my Gizmo account to work yesterday with the Linphonec client, from the Debian Linux distribution package linphone-nox. This particular client is a text console application that simply presents you with a prompt to type in commands, and does offer a 'help' command to get a list and further details of possible commands as well as tab completion. In general the commands are fairly straight forward, but I do have a few complaints. It does not respond to 'exit', you must type in 'quit' to leave the program. There is no command to toggle muting on the microphone, so I have to put it in a wrapper alias to handle this with an 'amixer' command I figured out to work with my particular sound card. This probably varies from soundcard to soundcard. Also there is no direct command to dump the call log (the output of the 'call-log' command) into a file for saving. There may be a switch, '-l ' to handle saving the logfile, but that will need to be folded into the wrapper alias, so it has to be thought out a head of time.

One of the things that was notable about the call was that it traversed three firewalls, two of them performing NAT (Network Address Translation). There had been some adjustments to these firewalls to handle the outgoing calls, but apparently that was sufficient to enable incoming calls. NAT is frequently considered the bane of VOIP, but apparently, at least on a limited scale, it can be dealt with.

Anyway, before the day ended I'd recieved several other calls from Ralf and another friend further confirming that the combination of software, hardware and protocols provided functioning telephony.