Digest from questions about IPTelephony
Many thanks to all who responded. I have been asked by a few people to post a digest, so here it is. I have chosen not to attribute the quotes because some of the people who responded directly to me. If they had wanted their statements made public and attributable, then they would have posted publicly. Please remember that I am a conduit here. These are opinions of others that I have assembled. So if you feel like flaming me, go ahead, you won't get much back from me though! I hope that I have represented the views of the responders accurately. If not, please publish corrections. The general consensus seemed to break down into the following areas: Call Quality ------------ There were several comments related to call jitter and how different equipment has different jitter/quality characteristics. Reference was made to the following report.... http://www.iwl.com/Products/maxwell/VoIPReport.html The report speaks for itself, but I don't know when it was created and whether the products have been updated since. "Yes, there are issues. Packet jitter is the biggest annoyance, but the H.323 VoIP protocol is reasonably robust about such things by providing some degree of jitter correction at both ends. The clincher is usually finding network providers that do a reasonably good job of keeping the network in a stable state. With reliable connectivity, H.323 can keep nearly circuit-quality calls in at least 95% of cases, and still audible but sometimes "cell phone quality" calls every once in a while. If you're connecting primarily to a nearby (in Net terms) landline gateway for most of your IP-to-PSTN calls, you'll probably never notice the difference." General conclusion is that most of the time call quality in IPT solutions is at worst adequate (cell phone quality) and at best as good as PSTN/PBX Robustness/Reliability ---------------------- 2 users report 100% availability using private corporate networks. But the caution is that the network design is critical. There is a considerable amount of configuration activity. One user reported that the most common source of problems was keying errors. Many configuration activities were templated using perl scripts to reduce configuration errors. One question posed is "When was the last time you had to update the firmware on your phone?" A reference to the need for software/firmware in the phone giving another possible point of failure when an update fails. Observation that a PBX approach is highly centralized, so can present single point of failure behaviors, whereas the IPT approach leads to a more distributed and potentially better self healing approach. At a time of national crisis (9/11 in NYC), the phone system wasn't any more reliable than the data systems. "Now, *faxing* is a big problem in the VoIP world. If your landline gateway provider doesn't give you a decent method to do fax calls, you may have an issue. V.22 and V.23 fax calls (not to mention modem calls) do not work well over a VoIP-modulated line, but some landline gateway services overcome this by placing a POTS-emulating device at the fax machine, translating back to a digital data stream, then back to POTS fax on the other side. There's also net<->fax gateway services out there." "We have been running approximately 3.5 MILLION minutes per month across our xxx VoIP solution for approximately 12-14 months: Do we have problems, yeah occasionally, but they are actually in line with the frequency of problems when running on a real pbx.........." (Vendor name removed by me) "Reliability-wise, 100% uptime requires redundant IP PBXes, backbones, switches and backup UPSes for all. This is no different to what a telco does in their Central Office for their class 5 switches, but any reasonable sized corporate network already has the UPS and backbone infrastructure in place. Why - because they have learned the hard way that people can live without phones for a while, but go ballistic if they don't get their email on time." "Things like intelligent routing and a good telecom engineer should help alleviate concerns with network outages. i.e. you're still gonna have a tie trunk to the local telco to offload non-corporate phone calls anyway...in the event of network outages, you can just seamlessly re-route the traffic over the PSTN. I wouldn't buy any of that ip-phones-on-the-desktop-crap that xxx keeps pushing. Yes, there may be some applications for the ip handsets, but the last thing you wanna hear is that someone can't get their vmail because the dhcp server barfed." Note product name removed by Chris Corporate usage vs. usage over the internet vs. POTS -------------------------------------------------- There were many cautions expressed about using VOIP over the internet. QOS control must be implemented for consistent quality, but of course that isn't possible if you don't know how calls are routed. One user reported how nice it is to have "extension portability" take the phone all over the campus and his phone number follows him. One user reported (home user) that he can take his ATA device overseas and essentially get local phone number support while traveling. "Note that you need to make the distinction between IP-only calls and calls that originate/terminate on the public POTS network. For the former, you should be able to reach reliability levels that are no worse than good old PABX equipment as long as you don't use the public internet as part of your IP path. For the latter you are not going to improve upon a PABX......." "I am about to deploy an IP telephone network in a corporate environment and I have studied others who have done it. Sure, the Internet at large is less than reliable but how often does the actual network within your company go down? I'm not talking about the file server or mail server or firewall but the actual network? That is all IP telephony depends on unless you are planning to make calls out through the Internet. A properly managed ethernet network these days is highly reliable. I would have no problems putting the internal phone system on it. I would be more hesitant to do voice over IP over the general Internet although I wouldn't be too worried about running voice and data over dedicated lines connecting offices etc." Security -------- In a corporate environment (all of the IPT gear behind corporate firewalls) the security issues do not appear to be great. Caveat given without explanation was "depending on what you are using for your PBX). Outside the firewall is something that few seem to have come to grips with. Not much discussion of security in this thread. Implementation and support complexity ------------------------------------- "Maintenance-wise I'd say the IP PBX is vastly superior to the telco. Think of it like this - you are paying a telco (and your internal telco techs) a premium to maintain and update your phone numbers and troubleshoot your internal analog wiring infrastructure. On a (sic) IP PBX, you can remove them from the equation entirely and put this under the IT infrastructure group using the same wiring you use for your pCS. No more punchdowns every time an employee moves from cubicle A to cubicle B -- just move the IP phone and power it up." "Most problems with IP telephony come from the 'router people' not talking to the 'firewall people' and both of them not talking to the 'telephone people'. If you can get these lines of communication working, you'll likely succeed. If you don't, go with the traditional way, because then you don't have to make the people communicate." Cost (compared with traditional PBX approaches) ------------------------------------------------ There was not much data presented here on cost. Certainly little hard evidence that IPT is any more or less expensive directly than PABX approaches. The costs were alluded to by the comments on punch-downs, single infrastructure etc. but no hard numbers presented. Editorial comment: I am sure the vendors will be delighted to supply that information :-). The two strongest opinions voiced suggest that the lower TCO touted by the vendors are unsubstantiated (they used stronger language as you see in the comments.) Unclassified quotations taken as a whole --------------------------------------- "When using shared infrastructure, there are so many ways for one user of the infrastructure to disrupt the work of another. You must have SLAs with pay-back on all services that you use (dark fiber, dwdm, layer 2 service, layer 2 over layer 3 service like MPLS, layer 3 service..... any service at all). If you are building a network which will support both your data and your voice traffic you must make the network as robust as possible. Make sure you rate limit the traffic sources before they reach the bottleneck .... Make sure you have 2 paths between critical points. For example it may not be justified to have a redundant GigE on each access switch, but it is in most cases justified to have redundant links between higher level aggregation devices and between sites. With a proper redundancy and security design you can reach very long up-times. However there is always the risk of human error (which seems to be only corrected through external auditing, and proper change management procedures) and the risk of co-related failures (for example in case of an attack against a bug in the software of two redundant devices)" Karsten W. Rohrbach said.... "Just a few thoughts: - several manufacturers of VoIP equipment happened to have shipped bad firmware with security problems (mainly DoS, cf. http://www.securityfocus.com/archive/1/273673, for example) - when exactly did you upgrade the firmware of your telephone set last time? - VoIP phone sets are not very widespread yet, so most of the hard-/software was not audited thoroughly yet. - you /will/ need bandwith management/QoS when deploying a larger scale VoIP network - you'll need the folks to understand the technology and its implications (to successfully operate all that stuff) - desktop integration of VoIP phones, anyone? IMVHO, VoIP stuff will reach a level of usability, when it's properly integrated with desktop/laptop address books and available as plug-in USB or serial device, giving a certain benefit to the user. I dial folks from the directory in my mobile phone, why shouldn't I do that from my desktop workstation? I have not seen a really usable solution yet. Most TCO calculations are - in terms of obviously increased maintenance, compared to regular phones - simply bogus. And, yes, it /is/ possible to wire analog, ISDN and ethernet over the same wire infrastructure. ;-) Repost this mail to NANOG if you think it's of interest to the other NANOG folks. Regards, /k" Again thanks to all who responded. I hope this digest is of use to the communuity at large. I also hope that I have been fair to all parties. Regards Chris
participants (1)
-
Christopher Bird