login | register
Sat 17 of May, 2008 [10:20 UTC]

voip-info.org

Search with Google
Search this site with Google. Results may not include recent changes.
 
Google Ads
Shoutbox
  • Juan Ortega, Thu 15 of May, 2008 [10:33 UTC]: Hi everybody, I'm Juan, an ITCom student, and I need to know what basic elements I need to create a VoIP network. Can anybody helpme, please?,Thank you very much
  • gineta, Wed 14 of May, 2008 [03:58 UTC]: any here not fine the configuration of firewall juniper -screem for VOIP asterisk????
  • Anoop Prabhakaran, Tue 13 of May, 2008 [12:16 UTC]: I am developing Asterisk IVR, Whenever i make a internation call to the IVR system, the DTMF is not getting detected properly, this happens only for the first time, second call onwards system works fine. why this is happening
  • joe, Mon 12 of May, 2008 [04:27 UTC]: Is there an opensource browser based softphone, or a system like Busta where everything is not manages through their website?
  • Nick Barnes, Fri 09 of May, 2008 [11:36 UTC]: Christopher - yesterday I tried an Asterisk install on a CentOS 5.1 box with stock GUI and it all worked fine. Sorry I can't help.
  • aero, Fri 09 of May, 2008 [08:20 UTC]: can someone help me out on this, i tried to play some sound files on my asterisk box and this is the error message i got. WARNING[4429]: format_wav.c:169 check_header: Unexpected freqency 22050 May 8 11:17:39 WARNING[4433]: codec_gsm.c:194 gsmtolin_fra
  • Christopher Faust, Thu 08 of May, 2008 [14:15 UTC]: I beleive that I may have to change something in the xserver configuration. Please advise
  • Christopher Faust, Thu 08 of May, 2008 [14:14 UTC]: Everything was perfect. In the bios I have increased the memory allocated Still receive input not supported on my display.
  • Christopher Faust, Thu 08 of May, 2008 [14:13 UTC]: This would not be my main box. I am doing some testing to see if I can install zaptel and asterisk 1.4 on a full centos 5.1 box with development software Its bizzare, because before I went through the asterisk and zaptel installation everything was perfe
  • Nick Barnes, Thu 08 of May, 2008 [13:44 UTC]: Christopher - I can't see any way in which an Asterisk installation would muck your GUI, but remember that it is advised not to use a GUI on an Asterisk box anyway.
Server Stats
  • Execution time: 0.71s
  • Memory usage: 2.23MB
  • Database queries: 32
  • GZIP: Disabled
  • Server load: 0.78

Grandstream GXP-2000 - Solving Echo Problems


Grandstream GXP-2000 - Solving Echo Problems

written by thetatag on 12/16/2005

What follows is a message sent as part of ongoing communications between myself and Grandstream and is the result of exhaustive testing on my part. A summary appears at the bottom for those who want to skip the subtle technical details and information on how this conclusion was reached. As this information is being reviewed by Grandstream engineers, I would greatly appreciate any comments or testimonials as to the effectiveness of this technique in your own systems. Thank you. - thetatag


Here is what I can tell you about the echo problem commonly noticed in the GXP-2000, and one of the worst problems noted. Some background is needed, so please bear with me.

I have a PRI being delivered over hDSL from the local telephone company. It is attached to Digium hardware in my Asterisk PBX. The Asterisk PBX connects to a 10/100 Ethernet switch which then connects to several GXP-2000's. (It is rare to see more than four in use at one time, though.) No other Ethernet traffic except NTP hosted by the Asterisk server exists on that private LAN.

Because the PRI is delivered via hDSL, which is becoming quite popular when the termination point is within engineered range of the wire center, the PRI signals are generated only three of four feet from the Asterisk PBX. (Yes, this is very important.) This produces a virtually 0dB loss in each direction on the PRI circuit, and the hDSL circuit is not subject to loss along its data path.

Having said that, the Asterisk PBX was originally configured with a 0dB loss between itself and the telco, which is correct. The receive and transmit gains were set to 0.0 as well within Asterisk. Through extensive testing with the telco's 1008Hz milliwatt tone and a loopback into Asterisk's similar tone, the 0.0 receive and transmit gains were determined empirically to be optimal. The echo cancellers worked perfectly when we used POTS analog phones connected to a Digium FXS card.

