AppNeta | The Path

Archive for the ‘VoIP’ Category

"Many customers looking to implement a VoIP solution for the first time have absolutely no idea how critical a clean data path is to its usability. We use PathView and PathView Cloud to get an in-depth look at a customer's network health. It's like an MRI for their IT departments." – Eric Knaus, president of RonEK Communications

How are you ensuring a successful transition before plugging in the first phone?

VoIP, Video and Unified Communications are highly cost-effective network services. While your wallet may be breathing a sigh of relief, your network is about to get the wind knocked out of it by the  weight of VoIP and video conferencing services. Network performance is dependent on existing applications and user activity so network engineers implementing VoIP must take this into account.

In the past, enterprise companies dedicated a separate network or connection specifically for VoIP. If the phones don’t work, your business stops. For many organizations, adding to the existing network demand and performance challenges is unrealistic.

Throwing VoIP onto a network without pre-assessing is like jumping into a pool without checking for water (ouch!). Without a full comprehensive inspection of your surroundings, the results will be painful.

As VoIP moves toward a standard application regardless of business size, network engineers are forced to piggy back VoIP onto the existing infrastructure. And for any network engineer who wants to maintain the performance of existing applications AND ensure the performance of the new VoIP services, a pre-deployment network assessment is critical

An Effective VoIP Assessment will:

• Measure the call load capability of the network

• Identify the faults and shortcomings of the network

• Provide a holistic view of the network’s ability to handle data and voice traffic

• Lower the project’s cost estimates

• Verify service level agreements (SLAs)

• Eliminate the network as a gating factor in the VoIP project

A functioning network does not always equal a prepared network. Issues in the infrastructure may not be visible until the weight of a VoIP implementation crushes it.

Watch Webinar!

But where are the problems that are going to obstruct VoIP performance?

Three key benefits to conducting Advanced Network Assessments:

1. Test how well the network will perform without deploying a single device. VoIP pre-deployment assessment should look at the current state of the converged network, evaluate its ability to support VoIP and identify the dysfunctions that are restricting performance and the requirements to meet call load need.

2. Look at the life-cycle of your network in relation to VoIP. Generate call loads over days or weeks to take into account on and off peak network services. See in real-time how scheduled back-ups, data uploads and periodic events will affect voice quality.

3. Simplicity. Take it one site at a time. If the company decides to bring on a new location, your assessment process should not start from scratch.

Pre-deployment assessments should be done prior to purchasing or deploying any VoIP equipment or making any upgrades. Get yourself a complete analysis of the end-to end data network, recording important measurements such as bandwidth, utilization, throughput, loss, jitter, latency and MOS. A proper assessment will identify and isolate faults on the network that currently inhibit application performance.

PathView Cloud will ensure a successful VoIP deployment and ongoing performance. PathView Cloud generates a series of packet bursts that are placed on the network in a proprietary manner and collect the information required for a full analysis of the involved network segment from end-to-end

Want to learn more? Visit AppNeta or do a FREE pre-assessment on your network today with the 14-day free trial!

In the past few years, businesses are increasingly focused on two areas: 1) saving money and resources and 2) consolidation and collaboration of operations. Particularly in technology, this consolidation can be witnessed in the jump in virtual desktops and virtual servers, both of which leverage resource sharing and economies of scale to save on space, power and ultimately, cost and complexity. At the same time, we are seeing more and more technologies standardize their protocols and use of network infrastructures.

Unified Communications and Collaboration is the concept of putting both voice and data on a converged line instead of the traditional method of separating phone and computer networks. Placing both voice and data on the same network line requires constant monitoring of that pipe for cases of unexpected interactions between the increased numbers of applications sharing one path. While helping PathView Cloud customers diagnose their networks, we’ve seen a wide variety of network problems; one customer’s VoIP calls had intermittent downtime and dropped calls, but only during the hours of 5-6 PM! With the help of PathView, we detected that the customer’s IP storage was kicking in and backing up computers at 5pm, the standard “end of the work day.” This increased consumption of network bandwidth and the lack of QoS on voice traffic allowed enough packets to drop, resulting in poor voice quality and dropped calls.

AppView Web

AppView Web

We’ve seen how people often assume that the pipe needs to get bigger in order to handle the extra traffic that will be traversing the pipe when Unified Communications are deployed. This is not always the case.

