to verify QoS Performance

Quality of Service, aka QoS, is one of those industry specific buzz words that everyone in the IT and telecom world is at least conceptually aware of.  When pressed for the details of the nuts and bolts, though, there is often an indignant “well, don’t you know?”  response followed by immediate loss of eye contact and shrug of the shoulders.  In the Precambrian VoIP era (roughly 2001 and earlier), many of us were migrating from traditional “digital” voice technology and were sometimes asked how we could prioritize voice traffic over any other network traffic to which we would respond “Why, QoS it of course!” .

“Great!  Then bring your QoS thingy  out and let’s get these IP phones working …” was usually the customer’s response.  But as soon as the door was closed or the phone hung up, there would be that soul searching, gut wrenching moment of “why did I commit to that?” followed by “Who do I know that can do this?”.   In the beginning, for many of us, QoS, like the earth in Genesis  “was without form and void, and darkness was over the face of the deep.”

IP Packet Cliff Notes

Many IT guys know – and many more voice guys should know – that when you are capturing packets – usually with Wireshark – what you are seeing is a combination of traffic that is LAN specific and traffic that is on its way to another network.  Most of it is “IP” and some of it is not.  Non-IP packets, for example, would be ARPs that you see in the capture saying “Who has 192.168.1.1?  Tell 192.168.1.104” – commonly known as a ‘request’.  These sort of requests are all over the place in a busy network and you will see associated with them the replies  like “192.168.1.1 is at 00:23:ae:63:21:aa” (a MAC address) .  You will also see  the occasional “Gratuitous ARP” which is basically some host making sure that there is not another host on the network that has the same IP address it was just assigned (either manually or by a DHCP server).   What makes ARP a non-IP packet is that it does not have an IP field in its header and is therefore un-routable  off the local network.

Typical ARP Packet

Comparing that with a typical TCP packet, you will see an Internet Protocol field along with all the goodies that come with it – including the holy grail (at least for this article) where you can actually tell whether the packet is given preferential treatment or not – the ToS (for Type of Service) field aka the  Differentiated Services Field.

There are, or better, there were two main flavors of ToS – IP Precedence and DSCP.  IP Precedence is the older of the two and consists of the first 3 “most significant” bits in the ToS field (i.e. reading the bits  from left to right).  From that, the router could determine what  ‘precedence’ this particular packet had (if any) in terms of how it got routed e.g. route it using a particular interface or use the path with the best known metric, etc. and not necessarily whether it got to go in front of the line or not.   Hence the term “IP Precedence” and not “IP Preference” .   When you see this, think DSCP as in just about every instance nowadays this term and method has superseded it.

A common QoS misconception that is shared by most non-packet oriented office members (think sales people who have just heard of the term and want to show off at the next sales meeting) is that you want to prioritize everything from a particular IP address.  On the surface that might seem okay until you realize the shear number of protocols, applications and chatter that just one semi-busy machine generates on the network.  There are times when you do this but not many.   Don’t be THAT GUY in the meeting with an owner/CEO and his IT staff that refers to QoS configuration in this manner – you will lose the job the minute they are able to talk about you behind your back.  And don’t pronounce it as “Kwoss” either, it’s Q-O-S.  Saying it any other way makes you sound like a hick telephone guy or a salesman trying to sound like he knows what he’s talking about.  It must be said smoothly, confidently and with a certain air of  “I know what this means, do you?”

Most QoS is a combination of “marking” packets of a particular protocol at the source level in combination with a matching QoS outbound map/policy/rule  at the router level and/or the managed path level in the case of MPLS networks.  You can prioritize packets solely based on ports, IP addresses even entire subnets but that is done at the router level only – usually one with a lot of horse power too – and frankly, it is less common.

DSCP (aka “DS”, “DiffServ”) stands for Differentiated Service Code Point – not that anyone actually says that unless they are trying to impress you –  and it comes in several decimal, binary or hexadecimal  values.   In Wireshark, the DS field itself is the second byte in the IPv4 header packet (which you will still see as the ToS field in some text books) and consists of  two sections –

