IT

I recently had a project where I needed to find out what telco served users based on their phone number (US only). Area code tables are a dime a dozen, but only give you the state, and I needed finer granularity than that, including the ability to drill down to the first three digits of the local phone number, for a total of 6 digits known in industry parlance as the NPA-NXX.

The solution I found is to go straight to the source: the website of the company tht administers the North American numbering plan on behalf of the FCC (the NANP actually covers more than the US, including Canada and some Caribbean countries, but the registrar I am refering to only covers the US).

They have a very convenient page with downloadable tables of NPA-NXX to carrier assignments. As an example, here is the entry for my home phone number:

Entry for 415-359-0918

State	NPA-NXX	OCN	Company name	Rate center	Switch	Use
CA	415-359	9740	Pacific Bell	SFNC CNTRL	SNFCCA12DS0	Assigned

OCN is the operating company number, a numeric code they use for carriers. The “rate center” (usually the city or town name) is unfortunately encoded using the proprietary Telcordia Common Language standards rather than in plain English, and you need to pay a license fee to get that database. The carrier name also varies wildly. Pac Bell has been fully subsumed under the SBC brand name, but the old identity still linger in these tables (Verizon, in contrast, has been much more diligent at having these tables updated, even when the pre-merger name is still mentioned).

With number portability, specially the forthcoming wired to wireless number portability required by the FCC, this information will be less useful as you will be able to have, say a New York phone number but actually be in Tokyo using a Vonage VoIP box (possibly even one with a ported number), but it is still a useful resource that is not widely known.

Update (2004-10-25):

This page is the most popular Google search on my website. If all you want is to look up a phone number and don’t want to go through the hassle of importing all the NANPA tables, there are a number of NPA-NXX search pages available on the web.

Many e-commerce sites have session timeouts. Dawdle too long between the moment you enter the site and the moment you actually want to buy something, and you will be presented with an unpleasant message. The words “session timeout” will be there, drowned in a sea of technobabble, and you will have to restart from scratch. Using a bookmark will often have the same effect.

At this point, you may well be tempted to go shop elsewhere; indeed, it is the only principled response to such blatant contempt for customers. You will notice that successful sites like Amazon.com do not make their customers suffer such hassles – once you’re in, you are in, whether you have to take a lunch break or not. I don’t buy the security argument either – there is nothing sensitive about the contents of a cart, security belongs at checkout time, not browse time.

The reason why such crimes against usability are perpetrated is that business requirements too often take a back seat to technical expediency, paradoxically most often due to lack of technical competence. Many web development environments keep track of what you do on a website, the contents of your cart, and so on, in “sessions”, portions of memory that are set aside for this book-keeping purpose. They cannot be set aside forever, and must be purged to make room for new customers.

The tyro programmer will leave the default policy in place, which is to dump the session altogether and place the burden of recovering state on the customer. More experienced programmers will implement the session mechanism in a database so it can be kept almost indefinitely. In an era where disk space costs a dollar or two per gigabyte, and a desktop computer has enough processing power to crunch tens of thousands of transactions per minute, there is no justification for not doing so.

I have seen some hype building up about ENUM (RFC 2916) recently, suggesting that ENUM will finally make Voice-over-IP (VoIP) leapfrog traditional telephony.

First of all, what is ENUM? It is simply a means for a VoIP program like Microsoft Windows Messenger or Apple’s iChat AV to find how to reach a correspondent from a phone number. First-generation VoIP programs required users to enter the IP address of their correspondent to call them, or to use non-standard or semi-standard directory services like Microsoft’s short-lived ILS. Since most people wouldn’t recognize an IP address if it bit them on the nose, this limited the market to geeks or incredibly determined penny-pinchers. With ENUM, if you know my phone number, say (415) 359-0918, or if you use the ITU-T E.164 international numbering standard, +1 415 359 0918, you would find the IP address of my VoIP phone/program by looking up 8.1.9.0.9.5.3.5.1.4.1.e164.arpa in the DNS. This is the reversed E.164 phone number, with e164.arpa tacked onto it, the way you can do reverse domain name lookup of the IP address 198.144.198.154 by looking up the PTR record corresponding to 154.198.144.198.in-addr.arpa. The .arpa is a legacy of the days when the Internet was bankrolled by the US ARPA, now the Defense Advanced Research Projects Agency (DARPA), and cause no little grumbling from people who would rather have a more “neutral” root e164.int.

This is a clever hack, allowing VoIP clients to leverage the DNS infrastructure, rather than building new protocols or even leveraging existing ones like LDAP. Every modern computer from Palm PDAs to Windows PCs to IBM mainframes have built-in DNS clients (although few support the ridiculously over-engineered new NAPTR resource record introduced for ENUM in RFC 2915). LDAP client libraries are nowhere near as widespread. Implementing ENUM is thus relatively easy, in the order of a few days of work at most, assuming the underlying name client software is not hardwired for IP address resolution only. In a similar way, a few years ago a group of young turks unsuccessfully proposed the ITU set aside an international country code for VoIP calls (the decimal IP address would be encoded as a 12 digit phone number). The old ITU proposal addressed the issue of getting conventional phones to reach an IP address, ENUM addresses how to reach a conventional phone number from an IP phone.

That said, while ENUM simplifies some of the logistical issues of managing a federated namespace or numbering plan, the bulk of the effort in transitioning to VoIP lies elsewhere:

