TECHNOtorials Discussions

IPv6 and VoIP

2009-12-07T18:48:30Z

As we seem to be moving toward an adoption of IPv6 sooner or later, I find myself wondering what the impact - if any - will be on VoIP. After all, VoIP has been a major driving force over the past 10 years, and we've pretty much accepted the additional overhead that is incurred - at least with UDP and IPv4.

And I can see at least two approaches to this question.

On the positive side, IPv6 will add a lot of additional controls for prioritization, etc., that should make VoIP "better." And the increased address space should be an advantage.

At the same time, voice packets are very small (for all of the obvious reasons). Generally, they're significantly less than 64 octets (bytes) for the payload itself. So we take that and add a UDP header and an IPv4 header and we're already extremely heavy in overhead.

Now IPv6 comes along and at least doubles the size of the header. Are we nearing a point where each diamond ring gets shipped in a railroad car? Does it matter?

Looking forward to your thoughts!

Dr. Jim's Guide

2009-11-24T23:19:48Z

Jim, great job on the tutorial. I've printed it out and have studied it carefully. I've used it in constructing some plans for our next generation products. I've already passed along to co-workers as the document gives everyone an even playing field of understanding and terminology. More of the great work, please!

Should your email be a "cloud" application?

2009-11-06T16:24:37Z

Over the years, email has evolved from the early days of being a network-based application to being primarily a program on the local PC. And although we can debate about various platforms (e.g. Outlook versus Thunderbird), we're seeing a lot of good reasons for moving email back onto the network.

In particular, the days of having all of your email, which is arguably your most precious resource, on your PC may be waning and perhaps should be a resource that resides on the network - either a "public cloud" or a "private cloud."

We'll be adding our comments on this subject, and we invite you to do likewise.

When Planning for VoIP, Don't Forget the ....

2009-11-05T20:25:38Z

Our team has been surveying sites where the existing analog PBXs are scheduled for replacement by VoIP installations. We're looking at what might be reusable in the conversion, and what needs doing. In most cases not much can be saved; most sites need lots of preparation before completing the changeover. Everyone's eager for new technology, but we must keep some key points in mind.

Cable Lengths. Many of this sites we've examined are campuses where multiple buildings spread as far as three miles. No problem for analog lines, where a local loop of up to 18,000 feet is standard (less for some PBXs). Copper cables for Ethernet, however, are limited to just over 300 feet (100 meters, according to the standard). Low-capacitance cables can stretch that distance, but not much. Fifty-pair copper cables worked well for analog voice, and also for data using Digital Subscriber Loop (DSL) technology. One DSL carrier can't service a building full of phones, so it's likely that optical fiber will need to replace the twisted pairs, not difficult when small form-factor pluggables (SFP) on routers and switches can carry GigEnet for miles on fiber.

Space for Remote Switches. We don't (yet) have a VoIP architecture that delivers connections over "fiber to the phone." Some day the network might be all glass, all the way. Now we rely on copper pairs, typically four pairs in a Category 6 cable, to link the phone to ..... what exactly? Not the PBX in another building, that's too far away, but to a switch somewhere within 100 m in the same building. That's where the fiber terminates too, on the switch. Those switches need power and an air conditioned space in each remote building. In analog days, the remote building needed only a few punch down blocks to cross connect house wiring to the distribution cable. Blocks were often placed in uncontrolled environments like boiler rooms, external electrical boxes, attics, and basements--not acceptable for active electronics. So don't forget to plan for a space with power and climate control for the switch.

Phone Power. Analog phones operate from the "loop current" injected by the battery at the PBX. With glass replacing copper in the distribution cabling, each phone needs a power source to replace the PBX's battery. Most phones accept power from a local "brick in the wall," but that can mean a lot of bricks that need attention, can fall out, get borrowed, etc. Best practice now is for the local switch to inject power into the CAT6 wire to each IP phone. Then, only the switch needs local power.

Backup Power. We've grown accustomed to a working phone during a blackout. Some of us like to keep at least one analog phone line per site (either from the local telco or a remote PBX) because the phone on that line will work when the building loses all electrical power. The phone carries on as long as the battery (at the PBX or central office) lasts. But what if a remote building served by VoIP loses power? If the switch has a battery backup or uninterruptible power supply (UPS), then it can continue to power phones and communicate over the fiber. Best to plan for how long you want backup to last when each phone could be drawing up to 15 W in addition to the switch's own drain. Than upgrade the battery to anticipate declining power storage capacity over the years of anticipated before replacing the battery.

Lightning and Surge Protection. On the bright side, replacing copper cables with glass fiber means almost zero risk from inter-building lightning strikes. There's no over-voltage protection needed on a fiber. But with the introduction of LAN switches and electronic phones into a building, consider the building's lightning protection. Could a strike reach the house telecom wiring or an electrical line? If so, that could burn both phones and switch. Bring back the surge protectors.

Privacy. A butt set or plain telephone could tap an analog conversation at a punch down block or connection point anywhere along a line. Historically, people dealt with that by locking telecom rooms and pedestal boxes. We watched for people digging around buried phone cables or climbing poles. But a clever hacker can tap an IP phone from just about anywhere, over the network. Openly posted software tools make it easy to spoof addresses, change reported equipment types, jump between virtual LANs, and do just about anything to a connection. Security deserves attention to avoid vulnerabilities and to balance risks against protections.

There's more, of course. Stay tuned.

Is Compliance the New Security Standard?

2009-10-28T00:37:04Z

Given the compelling case for securing the enterprise, why do CEOs fail to invest more in security solutions? Does this simply represent a failure of IT and security staff to make a compelling business case? Or are the CEOs in fact being short-sighted? For more on this topic, please see my blog post at http://www.cloud-compliance.com/blog/bid/27935/Is-Compliance-the-New-Security-Standard.

Ethernet Services and Committed Data Rates

2009-10-27T21:57:22Z

Having a Committed Data Rate (CDR) of some for is absolutely critical for all packet-based services. However, as the services become more complex, the parameters used to measure and enforce the CDR become increasingly complex. This is especially true for overhead-intensive protocols such as IP and Ethernet. Do you pay for data based on the entire packet size, for instance, or just the payload? Join us to explore these issues in this discussion.