1. The actual DS binary value which occupies the first six most significant bits .
2. The ECN value (aka Explicit Congestion Notification) which is used to notify end points that a router along the path is reaching its saturation point and to “lighten up” until it has a chance to work through its issue.  This is a little used feature and most of the time you will see it set to zero.

Technically, you can have up to 64 (0 through 63, that’s 2^6) values or “classes” but I’ve never seen a small or medium size business that needed more than 5.  For most scenarios, you will be using one of the following 3 classes;

1)      Best Effort – which is like sending a message in a bottle hoping that it gets to the other side … eventually.  Most sites we have walked into that are not using VoIP usually are using this. The numeric value is always zero.

2)      Assured Forwarding – This has decimal values between 10 and 38 and is a step or two above just throwing your packets into the Internet ocean.   It’s not FedEx but it’s not carrier pigeon either if programmed right.   In most cases you will use this to prioritize different services  such as video, a Point of Sale application, security , utilities, email etc.  I will sometimes put just the signaling  packets of VoIP in this class with a decimal value of 26 or 28.  In other cases you will use it to control access to a shared circuit – e.g. you may have 2 or more tenants using the same Internet T-1 and you want to control their percentage of usage equally.

3) Expedited Forwarding -  When it comes to the RTP voice packets, this is the only class you want because it is the one that gets your information there ahead of everyone else.  On top of that, you will usually reserve some bandwidth, to the determent of all other packets, when it absolutely positively has to get there …. now.  Its decimal value is 46. Special note – if your application requires either hex or binary and you don’t do conversions well in your head, get an app for your iPhone or Droid that does this – their cheap and often free.

QoS from Wiresharks' point of view

The actual decimal value in the Differentiated Services field that you see in Wireshark will not seem to match what you thought you programmed until you look at it in the packet details pane.  The reason for this is because there is an “off set”  which, in this case, allows you to address two semi-separate needs (DSCP and ECN) in one byte – that happens sometimes in packets btw.

Getting from Here to There in Style …. And Knowing It.

Keep in mind that the voice packets are usually going to be “marked” at the end points by what ever application is creating the data traffic – in this case the  “VoIP” app.  These points include the actual IP-PBX or Voice Server, the physical IP set or even the “softphone”.  Routers within an MPLS cloud will sometimes alter the marking by either changing them to “Best Effort” – which defeats our purpose – or some other value either intentionally or inadvertently.   Also, QoS of any sort only kicks in when the outgoing bandwidth from your WAN is saturated.

Customer "The Internet is slow sometimes but that should not affect anything you're doing, right?" IT Dept - "We have everything locked down pretty tight. I doubt we're using more than 1 meg."

From a VoIP standpoint, there are effectively 2 protocol groups you care about;

1)      SIP, SDP, H.323, RTSP and H225 (there are more but these are the most used ones) which controls the non-voice part of a conversation such as the set up and teardown of  calls (as a voice guy, think ‘signaling’) and almost anything that is not actually carrying packets with audio in it.  This does not HAVE to have the top priority as it is not nearly as time sensitive as the second group but in cases when network traffic is really congested, you should give it some type of priority.

2)      RTP and RTCP   which are referred to as the “Transport”.  RTP is the protocol that actually has voice audio in it and you will want this to get the highest priority possible.  RTCP is the control link for a particular RTP session.  It has a few flavors and is another form of signaling but you want to keep this with the same QoS treatment as RTP.

A typical question you will hear when the MPLS carrier or generic router guy starts setting up QoS for you is  “How are you marking your packets?”.  To which you would inform him that the packets will be marked such and such to which they will usually say “No problem” and then disappear with nary a call or email.  So the question becomes a) Did they do it? and b) How do I verify that they did it?  After all, it’s you and “that phone system your company sold us” that will be held accountable.  This is where two important rules come into play with regard to doing anything on someone’s network the first time around.

First Rule – Get a baseline of the health and use of their circuit(s) BEFORE you start tinkering.  This does not necessarily mean capturing packets with Wireshark (at least, not at first) as you are not so interested in the details of WHAT is going through (web traffic, emails, hosted services etc.) as much as you are interested in HOW it is going through.  Are the circuits you are working with clean and by that I mean is there any continuity loss?  High utilization? Jitter? High latency? Packet loss of  either voice or data packets – i.e. anything that will affect a real time application like voice..  Fyi,  normally data packets have larger payloads than voice packets and are sometimes treated differently as they travel across the network.   Programming QoS on a circuit that is not fit for the doghouse (even if you’re not in it at the time) will be a big waste of unbillable time.

Second Rule – Do not rely on the customer, their IT department or the carrier to give you anything close to accuracy or the truth as to the condition of their circuit(s).  They are usually clueless, misinformed or indifferent as to its importance.  Invest in a piece of software that can reliably measure all of the above.    The key word here is “reliably” because there is plenty of software (free and not free) that will claim to do it but  with some caveats.  If your reputation is being the “go to” guy,  don’t morph into the “go too cheap” guy.   If the app you’re using misdiagnoses, comes up with lots of false positives or simply misses the problem altogether, get something else … quick!    I am partial to Pathview (developed by Apparent Networks, btw we’re partners with them and can hook you up!) for that reason.  With this type of software, you can keep everyone honest – you, the customer and most importantly, the carrier/ISP.

Nothing gets you off the hook faster than being able to prove that a customer’s network or (more likely) Internet connection was screwed up BEFORE you walked into the building than a nice colorful graph or set of tests taken ahead of time.  I have run into situations where the IT department knew that the network was messed up but wanted to keep it that way just enough to allow them to increase their budget for more “ IT things” (not Pathview or anything like it by the way).   It was one of those “silent battles” that occasionally come up – just go in knowing that sometimes not everyone wants you to fix the problem.

Once both Rules have been followed, you will then have something to go to work with – and eventually pick up your check.    What you should see is things like jitter, MOS, packet loss and latency drop for those packets that are prioritized (see the graphs showing QoS enabled and not enabled).  QoS is not perfect but in critical situations – when done right – it’s pretty good.

Some Final Pointers

Implementing QoS is like any other network project.  Get the big picture first with baselines because it will definitely help color in the details later.  Links to remote sites – especially end users working at their homes as more and more are doing nowadays – are almost always the trouble points so use an app that is good for that and does not take all your hard drive.

Going in with a packet sniffer like Wireshark first – unless you are really familiar with the site or the problem – is arduous and may even distract you from the primary objective.  Besides, packet analysis is intense and time consuming – if you have that skill you are entitled to get top dollar but do it efficiently.   If you don’t have that skill and want it, check out Wireshark Network Analysis by Laura Chappell – you will be a much sought after, well informed (and well compensated) network geek when you are through.

If you are consulting or selling managed services,  it is important to straighten out your sales staff that contrary to what they read in the “IT Sales Action Hero” comic book, QoS is not magic and can not traverse into a remote network to prioritize THEIR data traffic.

Finally, be sure to let your customer and sales staff know that in the event that the entire circuit is down, nothing will get through – not even QoS’ed packets.  As obvious as this sounds, I actually had someone ask me that.  It’s hard to make this stuff up …..

Copyright Eric Knaus, WCNA  Jan 2011

Incoming search terms for the article:

• wireshark dscp
• arp packet example
• wireshark ip precedence
• nec aspire qos
• arp packet format
• dscp and its function ?? in wireshark
• dscp voip wireshark
• DiffServ Codepoint field in IP packet
• differentiated services code point 2011
• dscp values in hex

Coming from a voice background, one of the first things you learn is that you are guilty of  all things until you prove – and often to the satisfaction of  completely clueless people (see figure 2) – that you or the equipment you installed was not at fault for something not working.  Furthermore,  just because you correctly identified the problem as not being yours does not a) make you popular or b) excuse you from having to fix it anyway.   Our customers have greatly benefited from Pathview and, one would think, that because of the highly technical nature of networks, ISP’s would welcome the assistance from someone armed with such an application.  Amazingly, this is not so.