When you have the ability to do application-specific testing, you can see  both sides of the pipe in order to help you find the location of the voice quality issues, whether the voice degradation occurs from site a to site b or vice versa. AppView Voice gives you the ability to test devices with real voice packets to verify voice quality between offices or between buildings. This can be done with a specified number of voice calls on the line for a specific amount of time, giving you information such as Mean Opinion Score (MOS), packet loss, jitter and many other performance metrics, which give you insight into how the network is dealing with the extra load on the line. Similarly, it is important to be able to monitor out to a specific website, returning performance information such as DNS resolution time and Connection establishment time, to be able to see exactly what your bandwidth needs on for web-based applications.

AppView Voice

AppView Voice

Using PathView Cloud will help you determine whether extra bandwidth is needed or if settings or configuration are to blame for issues (such as setting proper QoS settings on voice packets!). So with the big move to unifying your communications, use PathView to save your sanity and help resolve issues in a much faster and more precise fashion.

My field engineering team works with customers and partners in many regions and time zones, and we often host working sessions from remote locations.  This provides great opportunities to employ our own solutions and “eat our own dog food” to monitor and troubleshoot common services we use between sites.

I hosted a virtual technology workshop a few days ago  from our Portsmouth office.  We were working with a partner to propose a hosted VoIP PBX service management offer.  I started the meeting using Citrix Online’s GoToMeeting and dialed in using my Vonage business line. 

Early in the discussion I was interrupted by a brief click followed by…dead air.  Vonage has been very reliable from many locations, so I assumed this was a fluke and quickly rejoined the call.  A couple of minutes passed, and my call dropped again.  At this point I was having flashbacks to my days as a subscriper of  AT&T ‘s wireless network last year and experience with many call failures. 

I rejoined and offered my apologies, this time using my Sprint-powered Evo. 

Some of the team members were new to the project, so I took this opportunity to demonstrate PathView Cloud’s network performance monitoring and troubleshooting capability and used  our own experience as an example.

A PathView microAppliance in my office was monitoring my Internet connection all the way to a companion  device located in a San Francisco area hosted facility.  This shows the WAN performance from the remote office out over the Comcast cable network and out to ‘the cloud’ using a variety of protocols including ICMP, UDP, and TCP. 

As you can see from the performance charts, data and voice loss were substantial, peaking at 20% several times throughout the day.  Mean Opinion Score (MOS) suffered as well.  You can see a number of red diamond-shaped event markers indicating performance violations for the path.  


Looking at the same path in a dual-ended view, we see loss in both directions but peaking on the return leg – San Francisco to Portsmouth.  You can also see a lot of transience of the route taken by the UDP packets used by PathView.  Check out the yellow diamonds indicating each route change.


It’s no wonder I was having dropped VoIP calls!  Looking at the diagnostic showed a clear issue in the Comcast network, starting with the first hop near my office.  Packet loss in the range of 4-12 % was experienced when the diagnostic fired.  You can also see where the ISP is retagging the QoS values in the IP headers defined for the path.  This isn’t unheard of, since QoS is rarely supported over broadband networks and the best effort Public Internet. 

When troubleshooting an issue with VoIP over the WAN, you don’t necessarily have to own the hosted PBX to gain meaningful insight to the performance between your handset and the service.  Often times the problem is with the WAN connection, and you can easily use PathView Cloud to monitor the performance from your LAN out to a hosted microAppliance.  If you’re an existing PathView Cloud customer or partner, check out our support site for details on targeting one of our hosted microAppliances for this purpose. 

With a solid example of WAN performance affecting hosted VoIP quality as context we went on to complete a productive workshop that day. 

Our own dog food: delivered easily via the cloud, and it never tested so good!


Isn’t it an awful feeling when you’re told something by someone who has a vested interest in you believing them?  Let’s face it, who has ever wholeheartedly believed what a salesman told them?  Yeah, there are cries of  ‘snake oil!’ in my head when I’m approached by these types.  So, I’m here to give you the goods.  I work on the Support team here at Apparent Networks and  over the next three days, I’ll bring you a few tales of performance management woe, and how Apparent Networks solutions came to the rescue… Really!

The first case involves an MSP responsible for the local data network. This site consisted of a business cable internet uplink with two LANs onsite; one for data, the other for voice.

