The Worldwide Lexicon, an open source project I have led for several years, recently published a suite of collaborative translation tools that enable you or your readers to create, edit and share translations to and from almost any human language. We have been testing the system throughout the summer, and in this article I explain how you can use WWL to make your site or content accessible in many languages.

WWL applies the concept of user generated content, similar to systems like Wikipedia, to the task of creating, improving and sharing translations for texts. The system does not use machine translation, but instead relies on people. Human language demands people to comprehend it, and while machine translation has improved, even accurate machine translations are not usually enjoyable to read. The key insight in WWL is that a website that has an audience will have bilingual readers, often without knowing it. These people are both interested in and more knowledgeable about the subject matter, so some of them will be willing to translate it, whether for goodwill or for money. WWL creates a simple way for a website’s readers to contribute, edit and share translations.

We began testing the system with a Word Press plug-in this summer, and have since released PHP libraries, as well as a Firefox extension. More tools are planned for release soon. The system is open source, and we are encouraging developers to embed this process in a wide range of platforms. The ultimate goal is to make collaborative translation a checkbox option on most publishing platforms, so that anyone who wants to be accessible can be. Since the release of the Word Press plug in, WWL has logged users in 107 countries representing some 50 languages, with over two-thirds of the users coming from outside the United States, suggesting a pent up demand for multilingual publishing tools.

WWL is easy to incorporate into a wide variety of web services. In this article, I’ll describe how to use the different tools we’ve created so far, and how they can be adapted for custom use.

ok… more on the geotagging photos sent to flickr via shozu and my Nokia N95 GPS-enabled smartphone. I’ve recently been doing some research to figure out exactly how to geotag my photos, and get them up on flickr then view on a map. From the outside looking it one would think, “no problemmo”, however, things are not often as simple as they would seem. Luckily there’s a couple of good third party apps that work very well. Those of you that depend on out of the box functionality that wil accomplish this will have to try again!

LiveContacts localizer now supports nokia N95 - plots mobile locations on Google maps

A nice addition to this way cool and popular social networking application… remember watching people mezmorized at Where2.0 as they watched the TwitterVision screen on the LCD?? Now Twitter has a client for the iPhone! PocketTweets is a Web-based Twitter client for the Apple iPhone. See the latest tweets from your contacts, update your status remotely, or see what’s happening around the world by viewing the public timeline. — all via EDGE or WiFi. PocketTweets was built from the ground up to support Apple’s new phone platform - http://pockettweets.com/

Comment: interesting to see some apps coming for the iPhone given that developers have yet to have access to an SDK or an open developer API - more iPhone info available via iPhoneUpdate blog

Looking for a way to “springboard” your mobile applications? Nokia, together with a number of high-profile sponsors today announced the launch of its second annual competition for developers and entrepreneurs working in the mobile space. The mobile rules competition was formerly known as the web2mobile competition. The competition is divided into two ‘tracks’. The first is for qualified developers working on mobile applications for Nokia platforms in four categories: ‘multiplayer and connected games’, ‘multimedia’, ‘enterprise’ and ‘infotainment’. The second is aimed at entrepreneurs, small businesses, start-ups and academic institutions and is for business plans in the mobile space, both those designed specifically for mobile devices and those that make existing static businesses mobile. See more details posted Here

Today the already way cool Nokia N800 Internet Tablet just got much cooler. This Linux powered Tablet enables users to browse the web and communicate with others easily anywhere in the World that offers up a Wi-Fi connection. Now users of the tablet can take advantage of Skype which is now supporting the device. See Here for details and see also www.nseries.com for more from Nokia.

Some features of the way cool N800:
Opera 8
Adobe Flash 9 browser plug-in
Internet communications
Skype support
Internet calling with integrated webcamera
Instant Messaging
Multi-protocol email client
Full screen finger keyboard
Access to internet media at home and on-the-go
High quality stereo speakers
Media player
UPnP architecture
Real Rhapsody
Expandable mass memory
Volume: 137 cc
Weight: 206 g
High-resolution touch screen (800 x 480 pixels) with up to 65,536 colors
DDR RAM 128MB
Flash 256MB, 128 MiniSD with extender included
Browsing time- up to 3.5 hours
Standby time- up to 13 days
WLAN: 802.11b/g
Bluetooth specification: 2.0.
Nokia AV connector 3.5mm
USB 2.0 high speed device mode for PC connectivity

