Most people reading this weblog have heard of ENUM by now. Or at least the promises: "ENUM eliminates printing URLs on business cards! Your 10-digit phone number will identify your email address and webpage using the magic of DNS!" Essentially, the entire E.164 hierarchy will be mapped onto DNS under the e164.arpa zone. Phone numbers will be broken up by digit, so at each digit the tree can be delegated to an organization responsible for smaller and smaller geographic areas, until potentially the individual phone number can be delegated to the owner of the phone number. The number owner can populate the zone with NAPTR records containing an IM address, email address, SIP address, webpage, and whatever else they may want to store there.

Privacy arguments aside, at first glance this seems asinine. Why, in the age of DNS, would anybody in their right mind want to revert to using numeric strings as identifiers? Isn't something like jsmith@corporatesoft.com much more memorable and self-descriptive than 17123514225? If numbers were better, the DNS system would have never been invented in the first place and we'd all be typing user ID numbers and IP addresses into our email clients.

The only vaguely permissible excuse would be backward-compatibility with devices having only a numeric keypad; telephones being the obvious one. But hold on a tic; if it's so hard to enter a real email address or IM screen name into a telephone, wouldn't it be equally difficult to type the actual message that you want to send?

So anyway. Regardless of the marketing hype, ENUM excited me because it allows SIP addresses to be tied to phone numbers. This bootstraps VoIP from the phone system, in a sense, because VoIP customers and carriers can use ENUM to determine whether a call can be carried over the Internet rather than the PSTN. Presumably, a call made from one CLEC to another can be completed through the Internet without the need for a peering agreement. This ad-hoc, peer-to-peer architecture is the basis for the infrastructure of the Internet as we know it, and is the key differentiator between the Internet and old-style circuit-switched networks.

ENUM is starting to be deployed across Europe, and a rational mechanism is used to delegate responsibility for each portion of the e164.arpa tree. Generally, the country code is delegated to the federal government or a neutral national body, who delegates the top-level number assignments to the phone companies. Then the phone companies allow the customers to control the entries for their number, much like controlling how the number is listed in the phone book.

You'd think this framework would be fine for the North American country code. Apparently not. An international body, the ENUM Forum, was formed to come up with a plan. And it couldn't be simple: the current working revision paints a complex picture defining a system of registrars to manage the ENUM tree as an entirely separate world from the phone companies.

Here's how it works: a "Tier 1" registrar will be appointed who runs the DNS servers for the 1.e164.arpa zone. Then "Tier 2" registrars will take orders from customers to register their own phone numbers. Tier 2 tells Tier 1 to delegate the phone number's corresponding zone to the Tier 2's DNS servers, and Tier 2 manages the NAPTR records for the customer.

Huh??? What's going on here? The phone companies that own the phone numbers will have absolutely no control over the ENUM zones? The 1.e164.arpa zone will be a flat namespace instead of a tree? And worst, I'll have to pay to register a phone number that the phone company already assigned me?

So much for using ENUM as a carrier-to-carrier tool. If CLECs don't get to fill their own ENUM zones, the leap from PSTN to VoIP depends on customers to bridge from E.164 numbers to SIP by themselves. Slowly it will happen, as businesses and individuals become aware of the benefits of VoIP, but it will proliferate like fax machines—the customers will build the network from the edge, rather than having a guiding organization to do it from the inside. Ultimately, the marketplace will be best off with the customer in control of his telephony choices, but the telecom industry will have to migrate to VoIP without the benefits afforded by the world-wide cooperation that fostered the Internet of today.

As I said last time, I'm trying to figure out the best way to drive an IVR system using Perl. All of the platform components, like the SIP agent and RTP streamer, talk to the central control script using D-Bus calls: events like incoming calls generate asynchronous events and the control script can use method calls to perform actions like answering the call, playing sounds, etc. In practice, this makes the individual components become nice non-threaded event-driven things, which improves the scalability. Unfortunately, it also makes the control scripts more complicated.

I'd like users to be able to write scripts like this:

$call->answer();
$call->play_sound( "hello.wav" );
for(;;)
{
	$call->play_sound( "main_menu.wav" );
	$a = $call->get_dtmf_digit();
	if( $a == 1 )
	{
		$call->transfer( $numbers{"marketing"} );
		break;
	} elsif( $a == 2 )
	{
		$call->transfer( $numbers{"accounting"} );
		break;
	} else
	{
		$call->play_sound( "invalid_entry.wav" );
	}
}
$call->hangup();

