Summary:	ASTERISK-10704: fundamental (?) autoservice problem
Reporter:	Dmitry Andrianov (dimas)	Labels:
Date Opened:	2007-12-23 10:04:09.000-0600	Date Closed:	2007-12-26 11:03:47.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/Channels
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	While troubleshooting an issue we are having with DTMF I discovered it is mostly caused by the autoservice. The problem is: 1. ast_read does alot of emulation stuff like expanding DTMF_END into properly separated in time DTMF_BEGIN + DTMF_END 2. ast_read is called from autoservice when running some long operations 3. autoservice queues collected frames back to the channel when stopped This results in thse DTMF_BEGIN/DTMF_END frames getting back to next ast_read call after autoservice has stopped. And ast_read uses these frames as input for the emulation process again. To me this is very wrong. Unfortunately I have no idea how to fix this at the moment. One of approaches would be to have ast_read_raw (or something) which just returns frame read fom the channel without any processing and queue these frames instead. However it can cause more poblems whet it solves. Another approach (which is a huge change) would be to have special threads which constantly read channels doing all the processing (what __ast_read does) and queueing result frames into special queue of the limited length within channel. This way ast_read would only take the frame from that queue. This way autoservice becomes unnecessary because each channel is "autoserviced" all the time. ****** ADDITIONAL INFORMATION ****** Actually, the problem I have (Zap channel gets muted sometimes when user quickly rolls over digits producing DTMF) is caused by combination of two bugs (one of them is this issue). I guess my particular case can be solved more easy by fixing the second issue (will file it separately) but I believe this one is very important to fix too.
Comments:	By: Dmitry Andrianov (dimas) 2007-12-23 11:55:23.000-0600 Another possible (and cheap) solution is just to add another queue (processed_frames) to the channel so autoservice will put all frames there and ast_read will be modified to first return frames from that queue without any extra processing and only when this queue is ampty, ast_read will be doing its regular job. By: Russell Bryant (russell) 2007-12-26 11:00:32.000-0600 I'm not sure this is really a "bug".  It's more that it's just a bunch of unnecessary processing.  If a BEGIN and END are queued up very quickly, then there is code in ast_read to ensure that the digits are spaced out to a minimum amount.  But, I'll make a change so all of this doesn't happen ... By: Digium Subversion (svnbot) 2007-12-26 11:03:01.000-0600 Repository: asterisk Revision: 94790 U   branches/1.4/main/autoservice.c ------------------------------------------------------------------------ r94790 | russell | 2007-12-26 11:03:01 -0600 (Wed, 26 Dec 2007) | 5 lines Don't store DTMF BEGIN frames while a channel is in autoservice.  It's just going to make ast_read() do a lot of extra work when the channel comes back out of autoservice. (closes issue ASTERISK-10704, patched by me) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=94790 By: Digium Subversion (svnbot) 2007-12-26 11:03:47.000-0600 Repository: asterisk Revision: 94791 _U  trunk/ U   trunk/main/autoservice.c ------------------------------------------------------------------------ r94791 | russell | 2007-12-26 11:03:47 -0600 (Wed, 26 Dec 2007) | 13 lines Merged revisions 94790 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r94790 | russell | 2007-12-26 11:06:26 -0600 (Wed, 26 Dec 2007) | 5 lines Don't store DTMF BEGIN frames while a channel is in autoservice.  It's just going to make ast_read() do a lot of extra work when the channel comes back out of autoservice. (closes issue ASTERISK-10704, patched by me) ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=94791