Monthly Archives: February 2001

VoIP Stumbles, But Stay on the Line

by Leslie Ellis // February 16 2001

The storied history of misplaced market expectations would make for a useful healing element in the obituary of Lucent’s scuttled cable phone line, were anyone to write it.

For starters, Lucent is hardly the first big equipment supplier to choose the hokey-pokey as its cable technology dance. Intel Corp. and Hewlett-Packard both put their left foot in, then took their left foot out, of the cable modem business. Neither stayed long enough to shake it all about.

Likewise, there’s a history between cable technologists and the company now calling itself Lucent. In the early 1990s, when Lucent was Bell Laboratories, it developed a cable phone equipment line with its then-partner, Antec Corp. The gear, branded “cable loop carrier,” ultimately tied up too many research and development dollars and was cancelled.

Last week’s Lucent development is sad, as are most layoff byproducts. The people who were making its “Pathstar” and related cable phone products are smart and earnest. They re-entered the cable phone market in 1999 with believable contrition about the company’s previous efforts. But, Lucent apparently found itself at the unhappy intersection of financial bloat and market impatience. It took its left foot out.

When big technology suppliers pull out of cable, it usually belies the un-reality of expecting massive market penetration, really fast. H-P, which entered the cable modem market with gusto in 1994 — who can forget the gigantic kayak paddles distributed around the industry? — mis-interpreted order sluggishness in late ’96 for data stasis. Hindsight shows a missed opportunity of some 4 million deployed modems in the U.S., as of the end of 2000.

Managed expectations lessen later disappointments, which brings us to cable’s current plans for voice over IP. Will it happen? Almost certainly. Why? Because all technology compass readings are pointing toward Internet Protocol; because it’s an incremental expense, and because it re-uses the data path the industry is already putting in place with cable modems. When? In four distinct and fairly predictable phases.

But first, some basics. Voice-over-IP contributes another awkward acronym to cable’s jargon cocktail: VoIP. (A few brave souls say it as a word – “voyp” – but end up sounding like an arrythmic windshield wiper or, at best, a background artist for Laurie Anderson.)

Cable VoIP has a technical shepherd: The CableLabs “PacketCable” group. In a blatant simplification, PacketCable is a set of software-based mechanisms written to do exactly what today’s analog, circuit switched phone network does, from dial tone to ring tone. Unlike other VoIP specification efforts, though, which address only portions of how to make a phone call work in IP, PacketCable maps out the entire journey. This is no minor task, yet much of the spec-writing work is already done.

Just as they did with DOCSIS, expect MSOs to vigilantly insist that vendors adhere to PacketCable. Already, MSOs are raising the red flag against any de facto standards attempts by the supplier community, warning that they’ll place their votes with purchase orders.

PacketCable has a technical pre-requisite: DOCSIS 1.1. This is the first phase in cable’s VoIP work.

PacketCable needs DOCSIS 1.1 for its quality of service (QoS) features, so that calls placed over the cable IP path (today’s cable modem path) sound clear and synchronized, and parallel the grade of service you currently get when you talk on a wired phone.

There are four test waves scheduled this year for DOCSIS 1.1. Results will be announced on March 30, June 22, September 28, and December 21. It took three full waves for suppliers to earn compliance for DOCSIS 1.0-based gear, which is the stuff being deployed today. CableLabs is in its second test wave for 1.1-based gear, with results expected at the end of next month. If history repeats itself, it will be the June 22 round that produces the first certified 1.1 gear.

Add nine months or so for PacketCable tests – this is phase two — and cable’s foray into VoIP becomes a Spring ’02 phenomenon. Until then, lab tests and market trials. That’s phase three, which will also yield knowledge on how to make the service deployable across millions of subscribers. Phase four is the launches themselves.

Everything from phase 2 onward will likely vary somewhat, MSO by MSO. AT&T Broadband has indicated a preference for “lifeline” phone, meaning the phone remains useable even if the power is out. Doing so requires shoring up the HFC plant to accommodate the powering needs of the VoIP gear when the power grid is out.

Others, like AOL Time Warner and Comcast, are more interested in voice as a sort of audio service that complements their existing data efforts.

That’s the who, what, when and why of cable VOIP. Next time, the “how.”

This column originally appeared in the Broadband Week section of Multichannel News.

The Wonderful Thing About Triggers Is …

by Leslie Ellis // February 05 2001

