Or: Catering to expectations in Voice Over IP.
By Brian Boyko
Editor, Network Performance Daily
When you pick up the phone, do you hear a dial tone? Chances are, you probably don’t.
For most industrialized nations’ telephones, what you hear is a recording of a dial tone. And when you dial, you’re not hearing the ringing on the other end. You’re being played a recording of ringing. (And a good thing too – do you really want your embarrassing ringtone to be the first thing your boss hears when he calls you on your cellphone?)
The reason for this is because the telephone is one of the oldest technologies, and when people use a phone, they have a very reasonable expectation for how it should work. Step 1: Pick up phone. Step 2: Check for dial tone. Step 3: Dial the number, Step 4, wait for other end to pick up. Step 5, Converse.
While the “back-end” of the technology has changed dramatically during that time, from operators plugging in holes in a phone board, to automated switches, to cell towers, and today’s latest phone technology, VoIP, the front end remains practically unchanged. People have come to know what to expect from a phone over a century of practically Pavlovian conditioning. (Bell rings, pick up phone, get treat!)
(Continued…)
This can be somewhat problematic for VoIP rollouts because users have come to expect a certain level of consistent quality from their phone lines. The quality of a VoIP phone call can, if not properly configured, vary greatly depending on network traffic, server load, input level, number of hops, error rate, and many other factors. Even when there’s a bad telephone connection, users expect that that connection is consistently bad – VoIP can’t always promise that.
So call quality has to be tested somehow. Which again is a problem because ultimately, the quality of a call is a subjective measurement.
So the International Telcommunication Union did what any engineer does when faced with needing a hard number to measure something subjective. They took a bunch of people, asked them to rate a call from 1-5, and averaged the subjective responses together to get a pseudo-objective level of quality. This is called the Mean Opinion Score [MOS], and it is not to be confused with the Downright Ornery Opinion Score [DOOS].
Ranked from one to five, five being perfect studio quality, four being standard toll call quality where the imperfections are noticeable but not annoying; three being slightly annoying, two is annoying, and one is somewhere around “Gilbert Gottfried,” it does, at least, provide some way to compare different audio codecs and call quality. You can try ranking sounds for yourself at this site from the University of Miami.
Now, here’s the rub. Many codecs for VoIP can reach or at least come close to the 4.0 quality requirement of a toll call. G.711, at a whopping 64 kbit/s reached a maximum MOS of 4.3; AMR at a slimmer 12.2 kbit/s gets 4.14, G.729 manages to get 3.92 at 8 kbit/s, and G.723.1 manages to get 3.9 at 6.3 kbit/s.
This may all seem well and good, except that these scores are determined under ideal network conditions. They are, in effect, the maximum level of performance that you’ll get out of each of those codecs. Add a few server hops, a maxed-out link, an overworked server, misconfiguration, or your everyday miscellaneous network gremlin, and you can find yourself with an end-user experience that doesn’t match up to the MOS that you should be getting.
VoIP is a different beast than your typical data application. If a TCP/IP application has a few milliseconds of delay on it, well, the data gets there eventually, right? A VoIP application with a few milliseconds delay can cause significant annoyance to the end user. Call quality is much more finicky and that’s why you need networking equipment that performs well, with very low latency. And people just simply aren’t used to having problems with their phone service. Phones should work instantly, and work well.
The trick is to first make sure that you have correctly defined QoS policies for TCP (data) and UDP (VoIP) traffic; without segregating the two, you end up with UDP taking more bandwidth while TCP takes less when both go on the same link. Then you have to use your network monitoring tools to determine when and where call quality problems – only then can you start answering the “why” and come up with a solution.
Maybe the problem can be solved by tweaking the QoS policies. Maybe it can be solved by upgrading a router. But rather than wasting time trying to figure out what order to throw the chicken bones, say the chant, and light the candles, wouldn’t it be better to get the network voodoo to work the first time?
————–
More information:
On VoIP Monitoring
No comments yet.