VOIP performance
chrisone
Member Posts: 2,278 ■■■■■■■■■□
Hi All, i am interested in your guy's take on how to manage and evaluate VOIP performance on a network?
Although i am an a network engineer and i see to it that i get the best flow for Voice traffic, at some points there is this "it was the network" ghost response to all voip problems instead of the actual voip components themselfs. It seems to be a very lazy and crude generalization of the network. I look at switch logs, port counters, MPLS statistics and bandwidth utilization, netflows , to see if I can catch anything that could hog up resources that would produce poor VOIP quality. We run Avaya stuff and our Voice guys arent really network engineers and have little experience in that area.
I was looking at this book, does anyone have any experience with this book or with any good tools or utilities to monitor voip performance/quality ?
http://www.amazon.com/Performance-Management-Optimization-Networking-Technology/dp/1587055287/ref=wl_it_dp_o_npd?ie=UTF8&coliid=IF3TC5NY48JJJ&colid=2R1R0S9FPG0X
Thanks!
Although i am an a network engineer and i see to it that i get the best flow for Voice traffic, at some points there is this "it was the network" ghost response to all voip problems instead of the actual voip components themselfs. It seems to be a very lazy and crude generalization of the network. I look at switch logs, port counters, MPLS statistics and bandwidth utilization, netflows , to see if I can catch anything that could hog up resources that would produce poor VOIP quality. We run Avaya stuff and our Voice guys arent really network engineers and have little experience in that area.
I was looking at this book, does anyone have any experience with this book or with any good tools or utilities to monitor voip performance/quality ?
http://www.amazon.com/Performance-Management-Optimization-Networking-Technology/dp/1587055287/ref=wl_it_dp_o_npd?ie=UTF8&coliid=IF3TC5NY48JJJ&colid=2R1R0S9FPG0X
Thanks!
Certs: CISSP, EnCE, OSCP, CRTP, eCTHPv2, eCPPT, eCIR, LFCS, CEH, SPLK-1002, SC-200, SC-300, AZ-900, AZ-500, VHL:Advanced+
2023 Cert Goals: SC-100, eCPTX
2023 Cert Goals: SC-100, eCPTX
Comments
-
SubnetZero Member Posts: 124One thing you could do is setup IP SLA's to monitor jitter
In the following example, two operations are configured as UDP jitter operations, with operation 2 starting five seconds after the first operation. Both operations will run indefinitely.
Cisco Example:
ip sla monitor 1
type jitter dest-ipaddr 20.0.10.3 dest-port 65051 num-packets 20
request-data-size 160
tos 128
frequency 30
ip sla monitor schedule 1 start-time after 00:05:00
!
ip sla monitor 2
type jitter dest-ipaddr 20.0.10.3 dest-port 65052 num-packets 20 interval 10
request-data-size 20
tos 64
frequency 30
ip sla monitor schedule 2 start-time after 00:05:05
On the target (destination) device:
ip sla monitor responder
Cisco IOS IP SLAs Configuration Guide, Release 12.4 - IP SLAs--Analyzing IP Service Levels Using the UDP Jitter Operation * [Cisco IOS Software Releases 12.4 Mainline] - Cisco Systems
Brad Reese on Cisco: How to setup Cisco IP SLA jitter monitors
You can also choose from a bunch of 3rd party tools like PRTG
VoIP Jitter - QoS Monitoring with PRTG
While no trees were harmed in the transmission of this message, several electrons were severely inconvenienced :cool: -
shodown Member Posts: 2,271Couple of questions to ask you do you have QOS on your network then we can go from there.Currently Reading
CUCM SRND 9x/10, UCCX SRND 10x, QOS SRND, SIP Trunking Guide, anything contact center related -
chrisone Member Posts: 2,278 ■■■■■■■■■□No we dont, however if we run QOS , some form of traffic needs to take a hit due to the priority effect. In all honesty we dont see our bandwidth utilization for voice traffic ever spike up past 75% and our latency is below 300ms, usually around 150-200ms depending on the site and its distance. I actually considered QOS but it was shot down, i think they would rather just throw more bandwidth at the problem. However like i said we dont even get close to 75% of our bandwidth and our switches and routers never hit any resource peeks.
I am just looking for more of a better view on the voip traffic and quality. Once i have this clearer picture if need be I can show management we need to introduce QOS. I need to be able to tell if voip traffic is suffering , i guess SLA's is the best scenario and we were using Denika. However i would like to use other utilities to have a better picture "graphs, stats" etcCerts: CISSP, EnCE, OSCP, CRTP, eCTHPv2, eCPPT, eCIR, LFCS, CEH, SPLK-1002, SC-200, SC-300, AZ-900, AZ-500, VHL:Advanced+
2023 Cert Goals: SC-100, eCPTX -
shodown Member Posts: 2,271Just to throw this at you
Buying more bandwidth doesn't always fix Voice Quality. QOS also allows packets to get market so they can get onto the wire 1st. If someone has a large file transfer going the voice packets can be getting stuck in between those FTP packets which even if you have decent bandwith can cause some of the symptoms you have complained about Voice traffic should also not take up that much of the link if you have Voice traffic anywhere near 50 percent of your link you need to buy more bandwith.
As for which traffic has to take a hit you can work that out when you get a QOS plan. You can get several QUE's of traffic from your provider and you can provision your apps accordingly. I'm baffeled with how many people aren't running QOS cause they have fat links, QOS will make them more efficient by ensuring the traffic that needs to cross 1st will. How many sites do you have and WAN topology?Currently Reading
CUCM SRND 9x/10, UCCX SRND 10x, QOS SRND, SIP Trunking Guide, anything contact center related -
networker050184 Mod Posts: 11,962 ModI agree with shodown. Not going with QoS is a pretty naive approach. Other traffic isn't necessarily going to suffer (noticeably anyway) for giving your VoIP priority in times of congestion. It will also give you some good show commands to hop in and look at while the issue is occurring.
As SunetZero pointed out there are quite a few products that can measure the quality or read the SLA output via SNMP for you.An expert is a man who has made all the mistakes which can be made. -
chrisone Member Posts: 2,278 ■■■■■■■■■□We have many without getting into details. We dont hear about voip complaints that often, but i would like organize this a bit better and i know QOS can come into play. I think the IP SLAs will work great for now that will give me a solid clue as to if the "network" is crippling the voice traffic or if its the actually POS Avaya equipment, these guys run on our network.Certs: CISSP, EnCE, OSCP, CRTP, eCTHPv2, eCPPT, eCIR, LFCS, CEH, SPLK-1002, SC-200, SC-300, AZ-900, AZ-500, VHL:Advanced+
2023 Cert Goals: SC-100, eCPTX -
ccnxjr Member Posts: 304 ■■■□□□□□□□Probably not the best solution for continuous monitoring, but for general troubleshooting or stress testing I'm using PJSIP
http://www.techexams.net/forums/off-topic/73568-voip-qos-tools.html -
ipSpace Member Posts: 147No we dont, however if we run QOS , some form of traffic needs to take a hit due to the priority effect. In all honesty we dont see our bandwidth utilization for voice traffic ever spike up past 75% and our latency is below 300ms, usually around 150-200ms depending on the site and its distance. I actually considered QOS but it was shot down, i think they would rather just throw more bandwidth at the problem. However like i said we dont even get close to 75% of our bandwidth and our switches and routers never hit any resource peeks.
I am just looking for more of a better view on the voip traffic and quality. Once i have this clearer picture if need be I can show management we need to introduce QOS. I need to be able to tell if voip traffic is suffering , i guess SLA's is the best scenario and we were using Denika. However i would like to use other utilities to have a better picture "graphs, stats" etc
Regarding the bold words, please regard that most often the 75% is an average of 5 minutes(with mosts of the softwares) so it could be like this: 100% for 2.5 minutes and 50% for 2.5 minutes.
An average of 80% is a lot in these types of environments(with 5 min average).
What is your average(5 minutes or less)?
My Network & Security Blog with a focus on Fortigate. New post on how to create a fortigate ssl vpn. -
effekted Member Posts: 166No troubleshooting to add, just wanted to say that anytime we see VOIP issues it is always the "network". We have QoS in place, can check everything there is to check on our network and see no issues where there would be bad voice quality from the network side.
I always joke blame the issue on vendor we're using, which is the same as what you use. Dealing with their support is horrible, and they always want to slap on Professional Services. It seems I am generally more knowledgeable then they are when it comes to certain things. -
chrisone Member Posts: 2,278 ■■■■■■■■■□ipSpace.eu wrote: »Regarding the bold word, please regard that most often the 75% is an average of 5 minutes(with mosts of the softwares) so it could be like this: 100% for 2.5 minutes and 50% for 2.5 minutes.
An average of 80% is a lot in these types of environments(with 5 min average).
What is your average?
Like i said if there are any spikes I havent seen it go passed 75% , average is about 30-50% link utilization and that is rolling the graphs back past 5 minutes to , last hour, last 24 hours (Scrutinizer). A constant 50% is actually rare too. We use solar winds engineering tools (free version) to nab live traffic flows. We use Whats Up Gold for our monitoring of devices as well. Some of our voice engineers use iCinga/Linux software but that is all SNMP based, no live traffic counters, no SLAs.Certs: CISSP, EnCE, OSCP, CRTP, eCTHPv2, eCPPT, eCIR, LFCS, CEH, SPLK-1002, SC-200, SC-300, AZ-900, AZ-500, VHL:Advanced+
2023 Cert Goals: SC-100, eCPTX