• Making IP phones as convenient as traditional phones (waiting 5 minutes for Windows to boot does not quite qualify).
• Providing the same level of resiliency as the old network, for instance in case of power failure (when I was in Telecom school, one of our teachers always insisted on the fact when phones fail, people can die because emergency services are not dispatched any more).
• Providing gateways between traditional telephony and IP telephony, and finding a sound business model to pay for it.
• Figuring out how billing and compensation will be handled
• Increasing competition by allowing direct calls when both users are VoIP capable, without having to know this explicitly beforehand.
• Improving the ubiquity of IP connectivity, specially residential broadband and wireless.
• Improving IP network quality of service, since Quality of Service approaches do not scale and end up being even more inefficient than the old network.

ENUM does not address the chicken-and-egg syndrome that is slowing VoIP adoption. A significant proportion of telephone calls is now carried over IP, for instance AT&T and MCI have both declared their intent to migrate over half their voice traffic to IP by 2005. But that is invisible to end-users, and not accessible – you won’t be able to dial an AT&T user by the IP address AT&T uses internally for them. AT&T will not give it to you because then they would not be able to bill you for it the way they can bill other telcos with interconnect agreements.

As the global E.164 numbering plan is controlled by the ITU and delegated to Telcos, ENUM will not by itself make it possible to create new phone numbers that are not controlled by Telcos. A competitive service provider could petition to obtain a number range, the way Vonage obtained US phone numbers for its VoIP service, but telephone billing has assumptions on the structure of phone numbers deeply embedded within it, probably inextricably. After all, it has taken carriers over ten years to learn to bill calls towards mobile phones in Europe differently by detecting they have a leading 6 digit.

Conceivably, the ENUM NAPTR resource records could be served from any domain name, not just one under e164.arpa. One could imaging that in the future, instead of giving a nineteenth-century style phone number (the first Strowger automatic phone exchange was installed in New Haven, Connecticut in 1891), you would give out a domain name (“call me at fazal.majid.info“) or something that looks like an email address. But that is not what ENUM offers (today), in part by design.

I bought a Sony Clié UX50 PDA a few weeks ago. I started noticing that every time I restart my PC (admittedly, not something I do all that often), an incredibly annoying Windows Explorer window set to C:\Program Files\Sony would pop up at the end of the boot sequence.

After a little analysis, it turns out the Sony installer created a registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Palm MulitUser Config with the value C:\Program Files\Sony Handheld\Configtool.exe. Enclosing that in double quotes using Regedit (insert obligatory admonishments about the dangers of Regedit here) fixes the problem. Click here for a screenshot of what it should look like.

Without the double quotes, Windows is thrown off by the space between “Sony” and “Handheld“, and assumes you want to run the command C:\Program Files\Sony with the command-line parameter Handheld\Configtool.exe. As there is no such command C:\Program Files\Sony, Windows just runs the default action for that object, which is to open it in a Windows Explorer window.

I wouldn’t have gone in such excruciating detail about this issue, except:

• Somebody else annoyed with this bug might find this resolution via Google
• It shows how sloppy Sony is about testing its software installers (in passing, note the typo “MulitUser” instead of “MultiUser“)
• That registry folder is where all the startup items that aren’t in the Start menu reside. You might want to have a look at it to see what odd junk resides there, such as obnoxious system tray items like RealPlayer.

Update (2004-01-12):

Sony has an official fix for this problem: PDTREGISTRYUPDATE.EXE.

I switched my long-distance telephone provider to SBC earlier this week. On general principle, I would rather avoid funding incumbent monopolies, but their $49/month unlimited local and domestic long-distance package is very attractive, and the competing alternatives like MCI’s The Neighborhood are not available in San Francisco yet.

The main factor leading to flat-rate plans is a series of FCC regulations named CALLS that entered in effect in July 2000. Prior to these rules, the local phone companies would skim 6 cents per minute in “access charges” from the long-distance company, which would have no recourse but to pass the cost on to consumers. This is why long distance prices were on a plateau of 10 cents per minute for such a long time.

The previous regulations entrenched the concept of cost per minute in the economic structure of telephony, even though it is almost entirely a fixed cost activity. Joe Nacchio, former CEO of Qwest, famously boasted that “Long Distance is still the most profitable business in America, next to importing illegal cocaine”. CALLS slashed these access charges, removing the main impediment to flat-rate pricing.

Former AT&T researcher Andrew Odlyzko has made a compelling argument for flat-rate pricing, noting that most people prefer it to metered plans, even if they pay more for it, flying in the face of most economists’ conventional wisdom (that says more about how disconnected from reality economists are than anything else).

I have managed a large telecoms billing system project, and an interesting point, seldom made, is that billing for metered services is in itself very expensive. Collecting all the traffic information, storing it, rating it, calculating the bills, invoicing, accounts receivables, dunning and handling customer complaints involves huge IT budgets and systems so complex that over 70% of new billing systems projects fail. For example, France Telecom spent almost half a billion dollars on its would-be next-generation billing system, Fregate, before pulling the plug. Most Baby Bells are still running CRIS, a creaking sixties-seventies mainframe-based billing system they inherited from Ma Bell.

There is clearly a point at which services become too cheap to meter, or more precisely, metering becomes too expensive. We may have reached that point already for voice, even if the dinosaurs don’t realize it yet. The only thing that is keeping per-minute charges alive is customers’ inertia, never a factor to be underestimated, to be sure.