OPNET Talks End-to-End Management and Monitoring of Unified Communications

Unified Communications (UC), especially the real-time applications, is unique because of user expectations. Management of UC is very important as it ensures service availability and service performance, as well as other aspects of UC including security and compliance.

“At the end of the day, the user expectation is real-time communication services are available any time all the time,” Gurmeet Lamba, VP R&D Unified Communications Management, OPNET told TMCnet in an exclusive interview.

For example, if your phone is not connected you can’t make a phone call. A user has an expectation that the phone should work every it’s used. If you call somebody on a cell phone, but the voice is broken, you can’t complete your conversation. In both of these cases, the service performance is not adequate and the user’s expectations are not met.

“The reason the user expectation is so high is because it is so critical to the users living their lives,” said Dave Roberts, director of product management, Unified Communications, OPNET. “You car should start, your lights should turn on, your shower should run.

”End-to-End in UC means managing and monitoring the breadth and the depth of all components involved in orchestrating a successful communications session. To make this happen in today’s world, there are a number of components that are involved.

For instance, in order to complete a conference call, all parties phones must work, the network to the conferencing server must work, and the conferencing server itself must work properly.

End-to-end management and monitoring means getting visibility and performance of every single component involved in the complete communication session.  End-to-end involves management and monitoring of every component in the breadth and the depth of the communication session. The breadth consists of the applications – unified messaging, conferencing server, devices, call management servers, etc. When it comes to the depth, components include a client such as a phone or an application on your computer, the configuration of the application, the network, the virtual server, and the physical server.

“You can see the technology stack from top to bottom and from left to right. All of it has to work,” explained Lamba. “Communication is the oil that keeps everything moving

”When it comes to the most perfect End-to-End Management and Monitoring UC solution ever invented, Dave Roberts, director of product management, Unified Communications, OPNET, said, “The first goal would be to have 100 percent visibility to all of the information at all times. You would have to know every configuration of everything that is involved with the communication and every state of everything happening on the network at any instance. And then, it would have to have a way to correlate and use that information to do to a few things including detect problems, analyze information to find the cause of the problem, and fix the problem.

Article from TMCnet.com by Amada Ciccatelli  on OPNET

Advertisements

Setting Up VoIP for Success

A common stumbling block in monitoring VoIP occurs when the network team misconfigures or fails to define the VoIP setup process for their monitoring system. The results can be serious when you investigate a call and it doesn’t appear, it has been misidentified, or mistakenly combined with another call. Here are five steps to ensure your VoIP monitoring solution is set up for success.

Identify call components

Depending upon the VoIP vendor and system, different components may be involved in the call. For example, in Cisco’s® systems, communications occur between phones and the call manager. Avaya® uses multiple components including the phone, control processor (C-LAN), and media processor (MedPro). Before configuration, map out all components involved in the call.

Recognize the call

The first step in configuration is to specify how the monitoring system recognizes a call has been initiated. The option you choose will depend upon the probe’s ability to view the call setup packets. Observer offers flexibility dealing with this issue. New calls can either be identified from setup packets or via RTP data packets. Calls can be closed if no packets are identified for a specified time period.

Depending on how calls are communicated and the data involved, the user also needs to specify the traffic type and whether calls occur concurrently. For instance, Avaya systems use MedPro to send RTP data to other MedPro systems and to phones. Multiple calls can be sent and received at the same time.

Network Instruments - Recognize the Call

Program call components

Components involved in the call should be identified and configured. Within Observer® under the Device IP Addresses tab, identify the device IP and type. This is critical for dictating how things are measured and displayed.

Network Instruments - VoIP Program Call Components

Monitor encrypted traffic

If SIP data is encrypted, it can be nearly impossible to identify a call. Depending on your monitoring solutions, you may have the ability to track encrypted traffic. Observer decrypts SIP traffic and provides quality metrics on the fly once it has the appropriate security certificate.

