Archive for the ‘telephony’ Category

How to annoy your customers, T-Mobile edition

Friday, February 22nd, 2008

Yesterday morning, I was awakened at 2:08 am by the incoming text message indication sound from my phone. I am traveling in Europe and my local time is +10 hours relative to my home, so it was a perfectly reasonable time to send a message to me in California. As I stumbled across the room, I wondered which of my friends or colleagues I had forgotten to tell about my trip.

The answer was “none of them.” T-Mobile had sent me a text message with the following contents:

Free T-Mobile Msg: Use your T-Mobile HotSpot account at Starbucks for years to come with no additional charges. Learn more at

As I have often said before, T-Mobile knows where I am. Their roaming database knows that I’m in Europe because I’m attached to the Vodafone Greece network. Therefore, the T-Mobile network is perfectly capable of knowing what time it is where I am. Sending me text messages in the early hours of the morning is just aggressively stupid customer service. At 2 am, I do not care about how long I can use the hotspots at Starbucks, and in fact, coffee is not something I remotely want to consider.

(Early morning disturbances from the phone were the driving force behind the time zone processing feature I developed for my home PBX. Read part 1 and part 2 of the Linux Journal description.)

If anything, this text message is yet another illustration of why I can’t wait to get an OpenMoko phone. The first thing I’ll do is develop a “turn off ringing and text messages within the hours of X pm to Y am” feature, so that I’m not bothered by this ever again.

I cut myself with the RAZR

Saturday, May 5th, 2007

In a post about Motorola, Katie Fehrenbacher writes at GigaOM:

The talk in Silicon Valley is that Zander received a lot of unwarranted praise for his role in promoting the RAZR, and his lack of product vision is only now being demonstrated after the shine of the RAZR has worn off.

If Zander is taking credit for the RAZR, that’s justification in my book for casting a board vote for Icahn. After a month of trying to using a RAZR, I decided that I liked it so much that I went back to the Nokia 6600 I had purchased in early 2004. I enthusiastically demoted it to a backup phone when I realized I had paid too much for it. (It was a gift, so you do the math.) My favorite part of trying wrap my brain around the RAZR was when I had to learn how to hack the phone and reinstall its software just to get a search function in the phone book.

Somebody once told me that the RAZR hardware was actually designed by one of the big custom manufacturers, and that the true designer of the hardware had tried to sell it to Nokia before Motorola. It was heartbreaking, because if the software was replaced with something usable, it would deserve to be the phone that everybody carries.

Pay phones, as seen through the balance of capital and labor

Thursday, April 12th, 2007

Several years ago, I took an introductory economics class from John Mutti. One of the basic principles that was discussed frequently, but often hard to illustrate in a concrete way, is that the relative abundance of capital and labor influences the mix of the two factors that will be used in any business.

I’m in China right now, where labor is relatively more abundant than in the United States. An economist would predict that businesses would use more labor and less capital, and you do get hints of that in the amount of labor used by hotels and restaurants. (I once ate at a restaurant in Jinan with a colleague, and the two of us were served by six staff members.)

Walking around yesterday, though, I saw the best example yet: pay phones. I’m used to pay phones being things you put coins in to get a dial tone. They’re sturdy, well-built devices that have to stand up to the abuse of patrons. As a result, they’re quite expensive ( will sell you one for $489, as I write this). Pay phones, as I understand them from my experiences in the developed world, are capital.

Not so in China. Here on the street, there are “public telephone” booths, which combine both traditional coin-operated phones and a table with several regular phones overseen by an agent. If you want to make a call, you pay the person inside the booth, and you get to use the phone. Here’s an image from the street yesterday. A woman is paying for the call she just made, and I believe the woman in the white hat is zipping up her wallet as she walks away after a call of her own. It’s exactly the sort of thing that an economist would predict. When labor is more abundant, it can substitute for capital. In this case, the labor of the person inside the booth is substituting for the capital equipment to collect coins.

Staffed pay phone in China

(Some of the booths even have signs that read “public telephone,” but sadly, not this one.)

Q&A with Mark Spencer at ETel

Saturday, March 3rd, 2007

At the O’Reilly Emerging Telephony conference, Mark Spencer spoke for 15 minutes on the future of Asterisk, with questions at the end. The audience, packed into a ballroom at the San Francisco Airport Marriott, actually left time on the table at the end, reflecting how Asterisk has become the community platform for innovation.

