I would like some help regarding the following. Some customers dialing into a 5300 experience severe echos that the input gain won't help. Other customers don't have this problem at all. Does anyone have any idea why the differences.
In our own office...using a headset with our phones and dialing into a 5300...we get extremely good quality....using the handset we get extreme echos. The input gain can't come close to solving the problem. These are loud echos....an input gain of 24 ms just makes it bad for people at home who dial in using a regular home phone....and 32 milliseconds makes it bad for everyone.
Does anyone have any idea on why this problem would exist....doesn't happen using sprint or at&t....just happens when we dial into the 5300 to make our calls. In all cases the pbx is not connected to the 5300 with a tie line.
Some of our residential customers have to purchase a newer phone to resolve echo problems. Adjusting the input gain might fix echo for some people....but introduces it as a problem for others. Echo for residential customers using pots....no pbx is a problem for a small number of people and usually not severe.
Sometimes I can call an area code and nxx and get an echo....happens all the time. Calling another area code with an nxx nearby...never any echo. What gives? Why would one area have echo always and an adjacent area....same area code....same city....just a different nxx never have echo? Why the seeming inconsistency?
I have the exact same problem using the CP7960's when dialling certain area codes in the UK and the symptoms are very common for international calls. I am using a 5300 as the VoIP gateway with Call Manager 3.07.
As well as echo, certain calls suffer from severe clipping of words and speech sometimes comes across as digitised.
I can only offer a suggestion with the clipping. We had one isp whose customers had bad clipping. He used a 5300 with the fast interface set to auto for speed in a switch, and a 3640 with a 10mb interface in the switch. The 3640 was used for routing the calls over a dedicated point to point t1 connection. We set the speed to 10mb...full duplex because of the brand of switch he was using and put an input queue and ouput queue on the fast ethernet interface. The clipping went away. Instead of dropping packets, it was able to hold them in a queue.
Do a show interfaces command for the ethernet ports and look for anything suspicious...input errors, crc and framing errors, deferred, collisions....all of which would indicate something amiss. All of the clipping went away.
Clipping can occur at the start of words in a sentence if vad is on. The problem is, you have to be a bat to detect it. We use vad on all of our 5300s on our network. So far, out of several thousands of people....only 1 person has mentioned the clipping.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
[toc:faq]CUCM Database Replication is an area in which Cisco customers
and partners have asked for more in-depth training in being able to
properly assess a replication problem and potentially resolve an issue
without involving TAC. This document discusse...