Making the right connection
When it comes to knitting together a Voice-over-Internet Protocol transport scheme, it's not as simple as just picking up the phone.
Cable operators are faced with decisions on where and with whom they should interconnect and how to resolve the technical nuances as voice traffic flows across multiple networks. Fortunately, they can tap into a considerable toolkit of PacketCable standards and network control gear to help the calls flow without hiccups.
Session Border Controllers (SBCs) can act as translators for
protocols including Session Initiation Protocol (SIP), Real-Time
Transport Protocol (RTP), and Common Open Policy Service
Protocol (COPS), and maintain consistent quality of service
levels as VoIP traffic flows from one network to another.
To get started, many operators are turning to the interconnect and switching assets of longtime telcos, including Sprint Corp. and MCI. Time Warner Cable tapped both to support its foray into VoIP, according to Gerry Campbell, the MSO's senior vice president of voice services.
But as more operators get into the VoIP game, it is possible they will look to each other, forging peering and interconnect agreements to pass traffic back and forth across their collective networks. Not only may this be cheaper than paying for capacity on telco backbones, but it also may support a wider range of multimedia services.
Time Warner's first steps in that direction will come with funneling traffic within its own divisions, according to Campbell.
"I think the industry is going to take longer, because it takes longer for engineering, operational, financial and business people to get together to come up with the terms," he says. For now, it is "inter-company—so if I pass a call in the Ohios, it stays on our network and terminates in other parts of Ohio."
"The choice is really do we do interconnects for getting traffic to each other, or are we sending it off to a third party who is doing LD for us?," says Rolls. "That's really the crux of the issue."
The matter is further complicated for Cox because the bulk of its telephony customers—about 1.2 million—are on its older switched telephony service. If Cox chose to connect with another MSO's VoIP network, that would require a gateway to translate between switched and IP signals. That could offset the cost savings gained from funneling traffic onto a fellow cabler's network or to a nationwide IP backbone.
With the cost it pays for long distance minutes from its telco partners fairly low already "you are shaving pennies off pennies," Rolls notes. "It's going to be worth it some day when we are all doing lots of native VoIP minutes. But today I'm more focused on laying the good technology foundation so we all have a very solidly agreed-upon method for doing it. And that stuff is in progress—those talks are well under way."PacketCable's task
One place to find that discussion is at CableLabs Inc. Jerry Bennington, executive consultant at CableLabs, hosts a group of members that periodically discuss cable backbone issues, and in the last couple of meetings, the discussion has expanded to include the impact of VoIP services.
"Basically all that is going on with the CableLabs stuff is to start to socialize the issue, understand it, to look for where the opportunities are," Bennington says. "And I think, as like Time Warner is rolling out a ton of voice-over-IP, and Cablevision has gotten really active and other people are sort of gearing up, it is just to try to start to understand the problem before we get too much momentum going one direction or another."
If operators do indeed choose to peer for VoIP traffic, they will also have access to the PacketCable family of standards, including PacketCable Multimedia.
"From a standards perspective, it has been addressed by PacketCable, but having that said, it is not fully completed yet. But operators are also today providing IP backbone quality of service in their networks, and there are different ways that they are doing it and different technologies that are being utilized," he says.
The issue also extends beyond simple VoIP to other kinds of multimedia traffic—such as video telephony.
"Remember, if you get into multimedia and things like that, this is more than just about phone call to phone call," Rolls says. "We might want to work with Comcast to jointly launch a videoconferencing capability using multimedia. And all of a sudden this may become much more important. So it is going to depend on what applications we all come up with, and then decide we want to interoperate with."Taking a SIP
One such question mark has to do with how cable operators will deal with SIP, or Session Initiation Protocol. While PacketCable is the preferred method for most of the cablers so far, SIP also is starting to work its way into the process—and even into PacketCable itself, with the addition of a SIP proxy extension. SIP's attraction is it allows two intelligent end points—say two media terminal adapters—to connect to each other without requiring a lot of network oversight. But while services including Vonage have embraced SIP, the technology is weak in setting QoS levels, and it is vulnerable to hackers who can hijack end points to avoid paying for service.
While Cox is sticking to strictly PacketCable for its first VoIP rollouts, "SIP has certainly become very important overall in VoIP, and there is some work being done in PacketCable to blend in SIP-type capabilities into the protocol," Rolls says. "It's on the roadmap."
Time Warner Cable also chose not to implement SIP protocols initially because it would be too difficult to sort out how to interconnect with other operators, according to Campbell.
"So we pushed it out, but that is something that we will continue to look for," he notes. "And I'm sure once the industry gets around to talking about interconnects we would also look at peering through a SIP arrangement."
It may not be clear to what degree cablers will embrace SIP protocols, but they will nevertheless face SIP issues arising from the evolution of next-generation voice industry wide—including services that let customers roam from cable-backed Wi-Fi to cellular wireless connections. Those services will doubtless use SIP protocols to some degree, Bennington notes.
"You've got to think about SIP-based traffic," he says. "It's not just classic telephony traffic any more that's important. In fact, it could very well turn out that classic wireline traffic will turn out to be a relatively insignificant part of the traffic compared to bringing your cell phone home or using your computer or any of the emerging technologies for voice. That's really an open palette going forward."Border guards
Cable operators may also vary in how they set the level of voice prioritization and quality of service.
Cox, for example, has built a distributed voice switching model, with a main switch in Atlanta powering several market launches in the Eastern half of the United States. The interconnecting backbone has been designed to be sensitive to QoS for voice traffic, giving it the highest priority, Rolls says.
Other operators may opt for lower voice packet priority levels, say for a second-line service. But with tools including interconnection agreements and session border controllers, it is possible to link up with these operators, Rolls says.
"It's very doable. There appear to be no technology barriers to do that. It's just sort of agreeing on the standards and protocols that we will use," he says. The possibility some cablers will opt for different VoIP schemes including SIP won't be a huge hurdle because "I think with the flexibility we are seeing from the border control guys it won't matter," Rolls adds.
Indeed, many point to these session border controllers as a way to smooth out differences between networks. These gateway devices perform tasks that range from shielding a specific network's service infrastructure information from other peered networks to dealing with service issues between the networks, according to Jim Hourihan, vice president of marketing and product management for Acme Packets, a provider of session border controllers that is now actively seeking cable customers.
For example, session border controllers can be programmed to react to an overload of traffic moving from one network to another.
"If you have a link between two providers that is at capacity and you throw that one more call on it, you degrade quality for every call in that link," Hourihan says. "So you need mechanisms that can keep track of the bandwidth that is being used between providers, and then in an intelligent way if you get that one more call you can reject the call gracefully with a network busy signal. That's a role we play."
Session border controllers also can fix subtle differences in QoS protocols in one of two ways. One option is to handle it via the differentiated services protocol (DiffServ), a packet marking technique used to set priority traffic on an IP backbone router network.
Markings can differ from network to network, so using DiffServ session border controllers can strip off the marks from the incoming network and apply the correct marks for the outgoing network, Hourihan says.
The other strategy is to use Multi-Protocol Label Switching (MPLS). In that case, the session border control simply applies a new label switch path to incoming packets. At present, cable operators are not using MPLS as much, so the more likely strategy for making these QoS translations is through DiffServ, Hourihan says.
"I think eventually even cable will head toward MPLS-based networks," Hourihan says. "Between the other wireline and wireless networks, it's becoming sort of the backbone QoS approach."
Another inevitability is that in the coming years, session border controllers also will be called upon to deal with differences in voice and multimedia codecs between the networks.
"The world used to be relatively simple in that regard. It used to be G711 or maybe G729a," Hourihan says. But there are a slew of newer codecs "and eventually the big issue will be between wireless codecs and wireline codecs."
Others are also looking into safeguards to protect networks when things go wrong. Siemens is working with partner Juniper Networks on a strategy to insulate one network from outages on a peered network.
Codenamed RESIP, "it's basically a method to devise techniques and protocols that would survive in case of a node failure in the core IP backbone," says Tuncay Gunluk, responsible for product strategy for Siemen's IT8000 product line. "The conversion as used in the IP world is when a route fails, make sure all of the data is very swiftly and rapidly routed to another node. And this can be achieved by this RESIP backbone network and another element of it is a protocol called BFD (bi-directional failure detection), which is the connecting link from the backbone to the actual gateways."
But while all of these issues are looming for the future, for now, peered VoIP networks will be somewhat limited until more operators jump into the game.
"I also think that it's probably nice to talk about now, but on the practical side we need more companies in '05 to roll out services, and it is probably a late '05 into '06—because I'm sure companies want to stabilize their own platform before trying to interconnect with somebody else's," Time Warner Cable's Campbell says.
CableLabs' Bennington agrees, noting the delay does give the industry time to sort out issues in peering VoIP networks.
"I think it is being looked at more as an opportunity [than] a problem," Bennington says of VoIP backbone discussions now under way. "I think there is a transformation going on in the industry."