The underlying network metrics that affect VoIP call quality are packet loss, jitter, and latency, and if you have good network performance for traditional networked applications, it is not a guarantee that performance will be good for VoIP applications. The real-time characteristics of voice create very strict requirements for network performance.

For example, an inappropriately configured network could have calls that are delayed, dropped, or just plain sound bad. These call quality issues would quickly affect the end-user experience because telephone usage is very user-intensive.

Continue reading "VoIP Management Series: VoIP Management and Network Performance – Part 2" »

Anytime you add a new application to the network, unexpected results (if not outright chaos on the order of the fall of the tower of Babel) often ensue. VoIP is no different and can affect network performance particularly. This is why efficient VoIP management is so important.

Most traditional networked application performance – email, ERP, Web, and database applications, have a few key assumptions. They usually use the TCP protocol, which is reliable and sacrifices time for accuracy, changing for new network conditions. They can usually tolerate packet loss (because of the TCP protocol’s ability to recover) and delay (because there’s no need for real-time throughput.) Applications slow down, but are still usable.

Continue reading "VoIP Management Series: VoIP Management and Network Performance – Part 1" »

We’ve been blogging with excerpts from our new VoIP Performance ebook here on Network Performance Daily. Today, Brad Reese gets into the game with his own advice on monitoring VoIP performance using Cisco NetFlow and IP SLA in a story on his Cisco Subnet blog called Are you Taking Advantage of NetFlow and IP SLA?

Brad quotes NetQoS CEO Joel Trammell on the subject. According to Joel, “the number one killer of voice traffic is network latency and jitter. Latency, jitter and packet loss cause poor audio quality and dropped calls. Latency caused by overloaded call managers or network congestion can be a major cause of poor VoIP performance."

Continue reading "Cisco IPSLA and NetFlow Help Network Managers Monitor VoIP Performance" »

It can be daunting to think of all the things a successful VoIP call needs to do – in addition to the call setup, which we covered previously, the conversation portion of the call needs to be converted into packet format, sent across the network, reassembled, and then converted from packet format back to voice.

Here’s a look at a couple of the different standards available to enable VoIP traffic across the network.

Codecs – short for “enCOde/DECode” – are required at both ends of the phone conversation to allow the audio signal to be sent and received across the network. Each codec has different bandwidth requirements and characteristics that can affect network performance.

Continue reading "VoIP eBook Excerpts: Critical Elements of Your VoIP Infrastructure - Part 3" »

Between dial tone, number lookup, ringing, and busy signals, there’s quite a lot that has to happen before you even start speaking and what most people think of as a “phone call” even occurs. Call setup protocols not only do these things, but also perform after-call resource cleanup and statistical reporting.

Each protocol uses TCP or UDP, and a well-known port or ports for communication. Some call setup protocols are used primarily for communication between endpoints (IP phones) and call servers, while others allow for communication between call servers and voice gateways handling calls to and from the PSTN.

These messages, which vary in size and number, handle functions like the mapping of phone numbers to IP addresses, generating dial tones and busy signals, ringing the called party, and hanging up.

Continue reading "VoIP eBook Excerpts: Critical Elements of Your VoIP Infrastructure - Part 2" »

Over the next week on Network Performance Daily, we’ll excerpt sections of the new NetQoS VoIP ebook entitled VoIP: Do You See What I’m Saying. Today, we take a look at the hardware needed to equip your VoIP infrastructure. Obviously, VoIP systems don’t just require some server configuration and special software. Quite frankly, you can’t plug an RJ-10 phone line into an RJ-45 ethernet port and say you’ve got VoIP.

(We all know someone who might actually do that. If you’re lucky, he or she is not in your IT department…)

So, what is some of the VoIP hardware you need?

First, in terms of sheer numbers, IP phones will make up the largest group of new devices on your network. These IP phones connect to the network via Ethernet and many of them get power-over-Ethernet (POE) from LAN switches that support it. Each of these phones runs an embedded operating system with a TCP/IP stack for communications, which means each phone needs its own IP, and software called a codec to convert a voice conversation to IP packets.

Depending on how fancy your phone is, many of these phones can also run applications. Additionally, there are also “soft” phones – basically headsets that connect to the computer and an application which runs on it.

Continue reading "VoIP eBook Excerpts: Critical Elements of Your VoIP Infrastructure" »

