The Day-to-Day Reasons for OCAP
by Leslie Ellis // March 22 2004
The weary consensus of the people cooking up new digital-cable applications at program networks is, not surprisingly, that it’s a nightmare — from a hands-on, code-writing perspective.
Cable providers agree: Implementing a “red button” with more sizzle than the one under the thumbs of Rupert Murdoch’s European customers is just plain painful.
The answer, both camps agree, is something that removes the need to constantly futz with the thick mesh of differences within the fielded base of digital boxes. Differences mean recompiling and recompiling, over and over, every time something changes. As one cable technologist puts it: “Every day of the week, I have to get a code drop from somebody.”
Things get more acute as operators — most of which currently store between 1,500 and 3,000 hours — start talking about bumping their on-demand storage libraries to 10,000 hours. From a navigational perspective alone, how does a reasonable person navigate a library that big? Scrolling down a 10,000-title text list doesn’t seem practical — or much fun, for that matter.
And that’s just one application.
An operator, for example, may use digital-video headend equipment made by both Motorola Inc. and Scientific Atlanta Inc. (Not in the same system, generally, but in the big picture of what’s out there.) Maybe that same operator uses three different types of electronic program guides, two different VOD vendors and four different generations of digital set-tops.
Maybe the four generations of digital set-tops each house a successively better processing chip. That means any software changes need to be recompiled individually — for each chip.
Perhaps the four generations of digital set-tops each house a successively better processing chip, which links to other supporting chips, like graphics and networking, and to the embedded software within them.
Altogether, that’s what technologists refer to as “firmware.” It means that any application that’s to run across all four generations of set-tops must be recompiled individually — for each version of firmware.
Then there’s the making-it-work part. Doing it right — so that new digital-cable applications work across gigantic bunches of differing boxes — calls for internal software engineers to run quality-assurance laboratories. It needs methods to keep sanity around software revisions, which come in daily, and from everyone involved.
Talk about a matrix of pain: It’s a nutty amount of work, best done by logical, steady people. And even then, it can push a person into a catatonic stare.
Porting: More Whine Than Wine
The story isn’t much happier for the few programmers who write code to make TV shows more useful or entertaining for the digitally enabled. They have to hand-code the “differences mesh” of all digital video headends, all guides, and all set-top generations — or at least all that are targets for augmented shows.
In software language, these coding differences fall under the larger mantle of “porting.” To “port” software is to make it to run on different types of machines.
Example: Say you’re a programmer, in the computer-science sense of the word. Say you work for a cable network. Your quest is to develop clickable things that hopefully beckon digital cable customers to engage.
For the sake of illustration, let’s say the clickable thing lets you toggle yourself to the on-demand library within your particular network, while someone is watching a show. (This application isn’t quite happening yet, but it seems like a plausible effort.)
First, your graphics guru figures out how to make the toggle look enticing on the screen — without overstepping the tight limits of what’s possible in the installed base of digital set-tops. Then, you divide the writing job into manageable chunks and start coding. Maybe you write the application in Java, or Perl, or PHP or C++.
If a particular MSO wants to customize the “look and feel” of the way customers maneuver themselves to the on-demand links — that’s a custom port, too.
The ultimate answer, MSO technologists say, is OCAP. OCAP, or the “OpenCable Applications Platform,” is a subset of Cable Television Laboratories Inc.’s OpenCable effort. Its mission, in part, is to eliminate the need to rejigger applications each time something changes.
There are companies out there working on answers to the problem of having to write, and port, too many times for practicality. For MSOs, there’s the traditional “middleware” camp — Liberate and OpenTV and their (shrinking) ilk. For MSOs and content developers, there’s GoldPocket, which roots its work in the “ITV Production Standards Initiative” (more at itvstandards.org), while adhering to OCAP.
ITV developers at the programming networks wish for OCAP, too. And they wish for ways to find and talk with each other — about how to find answers, solve problems, think things through. They’re a community so small (about 50 people, at best) as to consider themselves more R&D than rock ‘n’ roll.
That will likely change. With every week Murdoch gets his vaunted “red button” closer to U.S. soil, cable gets more serious about its back-atchya. And it’s a back-atchya that’ll beg for smart software people.
The good news is, change is in the wind for the industry’s perennial underdog: Interactive TV. Granted, the “ITV” descriptor may never regain enough strength to shake off the taint of its many stumbles. But, its recent fruits (any of the on-demand categories, for example) are gaining favor.
This column originally appeared in the Broadband Week section of Multichannel News.
You Make the Call: SIP & NCS and How They Differ
by Leslie Ellis // March 08 2004
Last time, we examined why SIP, or Session Initiation Protocol, is the kind of new thing that this industry ignores at its own risk.
This time, we’ll dive into how a SIP-based call is different than an NCS-based call — where “NCS” is shorthand for Network-based Call Signaling, the method predominantly used by the industry’s PacketCable 1.0 specification. (That means it’s the spec most MSOs are planning to deploy, and most VoIP vendors are building gear around.)
Before we even get started, know that both SIP and NCS take a gigantic leap from traditional telephony. In a massive oversimplification, that black phone bolted to the kitchen wall when you were a kid worked off the voltage of the actual phone line. VoIP phones work by sending a series of electronic messages that emulate how the old black phone worked.
The chief difference between SIP calls and NCS calls is this: One (NCS) gets real chatty with the center of the network, to figure out what to do. The other (SIP) doesn’t – its devices get chatty with each other to determine their to-do lists. They treat the network as a go-between.
Both work to call or receive calls from that old black phone.
How PacketCable Calls Are Made
Since NCS is the method being deployed by the MSOs who are doing VoIP, let’s start with it.
In the PacketCable world, you plug your phone into one of two devices. There’s an “S-MTA,” for “standalone multimedia terminal adapter,” or there’s an “E-MTA,” for “embedded multimedia terminal adaptor.”
S-MTAs are like VoIP sidecars. They plug into the Ethernet jack of a cable modem. E-MTAs are both cable modem and MTA, in one box.
Economically, sidecar S-MTAs are cheaper than E-MTAs, but E-MTAs are cheaper than buying a cable modem and an S-MTA. Without batteries, E-MTAs go for $70-$80, technologists say. That’s about $30-$40 incremental to today’s volume-priced cable modems.
For this discussion, we’ll assume we’re dealing with an E-MTA. When you turn it on, it gets two IP addresses: One for the cable modem, one for the voice activities of the MTA. The voice section also gets the electronic address of whatever softswitch is being used by that system.
Then, the chatting begins. The MTA pings: “Yoo hoo! I’m new here. Anybody there?”
The softswitch (which also goes by “call management server,” or “CMS”) acknowledges: “I see you. Who are you?”
The MTA says what it knows about itself: “I’m a 2-line E-MTA.” The softswitch gives it an identifying number, and asks to be notified if anything happens. It’s specific about what could happen, like someone picking up the handset of the phone, or dialing digits.
You Make the (NCS) Call
So that’s you, picking up the phone. Say you’re calling your childhood home, where that old black phone is still bolted to the wall, and your parents still have the phone number they had when you lived there. (That last part doesn’t matter to this discussion, except that in these times, it’s oddly nostalgic to know anyone who’s had the same phone number for more than 10 years.)
The softswitch collects the dialed digits, and places the call – either linking to the public switched telephone network over a “media gateway,” or finding the destination E-MTA. In the latter case, a similarly lengthy dialog happens with the destination E-MTA, to receive the call.
When the call ends, the E-MTA tells the softswitch that you and Mom hung up.
Again, this is an oversimplification. Lots of other things happen throughout the call, especially in setting it up and tearing it down. The point is that the activities are tightly managed by the softswitch.
In fact, the E-MTA is too dumb to know much beyond how to notify the softswitch when anything happens.
In the world of SIP, just the opposite is true. SIP devices, which are known in the lingo as “user agents,” or “UAs,” treat their work like any other Internet communications program. Destination phone numbers become much like e-mail addresses, for example, that can be dialed from a handset, a PDA, a PC, or a laptop. Functionally, UAs are like a combination of an E-MTA and a softswitch.
You Make the (SIP) Call
Again, you decide to make a call. You could call Mom again, but the interesting stuff about SIP surfaces when you call another SIP device.
Example: You’re in Europe, or Asia, or anywhere else that’s not North America. You plug your SIP-equipped laptop into a broadband connection. You plug a headset into your laptop. You click on the phone number of your co-worker, Jane – a local call, even though you’re far, far away – and pay next to nothing, or at least less than the hotel would charge.
Similarly, Jane — who maybe thinks she was a better candidate than you for the overseas trip — can decide whether or not she wants to take your call. She can also pick how she wants to take it – on her PC, office line, cell phone, and so on.
Logistically, here’s (loosely) what happens: The E-MTA inside your laptop (and Jane’s) is pre-registered with a “registrar” (potentially offered by your cable provider), which keeps a database of SIP device addresses. Jane’s might be something like “SIP:email@example.com.” Like a routing database, the registrar exists to know who you are, so it can find you when you get a call, or route you when you’re making a call.
Meanwhile, across the ocean, you click to dial. In the background, your SIP device is issuing an “invite” request to a location server, asking it to find Jane and invite her to the call. Maybe Jane uses SIP on her PC, and her phone. Your registrar passes your request to a location server, which doesn’t find Jane, so it passes the dialed digits to a re-direct server, which locates her.
Back at the office, Jane sees your incoming call pop up on her computer screen. She answers – by donning a headset and clicking an icon on her PC.
In the background, Jane’s SIP device and your SIP device already negotiated an assortment of details about the call itself. One example (of several) is which “codec” to use. “Codec” is tech-speak for “coder-decoder,” which is the thing that digitizes and squishes your voices for the ride over the wires.
Another example of the behind-the-scenes negotiations between your and Jane’s SIP devices is which port to use, to establish the session for you two to talk. So there’s back and forth chatting going on, but it’s happening directly between the two intelligent end points – not with the network.
The point: Contrary to NCS, SIP devices don’t need to ask the network what to do when you initiate a call, dial digits, talk, and hang up. All they need is somebody to help route you to Jane.
There’s no easy way to say which is “better,” NCS or SIP. Aficionados of both techniques generalize it this way: NCS is sturdy, but not amenable to quick changes. It’s a little better at regulatory stuff, like E-911 and CALEA, the law enforcement part.
NCS also contains specific methods to offer “quality of service” guarantees, which matter to offering sustainably good quality. This will matter big time, especially as video telephony enters the scene.
SIP is more agile, and is riding a big innovation wave right now. Plus, it’s not just for voice – instant messaging and video telephony work with SIP, too. But, SIP is potentially more prone to integration hassles. Already, a data communications trade magazine last month posted a front-page story about SIP incompatibilities with the firewalls resident in people’s home networks.
Note that early adopter people are already doing SIP calls, but they’re doing them from competitive providers like Vonage, and, shortly, AT&T, Verizon, and others. It just seems too logical and economical to assume that SIP won’t spread like wildfire.
This column originally appeared in the Broadband Week section of Multichannel News.