Archive for February, 2007

Truncated e-mail attachments of recordings with the Asterisk Gateway Interface

Saturday, February 24th, 2007

I recently wrote what I’m referring to as a “private podcast” service for Asterisk. My friends are widely distributed throughout the world. While there are some who are quite convenient to call, like those who are on the West Coast with me, others are much farther away. It’s really not that convenient to arrange times to talk to people in London or Singapore when you are in Califoria.

My “pseudopodcast” is an extension on Asterisk that prompts to record a sound file, plays it back, and then e-mails the sound file to a receipient specified by the extension. It’s implemented as an AGI script that takes arguments for the sender and receiver. The dialplan has a two-digit receiver extension that specifies the recipient. Caller ID provides the sender identification.

It’s a neat idea, and it has helped me stay in touch with several of my friends. The only problem was that I initially was sending out e-mail with the recording truncated. It would sound fine, but it would only be a few hundred kilobytes. It wasn’t a big problem because I had the original and I could mail in the traditional manner, but it was a bit annoying to have written all this automation that didn’t work.

The first thing I checked was that the file was being recorded OK. That allowed me to trace the problem to the delivery of the e-mail. After reading the documentation for Perl’s MIME::Lite module, which I used to create the message with its attachment, I discovered that MIME::Lite doesn’t do the encoding on attached files until it’s necessary. My first troubleshooting step was to write out the e-mail message that I meant to send to disk. By checking the message on disk, I could see that it looked fine. However, receivers still told me about truncated messages.

As a next step, I sent the e-mail message on to my ISP’s mail server. (I only run sSMTP on my Asterisk server because I don’t need to receive mail from the Internet.) Even that seemed to work, which validated the SMTP route between my Asterisk server and at least one Internet e-mail host. So, the problem wasn’t my ISP arbitrarily truncating the attachment.

What I realized when sending the the message “by hand” from the command prompt is that it takes a long time to send more than a megabyte through base64 encoding and SMTP. The problem was in how my AGI script was implemented. I had assumed that when I called MIME::Lite’s $message->send() operation, it would fork a copy of sSMTP and deliver the message. Almost, but not quite. When I hung up, the AGI script would be hung up, and that would kill its child processes. The reason all the attachments were about 500 kB is that was about the limit of my patience.

There’s a two-fold fix. One was to have the script call Asterisk’s Playtones() application to give me an audio indication that it was still working on sending. The second, and more important part, is to have the AGI script ignore HUP until it’s done sending the message. Problem solved!

Crippled Internet stations at the SAS lounge at Heathrow Airport

Saturday, February 24th, 2007

For my trip to Abu Dhabi, I had to change planes in London. The downside of my itinerary is that I will need to spend the better part of today at Heathrow Airport as a transit passenger. Fortunately, I have access to the SAS lounge so I don’t need to sit in the departure lounge for eight hours.

Although I have access to the lounge, the Internet situation is sub-optimal. Their captive 802.11 portal insists on redirecting me to the SAS web site no matter what I try to do (and I was even willing to give them money!). I’m writing this from one of the crippled Internet stations in the lounge. When you first walk up to a machine, it connects you via Citrix MetaFrame to a central server somewhere, and allows you precisely one Internet Explorer window. That’s an annoyance, at least until you go to a site that pops up a window that refuses to fully load and ties up your one window. When you get a web application that doesn’t like you for some reason (I’m talking to you, Outlook Web Access), there is no easy way to quit your session!


Off to Abu Dhabi!

Friday, February 23rd, 2007

I’m writing this from the Red Carpet Club at the San Francisco airport, waiting for my first hop flight on a trip to Abu Dhabi. I’ve been invited to speak at the Education Without Borders conference on networking and access to technology. Here’s the abstract for my talk, which was inspired by Stewart Brand’s book How Buildings Learn:

Pervasive communication networks greatly increase our ability to share information, but this can sometimes come at a great cost. In physical architecture, the imperceptible slow change of the site and structure dominate the more fast-moving familiar processes that are easily visible to the users of building. The same is true in communication networks, where the social environment of a network’s users and its basic technology steer its future development path. Network engineering is mainly a technical discipline that attempts to optimize for the technology of today while remaining open to tomorrow’s developments. Defining what is optimal and should be maximized, however, is a social question that drives those engineering decisions.