The only problem occurred when the GXP-2000 was used. And this was not consistent. Some calls would have terrible echo, and on others, the echo would be minimal. I went though no small amount of work tweaking every conceivable option on both the Asterisk SIP and Zaptel channel drivers and the GXP-2000 (excluding configuration options that just HAD to be a certain way for our use, of course). Nothing worked, although some changes mitigated the situation.

''Time passes.''

We have been comparatively echo-free for a few days now. As I studied more and more the problems the echo cancellers on Asterisk were having with calls originating on your phones (understanding that the echo cancellers are pointed towards the telephone lines and are not available on the SIP channels), I decided to try another tweak. I ignored empirical test data on appropriate receive and transmit gains and set them as follows: Receive gain was set to -6.0 and Transmit gain was set to -15.0. Keep in mind that this is on the Zaptel (telephone line) channel. The transmit gain is how much gain the voice coming from the GXP-2000-initiated call receives as it is passed to the PRI, and the receive gain is how much gain the signal FROM the PRI is given prior to being passed over the SIP channel to the GXP-2000. (I believe these are scaled in decibels, but I have not verified that.)

With our configuration, a -6.0 receive gain and a -15.0 transmit gain is rather huge, as again, both should be set to 0.0 due to a lack of virtually any line loss. Once the outbound audio was no longer clipping and the signal was in the appropriate range, the echo cancellers could do their job (quite well) and our echo virtually disappeared. However, at the same time, our non-SIP phones attached to the Digium FXS card had to have their configuration altered to compensate for these gain changes, or else the conversations on calls over the PRI would sound extremely quiet in them.