Figure 1. Customer reported that the Internet seemed to suddenly slow to a crawl. ISP response - “We are testing good to the modem at 3Megs. Contact your IT person. It’s obviously your equipment.” After hours of arguing with them (Comcast), it turned out to be their faulty modem.

True story

Those of you familiar with Wireshark know it to be a very popular packet sniffer. If you have been looking at Wireshark recently you will know the name of Laura Chappell and her very thorough book “Wireshark Network Analysis” released last March.  In one of her case studies was a very amusing yet oh-so-true true situation.

It was a familiar story of a user having trouble connecting to the corporate office and the IT department pointing the finger towards the ISP.  The ISP calmly assured them that they were not blocking any traffic.  When confronted with a packet capture showing otherwise,  the ISP confirmed that they were – as they put it – blocking  “ports in question”.  Begrudgingly, the ISP allowed these port through but with a few caveats.  In an almost whimsical way, the author ended his report as follows;

“We now have a happy user, but I can’t help but wonder how many other customers of this ISP are encountering similar issues and wondering why it takes so many attempts to get connected to their corporate network.”

If you haven’t had an experience like this with an ISP, you are either very new, very lucky or VERY oblivious.  In the words of Morphius to Neo …. “Welcome to the real world.”

Here’s the fact, ISP’s have for years held – and lorded over – their two trump cards to end users and vendors alike, i.e. “We’re more technical than you could ever hope to be” followed closely by “Prove it …!” said usually with a subtle yet detectable sneer either on the phone or through an email.  Unfortunately, things like “it seems slow …” or “I don’t think we are getting the bandwidth we are paying for …”, or even, “my voice is definitely choppy at certain times of the day …” just doesn’t cut it with these guys.

Baselining – Getting Prepared for the 3 D’s

When a customer approaches us with their story of woe, the first thing we do is establish a baseline with Pathview using targets both inside their network and outside to one of our micro appliances.   The more elusive or intermittent the problem, the longer the base line needs to be and by that I mean minimum one day and as much as a week or even longer.  It is also recommended to see what their system looks like when things are being backed up.

Field note – if the customer can’t tell you when the system gets backed up, it is probably related to when they are having some type of network problem.

Figure 2. The weekend staff kept complaining about the Internet being slow even when only 4 of them were watching the ball games … on their pc’s.

I usually tell the customer that if the problem looks like the carrier, it will take a minimum of 4 calls to their Customer Care/Support center to get to someone who can actually do something.  If you are a consultant, this is something that you charge for (what?! you don’t think a lawyer would charge for his time to do this?).  Once contact with the carrier has been made, you will begin with the first of the 3 D’s.

DENY

The way ISP’s decide to address a customer’s problem depends on their technical level in the Customer Service Center which generally falls under one of the following two axioms:

Axiom 1 – The less technical they are, the more they will want to sell you additional bandwidth.

Slow Internet? More bandwidth.

Getting cut off altogether?  More bandwidth.

PC making strange noises? More bandwidth.

Think some of your ports are being blocked?  Get more bandwidth and, oh by the way,

there may be an extra charge for unblocked ports (whatever they are).

Axiom 2 – The more technical they are, the likelier they are to put all the blame on the user’s equipment.

Usually they will say something like “Well, I’m logged into your router now and I don’t see any packet loss at this time or in the last 48 hours …”.  One time with the NOC guy on the line, I told him that I was going to make a programming change in the router and actually unplugged the carrier’s equipment.

“How does it look now?”  I asked after about a minute.

“Looks the same, no packet loss.”
No surprise, he was looking at the wrong circuit all along.  That one was easy.

The hard ones are when they are actually looking at the right circuit and for some reason insist they are not seeing what you are seeing.  This, by the way, is what sold me on Pathview and led me to an almost X-File motto,

“The truth is out there … somewhere, but you will need Pathview to find it.”

(I should probably copyright that before Jim grabs it!).

In the chart below,  the customer had installed an IP based pbx and had just converted to SIP trunks.  They kept losing calls and their voice quality was very choppy – other than that, it was great …

Figure 3. Using Pathview Cloud looking towards the SIP provider

