To continue reading for free, register below or login
To read more you must become a member of SearchUnifiedCommunications.com
Very methodically. The earlier question about security relates to echo and for those deploying encrypted VoIP, pay attention. Encryption means more latency because it requires more processing. But let's look at echo from the premise of a new VoIP network. From the ground up, you must evaluate your infrastructure. It all matters. To illustrate: Cabling for example, may reveal your drops are excessive in distance which is common. Minimizing potential latency by centrally locating your closets and risers are key to minimizing wiring expenses and the lengths of cables. Connected to those cables are managed switches and not hubs or split pairs to get two data connections for the price of one cable because you've just violated the managed cable plant. Switches need backplane bandwidth and plenty of it along with processing power. Past the switches you have connectivity to other switches and closets -- for those with copper, STOP! Copper is noisy and invites latency.
This is where fiber shines. We interconnect switch to switch in the same closet with fiber for a couple of reasons -- one, any electrical disturbance from the copper plant will remain on that one switch and not traverse to other switches and secondly, it's clean, fast and reliable. Sure, it costs more too but I have infinitely less issues. Then, we do the same between closet to closet using fiber -- not copper -- as the transport. Your fiber components may need checking too, to ensure that your cards/modules/interfaces support the overall distance of your fiber runs. Moving towards the data center you have routers, firewalls, servers and other goodies in place. We haven't even gotten to echo yet. Point I want to make is the same as before -- the infrastructure must be right. Can you measure it? YES! Network assessment first, not after you encounter problems. Network assessments will uncover what's hidden from the site surveys.
Now for echo -- you need to identify who is getting echo and when/where. A common echo issue occurs with POTS, FX (foreign exchange or Metro services) and analog services. The longer the loop, the higher the loop current, and the higher the loop current, the more prone your IP system becomes to echo. Echo is also a result of poor interoperability between gear. There's a lot to be said for standardizing on hardware because what goes on between the gear of different manufacturers are different buffer sizes, codecs and processing capabilities.
How do you fix echo? Again, it's methodical. Standardization is a good thing and good place to start. (Standardization: in the sense of adopting one manufacturer of your liking and increasing the odds in your favor.) Then, avoid inserting loss into cards; or station, line or trunk options because this can produce other issues. Narrow down and isolate where, when and who is experiencing echo first. Look for impedance mismatches in analog gear and settings because a 300 ohm loop optioned for 600 ohms isn't going to play right.
Sometimes, it's the simpler things of life like turning down your headset volume or your handset. There are still customers and users that sneak in HUBS. HUBS are geat producers of echo. For the very small applications in softphones and VoIP services, there are numerous adjustments in the supporting applications, and knowing/finding the right ones beckon attention. Echo cancellation is great and applying it universally may reap other calls for help. Many folks think echo cancellation applies only to phone systems and big gear found in call centers, but it does not. Even your devices -- headsets, USB phones and devices used for voice -- need to have echo cancellation and understanding their settings requires putting skin into the game. Narrow it down then, apply changes and begin testing, testing, testing to eliminate echo, echo, echo. It's a bugger bear of a problem to have and encounter head, but not impossible.
|