We are in the midst of one of the most fundamental changes in the physical architecture of the Internet, with potential profound changes in its social effect. Most of the technology that underlies traditional Internet access is based on “fixed” networks built from expensive and inflexible cables. The physical architecture constrains network services to areas where the infrastructure is easy to build, keeping access concentrated in densely populated areas. Newer wireless technologies free network builders from technological dependence on cables, and from the financial constraints of needing to pay for costly infrastructure. These technologies enable the network to reach into remote locations that would have previously been considered “off-limits” to traditional technologies.

The resulting flexibility from wireless technologies is shifting the focus of innovation and use away from traditional markets for new technology towards emerging markets that benefit more from its advantages. Instead of importing designs and their implicit social models from existing networks, network builders need to ensure that these new technologies are used within the correct social context and are made broadly available.

The conference is doing a/v recording. I’ll definitely post my slides, and with luck, the audio and video.

Early experience with the BART (not-so-)EZ Rider card

Saturday, February 17th, 2007

Last month, I signed up for one of BART’s EZ Rider cards. My experience has been pretty good. Even though the instructions on the card say that you have to touch the card directly on the reader, I am able to touch in without pulling the card out of my wallet. I couldn’t use the card when it was buried in the inside of the wallet, but when I moved it to the bill-area so the card is right next to the outer surface of the wallet, everything started working fine.

My wife’s experience, on the other hand, suggests you should hope and pray that your card never breaks. She carried her first EZ Rider card in the same way that she carried paper tickets, in a pouch designed for such things on her backpack. As is standard practice, on first use, the card was automatically loaded with $48 of value. Just as the card dipped below $40 (to $39.60, I think), it stopped working. According to the station agent, the card no longer responded to the reader and needed to be replaced. The only way to contact BART is through the EZ Rider “service center,” which is a single telephone number usually answered by a machine. After a little more than two weeks of calling and leaving voice messages that were never returned, she finally reached a live human who agreed to send out a replacement card.

I can only hope this isn’t a harbinger of things to come when the program leaves the pilot stage and goes live. Two weeks to get a person on the phone is ridiculous. I can understand the expense of staffing a call center, but it should be possible to leave a message and see some concrete action taken. I’m morbidly curious as to see whether they can successfully transfer the balance from the broken card account on to its replacement, largely because experience shows that it will likely be tremendously painful to contact the service center again to fix any potential errors.

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.

My ideal 802.11 phone

Tuesday, February 13th, 2007

This is an idea that’s been percolating for a while, but Dameon’s recent rant about how VoIP hardware is boring has triggered two responses.

One is that I have started explaining what I do with VoIP to the rest of the world as, “I have become my own telco.” If I want a service, I can define and implement it myself, without needing to wait for a big market to develop and catch the eye of the telco. (I did this recently to make Asterisk handle incoming telephone calls in a time-aware fashion for my international travels.)

But, more on point, I’m also excited by the proliferation of wireless LAN phones. The dual-mode phone is a way of communicating traditionally (with the cell side of the device) as well as with services that I can define myself (with the 802.11 side). Unfortunately, most of the phones on the market are hardly interesting. Here’s my “hit list” of features that you have to implement to make me pay attention:

  1. WPA(2). This shouldn’t even be hard at this point. We’ve worked out all of the kinks from these protocols, and there are multiple open-source implementations. There is no excuse for bringing any wireless LAN device to market that doesn’t support good security in 2007.
  2. WMM. Last year at Interop, I was able to demonstrate that WMM can give you voice quality, even with significant background traffic. There are plenty of reference designs from hardware vendors that do WMM. Selecting only WMM phones drops you to just eight Wi-Fi Certified devices.
  3. PMK caching. This is an under-appreciated feature that was part of the 802.11i amendment. It’s a way of saving master keys to cut down on roaming times. Combined with the “opportunistic” version that establishes master keys on APs before it’s needed, you can get some impressive handoff times between APs, and you’re hard pressed to hear a difference.
  4. U-APSD. This is an acronym for Unscheduled Automatic Power Save Delivery. Anybody who’s used an early 802.11 phone has undoubtedly noticed that the battery life is, to put it nicely, awful. U-APSD works keep the 802.11 radio powered down when it’s not used, so that almost all of the 802.11 radio (and power) usage is devoted to transmitting voice. Anecdotally, it can extend battery life by 50-100%, but there are so few implementations I can’t speak from a wealth of data.

