I wrote it to you above that the solution could be the codec
This echo is probably caused by caller system or ITSP. Changing codec usually not help much (i think they hope that compressing will remove echo).
Rosamilio I have found that VISP’s ( Voice ISP’s ) when there links get busy with calls, and they get to a certain bandwidth threshold,they will change the codec from a G711 codec to G729 compressed codec so they can carry more calls over the same dedicated link to meet the traffic conditions.
G729 = 8k compressed whereas G711 is base 64k
The more the calls are offered as G729, more chance you wil have trans-coding occurring and the echo at the start of the call.
Check the calls to see if G729 is occurring then you know it is a trans-coding call that is happening.
The current config does not have G.729 enabled at both ends; only PCMU is enabled.
I find this interesting as although voip,ms has multiple server options, I have all my systems, including my own, setup on one of them and only this client is reporting a problem.
Yes but natively there will be trans coding happening at one of the servers…
Can’t argue because I can only see my link between my UCM and the ITSP.
And again, why only for this one site…
ask the VISP if the link is connected to an impacted upstream route… only reason it can be different… maybe the server farm that this service is connected to is suffering bandwidth issues ergo the trans-coding…
Been doing lots of testing, including trying the G729 Codec. All to no avail; the echo persists on both in and outbound calls (during the first second or two of the call).
All other companies setup with this ITSP do not exhibit this problem.
The client’s IT guy informed me recently that he has setup their Fortinet router/firewall to use load-balancing; the client has two Internet connections - DSL from Bell and cable from Rorgers. Both have static IPs and we use DDNS on the UCM to set the DDNS IP.
This is definitely a different network setup that I have encountered before, and I am wondering it it may be part of, or the cause of, the echo.
Does anyone have experience with this? Any ideas?
yes…and the network is not the issue.
In an effort to learn/understand more, can you explain why you think it is not? And where would you look next?
I already have -
"Echo is either acoustic or from the telephone line (hybrid, line, near, far, etc.). Echo occurs at the analog level so it is not possible for SIP, being digital, to cause echo. It would be akin to getting your computer monitor to display two pictures, which in the analog television days was possible when the signal paths of a given TV station was reflected in some manner (building, cut in a cable) which allowed the signal to be received at the same reception point but at two different times and at two different signal levels.
So, if not acoustic, then it is somewhere in the analog realm where the SIP provider or, a path along the way, is reflecting back excess energy. Echo cancelers and suppressors can be effective, but alas you will likely have to contact the provider with some details about the given calls as I doubt there is much that you can do unless, using analog lines and then you can play the TX-RX and impedance settings. This is where the impedance matching comes into play when using the FXO ports of a SIP gateway.
I think it was Kev (Scottsip) who indicated the possibility that the timing in the first second or so and then going away is apt to be the time for the echo canceller to train and then kick in. I assume this to be a possibility.
Try a different provider as a test and please don’t go down the path of trying to compare as you did before as it is pointless. There might be some similarities in the name of the provider and the IP they use and the pbx equipment, but you nor I have any idea of any anything beyond that. Take a capture of a call and then send to your provider and have them explain it.
Capture call on GXP and on UCM.
PCM codec, then listen both, if you have.
Select only incoming stream and if you not hear receptionist there. If yes you have clear proof that echo is not generated on SIP based system (which is unable to do unless you have broken analogue handset).
Okay - from what @drostoker has stated the following is what seems to be experienced.
At random calls to the UCM via SIP from the SIP provider sometimes an echo is heard.
No matter what @drostoker tries to do at the telephone system end nothing changes - echo is heard
A caller from an unbalanced PSTN telephone line through their carrier to @drostoker’s SIP provider to the UCM via SIP causes echo
The SIP Provider performs echo cancellation to try and balance the call from the PSTN to SIP conversion and sometimes the echo training is not able to match the call quick enough ergo an echo is heard for the first 10 seconds of the call or so.
In this scenario there is nothing that can be done at the UCM - because the call does not hit the UCM as an analogue call it is received as a SIP call from the SIP provider.
Only way to have this resolved is to notify the caller that they need your services to convert their telephone line to SIP and sell them a service, or to notify your SIP Provider that they need to rectify the echo on their end.
At the end of the day you are the customer and are paying the SIP provider for a service - included in that is maintenance to cover diagnosis of issues like this.
This is not the UCM that needs to be fixed in the above scenario.
Ok, bow your heads…AMEN.
You may now return to your normal activities.
I had this article saved it is just an extract form it had the same problem with a GZP2170 at a site changed the handset and with another GXP2170 and the problem did go away. At least you with be trying what is in your control and can rule out the phone has being an issue.
The first source is referred to as sidetone . When you speak, your voice is looped back to you. This loop is purposefully designed into phone systems to improve the experience of speaking on a phone. As long as the sidetone is heard at the same moment you speak, you won’t perceive an echo. However, hardware problems in phone sets, lines, or software can cause the sidetone to be delayed, resulting in echo.
I think theoretically sip itself does not generate echo being packet based but echo is a reality on voip networks. If you out of options it with not hurt trying another handset .