The challenge was this: The client’s VOIP call quality was suffering and it was up to this MSP to prove a LAN fault, ISP fault, or VOIP system fault.  You guessed it – everyone was pointing fingers at each other!  Ok, so, how do you tackle this problem? The client installed the PathView & the FlowView Plus switch in the data LAN as they didn’t yet have permission to touch the VoIP LAN.. We set-up single- ended & dual-ended paths to one of the public Apparent Networks responders.  Why both? The dual ended path gave us a dual-ended view of UDP packets but it couldn’t provide full diagnostics because mid-path devices don’t respond to UDP.  Couple this with a single ended path to show diagnostic data – and voila; a complete picture!

What did we find?  We found crazy oversubscription of the link.  Because we used dual-ended we knew upstream was the direction that was saturated.  Great, step one done!  The next question I’m always asked is ‘what is this data and who is causing it?’ FlowView Plus to the rescue!  We ran a capture and within minutes we knew we had computers on the network uploading loads of mail to a hosted mail provider!  One firewall rule later and our MSP client was very happy that they restores voice service as well as fixed a previously unreported slow internet issue!  It’s always nice to uncover problems you didn’t know you had!

Ok, stayed tuned for The Straight Goods Part II…

It is a sign of the times that I need to clearly define the term “cloud services” if I am going to use it as an entry point to this blog. And since I wouldn’t dare assert my position to be expert enough to properly define this term (any attempt would surely bog down this entire effort), I will turn to the main sources of knowledge of our time…

If I type “Cloud services” into Google, the top response is of course a link to Wikipedia.  The Wikipedia search for “cloud services” gets redirected to “cloud computing” which is defined as:

Web-based processing, whereby shared resources, software, and information are provided to computers and other devices (such as smartphones) on demand over the Internet.

It is nice to see my opening premise is not far off the mark. Simply put, a cloud service is a web-based service that is delivered from a datacenter somewhere, be that the internet or a private datacenter to “computers.” For now, let’s leave the definition of an endpoint alone.  I know that is a big reach, but this is my blog, and it really isn’t the point.  The point is that for all of these services, they are generally delivered from a small number of centralized datacenters and consumed at some relatively large number of remote offices.

That is where things get interesting.

If we lived in a world where email and simple web page delivery was the state of the art, well, I wouldn’t have anything to write about, but we don’t.  The mainstream services that are being deployed in education, government, and enterprise accounts are ushering in a completely new level of performance requirements on the networks they depend upon.  Voice over IP (VoIP), video conferencing, IP based storage systems for file sharing, backup, and disaster recovery, and recently the deployment of virtual desktop services all bring with them new performance requirements.  Yes, that means more bandwidth, but that is just the tip of the iceberg.  All of these applications also have very real requirements on critical network parameters such as (packet) loss, end to end latency, and jitter.   Unlike simple transaction and messaging applications like HTTP delivery and email, when these new “performance sensitive” applications run into in appropriate loss, latency, and jitter, the result is application failure.  Dropped calls and video sessions.  Failed storage services including backup and recovery, and “blue-screens” where virtual desktop sessions belong.  What causes seemingly healthy networks to suffer from latency, loss, and jitter issues?  More on that in a later blog……

Successful cloud service delivery to remote sites is dependent on managing performance at that remote site.  Not datacenter application performance, or server performance, or network device performance.  Service level performance analysis from a remote site is a new topic, and we call it Remote Performance Management or RPM.

Let’s start with the basics, what do we know about RPM.

First, RPM is a location dependent topic.  Of course, the traditional datacenter performance management issues need to be dealt with.  That is part of datacenter service delivery 101.  No debate.  But if we care about the service quality that the users are experiencing, then we need to understand performance from the perspective of the end user, at the remote site.

Next, we need to address the complete performance management lifecycle.  Simply put, Assess the remote office performance PRIOR to service deployment; Monitor the remote office performance DURING service operations, Troubleshoot issues QUICKLY (like you’re there), and Report on the good, the bad, and the ugly.  When you add it all up, you need a broad set of capabilities to meet these needs

Finally, we need to keep it simple, affordable, and scalable.  The problem with most solutions around the remote office is not the device cost, but rather the administrative cost.

The bottom line is that if you are attempting to deliver today’s critical services for remote site consumption, you need to understand performance, so you’d better check your RPMs…….

Follow us on Twitter!

Error: Twitter did not respond. Please wait a few minutes and refresh this page.

%d bloggers like this: