SIP and IMS spell out a new future for cable VoIP

Two acronyms—SIP and IMS—are poised to spell a big difference in how the technology behind IP telephony services plays out in cable's not-too-distant future.

Their emergence has come several years after the cable industry made some initial, big decisions about how they would architect their VoIP networks. Early on, a primary goal of PacketCable was to provide primary line telephony services—essentially duplicating what the telcos were doing—but via a Network-based Call Signaling (NCS) system whereby the network, rather than the endpoints, kept track of the call, the state of the call, and handled tricky features like CALEA and E911. Unlike SIP endpoints, which are considered "smart" in comparison, the endpoints of PacketCable 1.x amount to the proverbial "black phone."

Mission accomplished. When cable was making its big VoIP decisions in the 1990s, NCS was the best bet.

"At the time, we looked at the maturity of SIP and the technical needs of the operators and decided that NCS was the most appropriate," says Ed Miller, vice president of the advanced network systems division of CableLabs.

Today, POTS (plain old telephone service) is not nearly enough to remain competitive in a sector that has seen a surge in features and capabilities based on SIP, or session initiation protocol, and a wave of "over-the-top" VoIP service providers.

"The value in rich media applications that can use [SIP] and the 'black phone' service that PacketCable was initially designed for isn't going to be enough from a competitive standpoint," says Brian Cappellani, chief technology officer of OSS specialist Sigma Systems.

That realization, and SIP's rapid and wide scale acceptance in recent years, have elevated its stature in cable circles.

It also houses a broad scope of functionality, including presence and instant messaging, and has become a protocol which application developers are building to.

"We see [SIP] initially as more of a vehicle for new applications," says Charter Communications' Wayne Davis, who shared his thoughts on SIP for CED's new "View from the Top" interview series (see p. 34).

But what applications will SIP drive? In addition to traditional voice, it is already fueling things like video telephony. Operators are also considering SIP for "second-line" voice applications—even "nomadic" voice services that are completely based in software.

"It's like getting a Vonage line and the same features and services, but it's offered over SIP, rather than NCS, but maintains the NCS lines at home," explains Mike Clement, director of market management for Siemens, a maker of PacketCable call management servers and gateways.

SIP can also be used by operators as an IP peering agent. Rather than connecting traditional "off-net" calls via the PSTN, that traffic could be kept "on-net" through session border controllers. In addition to saving operators from paying telco switching fees, this arrangement could help them establish their own peering fees.

Enter PacketCable 2.0

Although SIP did not score a cable win in the early going, it is now en vogue and primed to become a key part of cable's more formal technical language. A forthcoming PacketCable 2.0 specification will place more focus on multimedia applications with QoS. Moreover, NCS MTAs and SIP MTAs and other SIP-based devices (such as videophones) could be made to co-exist on the cable operator's PacketCable network.

The PacketCable 2.0 spec will look at a variety of SIP-signaling mechanisms, and employ a fairly modular network capable of rapidly supporting new services, CableLabs' Miller explains. CableLabs expects to finalize the spec sometime next year.

The purpose of the 2.0 spec is many-fold. In addition to building a spec for an end-to-end SIP architecture, it aims to enable a range of endpoint devices such as videophone clients (hardware and software) and to support fixed mobile convergence handsets that can support WiFi and cellular connections. Yet another objective is to integrate applications across platforms, enabling, for example, the ability to offer caller ID via the television or to provide click-to-dial applications.

PacketCable 2.0 won't be the first time that CableLabs has incorporated SIP capabilities. In 1999, PacketCable introduced SIP signaling so that call management servers could talk to each other across different cities or regions.

Operators are also considering PacketCable Multimedia (PCMM) to deliver the appropriate QoS to SIP devices that don't speak the PacketCable 1.x protocol.

Although those SIP endpoints can't participate in the DOCSIS signaling, in the PCMM architecture, they can speak to an application manager that, in turn, requests the policy server to obtain QoS resources from the cable modem termination system.

"The operators that have already deployed PacketCable 1.x certainly would also like to explore the ability to do the SIP-based approach," says Jeff Walker, senior director of marketing for Motorola's Connected Home Solutions unit.

A next-generation version of PCMM could add a SIP server to the application manager interface, and serve as a convergence bridge for IP services that use SIP as the common denominator, says Milan Karanguthkar, director of product management for C-COR Solutions.

A PacketCable replacement?

But the addition of SIP application servers also begs the question: Does it still make sense to deploy a call management server (CMS) if a SIP application server can handle these IP-based services, including voice?

