Back in the day before the Real Time Requirements of Voice and Video all we needed to worry about was Bandwidth. If there was enough everything worked the way it should. If there wasn’t enough, you could deploy some technologies that may help prioritize data that would provide a group of users with a better user experience. And if that didn’t work you bought more bandwidth.
Enter the Unified Communications Era – Voice, Video, Data and who knows what they’ll think of next, all running over the same network.
Delay, Jitter, Packet Loss, Bandwidth and contention from other applications are all things one needs to consider when managing these new multi-service networks.
As Network Managers we have always been cognizant of the user experience. For applications like telnet the appearance that your characters were being echo’s back to you immediately was important, even if they weren’t it was the user experience that mattered.
The quality of a phone call though is something that can’t really be measured scientifically. We attempt to measure using MOS scores based on the Delay, Jitter and Packet loss, but these don’t actually measure the users experience. One person may say the call is good while another says not so good. That same person may be biased based on their mood.
Recently we have been trouble shooting a customer with Echo problems. The difficulty here is that we receive a report of an echo problem at a site with little to no information on the Called Party, Calling Party, who heard the echo, was the echo constant, was the echo loud, what type of delay in echo was experienced, was there a headset in use, was it a conference phone, speaker phone? This is not to blame anyone, as the user is not expected to know that these items are important.
I came across a really good article while searching on a solution for this issue, and while most of the information I already knew it really helped us solidify the source of the issue. I will also say that our team of technical staff did a great job in implementing echo cancellation technologies that has ultimately solved the problem – albeit by masking the echo. I’d like to share some of the highlights of this article.
Bits do not leak, so you can disqualify the digital segment of the system
As long as VoIP calls continue to be terminated in analog tails, echo will be a problem. One major obstacle to widespread VoIP implementation is that many tail circuits have preexisting delays that will become noticeable only when service providers introduce digital segments to the networks.
Because of the fundamental delays associated with VoIP technologies, existing echos will be more annoying than with TDM, and even the normal operation of an echo canceler will be more apparent. Customers of VoIP networks need to be educated to expect the standard echo canceler operation previously described so that they do not confuse these types of echos with abnormal echos. Abnormal echos persist throughout a call and do not fade.
These problems will gradually be solved as digital networks extend out toward homes and telephone endpoints. Until then, how much echo can be expected? One call in 50? 100? 1000? Even if customers are trained to complain only when an echo problem is persistent and repeatable, a service provider cannot hunt down and destroy every echo complaint. No one has sufficient resources to do this task, and hunting down an echo is a necessarily intrusive process.
The challenge is to determine when an echo complaint is both solvable and worth solving. You know that the echo source is in the destination tail circuit. For an echo problem to be solved, the tail circuit needs to be accessible.
Even after the deployment of Echo Cancellation, there is still a Echo when the call is first answered, as the Echo Cancellation Mechanism must get some real data before it is able to effectively stop the echo.
So in short the real answer is to use all digital circuits. Other echo issues are sometimes related to the phone set itself. Lower end phone sets tend to have cheaper components and are not as good at isolating the microphone from picking up sound that has leaked from the speaker.
Document Source: http://www.cisco.com/en/US/docs/ios/solutions_docs/voip_solutions/EA_ISD.html#wp1042222