With data deployments settling into a comfortable pace,
cable operators are taking action on the next new service that will ride on their
networks: Internet-protocol telephony.
Although IP will theoretically deliver a smorgasbord of new, revenue-bearing applications
for broadband-network operators, most point to IP phone as the first to emerge.
Technically, however, there's still a lot of work to be done before IP-phone service via
cable is a commercial reality.
To discuss that workload, Multichannel News senior broadband editor Leslie
Ellis teleconferenced with Mark Coblitz, vice president of
strategic planning for Comcast Corp. and chairman of Cable Television Laboratories Inc.'s
PacketCable initiative; Mike LeJoie, vice president of corporate
development for Time Warner Cable; and Luisa Murcia, vice president of
technology development for Tele-Communications Inc.'s TCI.NET. An edited transcript
follows:
MCN: In general, what do you all have to buy to get
yourselves into the IP-phone business?
LeJoie: We have to purchase a call-management server, and
typically, they're a UNIX server or a [Microsoft Corp. Windows] NT box. It's not some
hugely expensive piece of hardware.
MCN: How much does it cost?
LeJoie: You're talking maybe $10,000 or $15,000. That would
probably be able to manage between 1,000 and 10,000 subscribers.
The other piece of hardware that we or someone would have
to buy is a gateway device, which is a computer that has specialized transcoding hardware
in it to convert from IP packets to standard telephony framing. It's got IP connections on
one side and telephony connections on the other side -- either a T-1, or a T-3. It breaks
down into basically DS-0 circuits on the telephony side.
MCN: How much do those run?
LeJoie: I'll give you a story on the pricing. When I first
starting looking at this 18 months ago, they were talking about a price that was about
$3,000 per DS-0 circuit. So if you bought a box that did T-1, they were talking $75,000.
That was two years ago. A year ago, they were talking $30,000-plus. And now, they're
talking $15,000. So now, we're down to around $600 per DS-0.
Coblitz: And this is before there's any real volume.
LeJoie: Right. So the price will very soon get down to the
$100- to $150-per-DS-0 range.
MCN: So that's it? Those two pieces?
LeJoie: Well, if you want to be able to hook up an old
black phone in a customer's home, you'd have to buy an MTA [media-terminal adapter]. The
MTA, if you integrate it in with a cable modem, the target price is probably, what, Mark,
$150?
Murcia: If it's integrated into the cable modem, we're
looking at around $100, depending on volume. The more volume you have, the better the
price. So the requirement for the client is the functionality of a DOCSIS [Data Over Cable
Service/Interoperability Specification] modem and, on top of that, we need functionality
to do the coding and decoding.
LeJoie: The interesting possibilities about this are that
one, it rides on top of the IP infrastructure, which leverages a lot of the interest
that's already out there in the vendor community for IP development. Two, it scales very
nicely. You don't have to go out and buy a $5 million switch to get into this business.
You can make a relatively small investment -- five, six figures -- and you can be in the
business. Or you can be messing around with it.
Coblitz: And just as a subpoint to that, the companies that
are doing this are doing it at a carrier grade. So it's not like you're just going out and
buying something like you'd go buy a PC [personal computer] off the shelf. You're really
buying something that's been built to do this kind of service.
LeJoie: The other thing that's maybe the most interesting
aspect of all is that IP over cable opens up the possibilities of doing the types of rich
media services that we've all dreamed about that you just can't do over switched-circuit
telephony. We're not tied to a 64-kilobit circuit.
It's IP, so when the demand is there -- and it has clearly
been indicated that people want to continue to consume richer and more complex types of
media for their communications and entertainment -- this system can grow and meet that
demand. Circuit-switched telephony might have a harder time doing that.
Coblitz: Let me add that this is not just data-rate
capability. As you start thinking about the call-management system -- which, in effect,
will communicate among not just one MSO's call-management systems, but those of multiple
MSOs -- we're now starting to bridge the gap among our networks. We can move traffic and
communicate service information across our networks.
So it opens up the whole interconnected world that we've
never really had before. It provides a real service, with real value to consumers. That
energizes us to connect those networks and to start finding other uses for those
interconnected networks.
MCN: Rattle off some of those rich media services that you
mentioned, Mike. What are they? Video telephony?
LeJoie: Yes. Videoconferencing is a very good one. Unified
messaging is another possibility.
MCN: By that, you mean the concept of a universal in-box
that holds faxes, e-mails, voice mail and video mail in one spot?
LeJoie: Exactly. Another possibility is that you could
provision kinds of services across this platform that would allow you to differentiate
features. For example, it would be much simpler to have distinctive ringing for different
members in a family, and to have multiple telephone numbers, on basically the same device.
Different users who might be living in the same household
may have different calling patterns; we can accommodate that. Or, you may want to have one
long-distance provider for international calls and another for national calls. Whatever it
is, you could set this up much more easily than you could across a circuit-switched
network.
MCN: You say that with such conviction. It sounds
complicated.
LeJoie: This is in theory. The reason is, in the IP world,
you have a lot of smarts that scatter all throughout the network, as opposed to being just
concentrated in the middle. Because of that, you can leverage the energy of the
development community -- all of these guys in the garage shops that are constantly coming
up with 50 nifty new little widgets that'll run across IP technology. I have no idea what
the 50 little widgets are. If I knew, I'd be out there building them.
Murcia: What we're looking at now as the first two
PacketCable-type services are telephony and video.
MCN: Separately, or together?
Murcia: Video telephony. Two-way or multiple-way video. Not
video streaming, but videoconferencing.
MCN: Tell me about the equipment -- the gateways and
multimedia-terminal adapters and all of that stuff that you're working on. What are these
things?
Coblitz: You have to start by taking a look at the
fundamental network. So, starting with the client in the customer's home, the data has to
come across our cable network to get to whatever is going to happen in the router system
within the cable headend, or wherever that routing is taking place.
Two fundamental things have to happen. First, because we're
using H323 [a videoconferencing standard] terms, we need what is called a gatekeeper. In
cable, we're calling that the call-management server.
MCN: What does a call-management server do?
Coblitz: It's analogous to the data-lookup and signaling
systems that take place within the phone company. Where's the call going? How do I
communicate to another place in the network what the status of the call is? What the
status actually is, and what are the attributes of the service that a customer has? The
call-management server does all of those kinds of things, and it does the appropriate
communication back and forth.
It may be that where this call has to go is out to the
public-switched-telephone network. And a gateway is a device that can take the IP packets
and then connect the call to the PSTN. Gateways do the translation from IP into standard
kinds of signaling and data for the PSTN.
MCN: That happens at the headend?
Coblitz: It can happen wherever it's appropriate within the
network. In general, you keep [traffic in] IP as long as you can. It might be that there
are cost differences in different cities that impact where you interconnect: Do you have
to interconnect at tandem [switches], or how do you get to a long-distance point of
presence? There are a whole set of issues about what the right cost structure is, and they
may be different from system to system.
Murcia: It's a function of traffic, communities of interest
and how much data you have going where, and, of course, the economics, in terms of costs
to interconnect to an Internet-service provider.
Coblitz: These gateways, or call-management servers, exist
today. If you were to dial a number to place an IP call today, you'd be calling a gateway.
You're calling the PSTN side of the gateway, because that's what you've got, in terms of
your phone at home.
Your call is answered by the gateway. It then goes out over
whatever IP mechanism it's going to use -- typically through some Internet connections,
but, in some cases, there are some managed networks that are being used.
[The call] eventually gets delivered to a gateway someplace
else, and it is translated back into a PSTN format, where it goes to the local company,
which completes the call. That scenario is in existence today.
MCN: How do you envision that scenario being modified, or
the gateways being modified, for the cable approach?
Coblitz: What we're doing is adapting the cable networks to
[the gateway approach] and adding clients. The clients today have predominantly been
PC-based, although you're starting to see some devices that you can put into the home that
sort of pick up the phone and will dial the number for you and go IP.
MCN: You've mentioned MTAs. Can you explain that?
Coblitz: Basically we've got three devices that may be the
source of the IP traffic within a home. The first is a digital set-top; another is a cable
modem connected to a PC; and a third would be a stand-alone device for people who don't
have any of that stuff, which would connect directly into the customer's twisted pair in
the home. That is what we call the media-terminal adapter, or MTA. It's a stand-alone
device.
MCN: If I had a cable modem and an MTA that connected to it
and to the phone near my cable modem, which would also be near my PC, what happens when
the phone rings in the kitchen? How does it know to ring?
Coblitz: Forget the part about it connecting to the cable
modem. I mean, yes, that's one way that it could be done. Assume that you've got a device
sitting in your home, and the connections are going out to cable, but inside, it's
connected to your twisted pair in your house. So, all of your phones work exactly the way
that they work today.
I don't think that you're going to see any of us calling
this "IP phone." It'll just be phone. It happens that we'll use this technology,
because it has some cost benefits and service benefits, but it won't be any different than
it is now.
MCN: What are you learning from the vendor community? For
IP telephony, is it the same mix of vendors, or are there a new batch coming in?
Murcia: Actually, what is interesting about this is that on
one side, you have the traditional telephony vendors -- the Lucents [Technologies] of the
world. And then, on the other side, you have all of these new data-communication vendors,
like Cisco [Systems Inc.] and 3Com [Corp.]. And then, you have various other companies
that have been building a lot of the niche capabilities, like NetSpeak [Corp.] and
VocalTec [Communications Ltd.]. So what is really good about this is the diverse vendor
mix.
MCN: Are you finding that vendors have products that you
can immediately use, or are you grooming your interests into their planning processes?
Murcia: We're taking a dual approach. We're looking at
existing products for initial testing, to understand how they actually work. Once we
understand that, then will come enhancements and additions to existing products to address
the needs of the cable side.
We're working with the vendors to develop the standards for
PacketCable. That's where the bulk of the work is -- with the vendors. The idea is not to
build a brand-new standard, but to build a standard on top of existing standards.
For example, H323 is really an existing standard. What
we're doing now is understanding where that standard is, where it is going and where we,
as an industry, can push it forward. On the other hand, we have needs that are specific
and unique to cable. The vendors also participate in the standards process. And together,
we build a unique standard for the industry.
Coblitz: In the case of equipment availability, we really
see three buckets. The first bucket has equipment that's already available and that people
are buying -- in particular, the gateways. There are various folks who have already tested
some of these things and who we're working with.
The second bucket is one with software changes and things
that we're looking at to allow us to communicate the way that we want to communicate.
We're looking at things that are already done, and at some that could be tweaked.
But the place where there is no equipment if you wanted to
go deploy it today -- and it's a reason why all of this is some time off -- is the client
devices. They don't exist. There's not a set-top that has IP telephony built into it;
there's not a DOCSIS modem that has it; and there's not an MTA. That's because when the
cable industry started to focus on that as something that we needed to go deliver the
service, we needed to go work with vendors to cause that to be created. That you aren't
going to find. But the industry is working with a set of folks to make that happen.
MCN: Some of the vendors are talking about a box that
connects via Ethernet to the cable modem, and that has an RJ-11 jack, too. And that's
their way of doing IP phone.
Coblitz: That's right, and that's the first step.
LeJoie: That is one version of an MTA. Then, there's
another version that integrates the cable-modem circuitry with the IP-telephony stuff. And
actually, there's an IP vendor that has exposed a schedule to us that shows an integrated
solution before the end of the year.
Murcia: What we see as even more potential for the market
is when we can integrate IP functionality into the set-tops. That gives you a wider market
to address. The problem with having a separate MTA is that now, you have another device
that you have to bring to the home. But there are also issues of cost, in terms of
duplication -- for instance, the connectors in the cable modem have to be duplicated in
the MTA.
LeJoie: You should really understand that what we're
working on is a standards-based implementation. The work that we're doing with vendors is
targeted at profiling the current standards efforts that are out there in a way that is
suitable for deployment across cable networks.
In the relatively rare occurrence where there's a hole in
the standard, or where there's something that we need to have done, then we'll go ahead
and work with vendors to spec that. The output of that effort will be an open edition that
we'll offer to standards bodies.
Coblitz: We also recognize that there's a set of the
potential customer base that are going to have digital set-tops, and some that will not.
Some will have cable modems, and some will not.
By having the three devices, including the MTAs, we can
actually address the entire marketplace -- anywhere that's passed by cable. This is a
service that is aimed, in effect, as ubiquitously as cable is -- to 97 percent or 98
percent of the United States. What we wouldn't want to do is to duplicate the
functionality of a house that has a set-top that would have IP built in. The MTA is a
solution for homes that have neither set-top nor cable modem.
MCN: I've heard mentions of latency times in the range of
250 milliseconds or less as a key criterion on all of this. Why is that?
Coblitz: 200 milliseconds or less.
Murcia: That's the overall latency.
MCN: From the time I speak until the time you hear it?
Murcia: Right. From mouth to ear, if you will. Anything
above that becomes noticeable to the human ear. You start noticing choppiness or lowered
quality. Latency is a measurement that you hear a lot in the context of toll quality.
LeJoie: The target is to be under 200 milliseconds, and
we're looking at driving it down lower than that. Typical end-to-end latency on a national
telephone call is under 100 milliseconds. On the tests that we're doing right now, we're
very low.
MCN: Tests? Can you discuss that work?
LeJoie: We're doing lab tests. We're evaluating a lot of
different equipment. There's nothing in the field -- not that I'm doing.
Coblitz: We're doing the same thing: We've got stuff
internally that's set up, and we're experimenting with all of that, but there's nothing in
the field yet.
Murcia: We're also testing internally, in a lab
environment. What we're doing right now is connecting to CableLabs and building a network,
through @Home Network, [Time Warner Cable's] Road Runner and MediaOne [Express]. We're
building it exactly the way that it would look when we put the service into the field.
Coblitz: We're all treating the tests as a way to drive
whatever turns up that needs to be specified.
LeJoie: There are still a lot of questions to be answered.
MCN: Like what?
Coblitz: There are a whole host of them -- things that
aren't done yet that we need to be able to nail all of the pieces that we need to do.
Signaling to each other is one example.
LeJoie: One of the big questions is true interoperability
of products among vendors. We want to make sure that we have a wide marketplace of vendors
to go to with these products, so that we can be assured that if Mark buys from vendor A,
Luisa buys from vendor B and I buy from vendor C, we'll be able to communicate across our
networks.
Murcia: Even though there's a standard called H323, and
vendors are building components like gateways and call-control managers, their [equipment]
still doesn't talk to each other. The way that I look at H323 is how DOCSIS is today --
where you have a DOCSIS 1.0 standard, with people hooking their equipment up together live
to find interoperability problems.
MCN: What is the status of the request for information that
PacketCable issued?
Murcia: We did one that Mike [LeJoie] spearheaded, to find
out which vendors were out there and what their level of involvement was, and also to
gauge their commitment to the industry.
LeJoie: And also to look at the gateways, or the
call-management servers, as we call them. To get answers back from the different vendors
on how they were implementing the services contained within that particular element.
The H323 spec is very broad, and it's really quite an
enabling specification. That's good in one respect, because it allows a lot of flexibility
in how a vendor chooses to implement this stuff. But it also creates problems in that two
different vendors can deliver products that are both compliant with the spec, but that
don't interoperate.
MCN: Different interpretations of the spec.
LeJoie: Right. There are multiple ways that you can
implement the different services. So the gatekeeper RFI was an attempt to learn from the
vendors that are out there exactly what they were doing, and to learn more from each of
the vendors -- they have the expertise, after all -- on what they felt was the best way
was to go about this. That was one RFI. Then, we put out another one.
Murcia: The second was on the client. A non-PC client was
nonexistent. So we were looking for the vendors. That was a different set of vendors [than
the gatekeeper RFI]. We were looking at the vendors that can not only develop product, but
that can mass-produce it. Now, we've combined all of the groups. So, out of the RFI
evaluation, we selected the core vendors that are participating with us and CableLabs
right now to develop the requirements that we need.
MCN: How many vendors did you pare it down to?
Coblitz: I don't think that's something that we need to do
in the public domain yet.
MCN: What, talk about the number of participating vendors?
Coblitz: It isn't a "pare-down" concept. It's
similar to what we did with DOCSIS. We have lead authors and vendor authors who are
helping us to write the first draft of what the specifications are going to be.
Any vendors that care to comment on what this is, and that
want to participate, as long as they come under the nondisclosure, are totally welcome to
be involved. The more, the merrier. If somebody reads this and wants to be involved, we'll
put them on the list, and they can participate.
LeJoie: At www.packetcable.com.
Coblitz: Right. So it's not really a paring-down. It's some
folks who are working together to help us with actually physically writing the first set
of specifications of how this will all work. And then it goes out to the vendor community
to be commented on.
Then, we'll come back and continue to move and change, so
there's not any one particular set of vendors that are the only sources for how this stuff
gets done. We found that very useful in the DOCSIS process, and we're doing it here.
MCN: Can you put some time-frame parameters around the
specifications that you would like to write?
Murcia: We put together in the business group of OpenCable
a set of what the services are. In that service definition, we put our wish list. One of
the things that we're looking at right now is understanding what we can deliver and when.
It'll probably come out that we'll do this specification in stages.
We're looking to get the first, 1.0 specification sometime
in the summer -- the first draft. The draft is being developed by this core set of
vendors. What we do is we release that draft to the entire vendor community.
Coblitz: We said that we'd do an outline by April, which we
did. And we have our vendors together, and they're all working. I think that somewhere
toward September-ish is when we expect to have the draft ready to go out to vendors, with
trial stuff in '99 -- no different than what I told you a few months ago.
MCN: Can today's cable modems support IP phone? I
understand that there's some sort of data-fragmentation addition to the DOCSIS spec that's
being called DOCSIS 1.1, and then a 2.0 version of DOCSIS that will enable IP phone, but
can IP phone work absent those additions?
Murcia: The infrastructure is mostly in place today to do
things like IP phone. What we're doing with QOS [quality of service] and the enhancements
to the existing DOCSIS specification will allow us to prioritize the traffic, based on
type. So as you get more traffic into the system, then you have more opportunities for
contention.
What you want to have is a system that allows you to manage
contention. Today, with relatively small amounts of data traffic on our big pipes, we
could actually manage voice traffic, because we wouldn't have that much voice traffic,
compared with data traffic.
MCN: Can you explain what the extensions to the DOCSIS spec
do and contrast that with the larger QOS supplements to the next full DOCSIS version?
Murcia: It's a whole set of extensions that are being
implemented in stages. We still are working to figure out how much additional hardware and
software will be required to allow the extensions. Today, DOCSIS depends on what we call
"best-effort."
MCN: You mean from a contention perspective?
Murcia: Yes. Today, you can't assign bandwidth on a
per-modem basis. All of the traffic generated in the modem needs to be assigned with high
or low priority. You cannot tier services with today's modems.
Data traffic, for example, will be handled differently than
computer-voice traffic. What the QOS will allow us to do is to have what we call multiple
identified packets, by service type. Via that identification, we can tell the system that
this packet is a voice packet, and I need a high priority, versus a data packet that may
have a lower priority. It will allow us to do packet classifications, so that we could do
constant bit rate, or have just best-effort traffic in there.
One of the other components with voice that is unique is
that it is also very sensitive to jitter. So not only do we have to transfer the packet
within a time frame, but the variations of timing between packets have to be constant, so
that the system can understand it.
Most of this can be done in software. The MAC [media-access
control] layer in the CMTS [cable-modem-termination system, or cable-data-headend gear]
has a lot of potential. The specifications that we build would all be hooked in there,
with additional software. One piece of hardware that we'd probably need to do would be the
modem, because today's modems can only support one SID.
MCN: SID?
Murcia: Service identification, which is how you identify
the packet. Additional hardware in the cable modem would allow you to support multiple
SIDs, so that you can identify different traffic packets.
If you have a large data packet coming in and, immediately
after that, a voice packet comes in, you've got to wait until the large first packet is
fully transmitted. Fragmentation allows us to segment the data into smaller packets. That
way, you can get the voice packets in between and be able to disassemble them on one side
and reassemble them on the other side.
LeJoie: You can offer IP-voice services across the current
cable-modem products that are out there today. The reality is that people are using
applications like NetMeeting and VocalTec -- the brains, the early adopters are playing
around with these things now and using them on our network.
In tests that I've run, they work much better across the
cable plant than across the public Internet or on lower-speed dial-up access networks,
just by virtue of the brute force of the bandwidth that we offer. So the idea that you
could offer a voice service today is probably valid, with some constraints -- the
constraints being that you couldn't really manage the QOS to a very fine degree. The
service may experience some glitches and pops, and you certainly couldn't guarantee
toll-quality service.
Murcia: One big differentiator is that now, [IP phone] runs
on the public Internet to provide the service, whereas we have a virtual-private-data
network. One of the issues with the public Internet is that once you get there, you really
have no control over the packets being transferred from one point to another.
That's another advantage of how we're looking at the
service. By virtue of having a private network, you can control how you send the packets
from one spot to another.
MCN: You're referring to "we" as @Home, Road
Runner and MediaOne Express -- the nationwide backbone providers?
Murcia: Exactly.