"That's really going to be a deployment decision by the operators," CableLabs' Miller says. Using PacketCable 2.0, he adds, an operator could enhance PacketCable 1.5 with SIP capabilities, or integrate SIP with the CMS for applications like TV-based Caller ID or click-to-dial.

For now, there's not much worry among the CMS vendors.

"I think it's an opportunity rather than something we have to worry about from an addressable market perspective," says Rafael Fonseca, vice president of product evolution for Cedar Point Communications.

Cedar Point's PacketCable-qualified SAFARI C3 Media Switching System could be made to receive a call request from a SIP device that's not a "subscriber" to the system, arriving to the system as a "peer," explains Fonseca.

That would also require a different database that deals with SIP endpoints and figuring out how SIP endpoints are sent off the operator's network and onto the PSTN.

At this point, there is little belief that SIP will replace PacketCable, which still has plenty of value to offer on the technical and regulatory fronts.

"We don't see [SIP] as a replacement for PacketCable at all. I think of it as an applications platform," Charter's Davis says.

"SIP is just a protocol," adds Fonseca. "If you need to maintain call state or [conduct] lawful intercept, then you need all of these components in your network regardless of the protocol you have."

While SIP-based VoIP service providers in North America wrestle with regulatory issues such as E911 and CALEA, cable has those covered if they apply PacketCable in their networks.

"We've already solved those issues," Clement says. "SIP is an overlay at this point."

But that could change as cable migrates to IMS (see sidebar at right) and fixed mobile convergence architectures. "Then you might look at SIP as a control protocol," Clement says.

SIP issues

Early on, cable wasn't too crazy about SIP, due to its nagging issues with QoS and security—two big pieces of the puzzle for a primary-line VoIP service.

And, because it relies on smart endpoints, the SIP network has more trouble with advanced calling features such as CALEA.

"We are all married to our call features, which can be trickier in a SIP network," says Ron Miller, senior director of product management for ARRIS. Those same smarts in SIP MTAs could also produce a much greater operational burden for cable operators. Whenever new features are added, for example, the endpoint needs to support a new software load. In a more centralized NCS environment, changes can be made at the switch rather than at every endpoint on the system.

And, despite its popularity, SIP technology is not as uniform as one might believe it to be.

"SIP is not as standardized [as PacketCable]," says Lou Donofrio, director of product management for Motorola's Connected Home Solutions division. "There are different versions out there."

That makes for plenty of "one-off" testing with soft-switch vendors. "There are some special software loads that have to be created," Motorola's Walker adds.

With those kinds of challenges ahead, Incognito Software Inc. hopes to meet some of them with SIP Commander, a SIP-based provisioning engine that employs configuration templates for several MTA models.

"[One] of the issues with SIP in today's format, is that there's no configuration standardization," says Incognito CEO Patricia Steadman. "The configuration file and the encryption for that file are all uniquely determined by the vendors."

The last thing an operator needs is to introduce SIP, and then see provisioning and operation costs "go through the roof," she adds.

Spelling it out

So, how quickly will SIP proliferate? It depends on where you happen to be looking.

"Domestically, you see it here and there from the...smaller guys. But the bigger guys are starting to pop their head up to check it out and test it in the lab," ARRIS' Miller says.

"It's very early on," adds Clement of Siemens. "Operators are trying to deploy NCS-based services right now. We haven't seen many cable operators looking at SIP-based voice residential services right now, but, with commercial services, I think that's when SIP really enters the picture."


SIP + IMS spells 'control'

Originally undertaken by the cellular industry, IMS (IP Multimedia Subsystem) is a mechanism for SIP-based control functions. Because it is network-agnostic, IMS looks to be a perfect fit for cable's own fixed mobile convergence efforts. In fact, CableLabs is tying its technical work on a "cellular integration" project with the PacketCable 2.0 effort.

Of great interest is IMS' ability to give operators some degree of control over SIP-based applications and services (See diagram, p. 18).

"One of the things that IMS and SIP can do is standardize the way sessions and voice sessions are controlled," says Gerry White, director of strategy and competitive intelligence for Motorola's Core Networks division.

That's because the "core" of that control plane is agnostic, meaning mobile, DSL or cable networks can tap the IMS framework, notes Dr. Neogi Depanker, senior manager of strategy for Motorola.

And that will grow in importance as operators look into seamless mobility platforms that transfer calls between the cellular and cable networks.

To support IMS, operators would be required to place additional servers on the network that provide the control framework. Handsets and other CPE devices would need to house an IMS software client. The system would also support standard interfaces for the applications to hook into. Because of IMS' agnostic nature, those applications (messaging, for instance) can be accessed through mobile devices, but also via the cable network.