Establish caller ID

The location of caller ID info varies by system and even components. To be sure the caller is properly identified, your network analyzer needs the location of ID details. In Observer, under the Caller ID Determination tab, users can establish a hierarchical set of rules to locate the sources of ID text.

Network Instruments - VoIP Establish Caller ID

Thanks to Network Instruments for this information

How does IPv6 impact VoIP?

Migrating to IPv6 requires more than flipping a switch. For the ill-prepared, migrating to IPv6 could adversely impact your VoIP systems.  The background of IPv6 is well known. Given how long OS vendors and Cisco have been ready for the change, you would think upgrading VoIP systems would be an easy thing.

The truth is not all VoIP vendors are prepared and it’s up to you to take charge. Let’s look at three critical areas needing consideration to ensure your communications systems are IPv6 ready:

  • VoIP system hardware
  • Security
  • ISP network translation

VoIP System Hardware
Begin by taking an inventory of infrastructure used to support VoIP services. With all hardware, verify IPv6 support and upgrade processes. For hardware or software phones, upgrading will likely require a software patch. Because demand for IPv6 VoIP is fairly recent, your vendor may have only begun to address this process. The second issue is one of logistics. Can your phones be remotely managed? If not, this will add substantial time to any migration.

VoIP servers are easier to upgrade. Server operating systems have long supported both dual stack and pure IPv6 options. Check with the VoIP system vendor for upgrade requirements and processes.

Security
Life behind a NAT, while not 100 percent secure, does obscure the VoIP server IPs from direct Internet exposure. VoIP systems are targeted by hackers, who once they have access to the system place calls at the owner’s expense. In moving to IPv6, the NAT device is no longer needed, which exposes your server’s IP to the outside and increases the likelihood of it coming under attack. It’s important to be aware of this threat and seek protective measures. Read more on VoIP security threats.

ISP and Network Translating
While most of the steps your ISP is taking to support IPv6 won’t have any impact upon service delivery, there are two areas to research.

  1. Does your provider offer IPv6 connections?
    You’ll want to understand the process and timeframe for requesting these connections, as it will directly impact your migration process.
  2. In transition, be aware of potential IPv4 issues.
    Providers faced with an exhausted IPv4 address pool may implement a provider-level NAT sharing one IP with multiple clients. This setup creates the potential for port collisions, which can be avoided by working closely with your ISP and understanding their policies for issuing IPs.

Because IPv6 has been spoken about as being on the horizon for so long, you would think all the concerns have been addressed. But what is still uncertain is the impact of IPv6 on VoIP systems. Only proper preparation will ensure VoIP performs smoothly through the transition. Here are resources to help you plan appropriately:

VoIP in an IPv6 world

Cisco Unified Communications and IPv6

Telnet Networks, would like to thanks Network Instruments for this article

10 Ways to Diagnose Voice Quality Issues in your Network

If you have implemented VoIP as part of your unified communication strategy, at some point in time you will be asked to troubleshoot call quality problems.    When issues do arise with call quality you will need more than just technology you need to collaborate with all your teams and get the information you need to solve the problem.   Below are 10 actions you can use to help get to the problem quickly.

1.    Sometimes, You Need to get Creative

While AppManager for VoIP can prove invaluable for receiving alerts and getting a large amount of data from various sources (e.g. call managers, network devices, simulated calls, call detail records), there will be times when you will need to do a packet capture or do a lot of SNMP-walking and testing.  Products like Network Instruments Observer should be part of your tool kit to understand what’s happening at the packet or communication protocol level.

2.   Collaborate with your Teams

When diagnosing a problem different teams often do not talk to each other, the infrastructure team may not be talking to the application team.   To diagnose a VoIP call you may need to investigate and ask questions of administrators in different areas.   One tool will never tell you everything that’s happening in the environment so getting additional information from other people and other tools, will help you solve the problem faster

3.   Get Technical!

