[asterisk-bugs] [Asterisk 0011917]: Not getting answers from get_data in a call-file call

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11917 
====================================================================== 
Reported By:                mavetju
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11917
Category:                   Applications/app_read
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.17 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             02-04-2008 06:46 CST
Last Modified:              03-04-2008 06:36 CST
====================================================================== 
Summary:                    Not getting answers from get_data in a call-file
call
Description: 
When I setup a call via a call-file and then drop into an AGI script, the
function GET DATA doesn't return DTMF keys. With the same AGI script called
directly (i.e. without the call-file) the function GET DATA does return
DTMF keys.
====================================================================== 

---------------------------------------------------------------------- 
 mavetju - 03-04-08 06:36  
---------------------------------------------------------------------- 
The magic seems to fail in zt_read() in chan_zap.c: Around line 4870, there
is a line like this:
 if (p->dsp && (!p->ignoredtmf || p->callwaitcas || p->busydetect  ||
p->callprogress) && !index) {

During normal calls and callback calls all these fields are the same,
except when the callback has been answered: p->dsp is then NULL:

-- zt_read - 1 - dsp: 0x7d9180, ignoredtmf: 0, callwaitcas: 0, busydetect:
0, callprogress: 0, index:0
-- zt_read - 2
-- Moving call from channel 95 to channel 112
-- zt_read - 1 - dsp: (nil), ignoredtmf: 0, callwaitcas: 0, busydetect: 0,
callprogress: 0, index:0
-- zt_read - 1 - dsp: (nil), ignoredtmf: 0, callwaitcas: 0, busydetect: 0,
callprogress: 0, index:0

Note that this setting to NULL happens while moving the call, it doesn't
happen in any of the "dsp = NULL" assignments in chan_zap.c.

So somewhere on the move it loses its DSP. "zap show channel" confirms
this:

Channel: 95
Owner: <None>
Real: <None>
DSP: yes

Channel: 112
Owner: Zap/4:112-1
Real: Zap/4:112-1
DSP: no

According to tzafrir on #asterisk-dev, the DSP on channel 95 shouldn't be
active, and the one on channel 112 should be.

Does this analysis make sense? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-04-08 06:36  mavetju        Note Added: 0083311                          
======================================================================