A country code for VoIP
I saw on boingboing
a few days ago that there's now a country code reserved for Internet
phones. I had a little difficulty understanding what that meant, but
think I've got it now. Essentially, this is a way to bring VoIP phones
into the standard phone number namespace. It is in this sense a dual
of ENUM, which is a gateway to access the phone number namespace
From what I can see, this new country code is being run by FWD (Free World Dialup). You
register for a free account using a simple, straightforward Web form,
and you get a number. Mine is 18408. Then, you point your SIP phone's
config to the FWD server, register, and then when people query the FWD
server for your number, they find your phone. For example, to reach my
phone, dial sip:firstname.lastname@example.org (try it; I'll try to keep a phone
This number also now exists in the POTS number namespace, but your
phone company won't route to it yet because they're evil. As soon as
public pressure overcomes their evilness, you'll be able to reach my
VoIP phone simply by dialing 011 +87810 18408 from your US phone.
I think this is a huge step. To the extent that people can call your
phone, it makes it practical to go VoIP only. Of course, you can do
that today with a service such as Vonage, but that costs $40/month, and
this is free.
From what I can gather, FWD is going to make a little money off "long
distance charges" from phone companies that peer with them. I like
this idea - it would seem to provide a revenue stream that would
actively promote the use of VoIP phones. You can bet that the telcos
are going to drag their heels as much as possible.
I think there's one more piece to this, which is phone cards.
Even if your scumbag incumbent telco won't peer with FWD, you'll
probably be able to shell out $20 for a phone card with a company that
will. There's no reason why these companies can't provide service for
a penny or two a minute. The standard phonecard service, after all, is
basically two telco to Internet gateways joined back-to-back. Here,
the caller just buys one of them. So this basically solves the problem
of being callable by my Mom. All she has to dial is 1-800-call-crd,
then a (typically 10 digit) pin, then 011 87810 18404. Only 34
digits, but at least she'll be able to reach me.
PC's running phone software don't make good phones. A dedicated piece
of hardware is better. Even aside from the general flakiness of sound
cards and drivers, phones are a lot better at ringing and being always
You can buy a phone like a Cisco ATA 186 for about $150 from eBay, but
I think the price is going to come down to $50 or so once D-Link or
Linksys gets into the game. Basically, it's the same gear as a phone
with a built-in digital answering machine (AT&T brand $30 at Best
Buy), plus a 10/100 Ethernet interface.
In any case, I tried out kphone and gnome-meeting again, and was
successfully able to complete calls with both. I had trouble compiling
GM 0.96, so no doubt I'll give it another go when I upgrade to RH 8.1.
I'm less impressed with kphone. I could receive audio ok but not
transmit, so I took a look at the code to see what was wrong. The
actual audio interface code is buggy and unsophisticated. One of the
most basic problems is their use of usleep(0) to wait for the next
timer tick for basic scheduling. This, of course, is hideously
dependent on the details of the underlying kernel scheduler, and in
any case, gives you very poor temporal resolution on PC hardware. Even
worse, if 5 ticks go by without an audio packet being ready, the code
reads a packet and drops it on the floor, for what reason I don't
There's also a problem with the kernel audio drivers I'm using (alsa
0.90beta12 with Linux 2.4.19). Even though kphone does a
SNDCTL_DSP_SETFRAGMENT ioctl to set the fragment size to 128 bytes,
the actual value, as returned from SNDCTL_DSP_GETISPACE, is 2048
bytes, which is way too big (it's 125ms). Combined with the
packet-dropping logic above, the net result was no audio.
People should not have to worry about this. I think it makes sense to
wait until you can get a Chinese-made phone with Speex in it at
commodity prices. Hopefully, this will happen soon.
A good homepage
I came across Miles
Nordin's web site last night after following a link
from the Java
discussion on our front page. I found myself immediately observed.
Miles writes well, is well read, and has a fabulously critical
attitude. Many of the other pages, especially those having to do with
wireless networking, are worth reading.
I basically agree with everything you say. If Abiword or OO are good
enough, and the code is clean enough to be split out as a batch
renderer, then there's no need for a separate codebase.
I've had a look at the Word document format, and it's not quite so bad
as I was expecting. The documentation is atrocious, but the
format itself seems fairly reasonable. Of course, I'm sure that if I
got into the details I'd find lots of corner cases and bad hacks.
The main thing not to like is the obvious lack of design for forwards
and backwards compatibility. No doubt, this is economically motivated
- gotta keep that upgrade treadmill going.
On the plus side, the format was clearly designed with an
implementation in mind (as opposed to the W3C process, for which
implementation is a distasteful afterthought). It's fairly easy to see
how to process a Word file very efficiently, in both CPU time
and memory usage. For example, resolving stylesheets is a
straightforward linear chain, as opposed to all the nutjob
nondeterministic stack automaton stuff in CSS, or the mini-Lisp in
I'm tempted to write here about Word's plex/fkp/character run
architecture as opposed to the more generic tree approach we tend to
see these days, but probably most people would be bored with that
level of detail. The top-level point is that algorithms for
manipulating Word's structures on-disk are straightforward, while
manipulating trees efficiently on-disk seems to require a lot of
cleverness. Of course, with RAM so cheap these days, it's reasonable
to ask whether memory-constrained processing of files is important at
The Word format is too tightly bound to a specific implementation, and
it certainly shows in what documentation Microsoft has produced. They
often seem to confuse the interface, which in this case is the on-disk
representation of the document, with the implementation details.
In any case, I'm glad I've learned more about the file format. Its
popularity means we have to deal with it somehow. Further, as PDF
continues to become document-like and less of a pure graphical
representation, it's important to understand the influence that the
Word design has on its evolution.
I've commented before on the need for a good, open, editable document
format. The lack of adequate documentation and Microsoft's proprietary
lock on change control make the Word format unappealing. I've
certainly thought about designing my own document format, but it's not
easy to make a word-processing format much better than Word, or a
graphics-oriented format much better than PDF. So that's probably a
windmill I'd be happiest not tilting at.