Traversing packets and understanding codecs, RTP streams, routing, and protocols will be necessary to understand what’s going on. Don’t get overwhelmed; just remember  to get to the root of the issue, it will typically involve some healthy technical banter, analysis, and study.

4.   Look at the Call Routes

IP Networks allow each packet to independently find the most efficient path to the intended destination.   The inbound and outbound path the call takes may be different using different devices along the way.  Monitoring the appropriate streams of data and what direction they are travelling will help you understand where data goes or where it comes from.

5.   Do your own Correlation

Take a look at the timestamps of events. Correlate those to when other alerts are happening. What time are network changes being made, do those happen around the same time that issues arise. You will need to correlate this information appropriately if you want to get on the right track. Look at the events from just one device does not help, you need to keep an eye on the big picture and see what’s alerting across the board.

6.   Investigate all Parties

Is there a WAN outsourced to a carrier? Is there a 3rd party system integrator who manages a portion of the network? You need to understand how other parties affect your task.  Often we do not have access to the cloud which is where you think the problem is, you are going to have to find help from someone who has the right access to the information you need

7.   Re-create the Problem

Are there any patterns to the call issues you are experiencing? Do they happen at certain time (other than when the network is just generally busy)? Do they happen over specific networks or links? The better you can consistently re-create the issue, the better you are at determining where the problem may lie as there are less unknowns.

8.   Triple-Check QoS

QoS is one of the most important issues to check on a large network.  A minor mis-configuration with QoS will cause problems in many areas.   You need a way to check the configuration and get proof the configuration is the way it is suppose to be.  By using VoIP Quality endpoint you can run simulated calls to see what is going on.

9.   Do not make any Assumptions

Just because someone says they have configured a device doesn’t necessarily provide the confidence that it really is configured the way you need it to be. Getting proof of network configuration or call manager configuration will be tricky but is vital. Many people may be involved in the management in all these devices and sometimes the processes are simply not in place for proper change management that allows for proper execution of changes. Automating the process of Configuration and Change management will allow you to stay on top of any changes in the Network.

Gain Support, Not Frustration!

When you approach other members of your team it is easy for them to feel like they are being blamed for the problem.  You need to gain their support to help you solve the problem, or provide you with some details to you so that you can either fix the issue or focus elsewhere.  This is more of a “soft” skill but can prove priceless when being pressured to find a resolution quickly.

When call quality issues need to be solved the right tools are critical in helping you solve the problem, the other part is member of your team and other departments that allow the call to flow over the network.

This article was adapted from NetIQ Qummity of which Telnet Network is a premier partner.

Avoiding The Perfect VoIP Storm

Perfect VoIP StormAlthough now a mainstream technology, managing VoIP remains a challenge for even the most seasoned IT pro. The application’s sensitivity to packet loss and delay and users intolerance for anything less than audio perfection can create a troubleshooting nightmare.

1. Understand and measure call quality

There are a variety of metrics and variables you can use to assess VoIP call quality, including jitter, MOS, R-Factor, gap density, burst density, Quality of Service prioritization, and compression techniques. Ensure accurately analysis by learning how to measure these attributes.

2. Make QoS a priority
Incorrectly set QoS precedence for VoIP traffic leads to delays in packet delivery and reduced call quality.

3. Deploy analysis tools strategically
Placing analysis consoles and probes on your network requires a clear understanding of VoIP traffic patterns. Are you concerned with monitoring VoIP traffic locally, over WAN links, or both? Depending on your objectives, place your analysis tools to ensure optimal visibility of VoIP communications. Learn more.

4. Compare jitter to overall bandwidth utilization
When jitter becomes a problem, look at the big picture. A correlation between jitter and bandwidth usage means the problem is overall network usage. If there is no direct correlation, excessive jitter might be caused by isolated network factors that require further investigation.