It may not be an iPhone, but then again it doesn’t cost $600 either - AND it runs Linux OS!

Ok, this is flipping awesome… you gotta love these whacked-out Europeans (no offense) and their awesome ideas… this time it’s aerial photography (video actually) over Denmark using a spanky, $600 Nokia N95 symbian OS smartphone duck taped to a kite!
The “pilot” managed to grab several minutes of video and even had a sweet landing. Try that with your Apple iPhone.. oh, hold on, it doesn’t have video capabilities! See details and video of the flying Nokia N95 over at the Erikso.com blog

Making things even moer interesting, I recently heard from a developer in the US who has a more “professional” application that extends this functionality (ie. getting your smartphone airborne!

Jeff Johnson from PictEarth USA contacted me and shared details of what his company has been doing for some time now, “inb a more professional manner”. Jeff and crew have developed software to run on the NSeries Mobiles that uses the GPS (internal or external) to record the position of the photos and make photo-overlays. The program generates KML that can be downloaded from the phone and uploaded to Google Earth. According to Johnson,”we are very close to having the ability to post data directly from the phone to our servers using the GPRS/EDGE/3G networks via FTP.”

PictEarth has complete details available online at http://pictearthusa.com and a complete archive or aerial photography can be found at http://flickr.com/photos/pictearth/sets/ - a 4000+ photo gallery from the N95.

PictEarth has developed software to run on the NSeries Mobiles that uses the GPS (internal or external) to record the position of the photos and make photo-overlays. The program generates KML that can be downloaded from the phone and uploaded to Google Earth… NICE! Jeff tells us that they are very close to having the ability to post data directly from the phone to their servers using the GPRS/EDGE/3G networks via FTP.

(Originally posted over at www.GISuser.com) - see images here

The Nokia N95 that I’ve been using for the past couple of months has forgotten how its volume keys work. It makes me super sad to say that even though Nokia made a great telephone, it’s not above certain mechanical difficulties that befall all of our devices from time to time.

Nokia might have come out with an iPhone before its time. Sure it’s not the super cool touchscreen interface and beautiful GUI that Apple seems almost singularly capable of creating, but it is very capable and easy to use. The N95 has been the best phone that I’ve had to date (and I have a box of used mobile phones) and I can’t wait to get it back from the shop.

O’Reilly editor David Battino recently pointed me to this interesting tip on how he improved the audio of a recorded Skype interview for one of his podcasts. From Digital Media Insider Podcast 11: Synth Mania, Part 1:

Because Paolo and I live on separate coasts, we decided to do the interview by Skype and record it with Ecamm Call Recorder. To maximize the audio quality, I used a Rode Podcaster USB mic instead of my usual Logitech headset. (The Rode is what I use for the show’s main voiceover.) I recorded into Call Recorder using the highest quality AAC compression setting.

But we also tried a radio trick called a “two-ender” to boost the quality further, and it worked great. Paolo set up two mics–one feeding his Skype computer and another feeding Sound Forge on another computer. After the interview, he sent me the local recording, and I substituted it for his side of the Skype recording. (One of the great things about Call Recorder is that it saves each side of the conversation on a separate track.) Not only did the direct recording sound fuller, it avoided the clipping distortion in the Skype signal, something I encountered on my previous Skype podcast as well.

One of the biggest draws for me to attend ETel was the Neo1973 and OpenMoko. My dissatisfaction with Apple for the closed platform on the iPhone means that I’m looking for an alternative.

In addition to the “pure” interest I have in an open, customizable platform, I recently attended the Education Without Borders conference, where I had the opportunity to speak with several student delegates from the developing world. In most of the world, mobile phones take the place of computers; OpenMoko is an alternative way to spread mini-computers throughout the world and bring services to people for the first time.

Earlier this month, the OpenMoko project announced a delay. The delay seems to be due in part to the huge undertaking of the project. Linux could draw on an existing base of freely available source code to bootstrap the project, but the OpenMoko project needed to build a foundation before getting started. They found a nice field, imagined a grand castle, but then needed to start building shovels to dig the foundation. The team has had to write the tool chain almost completely from scratch while ensuring that it’s legally permissible to redistribute everything.

Sean Moss-Pultz brought an early demonstration phone to the conference. It’s a very early developer release. It still takes quite some time to boot, and has not been optimized at all. Even so, I still left drool all over the phone’s case when I got to touch it.

Here’s the phone itself, in my hand:

(I apologize for the bad resolution on these photos. I had to use a camera phone to get them, since my Nikon camera is not working.)

The form factor of the phone itself is comparable to my Nokia 6600. Here’s a photo of the Neo1973 next to a Nintendo DS Lite for scale comparison:

Finally, I met up with a group of folks from the project and the Silicon Valley Mobile Homebrew group. They’re trying to take the OpenMoko project and allow it to be further customized, even to the hardware level. It’s a great idea for people like me, since my idea of a high-end phone is likely to be slightly different from somebody else’s idea.

There whole point of HomeBrew Mobile is to make everything customizable, even down to the case design. Adrian Cockroft, the designer, brought along a 3D printout of the case for people to try out. Another person at the meeting had brought along the system board that’s being used by the project, so here’s what a Neo1973 looks like without the case:

On the hardware itself, there are two noteworthy points. The phone has an external antenna port, which should be beneficial if you live in an area with marginal reception. It also takes a “standard” Nokia battery. The software currently running on the Neo1973 doesn’t have any power-saving optimizations built in to it yet, so battery life was very short. When the phone was passed around the table, the battery died. However, I was able to take my fully-charged Nokia BL-5C and put it into the Neo1973, so we all got a chance to poke at the software. It also means that you’ll be able to use a large network of suppliers for spare batteries from day 1.

Now that I’ve seen the hardware and used the software, the wait hurts even more!

Summer Bedard of NYU’s ITP program just showed off an Asterisk-driven queue program. Queue managers aren’t really that interesting because most of them operate on a FIFO basis, perhaps with levels of priority for a few different classes of service. In this queue manager, callers compete with each other for places in the queue by answering questions.

The queue asks a series of questions, and depending on your answer, it will move you up and down the queue. For example:

Queue: “Are you decisive?” (yes)
But, if the answer isn’t fast enough, you move down the queue.

The funniest part of the demonstration was the following couplet:
Queue: “Do you procrastinate?” (yes)
(relatively long pause)
“Would you like to answer this question later?”

To try it for yourself, just call the phone number on the web page.

Today, Moshe Yudkowsky talked about revolutions and what causes them. His basic contention was that revolutions result from taking systems apart to separate concepts or structures that were previously bundled. That may be in the area of authority (such as the way that user-generated and selected content led from static web pages to community sites like Digg), mechanics, spacetime, and two other areas that I don’t remember. In Internet telephony, the revolution is largely mechanical, with the separation of the call bandwidth from its routing. The presentation then described how Internet telephony fit into the five classifications, though spacetime was curiously a set of question marks (”????”, plus a statement that people who figure this out will become quite rich).

We are only scratching the surface of VoIP and have yet to see the full implications the revolution, but a common thread to many of the presentations is to provide tools that enrich the context around a call. So many people use caller ID and a mental firewall that well more than half of the calls I make wind up in a voice mail box. In many ways, the separation of transport and routing makes VoIP even worse, since I have no idea where a call may land when I initiate it.

My own personal attempt to build some context into the calls I receive appears in the March 2007 issue of Linux Journal, where I built time zone awareness into the context of a call with Asterisk. Naturally, there are many other ways to build up the context around incoming calls, many of which have been demonstrated or talked about at the conference.

I use Google’s SMS service a lot, especially for directory assistance. It works great most of the time, but it could be even better by turning this into a location aware service. You can do this with two pieces of information and a simple rule.

First, you already know the sender’s mobile phone number. My cell phone is in area code 415 (San Francisco and Marin county). You can use the sender’s area code to guess their default or home location.

Second, the SMS gateway should be able to tell you the cell tower ID that the user is on. Map the cell tower ID to the antenna’s location, and you have a crude position fix, accurate to within a few miles or less. In most cases, you should know what town the sender is in (you might have to implement an opt in SMS script to get user permission to share location data).

The SMS service will then use the following simple rule:

* if sender does not include a city, state phrase in the query, assume this is a local search
* compare cell tower ID against database of cell tower sites to get lat/long fix
* if cell tower ID not available, use sender area code to guess location
* if search result is short, reply via SMS
* if search result is long, reply with SMS that includes http://x.y.z/abc pointer to temporary web page with search results

Then it’d be simple to do local search. For example, I could send a text message “laundromat”. If the service knows which cell tower I was on, it’ll know where I am within a mile or so. I get a test message back like:

“Laundromat : Near San Francisco. CA/Sunset : 3 Matches : http://sms.google.com/ae617210 for results”

I follow that temporary URL and get a mobile friendly web page with the search results and a map. To fine tune the way search results are sent back, you recognize a few commands like “set phone nokia n80″ or “set format html” so frequent users can get the most of the service.

That’s it, but with these relatively straightforward changes, Google SMS would be an excellent tool.

Reading the recent post about the poor state of voice mail, I realized that this is a perfect example of how bad the carriers are at innovation. This problem can be solved quite easily, without requiring a major overhaul of either voice mail systems or handsets. The solution works, more or less, like this:

1. a caller leaves a voice mail for you
2. voice mail system sends an SMS service message (e.g. “Msg from 4155551234 (John Doe) at 1:36pm”)
3. service message contains callback number to hear that specific message and/or URL for the audio file
4. if handset is smart, it fetches the audio file in background, displays it in a conventional inbox arrangement
5. if handset is dumb, it just displays the SMS message, you do a callback to a DID that plays that specific message when you call that DID from your mobile. With a pool of 100-200 DIDs, the phone company can provide random access to voice mail easily (if someone has more than 100 messages in their inbox, something’s wrong). if something goes wrong, the voice mail system defaults back to the usual sequential playback sequence

NOTE: an even better option is just to use MMS, it’s widely available now, but I use SMS to illustrate how this can be made backward compatible with really old handsets.

I am sure I am not the only person to have thought of this, and that somebody, somewhere has probably done this, but every voice mail system I’ve used in the US is stuck somewhere circa 1985. When you understand how easy it would be to improve something so many people use, it certainly makes you wonder what the carriers are thinking, if they’re doing anything besides cashing checks.

Asterisk VoIP News has posted some good tips for installing Asterisk on Fedora Core 5 from Matt Birkland, a Seattle Asterisk PBX Integrator. Fedora Core 3 and 4 are supported by Digium, but not 5.

The Zaptel drivers compile fine(get your 2.6-dev installed to be safe) the main problem is that ABE looks for specific libraries of older versions found in Fedora Core 3 and 4. Below is the list of failed dependencies and how to install the correct ones without breaking half the programs.

JupiterWeb, a division of Jupitermedia Corp have announced the winners for the Developer.com Product of the Year Awards for 2007. These 2007 awards mark the fifth year for this competition. The winners were nominated and selected by the users of Developer.com (www.developer.com). Under the category of Web Service Product of the Year the familiar Google Maps API took the award (no huge surprise and definitely a boon for geospatial technologies).

Ever wondered how Navteq keeps all that data up to date so you can make the most of those popular and useful Google Maps? In addition to a number of crews constantly driving the streets, adding POI information, recording attributes, making corrections etc… there’s also a very cool online application that lets YOU report incorrect or missing information - The Navteq Map Reporter

I split my time between the Bay Area and Argentina, and so to cut down on my telecom costs, I use VoIP (Gizmo in particular) quite heavily. In this short how-to, I share a trick you can use to get local DIDs (direct dial numbers) in some 50 countries worldwide.

So far, the success of Skype within their walled garden of VoIP has been quite impressive. One of the more interesting things I’ve learned from my travels is that Skype is extremely popular in Asia (at least outside of Japan) so much that in many places, “Skype” is synonymous with “VoIP.” However, there is benefit in using a standards-based approach, especially if that helps us to integrate Skype’s network in with the rest of the telephone network. This has long been a point of interest; Stuart Henshall wrote about Skype/SIP interactions more than a year and a half ago.

I’ve spent a good bit of my free time in the last month investigating three small-scale Skype to SIP integration packages. You can read the details at the link. Of the three that I looked at, ChanSkype was the most promising. It had a complex setup, but by far the best sound quality and it was also the easiest to integrate into the dialplan. A new version was released last week, but I haven’t been able to try it yet. Stay tuned…

One of the reasons that I was late to VoIP was that the initial services just weren’t that exciting. (To be fair to myself, I probably wasn’t really that late. I just feel like it sometimes because so many of my friends were first-wave early adopters.) Another way to connect up to a regular phone number was certainly interesting, but after having been a world-traveling GSM subscriber for years, the idea of getting a number that followed me around the globe really wasn’t earth-shattering.

VoIP is much more interesting when you can find ways of supplanting the telephone network instead of attaching to it. I recently signed up for an Internet Telephony Administrative Domain (ITAD) number. ITADs come to us from RFC 3219, and were originally intended to be part of an alternative telephone routing scheme. However, they’ve been re-purposed as a generic “Internet-style” telephone number.

Like an e-mail address, an ITAD Subscriber Number (ISN) consists of two parts. Within a realm, each user is assigned a unique number. The two are then joined with an asterisk, so that user number 123 in ITAD 456 would be addressed as 123*456.

If you’d like an ITAD number of your very own, there’s a short cookbook with instructions that take you from wanting a number to being globally reachable. When I applied to IANA, I had a response from them in one business day. (Unfortunately, I was busy traveling and sat on it for a few days. If I’d been able to respond promptly, I might have had a lower number than they do!)

If you’re running a PBX and want to call me, or more likely, somebody at one of the other ITAD-enabled organizations, it’s worth it to sign up. The cookbook has instructions for advertising your reachability in DNS, and there’s a project-run DNS server that you can use if you don’t have access to a DNS server that supports naming authority pointer (NAPTR) records. When I wrote to get my ITAD number added into that server, I had a response in less than eight hours, even though I submitted my request on a Sunday.

As I write this, I am in South America setting up an engineering office. I have been traveling globally for about 12 years now, and remember just ten years ago, when doing business here was very difficult, and very expensive. Now, it took me a matter of days to set up shop, and will take less than a month to have an office up and running. With Asterisk and Gizmo, we were able to build a truly global PBX, and to completely axe the requirement to buy an office phone system of any sort. We now have a business phone system that is accessible via a local call in 30+ countries, and that costs virtually nothing to operate and maintain.

Eric Y. Chen has posted an excellent article detailing Phil Zimmerman’s secure Zfone VoIP client on the Voice of VOIPSA blog. In A Tour Through Zfone, Eric clearly describes the functions and features of Zfone, with lots of informative screenshots along the way. Highly reccomended reading for anyone interested in this new VoIP encryption technology created by the father of PGP.

People are right to worry about SPIT. Once it becomes possible for people to make SIP calls from one network to another without a pre-existing peering relationship, it becomes possible for malicious users to start flooding those networks with automated calls.

There is, however, a simple solution that allows VoIP network providers to strike a reasonable compromise between openness (e.g. the ability for anybody to dial user@voipprovider.com, just as they might send an email via SMTP), and reasonable security measures to thwart automatic dialing.

One simple trick that providers can implement is to force callers to respond to a voice prompt like “To complete this call, dial 1 (random noise) 2 (random noise) 5 (random noise).” The goal is to exploit the limitations of automated speech recognition so that a bot cannot get past this IVR challenge question. The IVR will always play a slightly different sentence, so it’s not obvious where the spoken digits begin, and then will intermix the spoken digits with background noises that will confuse a computer. Same basic idea as prompting a user to transcribe distorted text.

Once the caller passes this voice captcha test, that user’s endpoint can be added to a white list so that subsequent calls can be processed automatically.

While this will not prevent robot dialers from hogging capacity on the IVR systems that answer these calls, it will be a good strategy to prevent these SPIT calls from getting through to live users or their voice mail boxes. This isn’t a cure-all in of itself, and should be used in combination with other techniques: such as building whitelists of VoIP networks that peer for each other, automatically identifying suspicious calling patterns to they can be blocked at the firewall, and so forth.

To record voice samples for the WMM comparison in my last post, I set up Asterisk for recording. I wound up using two approaches to this: a star code (*8) to preface extensions that indicated the call should be recorded, and an interactive voice demonstration.

First, the star code: by prefacing a number in the 5000 block of extensions beginning with *8, Asterisk would record the audio from the call. The snippet of the dial plan is only four lines. It picks up the the phone, calls the Monitor application, and then dials the extension after stripping off the *8. Here’s what it looks like:

exten => _*85XXX,1,Answer
exten => _*85XXX,n,Monitor(wav,/tmp/monitor-${CALLERID(num)}-to-${EXTEN:2}-${TIMESTAMP},b)
exten => _*85XXX,n,Dial(SIP/${EXTEN:2})
exten => _*85XXX,n,Hangup

The audio from the phone call will be saved in two files, one for each direction (”-in” for the voice from the phone, and “-out” for audio from the remote extension). After making a call, I could go pick up the “-in” file, which is a recording of what the stream of voice data sounds like after reaching the PBX.

The second extension that I set up was a “demo extension” that also uses a recording to allow subjective assessment of voice quality. Upon calling in, Asterisk would answer the phone, tell the caller whether they were using encryption and/or prioritization, record a voice sample, and play it back, allowing a caller to hear what they had just said. Here’s the dial plan code for it:

exten => 5901,1,Answer
exten => 5901,n,Playback(wmm-demo/welcome-wmm-demo)
exten => 5901,n,NoOp(Caller number is ${CALLERID(num)})
exten => 5901,n,GotoIf($[ ${CALLERID(num)} = 5221 ]?500)
exten => 5901,n,GotoIf($[ ${CALLERID(num)} = 5231 ]?100)
exten => 5901,n,GotoIf($[ ${CALLERID(num)} = 5232 ]?200)
exten => 5901,n,GotoIf($[ ${CALLERID(num)} = 5233 ]?300)
exten => 5901,n,GotoIf($[ ${CALLERID(num)} = 5234 ]?400)
exten => 5901,n,NoOp(You should never get here!)

exten => 5901,50,Playback(wmm-demo/wmm-demo-record-prompt)
exten => 5901,n,Record(/tmp/wmmdemo-${CALLERID(num)}:wav)
exten => 5901,n,Wait(1)
exten => 5901,n,Playback(/tmp/wmmdemo-${CALLERID(num)})
exten => 5901,n,Hangup

exten => 5901,100,NoOp(Clear/NoWMM handler)
exten => 5901,n,Playback(wmm-demo/nowmm-clear-greeting)
exten => 5901,n,Goto(50)

exten => 5901,200,NoOp(Clear/WMM handler)
exten => 5901,n,Playback(wmm-demo/wmm-clear-greeting)
exten => 5901,n,Goto(50)

exten => 5901,300,NoOp(WPA2/NoWMM handler)
exten => 5901,n,Playback(wmm-demo/wpa2-nowmm-greeting)
exten => 5901,n,Goto(50)

exten => 5901,400,NoOp(WPA2/WMM handler)
exten => 5901,n,Playback(wmm-demo/wpa2-wmm-greeting)
exten => 5901,n,Goto(50)

exten => 5901,500,NoOp(Unex handler)
exten => 5901,n,Playback(wmm-demo/unex-greeting)
exten => 5901,n,Goto(50)

The only hard part to writing the demo extension (actually, anything interesting in the original Asterisk dial plan language) is that I had goto statements stamped out of me many years ago in my first serious computer science class. I’m sure that Mrs. Guerin would be pleased that I can’t write a goto statement without remembering the dire consequences for my grade, and that I’m considering switching to the Asterisk Expression Language.

A month ago, I was staging the Interop Labs, with a particular personal focus on VoIP on 802.11. At that point, I promised to investigate what improvement Wi-Fi Multimedia (WMM) prioritization makes to voice quality. The Interop show floor is a terrible radio environment. From the Interop Labs booth, I can see between 40 and 70 access points. In this environment, WMM makes a huge difference.

We’re running the Interop Labs on Asterisk. To show off the difference in voice quality, I configured Asterisk to record the incoming voice stream from the 802.11 phone. You can listen to the results, and see what a difference WMM makes. Both recordings were made just after lunch (about 1:20 pm) on the second day of the show, which was one of the busiest times for us in the booth.

So, without further ado, here are the three recordings:

• Introductory remarks. Before the show opened, I recorded a 5-minute introduction to the technology and the challenges we hoped to investigate. This recording was made from a wired phone about ten minutes before the expo floor opened.
• Non-prioritized voice. This recording is a bit over one minute long, and was made between a phone and an access point that don’t support WMM. You can hear the effects of the heavy background traffic in the frequent dropouts.
• WMM-prioritized voice. In the final 2-minute long recording, the voice is prioritized with WMM between the Unex WP2 phone and Trapeze wireless infrastructure. (This is one of the first, if not the first, public interoperable WMM demonstration.) Although the conversation breaks up, it happens less frequently and the dropouts are far less severe.

One important note: I recorded these samples at the PBX, so there’s only one wireless hop in them. A call between two wireless phones would have double the opportunity for packet loss or delay, and the difference between prioritized an unprioritized traffic would be even more striking.

Ever since getting a MacBookPro I’ve been lugging around 2 laptops just so that I could use my Verizon EVDO connection. The new Mac laptop has an Express/34 slot which meant my older PCMCIA Type 2 card was no longer compatible. Trips to Fry’s hunting for Express/34 cards have been painful, all the reps I talked to had never even heard of it.

While I wait for a USB or Express/34 EVDO Verizon compatible card to come on the market I have been using the Kyocera 650 on my PC and routing the connection through WiFi to my Mac. That’s one expensive personal router! Not to mention, it’s heavy. BTW Linksys and Kyocera both have 3G routers on the market that support a variety of PCMCIA cards.

Good news: I got the Elan Digital Systems U132 USB Card Reader working on my MacBook’s XP partition. My back is very excited!

Once I installed the elu132 driver all I had to do was setup a modem connection and configure the modem to dial #777.

Now, if only EDS had OS X drivers I’d be really psyched. Still, this is a major welcome addition to the world of MacBookPro Mobile Broadband service. And, another great reason for Apple’s BootCamp project.

Finally, if you’re wondering: the Kyocera 650 does in fact support VoIP calls (despite the sticker on the box that says otherwise).

Note: If you configure a few extra settings on the Modem, such as port speed, dramatic improvements will be noticed. In fact, the Elan drivers appears to offer increased upload and download speeds. I believe I was capped at 56K up before, that’s no longer the case.

Carla Schroder points us to her excellent three-part series on Building an Asterisk@Home Test Lab over on Enterprise VoIP PLanet:

Learn how to build an Asterisk@Home test lab. This series is also a good howto for setting up a small production Asterisk iPBX on the cheap. This three-part series is aimed at both telephony and Linux noobs. If you understand computer networking basics, this is just the Asterisk howto you need to get up and running. Not only for a test lab, but also a small production system. The series covers installation, what hardware to use, how to set up local extensions and automatic call routing, how to connect to the outside world, and how to replace the Asterisk@Home logo with your own custom logo.

VoIPowering your Office with Asterisk - Building a Test Lab, Part 1
VoIPowering your Office with Asterisk - Building a Test Lab, Part 2
VoIPowering your Office with Asterisk - Building a Test Lab, Part 3

Our pals at Makezine noticed this write-up in Popular Science on a low cost way to do your own cell phone tracking using the Mologogo service:

Cue the Mission Impossible theme. I’m working a top-secret operation, and my support team is monitoring my every movement. OK, so I’m just going to the hardware store, but my girlfriend, Jen, is tracking me. Using a $100 kit from Mologogo (with a $6-a-month data plan), I’ve turned a prepaid cellphone into a GPS tracking device. Every few minutes, the phone transmits my location within 100 meters to mologogo.com, which posts it to a Google map that Jen can access from any computer. She can view my most recent spot or my past 100 recorded locations as little pushpins stamped with date and time.

Last week, I was at the Interop Labs working with the VoIP Security and Integration initiative. Before arriving, we set two major tasks for ourselves. One is to look at how VoIP interacts with security products (particularly in light of the counter-intuitive SSL VPN call quality improvements that were observed recently). The second, and much more interesting objective from my perspective, is to look at how much 802.11 phones have improved in security and quality of service from a year ago.

Makezine is pointing to a plan for building a mobile mesh repeater node that can be used in a variety of settings, including when the communications infrastructure has been damaged in a disaster.

After Hurricane Katrina hit, BellSouth announced that it would take 3 months to restore phone lines. Volunteers using WiFi gear were able to connect churches and community centers within the first weeks and within three days of setting up an asterisk call server, routed 10,000 phone calls. Reliable backup infrastructure can be brought up in hours or minutes if you are prepared and have a plan in place.

(If you haven’t checked out the Instructables site that this plan is posted on, I reccomend giving it a spin. It’s a great and inspiring resource for DIY folks).

I’m back home from the Interop Labs, and I am starting the my next technical project. Soon, it will be initiative season in California’s political cycle, which means that political surveys, telemarketers, and presumably, push pollers will soon be upon us. I intend to build an Asterisk server to keep them away from my phone. I also want a PBX so that I can continue to study VoIP, especially VoIP on 802.11. Before I could start working on Asterisk, though, I had to get the motherboard BIOS straightened out.

Last summer, I wrote that reliability should not always be a goal in network design, especially with applications like VoIP. “Better late than never” is true for a stream of bits you need to reproduce perfectly, but it’s not the case for a stream of bits you’re trying to deliver in less than 200 milliseconds. If something is late, it’s better to forget it and move on.

Well, as the saying goes, the difference between theory and practice is greater in practice than in theory. The always-interesting Joel Snyder recently tested VoIP call quality through a variety of VPNs for Network World. From the pure theoretical perspective, going through a VPN technology that ensures in-order delivery should offer no help to call quality, and would be expected to cause some problems, especially on low-reliability networks that have frequent loss and retransmission.

That’s not what he found. After finding that call quality improved when using SSL, he used a network analyzer to find out what was going on:

In every case, adding an SSL VPN to a VoIP call over a good broadband network improved call quality. So in effect, wrapping a VoIP call in SSL gives it more structure, kind of like the rind of good Brie. What we had not counted on was the huge difference between what VoIP requires (64Kbps) and a typical broadband connection of 500Kbps or more. Because the broadband connection was so fast, TCP was able to repair the impairments without reducing voice quality.

(I’ll disagree with Joel on the cheese analogy, because I hate Brie. Rind or not, I find it disgusting.)

To see the improvements, check out the pop-up graph about half-way through the article. It’s a graph that compares the mean opinion score (MOS), a measure of call quality, to an unencrypted reference for four test scenarios. Data points farther to the right are better.

The biggest surprise came from the test on the “bad” network (the orange data points in the picture). SSL VPNs delivered a signifcant performance improvement. On the graph, you can see that the orange data points are far to the right of the unencrypted reference line, and offer the widest gap between the reference line and the measured SSL-protected quality.

The best news of all our testing came when we set up the bad network, representing the lower end of quality of the broadband services. In this test, TCP and a high-speed network again came to the rescue. All but three of our SSL VPN vendors also improved the unacceptable call but took call quality up enough for the call to be considered acceptable. In these tests, we saw as much as a 45% to 50% improvement in call quality.

Interestingly, the call improvement is specific to SSL. Juniper’s product offers two operational modes, SSL (which is based on TCP, and therefore does re-order packets) and IPsec ESP (which is an IP datagram service, and does not). The SSL mode resulted in significantly better call quality as long as the network was providing decent service. In the last test, with a very poor quality network, the datagram services provided the best call quality, but it was still so bad as to be unusable.

I only have one minor technical nit to pick with the article. It states that a phone call requires 64 kbps. It requires 64 kbps of data payload throughput, but adding on the encapsulation headers for UDP and RTP pushes the required throughput to 80 kbps. (See Table 1 at the bottom of the first page in my VoIP capacity analysis for more codec details.) As the test shows, 100 kbps is not enough to sus