Merged revisions 89790 via svnmerge from

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r89790 | russell | 2007-11-27 15:45:51 -0600 (Tue, 27 Nov 2007) | 41 lines

Merge changes from team/russell/autoservice_1.4

This set of changes fixes an issue that was reported to me on IRC yesterday.
The user, d1mas, was using chan_zap for incoming calls and was having DTMF
recognition issues in some situations.  Specifically, he noticed that the 
problem occurred when using DISA or WaitExten.  He also noticed that when 
using Read, the problem did not occur.  His system also used DUNDi for 
dialplan lookups.

So, he theorized that if the DUNDi lookups blocked for some period of time,
that audio from the zap channel could get lost.  If the audio got lost, then
it wouldn't be run through the DTMF detector, and digits could get lost.
He was correct, and the following set of changes fixes the problem.  However,
the changes go a little bit further than what was necessary to fix this exact
problem.

1) I updated pbx_extension_helper() to autoservice the associated channel to
   handle cases where extension lookups may take a long time.  This would
   normally be a dialplan switch that does some lookup over the network, such
   as the DUNDi or IAX2 switches.

   This ensures that even while a DUNDi lookup is blocking, the channel will be
   continuously serviced.

2) I made a change to the autoservice code.  This is actually something that
   has bothered me for a long time.  When a channel is in autoservice, _all_
   frames get thrown away.  However, some frames really shouldn't be thrown
   away.  The most notable examples are signalling (CONTROL) frames, and DTMF.

   So, this patch queues up important frames while a channel is in autoservice.
   When autoservice is stopped on the channel, the queued up frames get stuck
   back on the channel so that they can get processed instead of thrown away.

3) I made another change to the autoservice code to handle the case where
   autoservice is started on channels recursively.

   Previously, you could call ast_autoservice_start() multiple times on a
   channel, and it would stop the first time ast_autoservice_stop() gets
   called.  Now, it will ensure that autoservice doesn't actually stop until
   the final call to ast_autoservice_stop().

........


git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89791 f38db490-d61c-443f-a65b-d21fe96a405b

0 files changed, 0 insertions, 0 deletions