The SIP provider, Broadvox in this case, insisted that the problem was not at their end and to contact their local carrier.  The carrier, a wireless outfit, claimed that it could not be anything at their end so it had to be the customer’s equipment.

A quick look at their connection from our point of view (outside-looking-in to their pbx using Pathview Premise) and then to the SIP provider from the customer’s point of view (inside-looking-out using Pathview Cloud), shockingly revealed that the problem wasn’t the customer’s equipment at all but was instead the hop (in this case, the  wireless tower) just past the customer’s router.  Granted, the customer was in a remote area (northeast Texas) which is why they HAD to go with wireless for a while (but this was about to change).   The customer and I called the carrier and incredibly, got a hold of the operations manager on the first try.  Thus began the second “D” when dealing with the ISP.

DEFLECT

He had us on the speakerphone and it seemed as though he was trying to demonstrate to someone(s) in the room how to deal with a complaining end user.  In rapid fire he began to drill us –

“How much packet loss? I will need to know the exact percentage and where it is occurring”

“When did this start?”

“Why are you just noticing it now?”

“How come we’re not seeing it?”

“Are you sure you have power?”

“Have you replaced your equipment?”

“Is it raining there?” ç That was an interesting one!

“We have VoIP sets and we’re not having problems.”

There were a few others whose relevance I questioned but it was clear that customer sensitivity was not in the field ops hand guide.  The only question he didn’t ask is whether we though we needed more bandwidth but then again he was obviously an Axiom 2 guy. He finally ended it with a ‘and-don’t-call-me-back-until-you-have-all-this-information’ “Okay?”.

For a moment it seemed as though he was leaning back in his chair while looking at his understudies with the air of  “ … and THAT’S how you handle that!”.  At the same time I heard my customer softly chuckle since he had already seen the Pathview charts and tests.  Needless to say, we were quickly placed on hold and picked up elsewhere – not on speakerphone  – and he asked us to email the information.  I don’t know if he actually looked at it or not but within moments a service call was scheduled with the results in figure 4.

Figure 4. “Okay, should be working fine now. The tech ran a few DSL Reports tests and then a traceroute for good measure. Looks great!” Are you kidding me?!

I was stunned.  Yes, it looked better but the customer was, well, let’s just say he was still experiencing problems.  This time the customer forwarded the reports to the ops manager and anyone whose email address he had.  On to the third “D”.

DELAY

The response was that they did not see any problems – which also falls under “DENY” – but they promised to continue monitoring it and get back to us.  After a few days of non-returned emails and phone calls it was clear they were going to leave it as is and just wait us out.   Long story short, the customer switched Internet providers the next week and, while not perfect, things greatly improved.   I also heard that they raised the rent for the carrier’s repeater that was on their property.

Figure 5. “We don’t measure MOS in this department but that looks normal.” Is there someone I can go over this with? Hello? … Hello?

In the very old days of T-1 (for both voice and data),  and to a much lesser extend today,  the only way to really trouble shoot the circuit was to go on premise with a T-Berd and do a head-to-head test which meant disconnecting the circuit altogether from any customer equipment and start running tests directly back to the central office.  This was an after hours adventure known as a “vendor/telco meet” and had to be scheduled a few days in advance unless you happened to have your own T-Berd (which was not cheap) in which case you could almost do it on the fly.  The upshot was there was usually a conclusion one way or the other, the guilty were persecuted and sentenced while the innocent were absolved.

Figure 6. “We’re not seeing anything but go ahead and send us your graphs and we’ll forward them up the line.” Two days and 4 calls later I got a hold of a sharp router tech who found the problem in 15 minutes. “User provided graphs? No …. I’m not sure what they do with that stuff.”

But that was when the playing field consisted of AT&T, GTE/Verizon and then everyone else.  Nowadays, it’s all about how to repackage the same service that everyone else has and only worry about the larger customers.  The smaller the fish, the more they are going to have to put up with – “ ….just let them try to get out of our contract!”  Ironically, this is actually good for companies like us because the SMB’s of the world just simply don’t know who to turn to.

Parting Shots