Echo is a troubling problem. Most of us have suffered through some call where we had to try to talk with a lot of echo on the wire. It’s very distracting and makes it hard for most people to think straight and talk at the same time.

VoIP does not create echo, but due to the temporal aspect of echo, VoIP systems can and do increase the amount of echo heard when talking.

In any conversation, a certain amount of your own voice is part of what you hear, whether you are talking live, sitting in your office, or on the phone. This “hearing your own voice” is not echo and is referred to as “sidetone.” It’s a normal aspect of talking and listening.

Your own voice becomes echo when it comes to your ear with a significant delay from the time you spoke – longer than 25 milliseconds. But 25 to 150 ms is a typical delay range for international calls and this is why echo cancellation is necessary. Voice over IP calls have a delay budget also in the range of 150ms.

So, what causes echo?

First, let’s look at what doesn’t cause echo. Because delay is a necessary condition for echo, it is virtually impossible for components that are close to the speaker, e.g. on the speaker’s site, to cause echo. Even if part of the transmitted signal is being reflected back in the return channel, the propagation delays will be so brief that it will never be heard as echo.

Also, there is no way for the digital stream of packets in one direction to “bleed into” the digital stream of packets in the other direction. The same is true for the digital parts of the PSTN TDM network. While the underlying electrical signals carrying the bits are, indeed, analog, the corruption of those signals results in digital noise or other problems, not in echo.

So, strictly speaking, echo is never caused by voice over IP. In fact, what happens is that the longer delays introduced by all voice over IP systems reveal echo that was imperceptible with the shorter delays of the PSTN. By delaying existing echo signals more, they fall outside that 25ms window and become audible to us.

Echo is always analog and always at the far end of a conversation.

(Continued...)

Continue reading "VoIP Notes: Echo Echo In Voice over IP Systems Systems" »

We're here to answer some of the questions that came up during the Webinar but which we didn't have time to answer. If your question isn't answered below, you can send it to us through the comments form of this post.

---------------
Can NetQos work with any carrier IP softswitch or has it only been tested with certain softswitch manufacturers?

Jeff Hicks: NetQoS VoIP Monitor works with Cisco equipment only in release 1.0.

What about Nortel VoIP, Alcatel, Shoretel, or Avaya servers?

Jim McQuaid: We plan to support a second vendor but we have not yet made a firm decision.

My call manager comes with a management package. Can they provide end user experience as a management solution?

Jim: Many IP PBXs have basic management tools. NetQoS assembles call setup metrics, call quality metrics and gateway quality metrics into a single performance record, making it much easier to understand user experience.

What does a company do when they lose total power and they are on a VOIP system only instead of a land line system that will work even when the power is out? This is a huge problem that we do not have an answer for other than keeping an old analog pulse dial phone on hand for emergencies.

Jeff: Many of the phones are now powered using power over Ethernet (POE) technology. So the analogy is similar to the analog phone in that the VoIP phone will stay powered as long as the switch its connected to has power. This means that the data switches now need UPS or power backup to keep the phones up and running.

When degradation occurs how best to troubleshoot whether it is quality degradation caused by the quality of the codec versus external influences?

Jeff: You can take a look at the MOS and see if any network metrics were degraded as well. If the network metrics are ok, then it is likely an issue with the codec.

Does NetQos uses Cisco IP SLA probes?

Jim: Our NetVoyant product uses IP SLA to monitor network performance. The VoIP Monitor product itself does not use IP SLA.

Can R-factor be measured?

Jeff Hicks: It depends on the instrumentation provided in the phone or gateway. Cisco phones do not provide a R-factor.

Is this product an end-user LAN Administrator product or a carrier product?

Jeff: VoIP Monitor is more typically deployed in an enterprise setting.

Will the VOIP product have incident/investigation functionality that SuperAgent currently has?

Jim: Yes, the VoIP Monitor product has incident capability today and will continue to build out the investigation capability in the future.

Do you need the Monitor unit at every Call Manager instance in multiple locations?

Jeff: That depends on the configuration. Typically you would co-locate the collector with the CallManager. Multiple collectors can be deployed with a single console that aggregates all the data. Scalability depends on call volume/phones and deployment scenario. Depending on deployment it is possible to use RSPAN to span information from multiple subscribers to a single collector.
Do you need a Monitor for every Subscriber?

