The word “peer” is a busy one in Internet lingo. There’s “peer to peer,” often abbreviated “P2P,” which usually describes file-sharing methods for broadband-connected computers. It’s a big topic, with lots of offshoots.
Then there’s “peering,” also known as “IP Peering,” and the subject of this week’s translation. (The “IP” stands for “Internet Protocol.”)
Right now, when people mention “peering,” they’re usually talking about broadband-service providers who want to directly link their routers. That way, an e-mail message from me to you gets to you in the most direct way possible, even though we probably use different Internet-service providers.
Peering for data, in fact, is the norm these days — but it’s just the beginning. IP peering is poised to go much further.
PEERING FOR VOICE TRAFFIC
Take voice, for instance. If you’re a cable operator, you’re offering voice to round out the bundle and to subtract market share from incumbent telcos. If you were to peer your IP networks for voice services, though, you could do all that, plus save a pile of money.
Here’s where the pile of money comes from. Right now, most cable operators are providing voice services over their IP plant, but only up to a very specific handoff point. Generally speaking, it’s the juncture where the Internet ends and the public-switched telephone network (PSTN) begins.
Because they haven’t yet formalized “peering” arrangements among themselves, to directly route VoIP calls between their footprints, cable voice providers currently all pay what are called “termination fees.”
A “termination fee” happens when, say, a VoIP call made by a Charter Communications customer needs to end up at a house served by Qwest Communications International. At some point, that call needs to jump off of Charter’s IP plant and onto Qwest’s network. Every time that happens, companies like MCI, Sprint, and other “call-termination” providers hear a happy “ka-ching” sound.
WHICH IS CHEAPER?
Ultimately, peering is an exercise in economics, more so than technology. It’s a “which is cheaper” thing. It goes like this: Should you keep paying someone to terminate calls to “regular” [non-VoIP] phone numbers? Or should you buy the gear and do what it takes to peer? Which is cheaper?
Answer: If lots of traffic is traversing between “peered” networks, the case for peering can be made fairly easily. If traffic is minimal, maybe you wait.
VoIP, after all, is still fairly new. It serves millions of subscribers, yes. But from a traffic perspective, “regular” data services — Web surfing, e-mail — still generate considerably more volume than do aggregate VoIP calls. Plus, most people are still calling numbers that aren’t necessarily other VoIP lines.
A tenet of IP peering: It works best when all participants are passing a like amount of similar traffic.
Think of any metropolitan area with more than one cable operator offering VoIP service. Chances are high that people are calling across the (behind-the-scenes) geographic boundaries of the respective providers. As VoIP volume grows, peering is probably worth looking into.
The to-do-list for IP voice peering is (of course!) more complicated than traditional “data only” peering. Because voice calls happen in real time, and can’t afford quality hits associated with network delays, they require QoS — tech shorthand for “quality of service.”
Then there’s the fairly numbing topic that is “ENUM,” (pronounced “ee-num”) which stands for “Telephone Number Mapping.” ENUM is sort of the White Pages for routers: It’s a group of protocols that work in the background to convert phone numbers to IP addresses and vice versa.
CableLabs issued a request for information about the technologies needed for IP voice peering in late 2005; its PacketCable effort continues to work out the kinks, both in the lab, and in ongoing specification work. Translation: It’s in motion.
As the year unfolds, we’re likely to see voice peering trials amongst cable providers. Much of the intent will be to learn what it takes to do ENUM.
More on that next time.
Stumped by gibberish? Visit Leslie Ellis atwww.translation-please.com.