[asterisk-r2] RES: polling bug

Wed Dec 23 10:34:54 CST 2009

Hello Moy,

We loop two ports, originate using call files. Call goes out in port1 and comes in port 2. Port 2 answer the call and playback(tt-monkeys). Port 1 echo() the call. After playback is finished, the dialplan priority after playback do a Hangup().

We have two teams here testing it for production validation, and we found the problem of this new bug. The bug It is not on your code!

In team #1 we had the occurrency of the “new bug” that locks the ISDN channels, but not on team #2. So we did a deeper analisis.

What was the diference about our two teams? The echo cancelation!! That’s where the bug is!

Now I can easily reproduce it, and I can easily avoid it:

Scenario:

R2 loop + ISDN loop + echo cancelation type MG2 (echocancel=128) -> results in Lock channels after about 200 calls

R2 loop + ISDN loop + MG2 (echocancel = 256) -> results in Lock channels after about 150 calls

R2 loop + ISDN loop + MG2 (echocancel = 64) -> No problems after 40000 calls

R2 lopp + ISDN loop + MG2 (echocancel = 32) -> No problems after 40000 calls

Then I changed MG2 algorith to KB1 algorith.

Same scenario, but no problems with echocancel (32, 64, 128 or 256) and we did a big validation test with KB1:

R2 loop + ISDN + KB1 (echocancel = 256) -> No problems after 131000 calls

Is very clear for me that there is a problem with MG2 algorithm, that completely affects all the E1 channels. I will conduct some other tests today only with the original asterisk code (without R2 patch), using ISDN on the 4 E1 and MG2. Maybe this is a hidden bug that was there for long time? 

We tested this scenario with asterisk 1.4.22, 1.4.25, 1.4.26.2, 1.4.27.1 and with the current SVN branch 1.4. 

I think this should affect asterisk 1.6 too. We have tests programmed for 1.6 version for the next days.

We tested using the latest zaptel and then repeated the tests with the latest dahdi, and after that with that latest dahdi-trunk.

All combinations were affect by the bug in the same way I described above. 

And all combinations run perfect when using KB1 or MG2 with echocancel=64 or 32 

The tests were performed using an Intel Server with Q8200 quad processor and repeated using an HP Proliant dual Xeon Server (two quad processor), Centos 5.3 32bit, cpu processing was very low all the time about 2% to 10%.

Your code was validated with 131000 calls and I think everything is fine with it now.

--

Rafael Prado

 <mailto:prado at practis.com.br> prado at practis.com.br

De: asterisk-r2-bounces at lists.digium.com [mailto:asterisk-r2-bounces at lists.digium.com] Em nome de Moises Silva
Enviada em: quarta-feira, 23 de dezembro de 2009 12:43
Para: asterisk-r2 at lists.digium.com
Assunto: Re: [asterisk-r2] polling bug

On Tue, Dec 22, 2009 at 10:17 PM, Rafael Prado Rocchi <prado at practis.com.br> wrote:

Moy,

I am doing a lot of testing on the polling bug. Your latest revision (235811) fixed it apparently, but it introduced a new bug.

Hello Rafael, thanks a lot for testing, I committed but did not test myself yet :)

How easily can you reproduce the problem? you say "after a few R2 calls", can you try to put up a more detailed description? You loop 2 ports and then what, originate calls using manager or asterisk call files? once the call goes out in port 1 and comes in port 2, what do you do? send to echo() application? for how long? who hangs up the call and how?

-- 
Moises Silva
Senior Software Engineer
Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada
t. 1 905 474 1990 x 128 | e. moy at sangoma.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-r2/attachments/20091223/4bbee7e0/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5192 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-r2/attachments/20091223/4bbee7e0/attachment.bin 