Archive for October, 2006

Defeating telemarketers with Asterisk

Tuesday, October 31st, 2006

One of the reasons I initially started using Asterisk at home is that I was tired of telemarketers. Most telemarketers have been deterred by the national (U.S.) do not call list. However, the do not call list has two important exceptions for political organizations and charities (see question 29 on the FTC’s Q&A).

The exception for politics is a huge hole in California. In addition to all the candidates for public office, we typically are faced with a slew of ballot propositions. In this election cycle, there are thirteen state measures and eleven city measures in San Francisco, to say nothing of the actual people running for office. I think a majority of the money and effort is spent on the referendum side of the ballot, since text inserted into the state constitution, city charter, or California legal code never develops an annoying conscience and turns on its financiers.

Now that it’s the final push in the electoral season here in California, I’m sure the calls are flying furiously. However, I sit in blissful silence at home with a phone that’s not ringing. When you call my house, Asterisk picks up and asks you to enter an extension number or use the dial-by-name directory. If you don’t do either of those tasks, you can’t make the internal extensions ring.

Initially, I had expected that guarding the phone was going to be hard. I thought it would require validating caller ID, checking it for correctness somehow, and possibly even doing a “liveness” proof that generated a random string of digits for the caller and requested that the caller enter them back to you. It turns out that there’s a much simpler and easier way. Most mass-dialing operations use predictive dialers or robot dialers. Neither type of device is capable of understanding and reacting to speech appropriately. All I needed to do was to pick up the phone, read out an extension number (“hello, you’ve reached this phone number, dial extension 123 to talk to person #1“), and wait for a response. Most computer dialers are not able to intelligently process the voice, so Asterisk hangs up on them.

Here’s the essence of the code I use:
mainmenu => {
NoOp(Received Caller ID is => ${CALLERID(all)});

// Caller ID checks and Iotum processing left out for clarity
// Friends and family menu check goes here

// My voice menu — default for most callers

So far, that simple voice menu does the trick. I haven’t needed to modify the code yet so that when it detects a telemarketing computer, it plays the “disconnected number” tones with the Zapateller application.

Initial investigations on hooking up Skype to SIP with Asterisk: NCH Uplink, ChanSkype, and PSGw

Monday, October 30th, 2006

I’ve been playing around for the past couple of weeks with Skype-to-SIP adapters so that I could set up a Skype trunk with my home Asterisk server. No matter what your feelings on the proprietary Skype approach, it does deal with NAT quite well, and that may be important if you are on a single dynamic IP address connection. I’ve also been interested in integrating Skype into the Asterisk setup since the announcement of free outbound calling through the end of 2006. Although there are $1,000 Skype-to-PBX bridges, I am not interested enough in Skype connections to spend more money than my Asterisk server hardware cost. For my investigation, I looked at three “personal-scale” products:

All three products take the same approach. Each product is composed of a SIP interface component and a Skype client control component that uses the Skype API. When a call comes in to one half, it is directed to the other half, typically by redirecting the audio streams from the speakers through an operating system conduit. PSGw uses the term software audio cable, which is the best description.

Uplink Skype to SIP

NCH Swift Sound is an Australian company with expertise in computer-based audio and a few VoIP-related applications. Uplink’s installer offers you the Axon PBX, though it’s not necessary when you plan on using Asterisk. Uplink is a Windows application, and has a $40 price tag for license, though free downloads are available.

I already run one full-time PC for Asterisk, and I didn’t want another one just in case somebody decided to Skype me. My first approach was to try running Uplink in VMware, though I quickly abandoned that when it became clear just how much the VMware emulation layer would require in terms of resources. When the Windows VM needed CPU time, it dramatically affected performance of the applications running under Linux. The sound quality was awful, too. At first, I wondered if the sound quality was due to resource constraints on the shared system, so I ran Uplink on a separate machine. Although sound quality improved, the audio was still not anywhere near conversational quality. It was interrupted by frequent drops and hesitations. The only reason that I could make out what was coming through the telephone is that I had recorded the voice prompts myself.

To correctly get Skype to call out to a phone number, there’s a bit of phone number massaging required. Skype expects a call out number to be done in the international telephone style (+1415…), so you’ll need to add the plus sign on. To dial a skype user from the telephone keypad, you’ll also need to set up a mapping between a number and the name. Here’s some example dialplan code that does both. (Uplink is set up to register with the peer name “skype”.)
//Use “09” as a Skype outbound trunk
//Add leading “+” on to 1-NPA-NXX-XXXX number
// Map 09-888 to echo service
_09888 => {


  1. The easiest setup of the three applications I tested. Uplink installs like any other Windows application, and its configuration is well thought out. It also shows reasonable debugging information as it runs, so it’s pretty easy to see what’s going on inside.


  1. Windows-only solutions require a second box with Linux-based Asterisk systems. (This may be offset if you have a powerful enough machine to run VMware, but my VMware installation bogged down on a 1.6 GHz AMD Turion64 with 512 MB RAM.)
  2. Poor sound quality, regardless of whether Uplink runs in a VM or on an external machine.
  3. Poor call supervision. Frequently, Skype would stay connected even though Asterisk had sent a BYE message to the SIP side of Uplink. I had to fix this by hanging up in the Skype GUI.


Note: The following applies to an old version of ChanSkype. Last Wednesday, they released version 1.2, which could address one of my major concerns.

ChanSkype was announced in early October by a Brazilian company. The approach is perhaps the best of any of these products because it makes Skype instances appear as channels, rather than trying to control clients directly with a co-resident SIP gateway. It has the ability to use multiple Skype instances as outbound trunks from the same machine, which is a unique capability within the products that I looked at.

Configuration of ChanSkype was the most in-depth of any of the products. None of it is particularly hard, and the company provides quite good documentation. My two big challenges were the general configuration complexity, as well as the fact that the channel driver is provided as a 32-bit binary driver and can’t be dynamic linked into a 64-bit Asterisk.

The configuration complexity comes directly from the approach that the product takes. Several instances of the Skype client are each run by using VNC as the display. With several VNC instances running, each Skype client can function as an outbound trunk that is directly addressable by the channel driver. Unfortunately, even if you only want one Skype instance, it still requires VNC.

To set up outbound calling, you’ll need to add the plus sign on to the front of the number, as in the following dialplan code:
//Use “09” as skype trunk
_091X. => {

I had trouble with one-way audio during this test, though I believe that was due to NAT on my own network, and a SIP security device that I am using.


  1. ChanSkype had by far the best audio. The inbound audio when making a telephone call was nearly perfect, though it was hard to tell from the 15-second per-call limit that is embedded into the channel driver.
  2. Unlike the other two products, this one is capable of sending multiple Skype streams outbound because it runs multiple clients simultaneously. This is hard to test with a 15-second call limit, though.
  3. The best integration into the dialplan. Because ChanSkype is a channel driver, it’s easy to say Dial(Skype/skypeinstance/number) and let the channel driver figure out who’s free.


  1. This was the most complex configuration. Even if you only want one outbound Skype trunk, it requires running a VNC server for that client.
  2. If you run Asterisk on AMD64, there may be some extra work to get the 32-bit channel driver running. I run Asterisk on Gentoo, and found that recompiling Asterisk as a 32-bit application is sufficient because there is a wide range of compatibility libraries that can be used. (In talking with the company, I discovered they plan to release a 64-bit version.)
  3. ChanSkype doesn’t take inbound calls. If your purpose is to get cheaper outbound calling, this may not be a problem for you. (Note: ChanSkype 1.2, announced on October 25, lifts this limitation.)

Personal Skype Gateway (PSGw)

PSGw is one of the oldest Skype-to-SIP converters. Although it started on Windows, it was ported to Linux in July of this year. Because of my preference for a single-machine solution, I worked with the Linux version. Like ChanSkype, the Linux PSGw is distributed as a 32-bit application. On my system, however, there are repeated segmentation faults if it is run with 64-bit libraries.

PSGw requires a separate IP address from Asterisk to avoid port conflicts. I solved this with a secondary address on the main network interface, but this may not be possible if you don’t have enough routable IP addresses, or a way to keep the PSGw-to-Asterisk connection from going through a NAT. (At the Interop Labs earlier this year, we found that SIP and NAT don’t mix.)

Once I had successfully installed PSGw, it was easy to start. When I made my first call, PSGw mapped the call from SIP on to Skype and promptly died. As far as I can tell, the premature death was due to a library conflict. On Linux, the Skype API runs over D-Bus, and a key dynamic library used by PSGw is distributed as a 32-bit object. I was able to solve the problem by building a 32-bit chroot area, though that’s definitely not for the faint of heart. (To get Skype running in the 32-bit chroot, I needed to have a second, 32-bit version of the libraries it depends on, as well as the sound daemon used by KDE.)

Even once the 32-bit chroot was in place, there were problems with PSGw staying up if I permanently authorized PSGw to use the Skype API. To revoke the authorization, remove it from the config.xml file for the user you sign on as. Look for this line, and take out any programs that are authorized:


  1. By far the best call supervision. When Asterisk hung up, PSGw would terminate the Skype call. There was never a call leg that stayed up longer than its counterpart.


  1. Most complex setup on AMD64 due to the apparent requirement for a 32-bit chroot. (This isn’t documented anywhere, but the program crashed a lot until I put it into a 32-bit chroot.)
  2. Extremely poor call quality. I couldn’t tell that it was relaying human speech.

Closing thoughts

Based on my testing, ChanSkype seems like the most promising approach. I’ll try the recently-released 1.2 version, and report back.

In the future, it may be possible to use something likethe recently-announced Philips VOIP841, which would seem to offer the ability to be a Skype-to-analog converter that doesn’t require a computer. (Philips also announced Netgear would deliver a PC-less Skype phone.)


Thursday, October 26th, 2006

It certainly has taken me long enough to start my own blog. I’ve been at it since December 2002, when I first started blogging for O’Reilly.

Professionally, I’m a network engineer, which means that I’m a plumber for your data. Fortunately, when networks have trouble, the results may be ugly, but at least they’re generally sanitary. I took up residence in Silicon Valley after graduating from college and worked for a series of security companies. During those heady years, I liked to say that “I help build the Internet,” which generally worked as an explanation until the Al Gore “inventing the Internet” controversy. In those early years of my career, I learned that network address translation is evil, and that just sticking a firewall up doesn’t make your network secure.

In 1999, the large company I worked for acquired a little company that made wireless LAN hardware. I thought that 802.11 was the coolest technology I’d ever worked with. In those days, it was enough to walk up to somebody with a laptop and an 802.11 card, ask for a website, and pull it up in a browser. Even though it wasn’t fast, and certainly wasn’t secure, I knew I had to be a part of it. I now work on 802.11 full time, and I’m a voting member of the IEEE 802.11 working group.

Somewhere along the way, I had to prove that my liberal arts education was good for something more than just engineering, and I wrote a few books for O’Reilly. The only one that most people have read is my book on 802.11, which is now in its second edition. Writing is good for a variety of reasons. For me, one of the most tangible benefits is that it keeps me busy learning about new technologies. In 2005, I spent a good chunk of my free time learning about HDTV by using MythTV. To keep myself busy in 2006, I decided to start running Asterisk at home to learn about VoIP.

In my career so far, I’ve held a variety of positions that have required a great deal of travel. Leaving my own country has shown me that there’s a whole world out there that lives differently from me, and it’s been one of the best ways to help me appreciate where I do live. I started with most of my travel in Europe, though lately, I’ve been spending more time in Asia. Sadly, the list of the fifteen countries that I’ve visited does not yet include either Italy or Ireland.

While I’m traveling, I often take photographs. I have no professional training, so I rely on the large capacity of memory cards to take lots of pictures and throw most of them away. In this space, I’ll only be showing off the few pictures that are worth looking at.