Somebody asked a question about integrating speech recognition into Asterisk. In 1.4, Digium is selling the proprietary LumenVox speech interface. There is also the option to use the free Sphinx engine, but Mark’s experience is that it is challenging to build a multi-channel Asterisk system with the performance characteristics necessary to run Sphinx.

Somebody asked about the fate of the “Asterisk device” that was announced at last year’s VON conference. Mark said that the appliance is available now as a developer kit, but doesn’t know when it will be available as a customer product.

There was a question about the GUI; somebody wanted to know if it would be web based. It will be. The whole GUI sounds cool, since all Digium is doing is providing a framework to build a GUI with. Any changes made on the GUI will be reflected in the configuration files, and changes to the configuration files will be available to any GUIs built with the framework. Mark spoke of two goals for the fundamental design: (1) it should be easy to add additional commands in to the management interface, and (2) management should be possible over HTTP. I’m particularly pleased with the second point. I’ve experimented with the Asterisk manager, and while it’s nice, it’s hard to use across the network. Tunneling management over HTTP will enable use of an existing security framework. Using the manager will also enable GUIs to start or terminate calls.

The Q&A came to a close with a couple of questions on voicemail. Mark began his presentation with an apology for voicemail and queuing, and said that they would be changing. Somebody (Jim van Meggelen, I think!) asked if they would break apart into lots of smaller functions. Mark said that the functionality of voicemail wasn’t bad, but the code has grown to be unmaintainable. He would like to be able to add “personalities” to the system and enable more administrative configuration. He and Kevin differ slightly as maintainers of the code; he believes that the idea that voice mail must be configured properly to work is not appealing. Separately, one of the problems with implementing voicemail personalities (to make Asterisk sound like a Nortel or Avaya PBX) is that recording all the prompts and getting different control flows is hard to do.

In terms of queues, the fundamental problem is that the time that queues were developed there was nothing that reported state changes. The queue manager can only poll for status, but it doesn’t get events. While this works adequately when all agents are readily available, it breaks down a bit for remote agents because presence informamtion may not be handy.

Separately, I got a chance to talk to Mark. Jay Phillips introduced us once he realized that we’d both contributed to the March 2007 issue of Linux Journal. (Thanks, Jay!) Aside from the overwhelming smartitude, the thing that struck me most about Mark was his genuine interest in what everybody was doing with Asterisk.

Oh, no, OpenMoko delayed!

Saturday, March 3rd, 2007

On February 12, I went to check up on the status of the OpenMoko project. With my likely disappointment on the iPhone, I’ve been looking for a replacement for my aging four-year-old Nokia 6600. Based on my set of ideal features for an 802.11 phone, I’ve been looking seriously at the Nokia E series, but they are quite expensive. The recent announcement of the “i” models in the E series lineup (E61i, etc) has shifted my allegiance slightly. I’ve been working with an E series, but it has limited battery life and a flaky SIP stack. My thoughts increasingly turn towards OpenMoko, since it would embrace SIP and open telephony in a way that is still alien to the telcos and their big suppliers. Unfortunately, the project has been delayed a short while. There are good reasons for this, namely that the team is dedicated to having a completely open system from hardware specs up through the toolchain before finally getting to the phone software itself. All commendable, but it doesn’t make it sting any less.

One of the curses of OSS is that you must live your life in full view of the world with a transparency that is a bit jarring for those accustomed to hiding delays and flaws in commercial software. (I’ve come to the conclusion that big government IT projects are no worse than their corporate counterparts, just much easier to see. A similar analogy would seem to hold for open source projects.) I’d like to than Sean Moss-Pultz for his honesty. I still want the phone just as badly as I did before the delay was announced. Touching the phone last week at the Emerging Telephony conference only made my desire worse.

Oh, Apple, the iPhone’s carrier lock is heartbreaking

Wednesday, February 14th, 2007

One of the most annoying facets of the current market in the U.S. for mobile telephones is that the carriers control the market in a self-serving way. They build closed systems to extract as high an economic rent as possible. You want to be a bookmark on the default WAP screen? That’ll cost you. Phones are sold at a huge discount to get you hooked on the service, and then “locked” to that carrier so they can’t be used elsewhere. I’m assuming that the iPhone will be no different, especially since Apple has shown a willingness to trade away freedom on previous consumer electronics products.

In theory, the lock is supposed to be temporary until the carrier has recouped their subsidy. In practice, I find that most carriers use it as a way to keep you hostage. When I was a Cingular subscriber five years ago, I was told that I had bought the GSM phone to use with the “Cingular service,” and it was Cingular policy never to unlock phones. I’m sure that the then-current world roaming rate of $4.99/minute had nothing to do with the policy.