What this tells me is this: The gain is too high on the GXP-2000 causing a myriad of echo problems on many production environments that rely on any sort of echo cancellation (which does not work with a clipping or distorted audio signal). Ideally, I should be able to correctly set my PRI channel gains to 0.0 and not have the GXP-2000 peg the VU meter when I talk at a normal phone volume (and I'm not a loud speaker on the phone).

The reason, in my opinion, that the echo initially did not occur on some calls and was overpowering on others is that there should be no echo (except, perhaps, acoustic) on a digital line. So our calls to other digital lines would not produce a clipped and mildly distorted echo that could not be compensated for by the echo cancellers.

In my understanding, there is no way to control the microphone gain (or audio level in subsequent digital processing that is then sent digitally) on the GXP-2000. Rumor online has held that the speaker/handset volume control also adjusts the microphone gain, but I have not tested that, and it would seem to be a thoroughly bad idea. A configuration option to adjust gain would be useful, but the current system seems to have the gain locked at a non-optimal level.

What follows are some suggestions that may help or eliminate the echo problem:

  • Reduce the microphone gain by about 6dB or, better yet, make it adjustable from the web configuration and possibly on-screen display.

  • Implement a slow-tracking microphone AGC or compressor with a narrow gain range to limit microphone audio gain to the optimal level.

  • As part of the last item, detect audio clipping conditions and round out distorted waveforms. (Implemented correctly, this should have minimal processor overhead.)

- thetatag


SUMMARY

This information is useful only for eliminating echo with the GXP-2000 and does not cover techniques for eliminating telco-circuit or acoustic echo.


Extensive testing has indicated that the worst echo problems with the GXP-2000 are associated with an excessive gain level within the phone itself, creating overmodulated, clipped, and mildly distorted audio waveforms that inhibit the correct functioning of software echo cancellers.

What follows are some suggestions to mitigate this problem while Grandstream works on correcting the problem in the phone or its firmware.

  • Set up the optimal rxgain and txgain for your Zaptel channels. See Asterisk zapata gain adjustment for more information. Important: Use the first method presented for the most accuracy. Call your telco if you need the 1000Hz milliwatt test number.

  • Set up your echo canceller. You can find information on how to do this at Asterisk echo cancellation. Personally, I have had excellent success with the MG2 echo canceller (#define ECHO_CAN_MG2 in Zaptel's zconfig.h). In Asterisk's zapata.conf file, I am using echocancel=256 (although 128 would probably suffice for most installations), echocancelwhenbridged=yes and echotraining=800 (although somewhat less may work in most cases).

  • Make test calls and observe the echo. Call local, long distance, international, cell phones, digital lines, POTS lines, etc. See how the echo behaves.

  • Edit zapata.conf and drop the rxgain down by 6 and the txgain down by 15 from whatever their existing numbers. (If you have POTS phones attached to your system, you may need to compensate on those channels, keeping in mind that extension-to-extension calls will be effected.)


Needless to say, throwing the gains around on the telco connection is a hack to get around gain issues with the GXP-2000. And one can immediately see how it could have negative effects on extension-to-extension (POTS to POTS or SIP to POTS) calls. Still, for anyone who has experienced the infamous GXP-2000 echo problems, these gain adjustments are many times better than living with the echo.

- thetatag

Please enter feedback and comments below.


References:


See also:




Where to buy



Created by Robert Christian, Last modification by Jonita Prifti on Tue 27 of Nov, 2007 [16:10 UTC]

Comments Filter

Stating the obvious

by coleman on Tuesday 06 of November, 2007 [19:54:09 UTC]
At the risk of seeming stupid, one of my clients complained about the echo on the phones when calling another extension
It turned out that the other extension was just a few feet away and they were hearing the audio from across the room as well as though the phone. The problem was completely resolve by using good headsets.

Henry

Speakerphone sounds tinny

by coleman on Tuesday 23 of October, 2007 [18:24:45 UTC]
Many people complain about the quality of the GXP 2000 Speaker Phone.
The main reason is that the speaker itself is of poor quality, however if you want to void the warrantee
then open up the phone (4 screws on the back) and place a thin (1/4 inch) foam rubber about 2" x 3"
on top of the magnet of the speaker. Carefully put the base on making sure that the foam doesn't restrict the hook switch movement.
Screw it back up and ViOla !!
The foam helps the acoustics by dampening unwanted resonances (much like a hi-fi speaker encloser)

Henry
   

 
 

Speakerphone sounds tinny

by coleman on Tuesday 23 of October, 2007 [17:54:35 UTC]
Many people complain about the quality of the GXP 2000 Speaker Phone.
The main reason is that the speaker itself is of poor quality, however if you want to void the warrantee
then open up the phone (4 screws on the back) and place a thin (1/4 inch) foam rubber about 2" x 3"
on top of the magnet of the speaker. Carefully put the base on making sure that the foam doesn't restrict the hook switch movement.
Screw it back up and ViOla !!
The foam helps the acoustics by dampening unwanted resonances (much like a hi-fi speaker encloser)

Henry
   

 
 

Gain -- Ahhh

by Keith Smith on Wednesday 22 of February, 2006 [05:42:02 UTC]
I've noticed this on the Budgetone also. Our biggest echo issue is with the speakerphone. It is atroicious for the folks on the other end of the call, to the point of a headache. Do not see this with the Sipura/Polycom phones at all.

Could one do something with a cap,coil, or resistor inside the phone on this? I'm trying to remember but old phones used a loop thru the speaker and the mike w/ high impedance. I'd guess modern phones handle this a bit differently, but the "standard" handset should still be expecting the loop, and the speakerphone should be on a similar loop.

by Paul S. Chase on Thursday 22 of December, 2005 [20:56:07 UTC]
PBnJ Consulting pointed this little gem out to me...

Some further research into this matter seems to back up the thinking that led us to this conclusion, namely that there is a drifiting synchronization problem with the two asterisk servers: Recently a new configuration option was added to the IAX configuration file, namely:
 trunktimestamps
Set this feature to "yes" to cause the two sides to send timestamps with each IAX frame to ensure both sides stay in synch.

How Interesting...

by Paul S. Chase on Monday 19 of December, 2005 [14:33:38 UTC]
In our enviroment, we have 2 pri's directly connect to our asterisk server with approx 130 Grandstream GPXs. All GXPs are connected to 10/100 switchs and then to a core 1gig switch. The Asterisk server is also connect to the 1gig switch. Our echo issues is only on the INSIDE. External callers do not hear the echo, only the internal callers. There is also an echo at times station to station. We have been messing with the network to eliminate echo at night when there is no traffic.

I agree that the echo is mostly due to something in the GXP. Please keep us up to date with your discussion with Grandstream on this issue.

If there is anything I can do to help let me know. pchase {at} imtco {dot} com

Please update this page with new information, just login and click on the "Edit" or "Add Comment" button above. Get a free login here: Register Thanks! - support@voip-info.org

Page Changes | Comments

Sponsored by:

Terms of Service Privacy Policy
© 2003-2008 VOIP-Info.org LLC

Powered by bitweaver