When we started using Pathview, aside from the occasional ticker tape parade,  I was looking forward to the time and aggravation we would save ourselves and the customer.  What we got was all of the above along with the revelation that ISP’s ;

1)      Don’t look at packets they way they are actually used

2)      Don’t want your help when trouble shooting

3)      Often don’t have the software  tools, training or even the inclination to  look beyond the single port of a router.

4)      Would rather put you or your customer through the 3 D’s than to actually fix the problem.  How that happened is for another blog.

Copyright Eric Knaus 2010

Incoming search terms for the article:

• What is the mean time to send the 4 packets to the above web site?
• what are the port requirements for appneta appliances to connect back to the vox pathview cloud servers?
• voip ready check appliance
• voice Graph
• troubleshoot website blocking Paetec
• paetec communciations port blocking
• nec ux5000 choppy voice
• nec ux5000 calls drop every 15 minutes
• nec ux phone server garbled speech
• nec phones voip ready

connection is used up. Bandwidth The amount of data passing through a connection over a given time.
It is usually measured in bps (bits-per-second) or Mbps (Megabits
per Second). As a general rule, get as much as you can afford – and
the make sure you are getting it. Content Filtering On the Internet, content filtering (also known as information

filtering) is the use of a program to screen and exclude from access

or availability Web pages or e-mail that is deemed objectionable.

Content filtering is used by corporations and governments as part of

Internet firewall computers and also by home computer owners,

especially by parents to screen the content their children have access

to from a computer Dropped Packets Packets (i.e. small data “packages”) are occasionally dropped, or

lost, on the network for various reasons. For instance, two nodes

may be communicating at widely disparate transfer rates. TCP

packets are resent, UDP s are not. Hop In a packet-switching network, a hop is the trip a data packet takes

from one router or intermediate point to another in the network. On

the Internet (or a network that uses TCP/IP), the number of hops a

packet has taken toward its destination (called the “hop count”) is

kept in the packet header. ICMP Internet Control Message Protocol is a message control and

error-reporting protocol between a host server and a gateway to the

Internet. ICMP uses Internet Protocol (IP) datagrams, but the

messages are processed by the IP software and are not directly

apparent to the application user. ISP An ISP (Internet Service Provider) aka Carrier, aka Provider, is a

company that collects a monthly or yearly fee in exchange for

providing the subscriber with Internet access. Jitter The difference in latency from one packet to the next measured in

milliseconds. LAN A Local Area Network is a computer network that spans a

relatively small area. Most LANs are confined to a single building or

group of buildings. However, one LAN can be connected to other

LANs over any distance via telephone lines and radio waves. A

system of LANs connected in this way is called a wide-area network

(WAN). Latency In a network, latency, a synonym for delay, is an expression of how

much time it takes for a packet of data to get from one designated

point to another. Typically, latency is measured by sending a packet

that is returned to the sender. The round-trip time – measured in

milliseconds – is considered the latency. NIU A Network Interface Unit (sometimes called a network interface

device) is a device that serves as a common interface for various

other devices within a LAN , or as an interface to allow networked

computers to connect to an outside network. Ping Loosely, ping means “to get the attention of” or “to check for the

presence of” another party online. Ping operates by sending a packet
to a designated address and waiting for a response. The computer
acronym (for Packet Internet or Inter-Network Groper) was
contrived to match the submariners’ term for the sound of a returned
sonar pulse. Point to Point Point-to-point telecommunications generally refers to a connection

restricted to two endpoints, usually host computers. PSTN Public Switched Telephone Network is the world’s collection of

interconnected voice-oriented public telephone networks, both

commercial and government-owned QoS Quality of Service. Describes the ability of a e.g. router to prioritize

certain packets SIP Session Initiation Protocol is an application-layer control

(signaling) protocol for creating, modifying, and terminating

sessions with one or more participants. It can be used to create

two-party, multiparty, or multicast sessions that include Internet

telephone calls, multimedia distribution, and multimedia

conferences. TDM Short for Time Division Multiplexing, a type of multiplexing that

combines data streams by assigning each stream a different time slot

