Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
VOIP echo
- Thread starter MJ6
- Start date
There are two liekly possible sources of problems
1) Problems with the echo cancellors in your VOIP gear. Unless this is v ersion 1.0 device this is highly unlikley.
2) The usual source of problems is when there is too much packet loss. If there is significant packet loss the echo cancellors often cannot do thier job.
Manufactuers find that customers typically assume the problem is #1, but more often than not it is #2.
So, have you designed end-to-end QoS into the system? Or are you taking the "if I throw lots bandwidth at it, it may work" approach?
If you are taking this latter approach, then don't be surprised by the echo, it's just one form of problem that can occur when you try to use a packet based network for work better suited for a circuit switched network.
If you have designed QoS into the system double check that first. And check for end to end error performance. If that all checks then check with your vendor.
Let us know what you find.
Good luck.
1) Problems with the echo cancellors in your VOIP gear. Unless this is v ersion 1.0 device this is highly unlikley.
2) The usual source of problems is when there is too much packet loss. If there is significant packet loss the echo cancellors often cannot do thier job.
Manufactuers find that customers typically assume the problem is #1, but more often than not it is #2.
So, have you designed end-to-end QoS into the system? Or are you taking the "if I throw lots bandwidth at it, it may work" approach?
If you are taking this latter approach, then don't be surprised by the echo, it's just one form of problem that can occur when you try to use a packet based network for work better suited for a circuit switched network.
If you have designed QoS into the system double check that first. And check for end to end error performance. If that all checks then check with your vendor.
Let us know what you find.
Good luck.
mj6 - this problem may not even be 'caused' by the voip gear (well, not intentionally).
afaik, many circuit switched calls that have echo have such a low delay in the echo that the sound is dismissed as sidetone. As delay increases, PERCIEVABLE echo increases. I bet you probably have enough additional latency in your packet based voice network that your users are seeing/hearing the echo more than they used to. Like ISDNman said, make sure you've got some QOS configured to reduce latency if at all possible.
Sometimes echo cancellors have to 'converge' (learn the echo characteristics of a call) before they can be effective - that would explain echo at the beginning of a call, but not the rest of the call. Hope that helps.
afaik, many circuit switched calls that have echo have such a low delay in the echo that the sound is dismissed as sidetone. As delay increases, PERCIEVABLE echo increases. I bet you probably have enough additional latency in your packet based voice network that your users are seeing/hearing the echo more than they used to. Like ISDNman said, make sure you've got some QOS configured to reduce latency if at all possible.
Sometimes echo cancellors have to 'converge' (learn the echo characteristics of a call) before they can be effective - that would explain echo at the beginning of a call, but not the rest of the call. Hope that helps.
rtfm dude,
Been a while since I've seen you on these forums.
you are correct. The "cause" of the echo is most likely the hybrid connecting to the far end 2-wire POTS line.
And you are also correct that the latency causes the echo to become unmasked due to the delay.
But exactly because of the increased typical delay in VOIP systems the equipment included echo cancellers. The are nearly never present in non-VOIP system, but are an important aspect of VOIP systems.
QOS won't necessarily reduce the delay (generally not, though certain service include delay as part of the SLA) but losts packets will definitely increase convergence time.
Failure to ever converge (e.g the echo remains instead of disapearing) could be due to lost packets. QOS will definitely solve the lost packets problem.
cheers
Been a while since I've seen you on these forums.
you are correct. The "cause" of the echo is most likely the hybrid connecting to the far end 2-wire POTS line.
And you are also correct that the latency causes the echo to become unmasked due to the delay.
But exactly because of the increased typical delay in VOIP systems the equipment included echo cancellers. The are nearly never present in non-VOIP system, but are an important aspect of VOIP systems.
QOS won't necessarily reduce the delay (generally not, though certain service include delay as part of the SLA) but losts packets will definitely increase convergence time.
Failure to ever converge (e.g the echo remains instead of disapearing) could be due to lost packets. QOS will definitely solve the lost packets problem.
cheers
isdnman,
yeah - it's been awhile. I finally have some time to 'slack off' and help out.
I agree with most of your comments, but I seem to remember that part of a modem answer tone includes a phase reversal at the end which turns off echo cancellers in the circuit switched path('cause modems have built in ecan) - can you comment on that?
thanks!
yeah - it's been awhile. I finally have some time to 'slack off' and help out.
I agree with most of your comments, but I seem to remember that part of a modem answer tone includes a phase reversal at the end which turns off echo cancellers in the circuit switched path('cause modems have built in ecan) - can you comment on that?
thanks!
Good to have you back.
Yup, you are 100% correct. Modems have much more sophisticate echo suppresion so network error suppression is tunred off as you describe.
It is interesting. I worked on a modem project where the worked on most calls, but never on call on the AT&T network. I can't recall what we had to do to fix it, I think it was a timing thing.
On ISDN there are two different calls type for interworking to the voice network. The "3 kHz audio mode" is supposed to have echo suppression disabled and is also supposed to remain digital to the far end office.
The "voice mode" get treated exactly as any other voice call once it hits the network.
At least that is how it is supposed to work, but in our experience it seems to make no difference. Then again most of the network is digital anyway, and we do the phase reversal process as you describe.
Cheers
Yup, you are 100% correct. Modems have much more sophisticate echo suppresion so network error suppression is tunred off as you describe.
It is interesting. I worked on a modem project where the worked on most calls, but never on call on the AT&T network. I can't recall what we had to do to fix it, I think it was a timing thing.
On ISDN there are two different calls type for interworking to the voice network. The "3 kHz audio mode" is supposed to have echo suppression disabled and is also supposed to remain digital to the far end office.
The "voice mode" get treated exactly as any other voice call once it hits the network.
At least that is how it is supposed to work, but in our experience it seems to make no difference. Then again most of the network is digital anyway, and we do the phase reversal process as you describe.
Cheers
- Thread starter
- #7
Thanks for your help guys. Thought if I give you the 'full picture' you might have some more ideas of the likely cause-
We have a QSIG link between our MD110 PABX and the Cisco Call Manager. All IP PSTN o/g calls are handed off to the MD110 to process and this is where the echo is intermittently happening. PABX calls are fine.
We have a QSIG link between our MD110 PABX and the Cisco Call Manager. All IP PSTN o/g calls are handed off to the MD110 to process and this is where the echo is intermittently happening. PABX calls are fine.
MJ3
By intermittenly due you mena the echo comes and goes within a call? O fthat soem calls exhibit it and others don't.
If the latter, see if multiple calls to the same number (preferably a home or very small business number that is NOT on a hint group) give the same amount of echo.
If th eformer, I'd gues there is problem with corrupt ot lost packets. Is the IP link used for other IP traffic other than the phone system? Id there a QoS system in place? If so, does the voice traffic have the highest QoS.
best of luck
By intermittenly due you mena the echo comes and goes within a call? O fthat soem calls exhibit it and others don't.
If the latter, see if multiple calls to the same number (preferably a home or very small business number that is NOT on a hint group) give the same amount of echo.
If th eformer, I'd gues there is problem with corrupt ot lost packets. Is the IP link used for other IP traffic other than the phone system? Id there a QoS system in place? If so, does the voice traffic have the highest QoS.
best of luck
mj6,
ok - the easiest thing to do is to check the voice port of the gateway that ties to the MD110 and max out the echo-canceller length. Since the cause of echo is always analog, you can be assured that the echo is not being introduced in your packet network, nor the digital tdm link between the voice gateway and MD110. If you've got a PRI to the LEC too, then you can rule that out.
Alas, though we do not -cause- the echo, we are responsible for cancelling/suppressing it. If the IOS on your gateway is relatively recent, I believe ecan can be extended to 128ms, which takes care of just about everything.
Lost/late(a packet that is late is discarded) packets do not cause echo. They cause drops in audio, which your codec (since you're using callmanager, probably g711 or g729) must attempt to compensate for. A packet stream with a consistent delay(but not loss!!!) will make any existing echo more prevalent, like ISDNMan(superhero?) and I discussed above.
Also, some echo is uncancellable(at least with the software ecan in the voice gateway) - you may have to live with -some- echo, though by all means it should not be significant. I would have your users write down the numbers/time that give 'em echo, maybe you're calling a rural exchange that still has lots of analog? International calls? Satellite?
This is a great echo doc:
something more troubleshooting-centric:
paper on the enhanced ecan (128ms thing):
ok - the easiest thing to do is to check the voice port of the gateway that ties to the MD110 and max out the echo-canceller length. Since the cause of echo is always analog, you can be assured that the echo is not being introduced in your packet network, nor the digital tdm link between the voice gateway and MD110. If you've got a PRI to the LEC too, then you can rule that out.
Alas, though we do not -cause- the echo, we are responsible for cancelling/suppressing it. If the IOS on your gateway is relatively recent, I believe ecan can be extended to 128ms, which takes care of just about everything.
Lost/late(a packet that is late is discarded) packets do not cause echo. They cause drops in audio, which your codec (since you're using callmanager, probably g711 or g729) must attempt to compensate for. A packet stream with a consistent delay(but not loss!!!) will make any existing echo more prevalent, like ISDNMan(superhero?) and I discussed above.
Also, some echo is uncancellable(at least with the software ecan in the voice gateway) - you may have to live with -some- echo, though by all means it should not be significant. I would have your users write down the numbers/time that give 'em echo, maybe you're calling a rural exchange that still has lots of analog? International calls? Satellite?
This is a great echo doc:
something more troubleshooting-centric:
paper on the enhanced ecan (128ms thing):
Rtfmdude writes:
"maybe you're calling a rural exchange that still has lots of analog? International calls? Satellite?"
Exactly what i was thinking.
ON such lines there will be more leakage, but it won't necessairly be noticeable unless there are delays (including satellites or IP connections).
The level for echo to be annoying to users is a fucntion of delay. It is called "TELR" for talker echo loudness rating.
VOIP adds a minimum of about 10 msec delay for pacektization. Many codecs add delay as well. And of course actual transmission can cause delay. But you can see from the above that adding 10 msec alone could make several dB of change in the percieved echo.
Don't forget, 3 dB increases represents a doubling in volume.
"maybe you're calling a rural exchange that still has lots of analog? International calls? Satellite?"
Exactly what i was thinking.
ON such lines there will be more leakage, but it won't necessairly be noticeable unless there are delays (including satellites or IP connections).
The level for echo to be annoying to users is a fucntion of delay. It is called "TELR" for talker echo loudness rating.
VOIP adds a minimum of about 10 msec delay for pacektization. Many codecs add delay as well. And of course actual transmission can cause delay. But you can see from the above that adding 10 msec alone could make several dB of change in the percieved echo.
Don't forget, 3 dB increases represents a doubling in volume.
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question