|Summary:||ASTERISK-09035: waitforsilence still timesout inappropriately|
|Date Opened:||2007-03-16 13:59:33||Date Closed:||2011-06-07 14:08:01|
|Environment:||Attachments:||( 0) app_waitforsilence.c|
( 1) app_waitforsilence.c.original
( 2) New_Text_Document.txt
|Description:||I use waitforsilence in .call files and see that the call will terminate a few seconds after being answered. The debug log says status is timeout. I use mixmonitor for these calls and the call will abruptly terminate while the called person is talking at normal volume. Total time to timeout is about 4 seconds.|
The error is intermittent; other calls do work.
I have read that waitforsilence had problems with digital silence/inappropriate timeout that should have been fixed.
The calls go out in the evening when office is closed (little network activity)
All other manual sip/iax/zap calls work fine.
In the attached log, the call terminated while a person was talking.
****** ADDITIONAL INFORMATION ******
centos 4.2, kernel 2.6.9-22.EL
dell dimension 3000 dedicated machine.
intel pentium 4 2.8ghz
no irq conflicts
|Comments:||By: Serge Vecher (serge-v) 2007-03-16 14:09:23|
what about 1.2.16?
By: dghundt (dghundt) 2007-03-16 14:34:11
I'll work on testing this.
I am not optimistic as the fixes to waitforsilence seemed be back a while ago. I didn't upload the recording since it did not seem to matter.
By: Andrey S Pankov (casper) 2007-03-23 09:25:43
That issue has been never fixed in 1.2, please see ASTERISK-6420 for reference.
By: dghundt (dghundt) 2007-03-23 10:55:45
Is there a way to have the fix included in the next 1.2 release? Since it is a fix, not a new feature, this seems reasonable.
By: Serge Vecher (serge-v) 2007-03-23 13:19:30
does the patch from 6595 apply to latest 1.2 and fix the issue?
By: dghundt (dghundt) 2007-03-26 07:58:10
I am not sure what you are asking.
I think 6595 addresses the bug I reported here.
Are you saying that I need to apply the patch to whatever version of 1.2 I am using?
My question was posed under the impression that patch 6595 was applied to the subsequent asterisk 1.2 version like all other bug fixes.
By: Serge Vecher (serge-v) 2007-03-26 10:28:37
no, the patch was only applied to trunk in rev. 41915. I'm not sure the effort will be made now to backport it to 1.2 branch. Can you please test with 1.4.2 instead, which contains that patch?
By: dghundt (dghundt) 2007-03-26 11:46:02
Unfortunatley, I'm not ready to move up to 1.4 yet.
We use 1.2 in production for now.
I will try to apply the patch to 1.2.17 when I get a chance, and see how it goes. I haven't applied a patch before, so it may take me a few trials to get it working.
If it does fix things, I think the feedback will still be useful.
By: dghundt (dghundt) 2007-03-28 19:23:40
I have asterisk 1.2.17 installed, but having difficulty applying the patch.
How do I patch this with the patch2 version?
I also tried to compile the 6/2006 waitforsilence version 1.11, by putting it in the apps directory in place of the original version. That failed. How can I install the 1.11 version?
By: Serge Vecher (serge-v) 2007-03-29 08:22:10
you can't just drop the trunk version of an app into 1.2, because there were loader changes. You can make an svn diff of the revision the patch was applied in (41915) to the previous one (40722). Read on asterisk.org how to make/apply patches.
By: dghundt (dghundt) 2007-04-02 18:02:08
I spoke with Greg at digium support who was great to work with; spent almost an hour with him on the phone. He was unable to apply either of the two patches to Asterisk 1.2.17 as well. He spoke to some developers who said that the bug was supposed to have been fixed with waitforsilence v. 1.11 being applied to the stable 1.2 tarball releases, but for unknown reasons, it was not.
Is there a way to get this bug fix (waitforsilence v. 1.11) backported to 1.2 as it was intended to be? I understand that 1.2 version is still open to bug fixes.
By: Frank Waller (explidous) 2007-04-16 10:49:49
We see the exactly same problem, WaitForSilence returns instantly without any waittime.
Currently running on plain 1.2.17
By: Frank Waller (explidous) 2007-04-16 18:35:04
I had to fix the problem right away. So I'll upload a working backport for the 1.11 version of app_waitforsilence. Since I had to touch the file I included one more option that allows the user to set the Threshold in the same way the AMD detection does.
By: Frank Waller (explidous) 2007-04-16 18:55:33
please remove the app_waitforsilence.c.original file from this posting it was uploaded accidential.
By: dghundt (dghundt) 2007-04-16 19:39:48
Wow. Thanks. I'm sure many will thank you too.
Should I be able to drop this into 1.2.16 or .17 and recompile?
I'll start testing it. The dropped calls are intermittent but frequent enough to notice.
When I had an IRQ conflict, the dropped calls happened all the time; everything else seemed to work ok, so detecting the conflict took a while.
By: Frank Waller (explidous) 2007-04-17 16:47:51
I tested it with 1.2.17 I hope it works with 1.2.16 as well. The System our customer is running is working correctly with it as well as our testsystem. I think in total it was less than an hour to do, most of it was the help/instructions/documentation section. I would suggest 256 as a threshold I think, thats working good in AMD and so should work well here...
I faxed the release in for it as well so, maybe if there is another bug-fix release they hopefully will include it.
Just replace the file in the apps section and recompile.
By: dghundt (dghundt) 2007-05-14 08:10:52
It will be a little while before I can test this patch with asterisk 1.2.17, but the new app is working for explidous. I recommend we close this thread as resolved.
It would be nice to make it available to all in the next asterisk 1.2 release
By: Frank Waller (explidous) 2007-07-11 22:58:07
We have installed this now on a number of customer machines and it seems to be working fine on all.
By: Tilghman Lesher (tilghman) 2007-11-02 16:53:59
Since these changes appear to be for 1.2, I'm closing this out.