Jeff: That also depends on the configuration. Multiple collectors can be deployed with a single console that aggregates all the data. Scalability depends on call volume/phones and deployment scenario. Depending on deployment it is possible to use RSPAN to span information from multiple subscribers to a single collector.

Do you have auto discovery of VoIP infrastructure ?

Jeff: VoIP Monitor passively discovers gateways, call servers, and phone information.

Does VoIP Monitor do passive monitoring of all the traffic?

Jeff: Just the call setup traffic. VoIP Monitor does not monitor RTP traffic.

Can VoIP Monitor help troubleshoot IP to PSTN calls too?

Jeff: Yes, VoIP Monitor looks at setup and quality information for IP to PSTN calls.

Can I troubleshoot "class of service" traffic?

Jeff: Yes, see the NetQoS whitepaper: VoIP Quality of Experience: Ensuring Your Network Supports Optimal VoIP Performance

How does NetQoS provide information for VOIP Capacity Management?

Jim: We will be providing a Call Activity report for understanding capacity and load.

Can the info from router queues (overflows etc) and port errors on a LAN switch be co-related with calls that have quality problem using your solution?

Jim: Yes, The NetQoS Performance Center allows you to do exactly this.

---------------
We weren't able to get to all of the questions today and still have some more in the queue. We'll have more questions answered shortly.

By Brian Boyko
Editor, Network Performance Daily

I'm supposed to be a technogeek, right? Up on the latest and greatest gadgetry. I get called on international radio morning shows to talk about the latest trends, I'm a professional blogger - a career that didn't exist half a decade ago, I'm a smart dude with all the latest tech toys, doing viral videos with my $100 flash-memory vidcam. I'm 100% Web 2.0'n, YouTubein', Facebook Friendin', RSS Feedin', Linuxin', Twenty-First-Century-Digital-Boy.

But my cellphone is about four years old and I don't use it for anything other than making phone calls. No texting, no Web browsing. It just makes phone calls. And I don't plan on upgrading anytime soon.

My friends - especially those who live overseas - all wonder why I don't yet have an iPhone, the "wundertoy" of the century. The answer can be found in Cory Doctorow's post for Information Week. In short, the iPhone sucks on purpose. Sure, it's slick looking, has a beautiful interface, and provides a great playlist. But, does it live up to its full potential? Hardly. And you have vendor lock-in to blame.

It's possible to use a song in your iTunes library as a ring tone, but someone at Apple decided they wouldn't let you. It's possible to use the iPhone on multiple carriers, or to not lock-in customers for two-year service agreements, but someone at Apple decided, for whatever reason, they wouldn't let you. It's possible to switch out SIM cards so that you'd be able to use the iPhone internationally, but - well, you get the pattern by now.

This is where VoIP comes in.

Already, we have pocket-sized computers that we carry with us - Palm Pilots and Blackberries. Despite the lukewarm acceptance of Microsoft's "Origami" initiative, ultra-mobile computing isn't that far off.
Desktop computing took off because it was a general purpose device. You can play games with it. You can send messages with it. You can write papers with it, you can draw, you can compose music - you can do all those things with the right software on general hardware. That's the big draw.

So when the iPhone comes out, for all intents and purposes a semi-powerful computer that you can hold in your pocket, the first thing Apple does is lock it down so that you can only do what Apple says you can do. It turns a general purpose device into a limited purpose device.

Additionally, despite setbacks in getting municipal WiFi off the ground, I can't see, for the life of me, the possibility that wireless access points will decrease over the next decade - only that they're not increasing at the rate that we'd like. It won't be long before Wi-Fi coverage overshoots many of the major phone carriers cellular networks - it has to, because the cellphone companies have chosen non-interoperable standards and done their best to lock people into them. Wi-Fi, on the other hand, generally pushes out the same bits, no matter where you are in the world. So while AT&T may have deep pockets, the larger number of smaller pockets putting out Wi-Fi spots around the world will move faster and change with the technology instead of trying to halt technological change in order to milk more money out of an obsolete business model.

Companies such as Skype have already laid the foundation for VoIP's replacement of the cellphone network. Companies such as OpenMoko are working on the hardware aspect of cellphone computing. I'd be surprised if these two industries weren't already talking to each other about creating a "chocolate and peanut butter" solution which will make VoIP over WiFi the killer app of the cellphone, and cellphone connectivity the killer app of VoIP over WiFi.

