Cell phone caller to my SIP ITSP connected Asterisk hear echo

I have an Asterisk 18.6.0 (although version is not really relevant as this has been happening for a while now, even prior to upgrading to 18) connected to an ITSP via SIP. Frequently remote parties complain about hearing echo on their end. Most recently it was my wife on her cell phone.

What I am most unsure about in this situation is where the echo needs to be dealt with. Is that something I need to tune Asterisk for, or is it a problem at my ITSP and their bridge to the PSTN? Or is the problem entirely with the caller, be it their phone, or their provider?

In a SIP environment, it is the responsibility of the phone to cancel the echo. VoIP delays are sufficient that echoes are objectionable so echo cancellation is always desirable, and the phone is in the best place to cancel echoes from your side. The ITSP should cancel echoes from the PSTN.

Using hands free can make echo cancellation very difficult, because the acoustic part of the echo path is complex, and potentially variable. Handsets are much easier to handle, as the echo path is mainly in the handset itself.

Echo cancellation in the network is quite CPU intensive, and is made more difficult by the serialisation and network delays between the phone and the echo canceller.

The phone being which phone? The phone on the Asterisk side of the call or the cell phone that was calling through the PSTN->ITSP to my Asterisk?

Again, I’m unclear which phone you are referring to.

Wait, you just said the phone is place to fix it. But above you are saying the ITSP needs to fix it. I’m utterly confused.

The SIP phone is responsible for echo cancelling echo between its speaker and microphone. The SIP to PSTN gateway is responsible for cancelling echo from the PSTN side. So the phone in this case the phone is the phone on the Asterisk side of the call.

There are two ends of a call, and both can produce echoes. The ITSP is responsible for stopping your user hearing echoes that arise between the speaker and microphone on the cell phone.

Echo cancellation isn’t needed on circuit switched connections, at least not within a continent, because the echo time is short enough not to be objectionable, unless it is very strong, as might be the case for a speaker phone, although they often use VOX, rather than echo cancellation. To work well the echo canceller needs to be as close as possible to the source of the echo.

It sounds like the ITSP is handling their echo cancellation responsibilities effectively, as your agent isn’t hearing echo.

(The only time that Asterisk would normally get involved with echo cancellation is when using DAHDI, as that is connected to circuit switched connections. Although you can use software echo cancellers for that, it is better to use interface cards that handle it. You are not using DAHDI, and if you were, it would be in the ITSP role, not the SIP phone role.)

VOX = voice operated switch, i.e the phone disables the speaker when it detects that the local user is talking.

The mobile network will also be doing some echo cancellation, as the air interface introduces delays large enough to cause problems. However, this should determine there is no echo to cancel, because the SIP phone should have already suppressed the echo.

However, if the mobile operator’s echo canceller does, wrongly determine there is an echo, it can end up introducing an echo by trying to subtract out a predicted echo that isn’t actually there. Unlike modems, which go through an initialisation sequence to calibrate the echo, voice calls require the echo to be measured based on whatever actually appears on the line. That means it is possible that the network confuses sounds that aren’t echoes with echoes, and tries to compensate for them. If that happens, one would expect the echo to reduce over time, as the network learns the real echo characteristics. However the network cannot do this too quickly, otherwise it would keep learning false echoes.

The echo canceller in the phone will also take time to learn the echo. Although it will do this quickly, it might be at a time when the cellular network canceller is also in a fast learning mode. Again, if this is happening, you would expect the echo to die off as the call progresses. Cellular network cancellers probably can’t deal the the long delayed echoes from VoIP, so they are not a substitute for the phone’s echo cancellation. If landline users never complain about echo, it is possible that the mobile network is the source of the problem.

Interesting. So you are saying that the echo is being caused on my end (where the SIP phone is local to my Asterisk installation), with my SIP phone.

So assuming that I have multiple SIP phones here locally where the Asterisk installation is, a remote party (i.e. remote to my Asterisk/ITSP/PSTN) that is experiencing hearing themselves should be able to notice differences if I transfer the call on my end among my SIP phones, assuming some of the SIP phones (or ATAs) have better echo cancellation than others?

Just trying to make sure I fully understand the problem.

I’d expect it to depend on the SIP phones, and also how they are used. You could monitor the outgoing side of the call only, with Monitor, or, I think some options on MixMonitor, or possibly even ChanSpy, to see if you could hear the caller’s speech coming back.

If you can’t it would have to be the cellular network learning a false echo.

One thing I should check. Some people have strange ideas like playing a constant music background on their agents. If you do something like that it might well frustrate the cellular network’s echo canceller training process and cause it to try and cancel an non-existent echo. There might also be situation which didn’t allow the phones to train their cancellers properly.

As I said, echo cancellers have to train themselves in a situation where they have to use heuristics to decide whether they are hearing an echo or a genuine signal from the other end. They are going to work best if there is silence, apart from the echo. I’m not sure how they do this. One way might be to assume that there is either silence or a strong signal, and disable the learning process when there is a signal. However they might also rely, to some extent on the signal not being correlated with the one being echoed.

For more information, see An overview on optimized NLMS algorithms for acoustic echo cancellation | EURASIP Journal on Advances in Signal Processing | Full Text and, in particular note the section on “double talk”.

So it’s kind of interesting. I have 3 different kind of SIP phones here local to the Asterisk side of the link.

One is an Android phone running the Linphone SIP softphone. When I use that as my Asterisk side SIP phone (calling to a cell phone through Asterisk, through the ITSP and onto the PSTN), there is an initial very short echo but it mostly goes away. I assume that to be Linphone’s echo cancellation learning and kicking in.

My second SIP phone is a Panasonic “Joip” phone. It is a consumer-grade cordless phone that has both a traditional POTS land-line connection connection as well as a SIP stack to connect to their (now defunct) SIP-service silo. The idea was that anyone with a Joip phone could call anyone else with a Joip phone for “free”. But it’s really just a phone with hard-coded SIP server addresses, etc. that can be fooled into connecting to one’s own local SIP server with some DNS and port-forwarding tricks on the local network. There is no echo with those phones, even initially. They are really quite good at suppressing echo.

My third SIP phone is a cordless traditional POTS phone plugged into a Linksys wrtp54g router/ATA. It’s horrible. The echo never goes away on it, despite it claiming to have G.165. and G.168 echo cancellation.

I’m suspicious of this finding though. Even if I activate the mute on the phone I still hear echo. Does that make sense? If the echo is suspected of being physical feedback between the earpiece and the microphone of the SIP handset, shouldn’t muting the mic on the handset suppress any echo?

Two wire analogue lines can have echoes if they are not properly matched to the hybrid, the device that combines the transmit and receive paths onto the same wire pair. In fact I don’t think it is possible to completely eliminate this, so the ATA needs to apply echo cancellation or echo suppression.

Also, muting will remove the acoustic part of echo that is being cancelled, so, until the canceller relearns, the echo, it will be adding in a counter echo that isn’t needed. As noted before, I’d expect such artefacts to go away over time, so it does sound as though the echo canceller is not working, or is being overwhelmed.

There is a slight possibility that the extra delay, introduced by DECT is taking the canceller over its limits, but I wouldn’t have thought the delay would be longer than natural acoustic feedback, and should only affect acoustic echoes.

I even tried setting the FXS input and output gain all the way down to -11 as suggested by another blog posting regarding echo on analog phones with Linksys/Cisco ATAs.

That didn’t seem to help.

Is it just really well known that ATAs (in general) suck at removing echo? Or do I just have a really bad ATA?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.