in a set. TDM telephone sets (often referred to as digital  sets)

differ from IP sets in that they do not go on a LAN s infrastucture

are compatible with analogue wiring schemes and can work on cable

runs oup to 1,600 feet. VPN (pronounced as separate letters) Short for Virtual Private Network,

is a private network that uses a public network (usually the Internet)

to connect remote sites or users together. VPNs use “virtual”

connections routed through the Internet from a company’s private

network , a remote site or employee. WIC WAN Interface Card is installed in a router and is the component

that a Internet T-1 will physically plug in to.

Incoming search terms for the article:

• China Internet network Latency
• china internet latency
• 73ms jitter
• lan saturation
• latency china internet
• nec networking glossary
• network saturation available bandwidth
• Router interface saturation
• saturasi bandwidth
• site available bandwidth saturation

Incoming search terms for the article:

• internet latency china
• DATA COMMUNICATINS BUREAU
• max latency for voip to china
• the target site is in a town just south of shanghai called hangzhou

Incoming search terms for the article:

• how stable is VoIP
• get over ex
• how much bandwidth do you need for nec aspire
• is voip ready?
• is voip stable?
• voip ready cable connection
• what a stable looked like
• what stable look like

Incoming search terms for the article:

• how to connect chinaroy ip pbx
• nec ux basic tdm
• nitsuko paging is choppy
• TDM sets
• voip and LAN wiring
• will nec ux5000 and cisco IP phones talk with each other
• xfactor volp communications

Incoming search terms for the article:

• voip ready check
• voip ready router
• nec voip qos
• nec qos
• UX5000 qos
• ux5000 voip qos
• QOS on Nec voip phones
• qos nec voip
• @ronek com
• qos for NEC vOip phones

Incoming search terms for the article:

• voip no latency
• latency to houston
• voip latency
• audio samples of voip latency
• sample voip project plan
• ping too high for voip
• ping times high for voip phones
• ping from a NEC ip phone
• ping communication voip
• ping communication enable voip

Incoming search terms for the article:

• 3M bandwidth
• nec voip codec
• low sound volume problem with g729
• is my network voip ready
• nec aspire codec
• nec aspire outbound quality
• nec aspire voip compression
• nec voip choppy audio
• nec aspire choppy audio
• paetec voip fax troubleshooting

Voice over IP performance is a function of:

a) Bandwidth

b) Latency

Both components have to be within a certain tolerance  in order to be usable and there are a multitude of factors that can adversely affect either. Many IT professionals who are first time VoIP-ers  often think that given enough bandwidth, you can do anything – including voice. This is only half true. A lack of bandwidth can cause latency, but an abundance of bandwidth is not a guarantee of a clear conversation. Of the two, latency is not only a show stopper, it is also the hardest one to find and correct because there are many causes that are often times not within your control. Figure 1 is a great example of a company with a bonded 6M T-1 connection with such erratic latency – and jitter  – that it is virtually unusable for

voice applications. In many cases like this, the most natural scapegoat is the carrier, however, in this case, hop 14 is the WAN side of the customer s router and hop 15 is a device behind it which implies a problem with the hardware. Here, the problem turned out to be one of the 4 T-1′s were in a permanent Admin Down  mode and needed to have the WIC replaced.

WARNING TO THOSE JUST GETTING INTO VoIP – Voice is real time  – using primarily UDP packets – and therefore much more affected by things like dropped packets, jitter and high latency than regular  data. If there are issues on your Internet connections with these items, you will probably not realize it unless you specifically – and continuously – test for it. Most carriers only guarantee bandwidth and NOT latency. Trust me, the CEO, CFO, Customer Service manager and Sales manager will get upset if the email server or Internet is a little slow, but they will absolutely FREAK if their phones don’t work.

Incoming search terms for the article:

• voip latency tolerance
• are you ready for VoIP
• are you voip ready
• a lack of bandwidth
• voip jitter and latency tolerances
• tagging udp packets
• nec ux5000 voip bandwith
• nec ux5000 network slow
• nec aspire udp
• nec aspire telephone voip