It’s not easy being an interactive trigger. Its journey is arduous, sometimes traversing as many as three distinctly different broadcast networks. On arrival, the trigger doesn’t always (or even often) get a warm welcome, because most of today’s set-tops aren’t equipped to see it on the threshold.

Even if the trigger is recognized and ushered into the box, its lifespan is short: An expiration date is imprinted into it. In the sliver of time before it dies, the trigger has one purpose: To be the bright, sparkly thing, the attention-getter, that coaxes TV viewers to point the remote at it, push the button, and initiate a tryst.

Like salmon, triggers are born with a mission: To make a difficult journey, perhaps with a tryst near the end. If they’re lucky. Then it’s over. (And we haven’t even gotten to the upstream part yet.)

Yet the interactive trigger, for dozens of interactive service providers, is the capstone in the bridge between today’s broadcast world, and tomorrow’s interactive, session-based world. Regulators are also curious about triggers – especially who may or may not block them. And, fears are already mounting about the potential to slip unauthorized triggers into a broadcast, prior to established business arrangements.

What on earth is a trigger? The word itself is comes from the Advanced Television Enhancement Forum, or “ATVEF,” an ITV standards group spawned by Microsoft Corp., Intel Corp. and others. The idea was to bind interactivity into a TV broadcast. (Some now call this “program synchronous” interactivity.) The design goal was to make it quick and easy, and write once/run everywhere, for content developers.

Quick and easy usually means using existing standards, which in ATVEF’s case is HyperText Markup Language, or HTML. The “trigger” is the Web address where an interactive application is held. Because Internet pages look smeary on TV without some tweaking, the URL embedded in the trigger is usually a special destination, already tweaked for TV resolution.

Triggers ride shotgun, and in real time, within the vertical blanking interval of an analog TV broadcast. In digital broadcasts, like those based on MPEG-2, triggers splice into a private data stream. Those regions also hold things like closed captioning information.

In some cases, the TV picture and any embedded triggers blast up to a satellite in space, then down to headend receivers on Earth. There, the trigger may get removed and re-spliced into the picture before riding in one of three signal paths – VBI, in-band, or out-of-band – over cable’s hybrid fiber-coax plant to a set-top box.

Say the set-top can recognize the trigger. Say it knows to translate it into an eye-catching icon, on the TV screen. Maybe it’s an offer for a sample of the Super-Hot compost activator Roger Swain is using on “Victory Garden.” (Hey. The writer gets to pick the example.) Say the viewer decides her own pile could use a kick, and clicks.

What happens next depends on the set-top. Units equipped with a two-way IP path (such as an embedded cable modem) would likely fling the request up the cable reverse path, using the IP signal path, through the companion CMTS (Cable Modem Termination System, the headend part of high-speed Internet systems). Destination, out of the CMTS: The server holding the Web link.

Maybe that server is in the headend; maybe it’s on another continent. Latency matters here, so that’s a good thing to ask about when talking to ITV suppliers. The viewer just acted impulsively while watching a show. For her, its about the show, not the impulse. The second it becomes about the impulse, it becomes annoying.

Set-tops not equipped with a two-way IP path have a tougher time with triggers. If the box is a two-way unit with impulse pay-per-view features, it can pass the trigger along – in due time. Most IPPV boxes rely on a polling technique, orchestrated at the headend. Essentially, a companion unit in the headend pings each set-top, one by one, in a big circle. If it were a conversation, it would go like this: Headend to box: “Got anything? No? Okay, catchya next time.” And so on, box by box. The round-trip is measured in hours, not seconds.

Why should you care about triggers, especially with everyone saying 2001 is VOD’s year, with all the interactive stuff to follow? Two reasons, really. First, it never hurts to understand how things work. Second, triggers are likely to find their way into your system at some point.

If you want to be trigger-happy, be sure to ask ITV suppliers about the back-channel. Does it require a two-way IP path to a server? (If so, do you have one?) Is the server local, or remote? Is there anything proprietary in the mix?

Remember scale, too: What happens if zillions of people all click at the same time? Ask about latency. How long does it take from click to response? And, ask how the service maps onto your existing and future digital set-top deployments.

Triggers do work, by the way. Ask Mixed Signals Technologies or RespondTV, two of several providers using triggers regularly on the WebTV service.

Whether or not they work for you depends on your technology roadmap.

This column originally appeared in the Broadband Week section of Multichannel News.