This seems simple, until you think about asynchronous events. What happens if the caller never enters a digit? Do we time out? If so, do we break out with die() or return an error from get_dtmf_digit()? If we return an error, does the programmer have to check for errors every time the script waits for input? What if the user enters multiple digits? Do we throw the extras away, or buffer them in case we need more input?

It gets even worse when dealing with scripts that might block. What happens if a database call freezes and the caller hangs up? When do we notify the script? Do we kill it immediately, to free up resources and prevent the system from being tied up? Or do we wait for the database call to time out to allow temporary files and what-not to be cleaned up?

The other problem I'm contemplating is the abstraction between Perl and C. The D-Bus stuff has to live in C since there's no Perl interface to D-Bus. But do I make the Perl->C interface specific to the signals and methods used by this SIP platform, or do I make it generic enough to be used with any D-Bus component? If I go for the generic approach, does that complicate scripts since I can no longer diddle directly with the Perl interpreter? If I go for application-specific calls, does that limit compatibility with future components?

Right now I'm leaning towards the simplest implementations, just to get something out the door. But I still get that nagging feeling that I'm going to cause myself some pain later down the road...

Over the past month or so, I've been trying to put together a new platform to sit at the center of a SIP-based VoIP network. As VoIP starts to take off, I'm unsatisfied with the current solutions in the open-source community for providing PBX-like services for IP phones, so I'm trying to figure out what a "good" architecture would look like. Currently, we have SIP Express Router, the most popular SIP proxy/registrar in the open-source world, the VOCAL service platform, which everybody hates, and Asterisk, the PBX-in-a-box that supports all the bells and whistles you could ever need.

SER is a great product, featuring unwavering RFC compliance, strict attention to optimisation, and good old-fashioned German engineering. It has some weaknesses, such as the bizarre, half-baked interpreted language used for processing incoming transactions, but overall I've been quite pleased with it. Free World Dialup handles almost a hundred thousand calls daily through a single server running SER.

Asterisk is a PBX-like system, started in 1999 before VoIP became popular. Its architecture strongly resembles traditional PBX systems, with all signalling and audio from dumb user terminals (phones) running into a big black box that performs all the processing. While this is fine if you're still using POTS or POTS-like phones, but it seems silly for SIP. If two SIP UAs are able to send audio directly between each other, why insist that the media still be sent through the server? I have other issues with Asterisk as well, such as the lack of scalability, but this Centrex-like architecture bothers me the most.

The problem is that no other free VoIP product offers the features that Asterisk does. While SER provides an excellent SIP signalling and call control platform, you cannot find a powerful voicemail system, IVR capabilities, or PSTN interfacing anywhere in the open-source world besides Asterisk. This is why I'm working on my own.

The goal of the new architecture is to provide an open-source IP-based platform that can accept and redirect calls with SIP, and provide Interactive Voice Response capability on an RTP session. Currently the system is divided into components that handle SIP interfacing, RTP streaming, and call processing using an embedded Perl interpreter. All the components are tied together using D-Bus, which offers both remote procedure calls and asynchronous signalling in a network-transparent way. Splitting the components this way allows the system to be scalable across a server cluster, allowing, say, two SIP frontends to control RTP streams from twenty backend streaming servers.

I have most of the components working now, but it will take some time to figure out the right way to provide the Perl interface for call handling. More on this later.

Yes, you read that right: "Verizon Communications will begin selling Internet telephony services to broadband customers early next year". But wait, what are they really offering? "[T]he company plans to begin offering unlimited dialing between broadband-enabled computers for a flat fee." Excuse me? Calling between broadband-enabled computers has been here for many months, through services like IPtel and FWD, and it is such a trivial service to provide that nobody charges a dime for it. And now Verizon thinks they can get people to pay for the privilege?

But maybe there's something to this beyond the SIP registration service. Perhaps they're planning to offer Quality-of-Service for VoIP calls on last-mile links? That would make this PC-to-PC service an interesting prelude to the PC-to-phone service that they're talking about offering later. At least until home router manufacturers start supporting VoIP with QoS in their devices, eliminating the incentive to pay Verizon a monthly fee for the same service.

It should be interesting to see how this plays out. I fully expected the Bells to attack VoIP through regulatory channels, which has already started, but I didn't expect them to enter the consumer VoIP arena quite so quickly.