(Fortunately, it was a Nokia phone, so the unlock procedure is well understood and there are many unlocking tools available.)

The “control your customers and force feed them” model cuts against my entire experience, which is based on open systems and architectures. Innovation in entire handset business is constrained by the fact that the cell phone companies buy and promote the phones, not the manufacturers. Anything that does VoIP is a big threat to per-minute pricing, and therefore won’t be bought or actively promoted by the carrier.

With the carriers strangling new services and innovation in an attempt to ensure they are stillborn, there is one obvious way around it. If consumers were to purchase phones that were compatible with the carrier network, there is very little that a carrier can do about it. I had hoped that Apple would sell the iPhone directly to customers (in addition, perhaps, to the carrier channel). Apple is the one company that can build a product that people would head to the stores for, and perhaps shine a little bit of the light of open systems on to the mobile telephony world.

I’m not surprised Apple didn’t take on the telcos. They can still demonstrate their famous focus on usability by showing off the integrated voice mail system they developed with Cingular’s voice mail vendor. Using the carrier sales channel is going to move a lot more phones in the short-term, even though there is a much more diffuse long-term benefit of breaking the innovation choke-hold.

For the record, this is a bit of a wish on my part. I would love to have an iPhone, but Cingular’s mobile data plans ($79.99/month for unlimited) can’t touch the price of my T-Mobile plan ($30/month, for unlimited hot spot and EDGE). I can’t afford the service to move over to Cingular, but if the phone were made available in a non-locked model, I would be in the store on the first day with cash in hand. Fortunately for me, there is a true open mobile phone platform still to come.

Robo-caller, meet Asterisk. And then go to a special circle of hell.

Monday, November 6th, 2006

Clearly, for people who use automatic robot callers to send you recorded messages deserve to go to hell. If somebody with the right connections is reading, I’d like to propose construction of an extra-special circle of hell for people who use mis-programmed auto-dialers. The Barrington Courier-Review (Illinois) is reporting that some political telemarketing machines will call you right back if you don’t listen to the whole message.

The campaign caught making repeated phone calls has blamed the telemarketing contractor, saying that it was obviously a mis-configured computer. Well, those campaigns can retain their mis-configured computer, because my correctly configured Asterisk machine will handle the calls appropriately. I’ll make my voting decision in peace, by reviewing sources of information I trust. (Hint to campaign managers: this probably is not you.) Please, make as many calls as you want. My computer is happy to listen to you spew your message, and it will deliver it to me if it is appropriate. I have programmed my computer with an algorithm that is working quite well so far, namely, that all telemarketing calls should be discarded.

However, there’s clearly a reason why these calls get made. Somebody has to believe that they work, which means that they’re either effective or cheap. Thudfactor says that a robo-call is only five cents per call, though I’ve also heard figures between one and two cents per call. No wonder they’re so depressingly common. The Center for Information and Research on Civic Learning and Engagement (CIRCLE) says that

[t]he most effective way of getting a new voter is the in-person door knock by a peer; the least effective is an automated phone call. Canvassing costs $11 to $14 per new vote, followed closely by phone banks at $10 to $25 per new vote. Robocalls mobilize so few voters that they cost $275 per new vote. (These costs are figured per vote that would not be cast without the mobilizing effort.)

(The figures cited are a study of the youth vote, which may not necessarily be representative of the whole voting population.)

Keeping track of mobile phone minute usage

Monday, November 6th, 2006

One of the things that I can’t stand about being a mobile telephone subscriber is the worry about overage charges. A long time ago, I did go over my monthly allocation, and paid for it at 35 cents per minute. (Years ago, the company I was working for at the time refused to pay for the overage at first, even though it was incurred working a major customer problem, but they did come around eventually and cut me a check.)

Well, Winston Huang felt my frustration, and has released a Firefox plug-in that checks my T-Mobile minute balance. Now, every time I open a web browser, the minute usage is displayed in the bottom bar. Here’s what it looks like this morning:

T-Mobile Firefox plug-in screen shot

The only thing that needs to happen now is a monthly graph so you can display trends over time, for visual people like me. It would be nice if I could see how much data I’m using, too. Although my T-Mobile data plan is unlimited, there may come a time when they charge by the bit, in which case, I’ll want to track that, too.

(If you don’t subscribe to T-Mobile, Winston has a Verizon plug-in, and his site has links to a Cingular plug-in, too.)

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.)