TechTalks Transcript
IP Telephony
 Judith Boettcher [JB] |
 Howard Strauss [HS] |
 Charles Morrow-Jones [CMJ] |
 Russell Morrison [RM] |
November 18, 1999
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
JB: Welcome to the CREN TechTalk series for fall of 1999 and to this session on IP Telephony. You are here because it's time to discuss the core technologies for your future campus.
This is Judith Boettcher, your CREN host for today -- and a special thanks today for partial support of today's event goes to Cisco Systems and their central Ohio group, and their work in empowering the Internet generation. I'm pleased to welcome the technology anchor for TechTalk, 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 CREN webcasts. As technology anchor, I'll engage our guest experts 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 experts, Charles Morrow-Jones and Russell Morrison, your own questions by sending e-mail to expert@cren.net anytime during this webcast. If we don't get to your questions during the webcast, we'll provide answers in the webcast archive.
In our TechTalk webcasts, we have covered many leading-edge technologies. Just recently, for example, we discussed Internet2, wireless technologies and of course, much of what we discuss somehow or other involves the Internet. All these technologies and many others are interesting of themselves. Almost daily, there is some neat new thing that becomes possible, and usually we can't wait to get our hands on it and have it running at our own college or university.
Some technologies take off like rockets, while others remain just fascinating curiosities. The difference, I've come to believe, is the appearance of one or more killer applications that makes a technology soar. On the Internet, two applications that changed it from the private preserve of governments and universities to the technology that ate the planet are e-mail and the Web. Without e-mail and the Web, few in the real world would even know what the Internet was, let alone use it every day. Many technologies are still waiting for their killer applications. Internet2, for example, will never really be successful until there is some compelling application that just wouldn't be possible without Internet2.
Today we'll be discussing IP telephony and Voice Over IP. These technologies enable phone calls and phone traffic to travel over the same networks and in the same way as our e-mail and web pages -- namely as digital packets. The initial impetus for this technology was to cut the cost of phone calls, especially the very high cost of international calls. The October 11, 1999 issue of Business Week estimates that 1.2 billion minutes of international voice traffic -- that's about one percent -- will be carried via IP over the Internet in 1999. They expect this to go to seven percent, or about ten billion minutes and almost a billion dollars in revenue, by 2002.
But the Internet was built to move data, not real-time voice or video. The Quality of Service requirements for any real-time application are quite different than those for moving data. If a few e-mail packets or web page packets get delayed by a second or so, it doesn't materially affect the usability of e-mail or the web. But random one second delays in voice packets would quickly send you back to using the PSTN (or Public Switched Telephone Network).
Many people are hard at work on the IP telephony Quality of Service issues, but there's much more to be done. As for the cost advantage of IP telephony, it may be ephemeral. It is quite possible that phone companies will soon offer free voice calls when you sign up for a package of data and video services, and that federal or local regulators will impose tariffs and taxes on IP telephony, especially when it starts to cut into the revenue of traditional voice carriers. This technology might prevail anyway because it uses the digital packet switched technology that the Internet seems committed to, and about half of the traffic carried by the PSTN is already some form of data.
But using IP technology for telephony should provide many more advantages than just possible cost savings over the PSTN. What I'm convinced is out there somewhere are some killer IP telephony apps. Once we've digitized and packetized our phone calls, it seems obvious that there must be things we can do that would be impossible to do with the PSTN and its 120-year-old technology.
To get you started on being one of the people that develops one of those IP telephony killer apps and earns a zillion dollars, Chuck and Russ will get you started on understanding IP telephony basics and will point you towards ways you could try this on your own campus on today's webcast of TechTalk.
Judith?
JB: Well, thank you, Howard. And after your intro, I really begin to wonder whether the word "telephone" will be in our vocabulary. Maybe we're talking about -- when we talk about IP telephony, it's like talking about the horseless carriage that we used to talk about cars. Well, thank you.
Let's go on and introduce our experts for today, both from the Ohio State University, and they are Charles Morrow-Jones and Russell Morrison. Charles Morrow-Jones (and I think we're going to call him "Chuck" from now on) is the Director of Enterprise Networking within University Technology Services at Ohio State. And Chuck has been involved with various aspects of information technology for 25 years, much of that at Ohio State. Our second expert, Russell Morrison, is a customer service engineer working with Chuck on Enterprise Networking and specifically on the IP telephony project at Ohio State.
Chuck, Russell, welcome, and thanks for being here.
CMJ: Judith, thanks a lot for having us today. We're glad to be here.
JB: Great. Okay. I think we should just -- we've got a lot of questions I suspect we'll be getting, so let's go ahead and get started with our questions. Howard?
HS: Sure. Chuck or Russ, I'm not sure who wants to handle this and perhaps you're just going to both jump in here -- and you ought to feel free to do that. Maybe we could start about talking about IP telephony and Voice Over IP. If you could just give us the basics of what those things are.
CMJ: Okay, I'll give it a try and then maybe Russ can bail me out.
JB: Okay.
CMJ: We see Voice Over IP, IP telephony as a continuum of solutions that involved transmission of Voice Over IP to some extent during the course of -- let me use traditional terminology and call it a "phone call". So IP can play a very miniscule role, all the way out to we can have solutions that are end-to-end IP.
We have a number of providers out there who are providing IP as the center of their voice transmission and that's where we're finding a lot of this international market. So the Public Switched Telephone system will go to a gateway point, and the voice traffic will be turned into data, transmitted either over the conventional Internet or over a virtual private network to some point in another country, at which point it will be turned back into an analog signal and pushed out through the PSTN in that other country. Savings exist in that middle link, that is, the intercontinental link.
JB: But you're saying, Chuck, then that our various AT&T, Bell South, MCI, all these folks, may well be using that technology in our everyday phone calls.
CMJ: Exactly.
HS: And we wouldn't even be aware of it then?
CMJ: We wouldn't know --
HS: We pick up our regular old telephone and we make a call and they fiddle around with the signal somewhere in the middle.
CMJ: Right. It's like the days when you didn't know, nor care, whether it was going over fiber or microwave.
HS: Well, like we don't care today. I mean, I don't know if I make a phone call whether it goes up over a satellite link or where it goes.
CMJ: Right.
HS: And so it gets changed around and mixed with other things, that kind of thing. But the other situation you described was as it leaves your phone, it's going IP.
CMJ: Right. The other situation is --
HS: That sounds like you'd have to know about that because, well, you'd be doing something different right at your phone.
CMJ: Well, the phone actually is the digitizing instrument and it's digital over IP all the way to another phone that is also speaking IP, if you want to think of it that way.
And those kinds of systems can exist in pure IP mode or they also can have gateways to the existing PSTN. And I think it's at that end of the spectrum where Russ and I would like to focus today because that's where we've had most of our experience. And I think that's where a lot of the interest from universities is coming, is in the more ubiquitous use of IP across an entire --
HS: Okay, so it's IP end-to-end.
CMJ: Right.
HS: Or at least you're concerned that it's IP at the end you start with.
CMJ: IP, let's say for 98% of the time.
JB: Chuck, just so that we can clarify some of the terminology, you know, I've been hearing about both Voice Over IP (in fact, that's the name of that working group that we've got a link to) and then there's IP telephony. Is there any -- what's the difference between those, or is there any difference?
CMJ: I think that it's one of those that it depends on the speaker whether there's differentiation or not. I've heard people use them interchangeably.
We tend to think of the IP end-to-end as being IP telephony and refer to it that way, where the Voice Over IP is broader, just involving IP somewhere along the way.
JB: Okay.
CMJ: But I'm not sure that there's any standardization that yet exists.
JB: Okay. But for your own particular project, you are calling it when it's end-to-end, you're calling it IP telephony?
CMJ: Correct.
HS: Okay, if we're going to talk about the advantages (and I assume that's what we're going to spend some time talking about) of IP, could we talk just a little bit about -- I mean, could you give us an example of how a call travels across the PSTN today, not using IP. And what's really different about something going across our data networks using IP packets?
RM: You want me to take that one, Chuck?
CMJ: Sure.
RM: Hi! Russ Morrison.
JB: Hi, Russ. Great! Glad you jumped in.
RM: Thank you. The going over the PSTN, the way calls are set up are through a signaling called SS7 (Signaling System 7), and over the legacy network, when you make a call from --
HS: When you say the legacy network, you mean the stuff we use every day?
RM: Yes.
HS: So the stuff we use every day has become the legacy network.
RM: That's correct.
JB: Okay.
HS: That's awful! It sounds like the thing is out of date.
RM: And I think we are evolving there! The legacy network (or the PSTN today), when that sets up a call -- when I call from Columbus, Ohio, to California, there's a signaling that goes between Columbus, Ohio, and that signaling finds the best route. I can make a call at 4:00 and that Signaling System 7 will find the best route there, and the best route may be to go from Columbus to Cleveland to Atlanta to California.
HS: But the point you're making is that there's a physical connection? I could, once all the little switches are clacked shut, I could follow a wire or a transmission from tower to tower? I mean, there's a dedicated circuit set up, right?
RM: It will be dedicated once the call is complete, yes.
HS: Right, so that's -- I mean, the effect is that there's some physical dedicated circuit that's set up and it belongs to me and me only.
RM: That's correct. And you own that piece and the way that signaling works is if I make that call at 4:00, I may go the route I just mentioned, but if I made that same call at 4:01, instead of going to, let's say, California by way of Atlanta, I could go to California by way of Chicago.
And that's the way the system works today. And when you use the PSTN you go from your PBX (Private Branch EXchange) to a Local Exchange Carrier (a LEC) -- for example, an Ameritech or a US West or a Southwestern Bell. And to an IXC (an IntereXchange Carrier) who are the Sprints, MCI's, and all that has to take place for that call to be completed. And once the individual called in answers their phone, then I get that nailed up circuit that you just referred to.
HS: Right, and that circuit stays up as long as we stay on the line.
RM: That's correct.
HS: Okay, and this whole thing really was built for voice, which seems to me the network was built for relatively short calls, calls of relatively short duration. Because you really don't want to tie this stuff up for hours on end.
RM: That is correct.
HS: So data must be a real mess for the PSTN.
RM: That's correct.
HS: Because people tend to get on -- I mean, like, you'll get on your computer and you'll be on it for hours.
RM: And many local exchange carriers like the Ameritechs and Southwestern Bells are looking at ways to deal with all of the individuals dialing into their PBX's -- or, excuse me, their switches -- and their strategic locations around the city because they're not used to the Internet user. They're used to the home user, like you just referred to, making a call, talking two, three, five minutes and hanging up, where users now are dialing into AOL and staying connected for hours on end. And it's putting a strain on the current legacy network.
HS: Okay, how does IP telephony differ from that? It seems like you still have to connect those people to each other.
RM: That is correct, but you're not using the PSTN at all.
There's a couple ways of using IP telephony. One is when we're using the commodity Internet (that's the Internet that we're all used to when we type "www" -- we're going out on the commodity Internet). Placing a call, an IP telephony call over the commodity Internet, you're actually contending for bandwidth with all the other users who are out there.
HS: So this -- on your end, what happens first? I'm talking into my phone. Let's say that this was a phone and my call was going to go out over IP. You made a point before that your call's going out digitally, not analog. So something's had to convert my voice, something's got to digitize my voice, right?
RM: That's correct.
HS: And is that my phone?
RM: Your phone will actually digitize, yes, and then your Call Manager or the software PBX that handles your IP call, that sets up your IP call (similar to a switch or a PBX in the legacy telephony world) will take that packetized packet.
HS: Does my phone packetize it or just digitize it? Or is my phone doing both of those things?
RM: No, actually, your phone will be digitizing it.
HS: And then the Call Manager, the thing the Call Manager runs on is going to packetize it?
RM: Yes, you'll start putting packetize headers on that, that's correct.
JB: But maybe we should -- Russ, let me just make certain that this is clear. Am I picking up my regular telephone or am I using a different kind of appliance?
RM: You are picking up an IP phone, not a traditional phone that one may buy, like an AT&T or a Western Electric phone.
JB: Okay, and does this Internet phone look anything like my, you know, my legacy telephone that I've been used to?
RM: Yes, they look identical in that they may have different colors and different buttons, but to see an IP phone sitting on your desk and seeing a legacy phone sitting on your desk, unless you were told, more than likely you would not know the difference between the two.
HS: Unless I followed the wire out the back of it.
RM: That's correct.
HS: Where's that wire go if it's an IP phone?
RM: It plugs into your Ethernet network.
HS: Okay, so I need -- do I need an extra Ethernet connection in my office?
RM: No, you do not. The current phones being manufactured today come equipped with either a hub built into the back of them or a switch built into the back of them so the user will only need to unplug their connection from their PC, plug it into the back of the phone and then use the other port on the phone and plug that into their PC.
HS: Okay, so if I were talking on my phone and collecting my e-mail at the same time, I'd be just contending for bandwidth on the same Ethernet connection?
RM: That's correct.
JB: Wow! Okay.
HS: Okay, so what happens is we got as far as the Call Manager, right?
RM: Yeah.
HS: And I now have digitized packets that may be at this Call Manager, and how are these things routed to where I want them to go?
RM: How they're routed, you can set that up in your Call Manager. You can actually set up route patterns, just the way a route is set up in a PBX. In a PBX, you dial -- your calls are routed by the area code, 614 and what have you. In Call Manager, you can do -- you set up your route patterns to do the same thing. I can set up one Call Manager to route its calls to another Call Manager across the country.
HS: This may seem like a minor point, but to me it's an important point. When I pick up this IP phone and I want to call you, Russ, what number do I dial?
RM: You would have to have my numbering plan, the same as you would have to have the numbering plan to call my sister on the legacy phone network.
When we start setting up Call Managers across the country, we will have to exchange our call patterns. Now, one way that we'll be setting up call managers is we can also, by way of a gateway, use the exact same numbers that are currently used on the PSTN on the far end.
HS: So this little, this little Call Manager does something like a domain name serving? I key this telephone number in, this telephone-like number in, and it looks up the -- it's really looking up the IP address of your telephone.
RM: No, actually, it's not looking up the IP address. What it's doing, it's taking a look at that route pattern and it's going to send the digits that you type in your IP phone over to the Call Manager that you route it to. And that Call Manager that you route it to will take those digits and find out whose phone that is, find the IP address -- or actually the MAC address, the Media Access Control Address -- and ship those digits to that phone.
HS: Isn't this MAC address really an IP address?
RM: No, the MAC address and IP address are two different --
HS: But these phones, these IP phones, do they have IP addresses?
RM: Yes, they do. Every device on the Internet has some type of IP address. Some are behind something they call Network Address Translators which are routed IP addresses, but as for this conversation to go from your phone, your IP phone in your location to my IP phone here, we have an IP address on our local network.
So I have an IP address on my local network and you have an IP address on your local network so your phones can be identified locally. But when I send a packet to your Call Manager from my Call Manager, it gets there. It finds your phone and your Call Manager by MAC address, and then your phone has an IP address so it can be identified on your network and it sends those digits to your phone and your phone rings.
HS: Okay, but the other point that's sort of implicit here is that there's no dedicated connection.
RM: That's correct.
HS: Between me and you.
JB: It might be a good time to just remind everyone that they can send in questions, now that we maybe have confused everyone on this, to expert@cren.net.
HS: Yeah, or pick up your IP phone.
JB: Right, okay.
HS: And call Russ!
HS: Don't do that! Okay, I'm just trying to, again, get a feel for how this thing really works when I pick up my IP phone. But it sounds like, though, that we're contending for exactly the same bandwidth out on the Internet. And for example, around here on the East Coast, around 2:00 in the afternoon, the Internet seems to get a little slow because zillions of people are doing stuff. How does IP telephony -- it sounds like IP telephony is going to pour a whole bunch more traffic onto the Internet. How are we going to deal with this problem?
JB: And how big are the telephone calls?
RM: Well, actually it's not much with regards to bandwidth utilization that an IP phone uses. You can compress actually an IP phone call down to 5K. That's five kilobits per second, which is nominal. That's -- in terms of bandwidth utilization, that's a drop of water in a bucket.
JB: So I could actually, from the IP phone, really be surfing the Net and talking at the same time over my same connection and I wouldn't notice anything?
RM: Correct, but keep in mind that's also governed by your size of pipe to the Internet. So if you don't have a very large pipe to the Internet, then you're going to be slow without using your IP phone, and you're also bound by the traffic on the commodity Internet once you get out onto the commodity Internet, if it's extremely busy. Like the example at 2:00 PM, then you're going to suffer the consequences of that, or your call will.
HS: Okay. And the consequences are going to be Quality of Service problems.
RM: That's correct.
HS: Right, so the sound will sound jerky and delayed and things like that.
JB: Can we go back to a question? We talked about the fact that we're going to have to have a different kind of a phone. It's going to be a phone, but a different phone. Are these phones expensive, these new phones expensive?
RM: At the moment, they are. Right now, the couple of manufacturers that are out there are at the $300-500 an instrument price point, retail.
JB: Okay.
HS: The expense is because these things have to digitize the audio? Is that what makes them expensive?
RM: No, really, it's the fact that the expense is that we're at the very front end of the production curve.
HS: Okay, so it's a Econ 101 problem.
RM: Right. Very few units are being --
HS: The cost and price have nothing to do with each other.
RM: Very few units are being produced, so the cost per unit's high. And all the expectations are that, as IP telephony is adopted by more and more organizations, that we'll see the price drop, much as we did with conventional telephone units, as we've seen the prices of those drop by an order of magnitude over the last ten years.
So all expectations are that we'll be under $100 a unit relatively soon, but whether relatively is a matter of a month or of four or five quarters is open to debate.
HS: Could we talk for a bit about the role of gateways here? I mean, if we want to interconnect the networks -- and I assume that at least for the foreseeable future, we're going to want to do that -- we need ways of going IP to PSTN, and PSTN to IP. Is that right?
CMJ: Right.
RM: Yes.
HS: So are there gateways out there that do this? I mean, are there a lot of those things out there.
RM: There are gateways and NEC's. There's different flavors of gateways that you can purchase. There are certain station gateways where you can run one POTS line into a Plain Old Telephone Service line, a regular phone line into it, and you can set up route patterns in your IP PBX or IP Call Manager and route calls off of your Net and the call routing off Net to your local PSTN or just in your local environment.
As an example, if you were to call me from your location to me at my location here in Columbus, Ohio, I can give you the route pattern to also access my digital gateway -- which is a T1 gateway, or 23 channels.
HS: You referred to an IP PBX and it sounded like you were treating it as though it were a Call Manager. Is there an IP PBX? Is that different from the Call Manager?
RM: They're synonymous, and I'm sorry. I shouldn't change in the middle!
HS: That's okay, people are going to probably hear both of the terms anyway. But both these things are software? I mean, this is not -- if I wander off and I find my PBX for Princeton University, I'm going to find it's a big hardware box. But you're saying the Call Manager is just some software that runs on something.
RM: Well, it is a PC that runs PBX software and so there is a hardware device. There is a PC sitting there that has software on it that's running Call Manager. That's the name of the software that does all the routing for us.
HS: And it just runs on, like, an NT box or something like that?
RM: That is correct. The version we're running, we're running on NT 4.0, Service Pack 4.
CMJ: If we can pursue that just a minute, Howard.
HS: Sure, let's pursue it.
CMJ: There are two different approaches being taken by the various manufacturers, and a lot of it depends on the background that the manufacturer is coming from. So Cisco, for example, since its strength really has been in data all these years, has gone with what I'll call the PBX-less approach of this Call Manager being the centerpiece. Nortel and Lucent, on the other hand, coming from a very traditional telephony background, have incorporated boards for their PBX's that handle a lot of the same functionality.
So we are going to see the two -- I would call them competing models of PBX-aware vs. non PBX-centric, let me call the Cisco approach -- proceeding in tandem for the foreseeable future. I can't see Cisco coming out with a big PBX just so they can get Voice Over IP to work, and similarly, I can't see the Lucents and the Nortels abandoning all their telephony market history to go with the non-PBX-centric approach. So they are two contrasting flavors of getting IP calls from one place to another.
HS: Okay. We have a question that just came in from Dr. Gerald Cullen from -- I'm sure I'll get this college pronounced a little bit incorrectly -- Canesius College.
JB: I think that's good, Howard!
HS: Okay! And Dr. Cullen asks, "Given the unpredictable bandwidth problem on the public Internet, won't initial use of IP telephony take place mostly on private campus networks and private pathways managed by organizations?"
CMJ: I believe, in fact, that the answer to that is yes. In fact, the Gardner Group in a recent series of recommendations has recommended that companies and other organizations look primarily at it as an Intranet technology rather than an Internet technology for that very reason -- that it's not looking like the ability to do Quality of Service, particularly over the commodity Internet, is anyplace close. And without being able to have assured data delivery rates, IP could easily fail over a congested network, whereas on an Intranet, the organization usually has better control over how much bandwidth they can make available.
HS: What's it going to take to change that? I mean, what would it take to make it so that you could use this thing on the Internet, rather than keeping it inside campuses?
RM: You would have to actually nail up bandwidth, really, and develop a VPN. There is no way, without a VPN, to govern your Quality of Service.
HS: Could you just tell our listeners what you mean by VPN?
RM: I'm sorry. Virtual Private Network. If you're dealing with the commodity Internet, then it is just that. You're going to have to fight for bandwidth and you can -- there are a few ways to set up routing and the Quality of Service routing. You can use some of those protocols to insure that your packets get through first, but without grooming off a specific amount of bandwidth, even though your packet may be first, if it's still congested, it's going to have to contend with the Quality of Service issues. So the Virtual Private Network is really the way to go to take advantage, full advantage, of this type of technology.
HS: If that's the case, I mentioned at the beginning that Business Week said that there are billions of minutes of international calls being made over IP telephony. How are they able to do that? Without running into this bandwidth -- do they have a private network?
CMJ: Yes. Most of those are not flowing over what we'll call -- what we keep calling the commodity Internet. Most of those are private links of some kind that they can guarantee bandwidth on.
HS: Okay, so they're using IP for what advantage, then?
CMJ: Principally because a lot of those organizations have large IP networks in place already to handle data, that are not being used to full capacity. So it's just a way of squeezing higher return out of your existing IP network.
HS: Okay, we have another question from David Flege at Wayne State University, and David says, "Given a large institution such as OSU, if you were to transfer your entire campus telco system to IP telephony using your current network backbone, would it work with the same Quality of Service that you currently achieve with your present system?" In other words, would IP telephony be transparent to the user?
JB: Right, could you do this without the campus realizing they were on an IP system?
HS: You have to slip in these different phones, right, for them?
JB: Right!
RM: We happen to be very fortunate that we could. Our backbone is not close to being maximally utilized. We have plenty of excess bandwidth to do this. Some colleges and universities may not have the robust backbone that we do, but the answer to the question would be yes.
JB: Okay.
CMJ: I guess I would qualify the yes just a little bit, and that is to say that since we don't control the Quality of Service all the way to the wall plate in the office, there certainly are pockets of the university that would encounter troubles due to outdated wiring in buildings and hubbed networks rather than switched networks inside buildings.
HS: But you're suggesting, then, that IP telephony could really replace our campus PBX switches. Is that what I heard?
JB: I heard this big pause here.
CMJ: Could it? Yes. Do we want to? No.
JB: And why not?
HS: Why don't we want to?
CMJ: We don't want to right now because we are so used after -- as you said, Howard -- 125 years of development of striving for .9999 uptime services, I don't think any of our users would settle even for .90. And realistically right now, I think the equipment -- probably equipment coupled with campus network hiccups, potential impact of power outages and so forth -- I don't think the equipment can assure us that we can hit .99999 service like we've got with the phones that are on our desk right now.
JB: So it may be in the best interest of everyone to go ahead and keep parallel systems in place for awhile?
CMJ: With everyone that I've talked to in university environments, at least, that's the approach right now -- is realization that production on this stuff is probably a year to two years out, that we owe it to ourselves to be experimenting with it right now and doing moderately small deployments of, you know, hundred-ish type phones.
HS: What's going to change, though, in a year or two? I mean, what are we looking for that's going to make this thing possible that's making it not possible now?
CMJ: Well, one of the key things right now is that as you know, your conventional phone works just like a charm, even if the electricity goes out.
HS: Yeah, that's kind of a nice thing, but there's a bunch of batteries sitting behind it.
CMJ: There's a bunch of batteries sitting somewhere on your campus or at the telephone company --
HS: Probably both places.
CMJ: Right. Provide battery power to the phone. In contrast, the existing IP phone units rely on wall power at the moment to function, so if the power goes out, you don't have a telephone. Now, I know most of us don't have extensive power outages on campus, but even if we have, you know, two or three losses a year of five minutes' duration and our campus happens to have life-critical facilities like hospitals and so on, clearly that's not going to be an acceptable situation.
HS: But our mainframe has UPS on it. Why can't we take that approach with this thing?
CMJ: Well, you could take that approach, except each of your --
HS: Oh, each phone has to have it!
CMJ: In our case, it would be each of our 20,000 phones has to have a UPS on it.
HS: That's right. Our mainframe, you know, stays powered on, it's in one spot, that's kind of convenient.
CMJ: Right.
JB: You mentioned your 20,000 phones. That's the number of phones on your campus, right?
CMJ: Right, that's the approximate number of phones at Ohio State.
JB: Of regular phones. Now how large is this test implementation that you're doing right now? And do you want to just give us an indication of what it's costing you to do this test implementation?
CMJ: Want to take that one, Russ?
RM: Yeah. As for the size, it's going to eventually be approximately 150 phones with hard phones, which are phones that look like phones today, and soft phones. Those are phones that are programmed on the PC. And the -- I'm sorry, what was the second question?
JB: The second part was -- now, actually before we go into the second part, you said going to -- how far along -- maybe we could stop. How far along are you on this project? And then the other part of that was just, you know, how much is this costing for this project? Because I suspect there's more than just the telephones involved. There's gateways and all the Call Manager stuff and everything involved in it, right?
RM: Yes. How far along? We only have a couple of phones strategically placed on campus. A couple dozen, I'm sorry.
JB: Couple dozen, okay.
RM: Deployed. By year's end, we're shooting to have 50 deployed.
JB: Okay.
RM: And what it is, as we're deploying them, there's issues that have to be resolved. Because we are decentralized as a campus, meaning that there are network administrators in every building and these phones use something called Dynamic Host Configuration Protocol or DHCP --
JB: Yeah.
HS: Yeah, lots of folks use that for their PC's sort of regularly anyway.
RM: Correct. And we have a university-wide DHCP server, but if a department's running a DHCP server behind their network, we have to -- there are logistical issues that have to be addressed. So that's kind of slowed our deployment to this date, but we're looking to try and have 50 done by year's end.
JB: Okay.
RM: As for the cost of the system, we're right around $50,000 and that includes our gateways, the PC's, all the phones. And when I say PC's, we've got two Pentium class PC's dedicated, a primary Call Manager and a backup Call Manager. The 100 phones plus the software for the Call Manager, the user license and the gateways.
HS: Okay, we have a -- go ahead, Judith.
HS: We have another question from David Flege at Wayne State University. And you're going to have to help me with the terminology here. Wayne talks about PTT's. What are PTT's?
RM: PTT's?
HS: Yeah.
JB: Well, the question goes something like this. Maybe that'll help.
HS: Maybe you could figure this out from the context of the question.
JB: Right.
HS: I don't know what PTT's are. He says, "Many countries use their PTT's as a major source of revenue generation and information control mechanisms. How will IP integrate into foreign PTT's from a regulatory perspective? Is the ITU addressing this issue from a standards and policies standpoint?" PTT sound to me like they're the public telephone networks or something.
RM: Okay. I think, though, that we're talking about them in countries where they fairly heavily regulated IP traffic as well as voice traffic.
HS: And so both of these things are going to be regulated anyway?
JB: What about the -- do you know whether the ITU -- now, that's the International Telecommunications group, isn't it?
RM: You mean Union, yes.
JB: Is it the Union?
RM: Yes.
JB: Okay, are they addressing the use of IP, Voice Over IP because -- from the policy, any policy standpoint that you know of?
RM: Right now there are no, let me retract to say there are no -- to date, from the research that I've done and with regards to regulations and standards, the vendors that we are dealing with -- the major vendors, the big three being Nortel, Cisco, Lucent -- they are all taking their own stance and they're dealing with their own protocols so they don't have a standard.
There's no IETF standard or ITU standard for how an IP telephony phone call needs to be packetized. And as for regulations, like from the FCC governing our regulations on how IP telephony will be regulated as it relates to the legacy telecommunications market, there was a proposal, a report to Congress on April 10, 1998. And that was the last major report done to Congress on where should IP telephony fall. Should it fall under information services, under the Universal Service Agreement, or should it fall under telecommunications services? And today, it still falls under information services.
JB: Oh, okay.
RM: So we in the US, from the FCC, right now are not being given any direction with regards to being regulated in using IP telephony.
JB: That's interesting. We were talking -- I was talking with a couple folks last night and they mentioned that because of that distinction between the telecommunications and information services, that if one has a cable modem, that you are actually freer from being, shall we say, regulated than if you're using the DSL technology. At any rate -- I'm sorry, Howard?
HS: That's okay. But following up on that idea, are there any pending federal, state, local regulations for this whole IP telephony thing? And I mean, are the -- right now, the thing is free. It would seem like the MCI's and AT&T's, etc., would want to make sure that this doesn't stay free.
RM: There has been a lot of -- if you go to the FCC website and take a look at the April 10, 1998, report to Congress, a lot of that's covered there. A lot of what the MCI's are saying and what the Sprints are saying is if it looks and acts like a phone, it should be regulated like a phone.
JB: Um-hm.
RM: And again, because it is packetized and it's information services today, it's still being -- the individuals using these services are hiding behind that and the Universal Service Agreement, that it's not telecommunications services, it is information services.
JB: Okay, and let me -- as we're getting closer to, you know, our time here, I'd like to invite our listeners that we probably can still have time for a couple more questions, so to get those questions in. Okay.
HS: I talked in the beginning about killer apps for IP telephony, and perhaps I won't put you on the spot and demand you tell me some. But --
JB: Get ready, though!
HS: I'm ready to do that. But it just seems to me that we have -- we've now taken the voice and we've digitized it and packetized it. Could you talk about some potential advantages of having the stuff in this digitized, packetized format that give us some advantage over just having the thing as analog messages floating around the PSTN?
CMJ: One of the things that particularly trade magazines have talked a lot about as the potential killer app here is Web-Enabled Call Centers.
HS: What's that mean? It's a catchy name.
CMJ: Yeah, they've got the terminology down.
HS: Web-Enabled Call Centers.
CMJ: I just need to define it here. Basically, it means that you might have a website, for example, for your company with Frequently-Asked Questions on it. It doesn't address all of the users' questions. So at the poke of a button, their PC with a microphone can generate essentially Voice Over IP that goes to your site, hits a real person who can answer their question. So that's the kind of human and website interaction that I think a lot of people are envisioning when they talk about Web-Enabled and IP-Enabled Help Desks, basically.
HS: So we could actually begin to capture some of this. The voice is digitized anyway so we could tuck it away more easily.
CMJ: Right.
HS: It supposedly could even do voice recognition when we get the technology. So then you could go voice to text.
CMJ: And that would be just a tremendous way to, for example, develop Frequently Asked Questions, if you had a Help Desk, that you could digitize the questions as they came in, eventually do voice recognition on them and then have somebody either type in or voice in the answer to them. It'd make FAQ's a lot easier to develop.
JB: Well, it sounds like people could even use voice to just register for classes without actually doing it on the web.
CMJ: Yes, there's some sense that it might replace analog IVR's.
HS: IVR's?
CMJ: Interactive Voice Response systems that a lot of universities use now, for example, for registration from a touch tone phone.
JB: Yeah.
CMJ: It's entirely possible with digitization and then some sort of voice recognition scheme that we could move to IP phone base vs. IVR based, as you say, registration or other student information systems. I think, really, those are special cases of enabling user response through two different media to whatever it may be -- sales or student registration or whatever.
HS: Okay, we did get another question in here from Glenn Wittmer, and he's from -- if I can figure this out -- University of Illinois.
JB: That was an easy one, Howard.
HS: Yeah, I was trying to look at the @ thing rather than looking right at the bottom where it says University of Illinois.
JB: He spells it all out!
HS: Okay, at any rate, Glenn said, "You mentioned that only IP telephones can work behind IP PBX's. Aren't analog gateways available from some IP PBX manufacturers which can support traditional analog telephones?"
RM: That's correct. The -- and if I said that, I apologize. When I refer to gateway, that's what that is. One side is IP that connects to your IP PBX and the other side is the legacy telephone system.
HS: Okay, when we're talking about all these voice packets floating around the network, I mean, we're talking about some real advantages to that. We can capture the stuff, but I begin to think that we're not the only people who could capture this stuff. Isn't there a potential security problem here where anybody who could have a web sniffer could capture these voice packets and kind of eavesdrop on us?
RM: That's been brought up in many forums, and the answer to your question is yes. And Internet security for voice packets and capturing those voice packets and playing them back, that opens up a very big security issue.
But the response to that is today coming from some of the manufacturers of these systems -- is you can do the same thing today if someone's talking on a cell phone. If you have a scanner, you can capture it, record it. If you can walk into a telephone closet, you can clip onto something called a handset or telephone butt set, you can clip on and listen to a phone call.
HS: Sure, but it's a little harder to walk into a telephone closet than it is to sit at your computer.
RM: That's correct, but the reason for saying that is, they're saying that if you want secure comm over the current PSTN network, you use security. If you want secure telephony or secure conversation over a cell phone, you buy a scrambler. So they're saying --
HS: So is there something equivalent to a scrambler for an IP telephone?
RM: Not that I know of for the system that we're using, which is Cisco, but -- and again, I said that those are the responses that we're getting when we ask the questions.
JB: Um-hum.
RM: But as we understand it, that is an issue because you're exactly right. Someone can go to a web page, download a hacker's program and sit there and sniff voice packets and play them back. And that is a very big security issue. And that's only on the commodity Internet also. If you own a VPN, then you're secure.
JB: Ah, that would be another reason for going for the VPN for awhile then, huh?
CMJ: Right.
RM: Correct.
HS: Okay, in the last few minutes we have here (actually, we're past the end of this, but we'll continue for a couple more minutes if we can), can we talk about what steps people who are on campuses who are curious about this technology, what are the first few steps they might take?
CMJ: The organization right now that I think is probably in the forefront for universities, at least, is one of the EDUCAUSE organizations called Net@edu, which I think most of your listeners -- I hope, anyway -- are familiar with. They have formed a Voice Over IP working group and I believe that the web reference to that working group's papers and such is on the CREN website. Is that correct?
JB: Yes, it's up there very prominent. I think it's the second one on the list, actually.
HS: So they should try to join that organization?
CMJ: They might want to join in with that organization and, at minimum, try to follow the developments as they appear on the website because this is one of those that's changing weekly.
HS: Is there some kind of listserv they could become part of or join?
CMJ: I believe there is. They might want to just get a hold of EDUCAUSE and ask how to subscribe to that list.
JB: Actually, I think there's multiple links into that working group on the site for today, so it's an easy link for them.
HS: Okay, great.
CMJ: Then if a campus is interested in beginning to explore, several of the vendors do have products that probably -- well, these are retail prices, so retail someplace between $35,000 and $50,000 would let an organization get a Call Manager, a gateway and probably about 25 phone instruments.
And obviously, since that's retail, as educational institutions, we could expect to fare better than that, depending on who the vendor is. So that, hopefully that will give people at least a rough price point about what it takes to start to experiment.
HS: So I couldn't have an experiment with just two IP phones?
CMJ: You could, but it doesn't do much for you.
HS: Unless you had two people who wanted to talk a lot to each other?
CMJ: That's right.
RM: And it would take a little bit. You'd have to do some real creative programming to make the phones talk from one phone to the other without a Call Manager because a Call Manager sets up the calls.
CMJ: Yes.
JB: Oh, all right.
CMJ: At minimum, you'd need two phones and a call manager.
JB: Okay, all right.
CMJ: But anyway, then kind of the next step after that is to work with campuses nearby who are also experimenting, and try to set up routes between organizations just to see how difficult that might be. So we --
HS: Is there some directory of people? I mean, I have this phone sitting on my desk and it's not useful unless I have a bunch of people to call. And I don't know who to call except for the fact that either I know people or I have a phone directory. Is there some kind of IP phone directory?
RM: No, and there's been conversations actually we've had here at Ohio State and also with a couple of the partners we're working with in this IP test. And we're setting up our own, so when you have a VPN today for your IP network, you're going to have your own numbers. You can number your phones any way you want. And really only people who are in your circle know what your phone numbers are.
JB: Let me ask one other question. When we were talking in preparation for today, you had mentioned that Cisco was going to, in their campus company site, really move to implementing a total system-wide implementation. Would there not be a reason, then, if you have a fairly good-sized implementation on your campus, then aren't we getting to a point where a directory certainly makes some sense?
RM: Well, if you could get the players to participate and set up routes between Call Managers so you could use the IP telephony phone numbers, which are internal phone numbers.
JB: Um-hum.
RM: But I think what Cisco wants to do is they want people to not know, in a sense, that they have to dial something special. They're setting their network up so you still dial the same numbers and they do all the routing to those phones via the Call Manager. And that keeps the end-user from trying to figure out, "Is there some new route pattern I have to learn?"
And we're doing the same here at OSU for the people who we hand these phones out to in the campus community. We're not asking them to try and learn a whole new numbering scheme. We'll set up the routing such that they still dial the same number.
JB: So you do that all within the Call Center Manager then?
RM: That's correct.
JB: Okay. All right. Okay. I haven't seen any more questions coming in, Howard, have you?
HS: Nope.
JB: Okay, well, if folks have any other questions, our experts will continue to answer questions for the next 24 hours or so, so you can go ahead and still send some in if you'd like. Howard?
HS: Well, I think that about wraps it up. We do want to remind you about Net@edu. That seems like the first step that you want to take if you're going to get involved in this IP telephony. Get hold of those folks at EDUCAUSE and participate in this fine group.
Judith?
JB: Okay, very good, Howard. Thanks. And thanks to everyone for participating with us today and be sure to follow those follow-up questions, as I mentioned to expert@cren.net.
Be sure to mark your calendars for December 2, two weeks from today. And that TechTalk will explore the topic of NT deployment, and it will be sponsored by Microsoft. The expert for this session will be -- right now, we're not announcing it yet. It will be a special mystery guest.
HS: Are you ever going to tell me, Judith?
JB: Pardon?
HS: Are you ever going to tell me who it's going to be?
JB: Oh, some day, Howard! Someday soon, here. Also mark your calendars for the last session of the fall series on December 16th when our guest experts will be Karie Masterson and Ruth Sabean from UCLA. And they're going to be discussing course websites and also issues in building, maintaining and archiving of course websites.
As always, we appreciate suggestions and feedback on what and whom you'd like to see and hear on TechTalk. Thanks to all the institutions who helped support TechTalks, and invite your institution to help support them if you're not already a member. Thanks to everyone else, including our sponsor, Cisco; our guest experts, Charles Morrow-Jones and Russell Morrison; to Howard Strauss, our technology anchor; to Terry Calhoun, our event page producer; to David Smith and Patty Gaul of CREN; to Julia O'Brien, Jason Russell, Carol Wadsworth and the whole support team at the MERIT network; to Susan Berneis, our audio file transcriber; to Laurel Erickson, our transcript editor and indexer. And finally, a thanks to all of you for being here. You were here because it's time. Bye, Chuck. Bye, Russell. Bye, Howard. Take care, all.
CMJ: 'Bye.
HS: Good night, Judith.
JB: Bye-bye now.
RM: 'Bye.