Naturally, even after you get to the end of this list, there’s a lot more that can be done, but it’s relatively small potatoes compared to the big four. There are some further quality of service parameters that can be used to help an 802.11 phone in a big network select the right AP to go to, and there are some features that help further smooth out handoffs. To be honest, there are so few phones that can get to #2 on the list that I’m not worried about writing up #5 through #10.

APC SmartUPS recognition problems (“device not accepting address X, error -110” or “device descriptor read/64, error -110”)

Thursday, February 8th, 2007

After the power scare in December, I decided to run apcupsd to perform an orderly shutdown of Asterisk when the power failed.

I discovered something interesting about my APC UPS, though. If the UPS is connected to the computer when it first boots, the computer will be unable to recognize it. If they are not connected when the computer boots, everything will be fine.

I first noticed the problem when bringing my network rack back up from a forced power fail situation. Rather than recognizing the UPS, I received the following messages from the kernel:

usb 1-1: new low speed USB device using ohci_hcd and address 7
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new low speed USB device using ohci_hcd and address 8
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new low speed USB device using ohci_hcd and address 9
usb 1-1: device not accepting address 9, error -110

I was able to diagnose the problem by using a separate computer connected to the serial port on the UPS. With a helpful guide to the APC “smart” serial protocol (it’s really pretty brain-dead), I could interact with the UPS via serial from a laptop running on battery power. When the UPS was running normally, I could type commands to the serial port, like this:

Smart-UPS 750 XL

However, I noticed that when I was interacting with the UPS on serial and the Asterisk box came up when connected via USB, the serial port would freeze up. If I disconnect the Linux system from the UPS and plug it in after the system boots, then everything is OK. I am running the USB code as a module. Maybe it would be different compiled into the kernel.

Perl POE programs (for the Asterisk manager?) hang Linux

Thursday, February 8th, 2007

I have recently been experimenting with the Perl Object Environment. It’s a neat event-driven framework that builds on top of Perl. I started using it for the Perl Asterisk manager interface.

I started using the Asterisk manager as a way to get information out of Asterisk and to display on the LCD on my system. The POE component is much easier than coding up something in Expect, and it’s a wondeful standardized layer for catching events. I’ve been experimenting with a POE program that displays the number of waiting voicemails on the LCD panel. Here’s the core of the program, which essentially says that when the manager indicates a new waiting voicemail, call the voicemail_state_handler procedure, and when there is a voicemail status report, call the voicemail_status_state_handler procedure.

Alias => ‘vm-monitor’,
Username => ‘user’, # not real!
Password => ‘secret’, # also not real!
CallBacks => {
input => ‘:all’,
voicemail => {
‘Event’ => ‘MessageWaiting’,
voicemail_status => {
‘Response’ => ‘Success’,
‘Message’ => ‘Mailbox Message Count’,
inline_states => {
input => \&input_state_handler,
voicemail => \&voicemail_state_handler,
voicemail_status => \&voicemail_status_state_handler,


I’ve also experimented with programs that report other Asterisk data, or even programs that tick off a clock for display on an LCD. What they all have in common is that eventually, the system will lock up. Hard. Nothing responds, not even the attached monitor. I haven’t done any detailed diagnosis, but I can’t figure out what might cause the computer to just hang hard. The best I have for a working theory at this point is that the POE loop isn’t correctly freeing objects and is exhausting system memory to the point where a critical system task is interrupted, but that’s just a working theory.

Nikon Coolpix 4500 takes advice from Henry Ford (“Any color for your photos, as long as it’s black”)

Monday, February 5th, 2007

I have a four-year old Nikon Coolpix 4500 that I’ve owned for a bit more than four years. It’s served me well over that time, and it’s visited four continents in my search for the perfect shot. Unfortunately, it appears to have picked up mad camera disease on my recent trip to London.

When I went to power it up tonight to take a photo of a magazine spread, I was greeted with a black LCD screen. At first, I thought that I’d left the lens cap on, so I reached to take it off and I realized that it was already off. It almost looks as if the shutter is stuck closed. I get the normal markings on the LCD screen, but the image is always all black. I can use the viewfinder to see photos from my trip to London two weeks ago.

When I attempt to take pictures, I hear some mechanical noises from the lens area. The shutter sound isn’t quite as crisp as it usually has been, so it seems as if it the shutter is not opening.

I’ve written to Nikon tech support with a description the problem. I hope they can help, but if the camera is done for, I will probably buy that digital SLR that I’ve had my eye on.