A500 with HWEC gives occasional echo...*resolved!*
Submitted by Chrism2 on Wed, 02/27/2008 - 2:01pm.
Hi folks, I'm appealing to anyone who might be able to suggest something to help us fix our Sangoma a500 BRI (UK ISDN 2e) installation.
Basically we have a site with two ISDN 2e NTs (four channels, I think?) hooked up to a Proliant Server with an a500 card in it. The a500 has HWEC. We are using latest Wanpipe drivers and from what we can tell, everything is the way it should be; everything is working. Except we are getting occasional echo; most notably on calls coming from and going to analogue phone numbers. All the calls I have made to mobiles and digital phone systems have been perfect.
We originally had a box here with a Digium card in it with it's own HWEC. The customer complained of echo, so we went with what we know; Sangoma. No other site we have Sangoma kit in gives us any bother. This is our only BRI site with Sangoma, however.
We have updated the firmware in all of the Linksys SPA-922's we're using - even tried an Elmeg from a site with no echo.
We've gone as far as buying a new a500 and trying that in a new server, built from scratch. And still the echo returns.
Worse still, Sangoma, who have been commendably attentive, have got nowhere with their own tests. They too, are stumped.
I would greatly appreciate any advice on this problem as we're really scratching our heads with it!
The same problem here...
Thu, 03/06/2008 - 9:26am
Hello, Chrism2. I know it does not help you at all, but we have the same problems here (SPAIN). We have A500 PCI-Express with 2 double BRI modules TE mode (8 channels) on a Dell PowerEdge SC440. These echo problems are quite random and very difficult to trace. Unfortunatelly, they are frequent and very unconfortable for the user.
Our customer has reported us that it happens calling/receiving calls to/from analog lines and to/from ISDN lines. We have tried to call the same number again when we detect echo and sometimes the echo dissapears completely and sometimes does not. In other ocassions, we hear ourselves for less than a second and the echo dissapears. When everything works correctly sound quality is brilliant and clear. Of course, we have verified that the echo canceller is correctly loaded and configured. :D
The remote side (analog or ISDN) does not hear echo at all, the echo is always on SIP Phones. We are using Thomson ST2030 with the lastest firmware, 1.59 (updated today)... We have tried unsuccessfully to reduce the mic gain level (it seems that there is no way to reduce it through the Web GUI). Have you tried that on your linksys?
We have tested to change the TX_gain level on Woomera.conf without success... We have sent some binary log dumps of the echo canceller chip to Sangoma Technical support Team two weeks ago but no answer for the moment... :O
BTW, Sangoma has released today a new Wanpipe driver revision 3.3.2.p12b... I'll give it a try once again...
Regards,
Rhawk1
New drivers
Thu, 03/06/2008 - 9:32am
Thanks for replying!
I got an email from Sangoma last night about the release of new drivers. I don't have time to check at the moment, but I presume this is them. Konrad from SGA mentioned in his email that there was a timing issue which could have resulted in echo. Here's hoping that this is the fix for both of our problems! They certainly sound similar.
WanPipe 3.3.2.p12b drivers and ST2030 1.59 firmware applied
Thu, 03/06/2008 - 10:00am
Hello, I have upgraded Wanpipe drivers to the new 3.3.2.p12b revision and our ST2030 phones to 1.59.3 firmware. Our office is currently closed at the moment, so it is quite difficult to test our echo problems right now. I will post whatever it happens tomorrow morning. I hope it works... our client is really tired of this and it requesting us another solution (an external SIP ISDN Gateway)
Thank you very much for your quick response,
Rhawk1
A500 HWEC and echo...
Mon, 03/24/2008 - 8:36am
Just to inform you, we had the same results with wanpipe 3.3.2.p12b. No changes at all, echo appears spontaneous and randomly. We have installed 3.3.2 2008-03-13 release today to see if something changes, as always.
Anyway our client is absolutely fed up of waiting and we'll change the card to another ISDN interface with HW Echo canceller, maybe Digium B410P? Can you please give us any advice?. Do you have any well tested ISDN card/gateway with echo canceller that we could use?
Thank you very much,
Rhawk1es
Echo, echo..
Mon, 03/24/2008 - 9:01am
I spoke with Konrad at Sangoma online a couple of weeks back and I got the impression the release you have tried does *not* include a timing fix for our (seemingly mutual) echo problem.
We have since changed to brand new Linksys 922 handsets with the latest hardware which includes some form of Echo Cancellation. Ho Ho. Made very little difference on calling my client a moment ago.
As much as my faith in Linksys is about as low as it gets, I can be pretty confident it's not their fault as I've tried some Elmeg/Snom endpoints with the same issue.
You might notice that originally we had a Digium (none other than a B410P) and our issues all began with this. I'm not an expert on Digium but my experience with them is nothing but woe. We have not, ever, installed one and spent the last six months replacing Digium kit installed by other companies that echo like an Alpine mountain range.
I can appreciate your client is going nuts with it, though - might be worth asking elsewhere on the forum about competitors units as this is just IMHO.
We have lots of Sangoma sites, none echo except this. Alas this is the only BRI site.
Back to Sangoma I think.
A500 seems to be a beta product...
Mon, 03/24/2008 - 9:36am
Amazing... That definately confirm us that Sangoma A500 is a beta product. I can understand that ISDN is not as usual as T1's in USA or Canada. But, in Europe, Spain in particular, ISDN is a MUST!. I'm quite sure that A500 can be the "killer application" for Asterisk ISDN implementations. However, i believe it does not have the support we deserve, specially after waiting to fix these issues more than 2 months.
So, concerning the B410P, it seems that it is a piece of S***T too (sorry for my language, but this is really discusting). It seems that it does not exists any serious interface for ISDN under Asterisk... at least internal. What about external gateways?
Quadro ISDN Gateway (4 BRI)
http://www.epygi.com/quadro-gateway/70/#isdn?
Patton SmartNode 4638 - VoIP gateway , 4 ISDN BRI, SIP
http://www.wildix.com/product_info.php?products_id=156&cPath=3_11...
Thank you very much for your time,
Regards,
Rhawk1es
A500
Mon, 03/24/2008 - 9:47am
I really can't comment on external hardware, especially if coupled with Asterisk / Trixbox.
You're not the first person to say to me the A500 might be "Beta". I put this to our UK supplier of Sangoma products and he swears blind he's sold lots of these, that they are the Premium ISDN / BRI card of choice and that his other clients are happy.
Indeed however, I've not heard much from anyone else using these cards bar yourself, the support is uncharacteristically (for Sangoma) ropey and they do appear to be a work in progress.
The most frustrating thing is that the PRI cards simply work so well.
Come on Sangoma, you're lurking here somewhere! Whats the story?
A500 lack of documentation
Mon, 03/24/2008 - 10:13am
We asked a lot out there and every Asterisk tech support we contacted reported us that this kind of issues can be fixed lowering rx/tx volumes (in OpenVox, Junghanns or Rhino cards). An older version of wanrouter (3.3.0.2) had several parameters to set rx/tx gain levels on woomera.conf. We tried to use them without success from the very beggining (it seems that those parameters have no effect at all controlling audio levels on newer driver versions):
/etc/asterisk/woomera.conf
[settings]
debug=2
[default]
host=localhost
port=42420
audio_ip=127.0.0.1
default_context=sangoma
debug=2
dtmf_enable=1
jb_enable=0
progress_enable=0
context=sangoma
group=1
codec=alaw
rxgain=0
txgain=-20
As you can see, we set txgain very low, but there are no perceptible changes... A500 is NOW very easy to install on Trixbox. However, there is no documentation at all to fine tune the card, expect the wiki at Sangoma web site. Simply, there is no expertise to share. There are a HUGE amount of parameters not well documented or not documented at all, no info for controlling woomera driver from Asterisk CLI...
We have installed Sangoma A200HWEC's with very good results. "It must work" is a reality on the "analog" world.
We'll comment you any changes with 3.3.2 wanrouter 2008-03-13 version,
Thank you for sharing your experience,
Regards,
Rhawk1es
Maybe a stupid question but
Mon, 03/24/2008 - 10:26am
Maybe a stupid question but have you tried installing from scratch sans Trixbox or tried another distribution?
http://powerpbx.org/content/freepbx-production-install-guide-cent...
Wanrouter 3.3.2 2008-03-13 and the same echos (even worse)
Tue, 03/25/2008 - 9:22am
Just to let you know,
Wanrouter 3.3.2 2008-03-13 has the same echo issues, specially when a remote analog line is called/calling.
Absolutely annoyed of this situation... I've started to search other solutions, my client is very, VERY, V E R Y UPSET. I will post my experiences here too...
Regards,
Rhawk1es
rhawk1es,
I'm not sure if
Tue, 03/25/2008 - 9:35am
rhawk1es,
I'm not sure if you have had a dialog with Sangoma, but we got this from them today;
***********************************************************
Would it be possible for you to capture an echo call using the following procedure, before this however could you please upgrade to our latest driver, wanpipe 3.3.2 ftp://ftp.sangoma.com/linux/current_wanpipe/wanpipe-3.3.2.tgz. This procedure is going to create a recording of the call that we will then use to determine if the echo canceller is working properly or not.
1. Before you start make sure that your Hardware echo canceller is running. Make sure that your parameter is "TDMV_HWEC = YES" in your /etc/wanpipe/wanpipeX.conf. Also using “wan_ec_client wanpipeX stats Y” (where X is the wanpipe number 1, 2, 3 …and Y is the Channel)
You should see
wanpipe1: Running Get stats command to Echo Canceller device... Done!
wanpipe1: 1: Echo Channel Operation Mode : NORMAL
wanpipe1: 1: Enable Tone Disabler : TRUE
If Echo Channel Operation Mode Is Normal then your echo canceller is enabled. We could move to the next step.
2. Establish a call that has an echo problem.
3. Determine the call channel number by running "show channels" on Asterisk CLI:
CLI> show channels
(Here is where you have to pay close attention, when you do show channels you will see for example,
CLI> show channels
Channel Location State Application(Data)
SIP/1000-08ae50a0 (None) Up Bridged Call(WOOMERA/g1/1-aba0
WOOMERA/g1/1-aba0 102@from-pstn:2 Up Dial(sip/1000)
2 active channels
1 active calls
In WOOMERA/g1/1-aba0, the 1 after the / means that it’s Channel 1 (g1/1 ---> channel 1). With this you have determined the channel to use for step 4)
4. Run an echo canceller debug utility on that channel
#>wan_ec_client wanpipe1 monitor
Where
5. After 2 minutes of talk and noticeable echo
6. Obtain the debug statistics using:
#>wan_ec_client wanpipe1 monitor
The wan_ec_client will write a binary file in your local directory.
7. Send the binary file back to sangoma support
***********************************************************
Now. We're about to plan out putting this driver in place and running the monitor as requested.
Your post does not fill me with the greatest confidence.
We also are going to look at alternatives; but I have to say, I don't want to.
Me either...
Tue, 03/25/2008 - 10:32am
I have received the same information from Sangoma. Let me tell you that we sent on Feb 15th some capture files using that monitor. After one month and a half of waiting, they tell me that those files were empty and therefore useless...
When I started the monitor to capture the call, after three or four seconds of monitoring, the audio in ALL channels was choppy and distorted, so I had to stop the monitor and restart wanrouter to fix it.
I will send them some capture files too, but I'm afraid that this is going to take much more time of testing...
Wanrouter 3.3.5 is out...
Fri, 03/28/2008 - 10:17am
We have installed wanpipe 3.3.5 version (2008-03-27). It seems that they have inserted those timing fixes you mention. If you install it on Trixbox 2.2.12, review your span group numbers in /etc/asterisk/woomera.conf (the installer sets group number 2 for all spans) to match custom trunk declaration in FreePBX (WOOMERA/g1/$OUTNUM$).
Addiotionally, we had to edit /etc/wanpipe/wancfg_zaptel/wancfg_zaptel.pl and change "my $is_trixbox" value to "$TRUE" value to execute "/usr/sbin/wancfg_smg" correctly (the installer was unable to "Save&Restart" or "Save&Stop" asterisk).
I send you attached the changelog of wanrouter 3.3.5... It seems that they have introduced newer features. Please, look at "TDMV_DUMMY=YES" setting, do you think it would be necessary to use it to fix our echo issues?... We'll test it anyway...
* Wed Mar 26 2008 Nenad Corbic
- BRI TE auto clocking feature - Bug fix
This feature failed on on some machines with multiple TE BRI modules.
This bug would cause modules to loose sync. Bug introduced in 3.3.3
release.
* Tue Mar 25 2008 Nenad Corbic
- BRI TE auto clocking feature.
Where a connected TE port is elected
as the telco clock recovery port for the whole card. If that TE
port goes down, another connected TE port is found to provide
telco recovery clock to the card. If no connected TE ports are found
then internal oscillator is used.
-> This option is fully automatic no configuration options needed.
- BRI Zaptel Clock Source
Since BRI does not interface to zaptel, it acts as ZT DUMMY to
provide zaptel reliable timing. One has to configure
TDMV_DUMMY=YES in [wanpipe1] section of wanpipe1.conf
- A200/A400 Remora Relax CFG
If one module fails during operation the wanpipe driver by default
fails to load. With this option wanpipe driver
will allow the card to come up with a broken module so that
customer will be able to continue working until the module is replaced.
RM_RELAX_CFG=YES in [wanpipe1] section of wanpipe1.conf
* Fri Feb 14 2008 Nenad Corbic
- Added DTR API for Serial S514X Card
Ability to read and set the DTR/RTS on serial cards throught the API.
Sample code in wanpipe-3.3.2.1/api/chdlc/chdlc_modem_cmd.c
trixbox 2.4 / 2nd BRI
Fri, 03/28/2008 - 1:27pm
Now this is all interesting.
I think our install may have an extra BRI module where it doesn't need it. I'm going to get it removed ASAP to test this.
We're using Trixbox 2.4. AFAIK, this version of Wanrouter isn't designed for it.
But the code above looks promising.
Best regards,
Chris
A500 with two BRI modules, 4BRI lines here
Fri, 03/28/2008 - 1:46pm
We have 2 BRI modules, 4 BRI lines (8 voice channels) connected to Sangoma A500. All lines are used. Anyway, I think it would be a nice hint for Sangoma to discover what happens in our scenario if you just have one BRI module attached (2 BRI lines, 4 voice channels), :D.
Wanpipe 3.3.5 seems to run correctly, but we do not have enough channel usage at the moment to assure "stability" or "echo free calls". We'll see what happens next week, we finally convinced our client to give us one more week to do some "testings".
Regards,
Alberto
Hello all:
We have recently
Thu, 04/24/2008 - 7:13am
Hello all:
We have recently fixed a major bug with A500d. BRI hardware echo cancellation was not configured properly on start up. Every second channel on each port was not configured for hardware EC . This will cause random echo problems. The latest wanpipe-3.3.7 release has fix for this issue. I will upload new RPMs within next hour.
Thank you,
A500D is definately an alfa/beta product...
Thu, 04/24/2008 - 8:24am
After three months of testing and waiting, we receive the "great" new that BRI hwec was not configured properly on startup and that every second channel on each span was not being configured for hwec. We can't believe it, really.
We discover too that there is a new hardware revision of A500 to "improve" HWEC performance using a new 512hz clock that could should solve any random Echo problems on NEWER BRI cards... So, what can we do now? Can we change our card to the new HW revision to fix our problems?
Our client finally requested us a mandatory change of A500HW ISDN card to a Digium B400P, which is working correctly at the moment and without problems. So, we are very glad to check Sangoma Tech Support has found a solution for A500, but it has been too late for us and VERY EXPENSIVE in resources consumption and invested time.
We could test A500 once again to check wanpipe 3.3.7 performance, but we dont think it will be a production status for us, that's for sure, at least until we do not see a stable version of wanpipe A500.
Chrism2, how about you? did you send some echo file for testing? Or maybe you could test 3.3.7 to finally enable the echo canceller to all spans, :D :)))
Regards,
RHawk1
Echo
Fri, 04/25/2008 - 2:14am
Well,
We didn't get far with the last attempt some weeks ago. Basically, we sent the log files to Sangoma and they were found to be corrupt.
I haven't dared to show face since then, but I hear the new rpms "fix" this issue.
I've gone as far as getting a channel of ISDN2e installed in my office (we already have ISDN30) so I can troubleshoot this.
If this is the long awaited fix; great. If not. Hmmm.
What I want to know is this:
1) Do these RPMs work with Trixbox 2.4.x?
2) What is the correct step-by-step Sangoma-verified way of upgrading your existing install with the drivers?
Personally, I'm skeptical but I'm willing to try this with a little love from Sangoma.
Chris
We will test 3.3.7 ASAP
Fri, 04/25/2008 - 3:32am
Hello again, Chrism. We will try to test the card with newer drivers as soon as we can. We are glad to see that at least there is a possible solution for our problems and it was not our imagination.
I'm sure that you will agree with me that it is "somewhat" annoying that Sangoma tech support discover a CRITICAL problem with HWEC behaviour after three months of testing, in my humble opinion. Anyway, thank you Sangoma for your efforts to improve A500. We do really think A500 will be a mandatory choice for ISDN implementations, but we will wait to use it in production implementations until we have a stable driver version.
Chris, please, check the changelog of the driver 3.3.7 for A500, and post what hardware revision you have. Do you think it is possible that Sangoma could change an older card (we're sure that our card is an older version, we bought it in October 2007) to the newest hardware revision?... Hhmmmm :D
Regards,
Alberto
We are impatience to receive some news from you...
Fri, 04/25/2008 - 12:47pm
We have already built the newer drivers in our server.
However we won't be able to connect the ISDN lines until May 12th. Our customer is really upset, just hearing the word Sangoma... :D
Please comment us any improvements you may find, our fingers are closed here too.
Regards
Our new build has gone live
Thu, 05/01/2008 - 5:14pm
We have deployed a new server 3.3.7 at our clients site. Initial tests were successful, but by the end of Friday, we should have a better idea of how well we have done.
I see NCorbic from Sangoma is discussing new drivers (already!) to fix a Power Saving issue with BRI...
This driver was not posted before we deployed, so we're sticking with 3.3.7.
Let's hope this is an end to it.
Re: BRI
Thu, 05/01/2008 - 7:37pm
Hi
There are no real differences between 3.3.7 and 3.3.8 so you should be ok :)
We are getting some mixed reports from the field that BRI power saving mode can cause noise issues on some systems. Most BRI lines fortunately do not have power saving mode so lines stay up. We have a new 3.3.9 release that we are currently testing with some problem customers to confirm that our new updates are working. Once we confirm our updates in the field we will release the 3.3.9 :)
We are getting a lot of feedback from our customers from all over the world with different BRI line configurations and most are very positive! We are hopeful to get all these low level hardware issues under control in a very short time frame.
We will keep you updated. Thanks for all your support and patience.
Nenad
Sangoma Technologies.
So far..
Fri, 05/02/2008 - 7:05am
We called our client this afternoon, having let the server run since yesterday evening.
So far we have no complaint of echo.
I'll reserve the \o/ until next week once it's been running a while, but on the old driver we would have had a report of echo by now.
I'm encouraged.
Member Since:
2007-08-15