5. Proactively monitor VoIP activity
Utilize monitoring and notification tools to speed problem resolution. Determine “normal” or “acceptable” levels of activity for your network and its users. Then set up thresholds within your analyzer to alert you when performance degrades.

6. Baseline network traffic
To truly understand VoIP traffic, capture and store long-term network data. Only with critical trending data can you accurately perform baselining activities. Baselining validates VoIP performance, helps future capacity planning efforts, and provides long-term understanding of VoIP health.

Visit our online resources for in-depth info on VoIP and other unified communication applications.

Monitoring IP Telephony/Unified Communication

Many business start with VoIP as the first application to start there unified communication strategy. Once you have deployed unified communication, you need to continuously monitor and manage the environment. This will help you ensure agreed-upon service levels, including the availability of service and the quality of end user experience. You need

  • Visibility into all the elements of unified communication, from infrastructure to data applications and IP telephony
  • Assess Voice quality in real time
  •  Measure the end-user experience of applications
  • Reduce the time to resolve incidents

Why Monitor Your VoIP Traffic?

  • Any changes to the underlying LAN/WAN infrastructure will now affect VoIP Performance
  • Traditional Telephony (PSTN) each call is carried on a secured fixed bandwidth circuit for carrying the voice.
  • Packet Switched networks are designed to carry data, which are not time-sensitive.
  • With IP Telephony Voice is shared with Data as well as other voice calls over the same network
  •  IP networks allow each packet to independently find the most efficient path to the intended destination.
  •  Voice could arrive with different end-to-end delays, arrive out of sequence, or possibly not arrive at all.

Primary Challenge of Managing Unified Communication

Maintaining the quality and consistency of voice conversation in an ever-changing network environment.

Learn more here

Does Adding Bandwidth Solve all VoIP Problems

The amount of bandwidth required by a VoIP call can be deceptive. The codecs send data at relatively slow data rates. G.711 typically consumes the most bandwidth, operating at 64 kbps. But for every VoIP packet that is sent, an RTP, UDP, and IP header are added. These headers add 12, 8, and 20 bytes respectively. So while G.711 sends data payloads at 64 kbps, the actual amount of bandwidth required is more like 87 kbps due to the additional headers.

Knowing the required bandwidth is important, and ensuring that you have the right link in place to support the maximum number of calls that you need to support.   By completing a total VoIP Assessment of your network you can then understand your network typical usage patterns, topology, and device configuration before you deploy VoIP on the network.

It is also important to understand that adding more bandwidth does not solve all problems.   Although Bandwidth can reduce congestion which would enable those links to support more VoIP calls with higher call Quality, it will not reduce delay or latency.  VoIP traffic is extremely sensitive to delay.  Slowing down a VoIP packet by more than 150 milliseconds can cause serious quality problems. The delay encountered by a VoIP packet occurs in several areas:

Queuing – The time spent in router queues along the path through the network. The more congestion, the greater the queuing delay.

Serialization – The time it takes to put a packet on a network link interface. This number increases as the packet size increases and as the link speed decreases.

Propagation – The time it takes to travel from one point to another in the network. This time is a fixed value that’s directly related to geographical distance. A good rule of thumb is 10 microseconds per mile.

Jitter buffer – Each VoIP phone and gateway provides a jitter buffer to smooth out effects of network jitter (variations in delay among packets in the same stream). This buffer adds delay as the packet is held for playout.

The only latency component that might possibly be reduced by adding bandwidth is the queuing delay. The other latency components are not affected by additional bandwidth, so if you are experiencing call performance problems due to delay, adding bandwidth probably won’t help

By completing a full VoIP Assessment you can understand not only the traffic patterns that may cause congestion which would mean a that adding extra bandwidth will help, but also the delay and jitter components for proper call quality.  As networks are always changing you should proactively monitor call quality to ensure that you have trending information, which can tell you what upgrades will be necessary in the future and that the end user continues to have a great experience.

You can download a white paper on this subject here