It's an idea that Cisco had a while back. Remember the brouhaha over the "iPhone" trademark? Well, it turns out that Cisco put out the "Linksys iPhone" a while back - a phone designed to make calls over Skype. At $120 from Amazon - with only Skype fees to pay after that, this is a technology which fills a need. The only problems are that it is currently overshadowed by the Apple product of the same name, and that, for right now, the cellphone companies do have better network coverage. That won't last long though.

The big elephant in the room is that no one really likes the cellphone companies. Indeed, a great part of the AT&T/Apple deal was Apple banking on the goodwill of the Apple corporate brand name. And so all it takes to upset the apple cart of their market share is for someone to offer a product that offers everything - including the same or better call quality - that the cellphone companies do, and not "suck on purpose." (Oh, and maybe a slick looking slim-line case with chrome accents.) When that happens, VoIP is going to take off not just for enterprise networking but for personal computing - and VoIP monitoring becomes that much more important for providers to ensure call quality, and network administrators to make sure that VoIP traffic doesn't interfere with business.

By Brian Boyko
Editor, Network Performance Daily

Recently, World of Warcraft released a patch which enabled players to use integrated VoIP chat. Online gaming and VoIP are, in many ways, extremely well matched. VoIP can help with the immersion of the gaming experience - roleplaying characters with voice, coordinating attacks instantly and in real time, being able to more clearly articulate nuance and inflection that could change the meaning of a sentence… not to mention that you'll finally have some good idea of whether or not the attractive blood elf lady that's been chatting you up is a 45 year old guy living in his mom's basement. Of course, that's not always a good thing…

While I don't play WoW, I have found that VoIP has become a crucial part of my gaming experience - though I typically don't like first-person shooters, I greatly enjoy the Battlefield series because of its interactive voice chat. It's very immersive - with your squad leader barking out orders and relaying info to your commander, it - well, it would be tactless to say that it feels like you're a soldier in war, but it certainly feels like you're a kid playing soldier.

VoIP and gaming are particularly well suited to each other for another reason, more technical and esoteric. VoIP traffic and game traffic usually use the same protocol, UDP.

A quick rundown for the non-technical people reading this post: UDP is a lightweight protocol with no ability to check if a packet was received; TCP is more useful for ensuring that all of the data arrives completely, UDP, that most of the data arrives quickly. This is why UDP is used for online streaming media, voice, and of course, gaming, which requires split-second reflexes and precise timing.

And though we've covered converged data and voice traffic at length before, UDP and TCP on the same network at the same time can cause network and VoIP performance problems if UDP isn't limited to a certain quality of service. Imagine a TCP and UDP connection traveling together. TCP will, in order to make sure that the packets arrive accurately, will slow down its traffic when it senses that there's less room in the pipe. UDP, in order to make sure that the packet arrives quickly, will see that there's now more room in the pipe from what TCP vacated, and take up even more room… which causes TCP to slow even further. It's a vicious cycle.

But voice and data traffic both use UDP - which is one of the reasons that even before WoW's addition of VoIP, people were using Teamspeak or Ventrilo to provide their own voice capabilities with their friends, and though there was almost always a performance hit, the fact that both WoW and Teamspeak are UDP-based makes it easier for both application to co-exist.

There are a few TCP applications in most MMORPG games, but most of them are simple ones - things like transferring inventory and IRC-like chat - which typically don't take up a whole lot of bandwidth compared to the data sent through the game or data sent through the game's VoIP. One thing that IS TCP-based is the downloading of patches and game updates - there are non-technical reasons, such as game balance, that contribute to this, but just about any online game will stop play while you're downloading the patches, rather than downloading the packages in the background while you play. My best guess is that this is partially because coding simultaneous play (UDP) and data download (TCP) is much harder than coding simultaneous play (UDP) and VoIP (UDP.)

One exception to the rule that games must use UDP is Second Life - that MMORPG requires data to be downloaded constantly and accurately, with new items being built. I can't know for sure as I'm not a coder, but I believe this to be one of the reasons why play control (UDP) in Second life tends to suffer so much and objects take a very long time, it seems, to download (TCP).

We'll try to have more technical details on WoW's VoIP rollout later in the week.