TechTalks Transcript
Telephony Over IP: Are We Ready?
 Judith Boettcher [JB] |
 Howard Strauss [HS] |
 Doug Gale [DG] |
January 28, 1999
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
JB: Welcome to the CREN TechTalk series for Spring of 1999 and to this session on on "Telephony Over IP:Is it Ready and Are We Ready?" with Doug Gale. You are here because it's time to discuss the leading core technologies in your future. This is Judith Boettcher, your CREN host for today, and I'm pleased to welcome the TechTalk technology anchor, Howard Strauss of Princeton. Howard is a well-known Web and all-around information technology expert.
Welcome, Howard.
HS: Thank you, Judith.
I'm Howard Strauss, the technology anchor for the TechTalk series of technology Webcasts. The job of technology anchor is to engage our guest expert in a lively technical dialogue that will answer the questions you'd like answered and ask those very important follow-up questions. You can ask our guest expert, Doug Gale, your own questions by sending e-mail to expert@cren.net anytime during this Webcast. If we don't get to your questions -- and sometimes we don't -- during the Webcast, we'll provide an answer in the Webcast archive.
When you grab a telephone and call the next office or the next continent, do you ever think about how the message is transported across the telephone network? Probably not. Telephones just seem to work. It is likely, in fact, that you know more about how the Internet works than how the telephone network does. The Internet, of course, packages data into packets and transports the packets using IP, which stands for Internet Protocol this time.
That is not the way telephone messages are usually sent -- but they could be, and many companies are betting fortunes on making that happen. It may seem strange to you (and it certainly does to me) to have my voice compressed, cut up in little packets, routed across the Internet and reassembled and uncompressed at its destination. Since we all have experienced delays and failures in using the Internet to fetch a Webpage, it doesn't seem like a very solid ground on which to build the future telephone network.
Using the Internet to carry telephone traffic is called IP telephony. IP telephony doesn't change our phones or how we use them, but it does change the way the messages are sent in quite dramatic ways. Today this change offers the prospect of lower costs and many new features. But both the technology and the marketplace are very fluid and ever-changing, and in the near future, over half of telephone traffic will actually be data transmissions that are much more suited to an IP network than voice. This may accelerate the move to IP telephony.
If you have some concerns about the impact of using IP to carry telephone traffic, imagine what phone companies with zillions of dollars invested in the PSTN -- that's the Public Switch Telephone Network -- are thinking. Doug Gale probably can't tell us what's in the heads of telephone executives, but in today's TechTalk, we'll be asking him what we should be thinking and doing about this emerging technology.
Judith?
JB: Thank you, Howard. (Excuse me, I'm losing my voice. At a bad time, I guess!) I'd like to say how pleased we are to have Doug Gale from OARNET, the Ohio Academic Resources Network, here with us today. Doug is internationally renowned for his expertise on building and finding funding for campus networks of all types and sizes, and he is currently the director of OARNET, an Internet service provider located in Columbus, Ohio that provides Internet access to over a million people. He has been actively involved in the Internet2 project since its inception, and was an editor of the Monterey Futures Group White Paper on the technical requirements for the virtual university that serves as the requirements document for Internet2. Doug has led many workshops in campus networking strategies including CREN's Campus Communications Strategies Virtual Seminars CD and also was a guest here on TechTalk before.
Welcome, Doug, and thanks for coming back to TechTalk again.
DG: Thank you Judith. It's a pleasure. Howard gave an interesting lead-in when he talked about how IP transmissions can carry voice. I think it would be helpful if we for just a moment review how a traditional telephone call works.
HS: That'd be great, Doug. Although I worked at Bell Labs for a while, I'm still kind of rusty on exactly how that worked.
DG: Basically, when you make a long distance telephone call, the local exchange carrier such as Bell Atlantic or Southwestern Bell carries an analog signal with a bandwidth of about four kilohertz from your telephone to a nearby central office. There this signal is digitized and handed off to a long distance carrier or IXC such as AT&T or MCI. That digitized signal requires 64 thousand bits per second (64 kbps) of bandwidth. Then, at some distant location,the IXC transfers the signal to another local exchange carrier -- say, Ameritech -- which in one of its central offices converts the signal back to a 4 kilohertz analog signal for the short hop to its destination. Along the entire path, circuit switching technology is used. In other words, it looks like there's a pair of wires that runs from your telephone all the way to the other end.
There really are two reasons why everybody is interested in using packet switching to transmit voice signals. First, packet switching, which is used in our data networks, requires less bandwidth than circuit switching because in packet switching you can use better compression algorithms, which reduces bandwidth requirements by as much as a factor of eight. Second, you can eliminate wasted bandwidth during silences between individual words, which can reduce bandwidth requirements by as much as a factor of three.
HS: Well, maybe when some of us speak, Doug. I probably use up a little more bandwidth here.
JB: Howard talks very, very fast.
DG: There's a third motivation for making the transition to packet switching. The hope is that it will be simpler to manage one network -- a combined data and voice network -- than having to manage two networks like we do now.
HS: Excuse me, Doug. Is there really a second network? I thought that a lot of the traffic -- when I pick up my telephone and I connect to the Internet, I'm really going over the voice network, aren't I?
DG: Your Internet connection makes use of many of the same physical wires as the telephone system, but it uses a fundamentally different technology. So from a management perspective, the CIO at a local campus or the inter-exchange carrier really is managing two networks, the data network and a voice network.
JB: Okay. So in the early example, when you described how our current telephone works, Doug, and the packet -- the signals actually get digitized and sent over the network, and that is a physically different network than the Internet that we're using.
DG: Both the digitized and analog portions of a traditional telephone call are transmitted over the phone companys switched infrastructure. Internet Service Providers lease point to point lines from the telephone companies to support data services. The physical lines are common, but the equipment at the ends of the lines is very different.
JB: Okay.
HS: Is there some question about whether -- it sounds like when you're talking about the way this regular telephone call is made, is the signal an analog signal end-to-end, or is it ever digitized in the middle? What's going on in there?
DG: That's a good question because most people are not aware of the fact that with a standard telephone call, for most of the transmission the signal is almost always digital. In other words, many years ago the telephone company installed a technology to digitize the analog signal that comes from our headset. So for most of the distance, the signal is digital�
HS: Does that happen as soon as it leaves the central office?
DG: Somewhere around the central office or the next step.
JB: Okay.
DG: Now, when the telephone company digitizes the analog signal, they start with a four kilohertz voice signal. Two digital samples (one for each Hertz) are needed to completely represent the analog signal. In other words, if you start with a 4,000 hertz analog signal, you need to take 8,000 samples per second. Each sample is digitized with an 8-bit analog to digital conversion, so the final digital signal requires a 64 kilobit per second digital line.
HS: And that's what they're doing already today? We still haven't gotten to IP telephony, right? This is regular old telephony.
DG: Correct. With IP telephony we can use better compression algorithms and use the silence betwen words. For example, instead of using a pipe with a 64 kilobit per second bandwidth, we can now put it on a pipe with as little as 8 kilobit per second of bandwidth. In other words, we can carry eight conversations where before we could only carry one. Now you can gain another factor of three or so by using the silences between words in one conversation to contain other conversations.
JB: So it sounds like you've mentioned two different ways that we can get advantages with the packetizing of voice messages: both the compression and also the extra space on the pipes.
DG: Correct.
HS: And you haven't pointed out yet that the packet switching itself means we don't have dedicated circuits set up.
DG: The idea isn't so much the dedicated circuits, it's how many telephone calls can each wire or each fiber going across country support. Packet switching supports more simultaneous telephone calls on a given wire or fiber. That means the cost goes down.
HS: I thought, Doug, with all this fiber and all that kind of stuff, that the capacity of the telephone network was just rising enormously. So is there still a lot of pressure to get more room on these circuits to get more bandwidth? I thought with all this fiber, we had plenty of bandwidth out there.
DG: What we have noticed as a practical matter is that the cost of bandwidth at the current time is actually increasing. The reason for that is that even though there is more bandwidth available, demand for bandwidth is growing even faster.
HS: Okay, you talked about how we make a regular telephone call. Could you talk about the same sort of thing if we're using IP telephony? How's that go?
DG: There's a number of ways we can do it. I'm going to describe a couple of ways. One is we can hang a very inexpensive handset on our computer.
HS: And that's a handset that we have right now, or is it a special handset?
DG: This would be a cheap, ten dollar handset that you might buy at Radio Shack.
JB: That sounds good!
HS: So it's a regular old handset. It's my regular handset. I don't have to go out and buy some special digital IP thing?
DG: It's actually even less than what you're thinking. When I say the handset, I'm cutting it off at the telephone. It doesn't include the telephone circuit at all.
HS: Oh, okay. So you literally mean the thing I'm holding in my hand now?
DG: Absolutely.
HS: We just snipped the wire and plugged it into the back of my computer.
DG: Right. And within the computer, you would have the voice signal digitized and then put on the network. That's one way it can be done.
Another way would be to make a special box. That box converts the analog voice signal to a digital signal and puts it on the data network. You get a traditional data connection by plugging your computer into the back of that box.
There's various ways it can be done technically. The basic idea is to get the voice signal to a packet switched environment as quickly as possible to try to save money in the packet switched environment.
HS: But Doug, as soon as you take my telephone away and you just leave me with my handset, I have trouble dialing people. Does this mean I have to go off and go to other people by their IP addresses? I mean, I know I'd like to get rid of area codes and all that complication, but how do I route calls across this? Do I have to know people's IP addresses? Is there somebody translating phone numbers to IP? How's that part of the thing work? How do I actually get to people?
DG: Somewhere on your local area network, there has to be a computer that does this. When you're sitting at your whatever-it-looks-like phone and you enter a telephone number (because that's what you're used to) that set of numbers then goes to this remote computer on the local area network and generates the appropriate IP address. That computer or another also provides a gateway between the traditional telephony network and the data network.
HS: So since we really have a computer there -- looking up an IP address, right? That's what it's doing, if I understand -- since we have a computer doing that, you're saying that I really could make it so that I could just say, "Call Doug Gale" instead of typing your phone number. I mean, if it can take a phone number and translate it to your IP address, it could have the intelligence to take me saying, "Call Doug Gale" and translate that into an IP address.
DG: What you just described is one of the hopes and dreams of what we could do with a new kind of technology.
JB: So that's one of those new features that you mentioned early on.
DG: Yes.
JB: Okay.
HS: Can't we -- because I can't remember all these phone numbers with area codes that change every day. Doug, one of the things I mentioned in my opening thing was that this IP telephony is going to be cheaper than using the public switch telephone network. You talked about a couple reasons why the costs are going to come down, but do we have any sense of how much cheaper? And I've also heard that it's only cheaper because of the strange way we do tariffing -- that if the tariffing were done more fairly, that it wouldn't be cheaper at all.
DG: Let me give you two answers to that. One is an answer for today; one is an answer for five years from now.
If we look at the cost of doing voice over IP today, we can save money on cross country transmission lines, but that isn't the only component of the cost of a telephone call. There are costs for maintenance, customer support, billing, installation, and a whole range of services. Just because we can make one component of the half as expensive, it doesn't mean that the total cost will go down by a factor of two. That's only one piece of the cost of a telephone call.
If we compress the signal down to eight kilohertz from the 64 that's currently in use, in theory we can increase the capacity of telephone lines by a factor of eight. In theory, the cost of placing a long distance telephone call would be about 43% of what it is now. However, there is a "gotcha" in there. The "gotcha" is the way we tariff for telephone calls.
Currently, there's an arbitrage that applies to the way we charge for telephone traffic. Specifically, what we do is every time a long distance telephone call is made, the long distance portion of that call is transferred to the local exchange. In short, long distance traffic subsidizes local telephone traffic. The objective of universal service was to make sure that my grandmother could have a telephone for less than it really costs. So a long distance call is subsidizing the local calls.
Under the current tariffing, Internet traffic does not contribute to this subsidy. This difference in subsidizing local telephone service accounts for almost all of that 43% difference between traditional telephony and voice over IP.
JB: Wow!
DG: Right now, if you eliminated voice over IP's tariff advantage, the cost is about the same. In other words, there's no reason to --
HS: So there'd be no cost advantage to IP telephony. There might be other reasons --
DG: There might be other reasons.
HS: -- to do that, but not a cost edge.
JB: If pressed, Doug, what is the climate in terms of the timing in which the traffic over the net might be tariffed?
DG: I think it's realistic to say that the advantage that packet switching currently is given -- the way the costs are allocated -- that will not continue more than a couple of years.
HS: Okay, and there's no move to ask your grandmother (I'm sure she's a sweet person) to pay her own way here. I mean, it's been decided that people have as necessities food, clothing, shelter and telephones?
DG: That is correct. Politicians are elected and my grandmother votes.
HS: Who would take telephones from the tables of grandmothers.
DG: That is correct.
JB: It sounds like the Postal Service as well.
DG: Now, when you look out five years and look at 2003, 2004, then we see a different set of economics, and again --
HS: Okay, but 2003, 2004 -- at this point, you're imagining the tariffs are equitable. They're the same, at least.
DG: I'm saying the unfair advantage that voice over IP currently has, let's assume that goes away.
HS: Okay.
JB: All right.
DG: It means if that happened today, the advantage that voice over IP currently has over traditional telephony would disappear. I'm saying there's really no economic incentive if everything was done today to do this.
However, if we look out five years, or perhaps less, the economic analysis is different. If we assume improved technology as well as declining costs for operating packet switched networks and flat ratepricing, we get a much different answer.
HS: Which is?
DG: Currently voice over IP doesn't work worth a darn -- it doesn't sound good.
HS: Well, that was a question I wanted to ask. The thought of zillions of telephone calls coming in over the Internet (when I have trouble getting a Webpage in any reasonable amount of time) is kind of scary. It looks like the Internet already is over capacity. How is this stuff going to work? I mean, how could we possibly put the zillions of telephone calls that people are making -- or even some small fraction of them -- on the Internet and expect to get any kind of response? I mean, I can imagine somebody saying, "Hello," and then 20 minutes later, hearing the next word from them.
JB: In fact, you mentioned something in terms of just on the quality of the voice, let alone for the space for the voice. I think we were going to talk about both of those issues, Doug, weren't we?
DG: Yes. Howard's issues has to do with the Internet's capacity and yours refers to how good it sounds. The short answer to Howard's question is that the current Internet can't support the volume of today's telephone traffic.
HS: But aren't people just pouring the stuff into it right now? Is the IP telephony stuff pouring additional voice traffic onto the Internet?
DG: Not very much. It's not a big factor yet. But with new initiatives like Internet2 and Abilene, the Internet will have the capacity to support telephony. However, there's still a quality problem. If we make the Internet larger to address the capacity problem Howard was talking about, we still have two problems related to the quality of the sound transmission.
First, current generation packet-switching networks introduce a delay in the time it takes packets to reach their destination. That delay can vary anywhere from 20 milliseconds to 800 or 900 milliseconds.
HS: Which is close to a second.
DG: That's right.
HS: (That's for our users who can't do milliseconds!)
DG: That delay -- a millisecond is a thousandth of a second. The delay we're talking about sounds like a long pause before each speaker on the telephone conversation.
JB: I actually experienced that when my daughter was over in Spain and we tried to use the IP telephony. And it was very difficult to carry on a conversation.
DG: Yes. What you'll notice is the delay. If it's approximately 100 milliseconds, you won't notice it; if it exceeds about 200 milliseconds, it becomes objectionable. If it exceeds about 400 milliseconds, it becomes intolerable. The average domestic telephone call is about eight milliseconds. So there is a problem, a fundamental problem, with the way IP handles delay.
Now, the problem becomes even worse if there is a variation in the delay. It's one thing to have a row-row-row-my-boat echo problem: "Row-ro-row-ro-row-my-boat. Ge-gently, ge-gently, ge-gently, d-down-the-stream. Merrily, merrily, merrily, merrily, life is, life is, life is but a dream." That's annoying. However, a variation of that delay is what's called jitter, and that attacks intelligibility. The sound is similar to an extreme case of stuttering. That's a critical problem because you have to be able to understand what the person said. You can sort of tolerate delay, but if you can't understand them, the technology is useless. Latency affects the flow of the conversation; jitter affects its intelligibility.
HS: Isn't that a real opportunity for people doing IP telephony, in that it sounds like you could set the latency as high as people can tolerate it -- which means if you kept it constant, people would like that better, which means you could do a little buffering in there.
DG: That's right. That's exactly how you solve the jitter problem -- add buffering. Most of the devices currently on the market include substantial buffering. But that exacerbates the problem of delay..
Now, it turns out there's yet a third problem that still has to be addressed, and that's one of reliability. The traditional telephone system is 99.999% reliable. There's only about five minutes your telephone won't give you a dial tone. That's what we're used to. Unfortunately, our data network is far from being that reliabile. If we want voice over IP to be widely accepted, we have to increase data netkwork reliability.
HS: Is it likely we'll ever be able to do that?
DG: It can be done, yes.
HS: But when's that going to happen?
DG: Say, over the next five years.
HS: Doug, we have a couple questions coming in here. I wonder if we could just go off and try to answer some of these.
And also a point from John Collins at Duke University. He opens his question by asking if you could speak up a bit, and I should tell you, John, that we've been having a little bit of problems with (believe it or not) telephones here. So we'll try to get Doug to speak a little bit louder. But I think it's the telephone system, and not any failure on the part of Doug.
DG: John, we are having a telephone problem. They can hear me in the next 20 offices because I'm speaking very, very loudly, but I'll try to crank the volume up another notch.
HS: Yeah, but John Collins is off at Duke! And that's just a little further away, I think. But anyway, Doug, John has a question. He says, what advice would Doug give for a nonprofit organization that owns their own number 5 ESS PBX with 18,000 lines or a business and technical move to voice-over IP, and what pitfalls should we be aware of? Lots of question marks.
DG: My advice would be to drag your feet upgrading your hardware. Watch the experiments that are going on.
OARNET, for example, is planning to install local voice-over IP systems to replace its current PBX. But we're a fairly small organization. I would advise trying to delay major upgrades on an in-house PBX and see what really happens as other organizations deploy voice over IP.
HS: Okay, we have another question. This one comes, actually, from EDUCAUSE, which is kind of interesting. This is Casey (and I may get your last name pronounced incorrectly, Casey, I'm sorry) Lide. Casey says, "You've talked about handsets connected to computers. What's the role of gateways such as Vocaltech product, and how do they interact with the PBX? In other words, is there a context in which the IP telephony can be used in a manner completely transparent to the user, or perhaps with an access code, where they use their normal telephone rather than a tool attached or integrated within their desktop computer?"
That question was from Casey Lide. Casey, we were going to ask that question, if only you had given us more time! But I think we'll handle it here now.
JB: That's right, a great question. Doug?
DG: Actually, there are two questions, and the first question has to do with the gateway. That's the box -- computer if you will -- that interfaces the voice-over IP signal with the traditional telephony public switched network. And yes, if it's properly designed, it's made so that it is transparent to the end user.
Now, the second question has to do with how you connect the headset into the network. Now, the one method that I had mentioned earlier is one of two alternatives, and the method that Casey mentioned -- to attach a headset to the computer -- is the other.
The problem is that the Windows operating system itself adds 800 to 900 milliseconds of latency. If you program in some of the languages designed for game players, like ActiveX, you can reduce that to 300 or 350 milliseconds. That's still unacceptable. So unless Microsoft rewrites its operating system, we simply can't use the computer itself as the interface.
That's the reason that we're seeing the emergence of separate boxes. We plug the headset into the box and we plug the computer into the box to bypass the Windows operating system.
HS: Is the point that NT obviously was not written to be a real-time operating system? It wasn't designed to control refineries and things like that, and so it just wasn't designed to do this real-time voice conversion stuff.
DG: That's right.
JB: You mentioned some of those new boxes being developed, Doug. Are those being developed by the major telcos?
DG: Yes. They're also being developed by independent companies and some of those independent companies, like Selsius, are being acquired by larger companies like Cisco. Cisco recently bought Selsius, which is a small company that made one of these boxes.
HS: And that box -- that Selsius box -- could you tell us just a couple more things about it?
DG: It's typical of a number of units. It's a small box with a telephone on top. And it functions as a telephone, but it plugs into an IP network. Now, you plug your computer into the back of this box, because the Selsius box acts as an Ethernet repeater.
HS: So the computer plugs into the phone, not the phone into the computer.
DG: Right.
HS: That's the real difference here, and that's why we don't have the latency introduced by the operating system.
DG: Correct.
HS: And we ought to tell folks, if they want to check out this Selsius thing, they can go off to the Website at www.selsius.com (spelled strangely, I think) and they can find some information on that. It's kind of interesting. We have another question, Doug, from Peter Day at Emory University. Peter says, "I have heard that the Qwest Telecommunications Network is IP based. Is this true? If so, what does it mean for Qwest's ability to deliver services today and tomorrow, and what does it mean for its customers?"
DG: The answer is yes, Quest is IP based. Specifically, they're running IP over SONET. It means that they have developed a network that has been optimized for the kind of traffic that we run over the Internet for data traffic. It also means that if we can resolve some of the quality-of-service problems -- such as the latency problem and the reliability problem -- that they also have an infrastructure that can be used to support telephony.
I should also add that some major traditional telephony carriers are beginning to do a lot of research into voice over IP and have privately indicated that at least one of them feels that this is their business future.
HS: But are any of them offering this right now? I mean, does MCI or Bell South or AT&T -- if I called up one of those people and said, "Hey! I want to do some IP telephony!" What would they tell me?
DG: I don't believe any of them are currently offering those services. However, if you look at their Webpages, all of the people you mentioned are doing work in the area of IP telephony.
HS: Okay, well, I mentioned both local telephone companies and long distance carriers, so you're saying that both local carriers and long distance carriers are interested in this area.
DG: Yes.
HS: This is not going to just be the long distance carriers or be just the local carriers. What about ISPs? It seems like ISPs, that's another group of people that might be interested in doing this kind of thing. Are those folks doing some work in this area?
DG: As an ISP, I can answer, definitely, yes.
HS: What do you mean -- are you an ISP?
DG: Yes, we are.
HS: Okay.
JB: Yes, OARNET is.
HS: Oh, okay. I keep assuming that everybody is from a university -- that nobody could be from anywhere else, of course!
JB: Ah, there we go! Well, what are you doing as an ISP in this area, Doug?
DG: Well, we're doing two things. The first is that we are considering acquiring a local voice-over IP switch for our own internal telephone traffic. We are also working with several other universities in Ohio on an experimental basis to, again, interconnect small offices using IP to see how it works.
JB: Okay, so you basically have a pilot project going on this.
DG: That is correct.
HS: Doug, what about cable companies, cable TV companies? They seem to be involved in all kinds of things that involve communications. Are those folks getting into this, too?
DG: I don't have any specific information, but I'm sure they are because the market forces them in this direction.
HS: One of the things -- this might be a question a little bit to the side, but we just heard from our local telephone company (which is Bell Atlantic here). They just sent us all kinds of stuff on their DSL offerings. How does this IP telephony play with DSL? Is it a competitor? Is it part of it? I mean, DSL looks pretty good.
DG: I would say it is compatible. What you could do, if you had a good DSL connection, is actually run a switched voice signal from your home all the way through the system. So I would regard the DSL potentially for a local exchange carrier such as Bell Atlantic as a step towards being able to support telephony over IP on a larger scale.
HS: So you see all these things playing together? I mean, this IP telephony is not going to put cable modems out of business or push DSL aside or do any of this kind of stuff? It's going to coexist with all these other technologies?
DG: That is correct. I would also say I don't see it pushing the traditional PBX aside, because we have a tremendously sophisticated telephony infrastructure that's been developed over many decades. And just like the PC didn't kill off the mainframe, telephony over IP (if it is successful, which has yet to be demonstrated) should not kill off the traditional PBX system.
HS: Even though in a university (or a company or whatever) we have a computer on every desktop and every computer has an IP address, and so we have to have a data network connecting all these offices to each other -- you're still saying that people will still use some kind of private branch exchange to do telephone switching? You won't use this IP network that we have anyway inside our universities or companies?
DG: Do you still have a mainframe on your campus?
HS: You're just trying to embarrass me on the air here!
JB: Probably transparent. We don't know that, right?
HS: Do we have a -- yes, we still have a mainframe, though I think we call it a super server. (The way we're going to get rid of our mainframe is we're going to define it to be just a very big server.) Yes, we still have a mainframe here.
DG: A rose by any other name is still a rose!
HS: Still!
JB: This does get us into looking at the university campus and thinking about what are some of the practical implications for our university campuses with IP telephony, Doug. Would you recommend that somebody get started in this area right now, or just wait on it for a bit? Just what do you think are some practical advice that we might provide?
DG: I think campuses should start tracking these technologies very closely and perhaps begin some pilot projects.
I previously was on a campus and we had as part of our strategic objectives three or four years ago, to avoid upgrading our PBX and moving toward integrated voice and video and data infrastructure to the desktop. And we were projecting a 1998-1999 timeframe. In retrospect, we found when we tried to actually do it, that the technology wasn't quite ready.
On the other hand, what we're also finding is that it may not have been ready for 1998, but it looks like it will be ready at some point in the next few years for certain applications. Again, I want to stress that the PBX is not going to go away.
JB: So in other words, you might want to start using this technology in limited areas?
DG: Yes. You might take an individual department. For example, the networking group at Ohio State deployed voice over IP within a single department and then tied it back into their standard telephone system, just to gain experience on what really works and what doesn't.
JB: Okay.
HS: We have another question, Doug, from Richard Danielson in Laurentians in Canada (I'm not sure exactly where). But Richard asks or says that "We are interested in being able to use something like NetMeeting and broadcast a lecture to students by IP, then open up the conversation to questions from students. Is this possible?"
DG: Yes, it is currently possible, and I think Judith may want to answer part of the question.
The second part of the question is opening things up to students -- I think the current quality leaves something to be desired. But as we address this problem that I mentioned earlier -- the rate of delay and jitter -- the quality becomes better. It becomes a much more useful option.
Judith, you might want to comment on some of the stuff that you've seen running today.
JB: Okay. In response to that, we've been looking at that kind of technology, particularly for distance learning environments, and we do have RealNetworks coming out with a technology that we took a look at called Classroom Presenter. And that's in development right now, but it will provide an opportunity for a faculty member to go over the network and present a lecture and then be accepting e-mail questions real-time while that's happening. I saw just a short demo of that, but I think, again, we're seeing a technology that's in development and that will be coming soon.
So the idea, I think again, is just keep tracking and planning for that because it will be here soon, I think.
HS: Okay, we have another question from John Collins at Duke University, which I'm just going to paraphrase sort of because it fits in with a question I wanted to ask Doug. So John, I'm going to kind of share this question with you here.
But Doug, you mentioned Internet2 as a possible future solution to getting all this IP telephony over the Internet. Could you just talk a little bit about how that might work? I mean, is that realistic? Is that what Internet2 is going to be used for?
DG: There were really a couple of objectives for Internet2. One was to address bandwidth issues. How can we build a network that just has bigger pipes to carry more bandwidth? That addressed some of the problems, Howard, that you had referred to.
There was also an intent with Internet2 to focus a lot of effort on addressing quality-of-service. Remember, quality-of-service is that latency and jitter issue. The question of latency is the one where the packets don't quite arrive in sync.
HS: Right, but isn't there also just the issue of the quality of the sound?
DG: Yes.
HS: But I mean, besides latency and jitter, if a packet gets lost or garbled or something like that, latency and jitter can be just fine and the voice will sound horrible.
DG: That is correct, so there was an attempt to use better technology through the entire system to reduce packet loss -- improve latency and jitter, or at least precisely define it to specify that for certain kinds of traffic, you need to have very low latency and jitter. For some things like electronic mail, you don't really care.
So one of the things that's been happening with Internet2 is to provide differentiated services. So we might identify a certain packet and say, "This packet is part of my e-mail and I really don't care if it doesn't get there in the next 300 milliseconds."
HS: Right, because somebody's going to read it later anyway. They're not going to read it right now. So there's real-time vs. not-real-time issues.
DG: Correct.
JB: One of the things that we're getting close to talking about is the concept of just what are the standards in IP telephony. Are we at a technology point (as we often get) where there's just a lot of competing standards, Doug? Or are we getting close to having a situation where people are starting to agree on some things here?
DG: I think they're converging. They're converging around on the IP side something called H.323, and that has a whole series of standards underneath it.
In fact, I'm reviewing a paper for publication in one of the communications magazines now that deals with the dozens and dozens of sub-standards under H.323 and how those standards interface, for example, with the standards for handling call-forwarding.
So there are a lot of standards out there and they are, in fact, converging. Now, we have not yet had them well enough defined that there is inter-operability between implementations from different vendors in all cases. But standards are really evolving very rapidly.
HS: Okay Doug, as you know, earlier we had a question from Latvia, and now I see we have a question from almost the other side of the world in Hawaii. We heard from Allen Winery in Hawaii. It's really great to have people -- I mean, it's very late. It was 11:00 p.m. in Latvia. I'm not sure what time it is in Hawaii, but I'm sure if I mention this, I'll be told. But at any rate, Allen says -- he makes a comment first. He says, "Doug says that Windows' real-time performance is unacceptable for telephony, yet not knowing this" -- it's kind of an interesting thing -- "yet not knowing this, I have been using IDP-Net2 Phone with great success and did not have problems with the conversations. I have had traditional calls routed by satellite that were much worse". I actually can believe the part about the calls routed by satellite. You want to comment on that, Doug?
DG: It depends upon the quality of the line and how the network has been established. As you look at latency, one component of latency is just the speed of light and the distance. You can send a signal halfway around the world with 70 millisecond delay. If you have a network that doesn't have a lot of intermediate routers, has not been overburdened with users, is well-provisioned -- yes, you can in fact get satisfactory service.
In fact, I can name at least one university that uses a dedicated IP line between the central portion of the United States and London, England. Rather than run traditional telephony on that T1 line, they have deliberately selected to run IP because it is a leased line and they can control the quality of service, and by using IP they can put roughly eight times as many conversations on that leased line. And it's working very, very well for them.
HS: Doug, earlier in the talk, I stumbled across something when I said, "Gee, could I come along and just say 'Call Doug Gale' and this thing would work?" and you said that's one of those possible future applications -- future things we could do with IP telephony. Are there other things that you might expect that this kind of thing would enable us to do, enhancements to the way we use telephones today?
DG: Yes. Think about your traditional call waiting. Now, while we have been on this telephone call, I've notice my call waiting message light has started blinking.
HS: Mine, too.
DG: I have no idea who called. On the other hand, if we had an IP based system, I could very easily turn over to my terminal and it would say, "A call is incoming from so-and-so." And depending upon that call --perhaps it's from my wife -- I would look at that and I would key a response and say, "Put it on voice mail," because she wants to tell me that she's going to be late from work and won't be able to pick the kids up.
JB: And that you get to cook dinner.
DG: And I get to cook dinner. Another call --
HS: So now we're talking about the disadvantages of IP telephony.
JB: That's right!
DG: I might look and see that it's my boss, and I'll immediately punch a key that forwards it to one of my colleagues down the hall so his call will be taken. And so it gives us the ability to interactively actually manage more than one conversation simultaneously.
JB: Aha! So more multiple processing is ahead for all of us.
Okay, so we have call waiting and we have our telephone agents that will go ahead and dial phones for us. Any other new feature that you've been excited about?
DG: Well, IP messaging. If we think of how this broadcast is being done -- now imagine having that capability without having to go through the rigmarole of having a phone bridge or Webcasting. Just say, "I'd like to call the following eight people." They might call five others each, and this is all built into the system -- done automatically.
JB: So we really could do this over IP, then.
DG: Yes. I can send you a voice fax.
HS: Another question I have is we're talking about doing voice over IP. Are folks doing faxing over IP, or video over IP, or images over IP? Is this going to all be done the same way?
DG: That's the hope, yes, because if we can do voice over IP, it would be relatively straightforward to do video over IP with little additional bandwidth.
HS: Sounds like a lot of additional bandwidth.
DG: It turns out that getting additional bandwidth is easier than addressing the latency problem that we have with voice.
HS: Don't we have the same problems with video? I mean, the image is going to jump around and it's going to slow and I'm going to see people like they're moving underwater, that kind of thing?
DG: The eye is much more forgiving. Remember, your television image is refreshed only 30 times a second, and that's incredibly slow compared to the sensitivity of the ear. So the latency problem is much more difficult for audio than it is for video.
JB: We seem to have managed to spend just a wonderful time with you, Doug, and our time is about gone. Howard, do you have any final question -- or Doug, a final comment?
HS: No, I have about ten questions here, but I think we'll have to do these in another session. It will be kind of interesting, actually, to revisit this perhaps next year and see how many of these questions and issues are actually resolved. This certainly is going to make me look at my telephone and my IP network a little bit differently.
JB: All right, well, thank you. And we'll tell the folks who have sent in the e-mail questions that we'll try and get to those outside this Webcast.
HS: Actually, I believe we got to almost all of them.
JB: Oh, did we?
HS: Yes, I'm looking around. If there are any we didn't answer -- of course, all I had to do is say that and one more comes in! Any question we don't answer we will certainly get Doug to answer and put it in the archives.
JB: Very good.
Well, with that, then, I'd like to thank all of our Web participants for being with us here today, and it was great having a global group this time. Please send any other follow-up questions to expert@cren.net.
And also, be sure to mark your calendars for two weeks from today, February 11, 1999. This TechTalk will feature a return of expert David Wasley from the University of California System Office, and David will be talking about digital certificates and just identifying who your users are. So do plan on joining us and inviting your friends and colleagues as well.
Thanks to all who helped make this possible today: the Board of CREN; guest expert Doug Gale; technology anchor Howard Strauss; Web content producer Terry Calhoun; Paul Bennett at UM Web Services for encoding; and all of you for being here. You were here because it's time. 'Bye, Doug. 'Bye, Howard.
DG: 'Bye.
HS: 'Bye, Judith. and thank you, Doug -- it was very interesting.
DG: Thank you.
JB: Just great. Take care.
HS: 'Bye-bye.
