[Home]

Summary:ASTERISK-11370: Not getting answers from get_data in a call-file call
Reporter:Edwin Groothuis (mavetju)Labels:
Date Opened:2008-02-04 06:46:30.000-0600Date Closed:2008-03-05 14:41:39.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) dtmf-1.txt
( 1) zapata.conf
( 2) zap-show-channel-1.txt
( 3) zaptel.conf
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.

****** ADDITIONAL INFORMATION ******

This very simple script shows the behaviour:

   #!/usr/bin/perl -w

   use Asterisk::AGI;

   my $AGI = new Asterisk::AGI;
   my %input = $AGI->ReadParse();

   $AGI->answer();

   my $i;
   $i = $AGI->channel_status();
   $AGI->say_digits($i);

   $i = $AGI->get_data("one-moment-please", 10000, 3);
   $AGI->say_digits($i);

The script is called via this context:

   [barnet-callback]
   exten => _.X,1,NoOp(callback time)
   exten => _.X,n,Answer()
   exten => _.X,n,AGI(callback2.agi)
   exten => _.X,n,Hangup
   exten => OutgoingSpoolFailed,1,NoOp(Failed)

This context is reached via this call-file:

   Channel: Zap/g4/0409227633
   MaxRetries: 0
   RetryTime: 60
   WaitTime: 30
   Extension: 0409227633
   Callerid: 0409227633
   Context: barnet-callback
   Priority: 1

AGI debug gives:

   AGI Rx << ANSWER
   AGI Tx >> 200 result=0
   AGI Rx << CHANNEL STATUS
   AGI Tx >> 200 result=6
   AGI Rx << SAY DIGITS 6 ""
       -- <Zap/4:100-1> Playing 'digits/6' (language 'en')
   AGI Tx >> 200 result=0
   AGI Rx << GET DATA one-moment-please 10000 3
       -- <Zap/4:100-1> Playing 'one-moment-please' (language 'en')
   AGI Tx >> 200 result= (timeout)
       -- AGI Script callback2.agi completed, returning 0

When calling it as a normal call (i.e. without the call-file), it gives this (as expected):

   AGI Rx << GET DATA one-moment-please 10000 3
       -- <Zap/93-1> Playing 'one-moment-please' (language 'en')
   AGI Tx >> 200 result=354
   AGI Rx << SAY DIGITS 354 ""
       -- <Zap/93-1> Playing 'digits/3' (language 'en')
       -- <Zap/93-1> Playing 'digits/5' (language 'en')
       -- <Zap/93-1> Playing 'digits/4' (language 'en')
   AGI Tx >> 200 result=0
Comments:By: Joshua C. Colp (jcolp) 2008-02-04 08:20:57.000-0600

Please attach complete console output with dtmf enabled in logger.conf to go to console.
By: Edwin Groothuis (mavetju) 2008-02-04 14:23:46.000-0600

<strike>As requested and uploaded (dtmf-1): The DTMF is seen by asterisk:</strike>

Further investigation showed that this was caused on the SIP channel going through the Asterisk PABX into to PSTN.

When dialing in directly from the PSTN, the DTMF does not show up in the logger.


By: Edwin Groothuis (mavetju) 2008-02-06 20:26:30.000-0600

It is still on feedback: Is there any other information you need?
By: Edwin Groothuis (mavetju) 2008-02-11 20:54:20.000-0600

It is still on feedback: Is there any other information you need?
By: Michiel van Baak (mvanbaak) 2008-02-15 18:18:34.000-0600

feedback received, changing to 'new'
By: Edwin Groothuis (mavetju) 2008-02-15 18:40:05.000-0600

I've tried Asterisk 1.4.1, 1.4.5, 1.4.9 and 1.4.18 and they all give the same experience.
By: Edwin Groothuis (mavetju) 2008-02-15 19:05:51.000-0600

It doesn't seem to be an AGI issue, because the Read() function in the dialplan doesn't like it neither:

exten => 93353699,1,NoOp(Callback1)
exten => 93353699,n,Answer()
exten => 93353699,n,Read(foo,one-moment-please,3,,,10);
exten => 93353699,n,SayDigits(${foo})
exten => 93353699,n,AGI(callback1.agi)

[barnet-callback]
exten => _.X,1,NoOp(callback time)
exten => _.X,n,Answer()
exten => _.X,n,Read(foo,one-moment-please,3,,,10);
exten => _.X,n,SayDigits(${foo});
exten => _.X,n,Hangup

The call on 9336 3699 works fine, the call back doesn't read the digits neither.
By: Edwin Groothuis (mavetju) 2008-02-15 22:44:50.000-0600

Reported it to asterisk-dev on http://lists.digium.com/pipermail/asterisk-dev/2008-February/031943.html.

The problem is visible in the output of the ast_waitfordigit_full() function, and probably caused by the wrong channel given to the function which handles the dialplan Read() function.


By: Edwin Groothuis (mavetju) 2008-02-16 22:18:53.000-0600

As suggested by Corydon76-dig: When I recorded the stream from the call file initiated call, I heard myself and the DTMF keys I entered.
By: Edwin Groothuis (mavetju) 2008-02-21 00:32:14.000-0600

Both this and my post to -dev seem to have gone unnoticed by the people who understand this system. What can I do?
By: Mark Michelson (mmichelson) 2008-02-21 16:02:23.000-0600

I took some time today to look into this. I tried the same setup you have (mostly copied and pasted your items into my dialplan and directly copied and pasted your AGI script) and things worked fine for me. The only difference between the setups is that I used a SIP channel instead of a Zap channel. I don't have any analog phones on-hand to test with right now, but I will bring one in to work and see if that is what is causing the issue.

Thanks for your patience on this, I know it can be frustrating to not hear responses for several days.
By: Mark Michelson (mmichelson) 2008-02-21 16:36:21.000-0600

A coworker lent me an analog phone to try using, and I still had no problems.

I noticed something a bit odd in your dtmf debug however. The DTMF digits were being received on a SIP channel, but yet your call-file specified a Zap channel. Is there a SIP channel involved in this call in any way?
By: Mark Michelson (mmichelson) 2008-02-21 17:00:20.000-0600

I had a brief discussion with mavetju on IRC and it would appear that this issue only shows itself when dialling in on a PRI. We both are able to successfully complete the operation when dialling in on a SIP channel. I'm moving this out of feedback.
By: Edwin Groothuis (mavetju) 2008-02-28 00:04:58.000-0600

I've done some more experiments:

- When calling out directly to a SIP phone - The application Read gets the DTMF digits.

- When calling out directly via the PRI - The application Read doesn't get the DTMF digits.

- When calling out via a SIP channel to a different Asterisk machine which sends it out via a SIP channel - The application Read gets the DTMF digits.

- When calling out via a SIP channel to a different Asterisk machine which sends it out via its PRI - The application Read doesn't get the DTMF digits.

I have compared the output of the SIP sessions (I couldn't find anything which makes me go "yes" or "no"), I have compared the output of "show channels", I have compared the output of "sip show channel", all are the same.

*HELP* !
By: Edwin Groothuis (mavetju) 2008-03-01 23:31:30.000-0600

When running the wct4xxp driver with debug=3 in modprobe.conf, I see this when calling the function Read() when I make a call to the PABX

Mar  2 12:41:27 tardis kernel: Got tone START of '5' on channel 30 of span 3
Mar  2 12:41:27 tardis kernel: Got tone STOP of '5' on channel 30 of span 3

With the callback function, I see them too:

Mar  2 12:44:37 tardis kernel: Got tone START of '5' on channel 20 of span 4
Mar  2 12:44:38 tardis kernel: Got tone STOP of '5' on channel 20 of span 4

So it is recognized on PRI level.

The question of course now is, how do these DTMF codes found in the zaptel drive t4_check_vpm450() get forwarded to the astersisk component chap_zap() (I believe).
By: Edwin Groothuis (mavetju) 2008-03-03 14:40:18.000-0600

Thanks to Corydon76-lap on #asterisk-dev: zt_handle_dtmfup() or ztread() might be the best place to look through.
By: Edwin Groothuis (mavetju) 2008-03-04 06:36:01.000-0600

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?
By: Edwin Groothuis (mavetju) 2008-03-04 15:18:05.000-0600

kpflemming requested the output of ztscan and the zaptel.conf, which I will post tonight.
By: Kevin P. Fleming (kpfleming) 2008-03-04 17:33:21.000-0600

Please try the modified version of chan_zap that is in http://svn.digium.com/svn/asterisk/team/kpfleming/issue_11917. It should correct this problem.
By: Edwin Groothuis (mavetju) 2008-03-05 04:46:25.000-0600

The patch at http://lists.digium.com/pipermail/asterisk-commits/2008-March/020387.html worked like a charm, thank you very much for it. I can't give you the output of ztscan yet, because the machine paniced when loading the driver 1.4.9.2 zaptel driver.
By: Digium Subversion (svnbot) 2008-03-05 09:28:52.000-0600

Repository: asterisk
Revision: 106038

U   branches/1.4/channels/chan_zap.c

------------------------------------------------------------------------
r106038 | kpfleming | 2008-03-05 09:28:49 -0600 (Wed, 05 Mar 2008) | 7 lines

when a PRI call must be moved to a different B channel at the request of the other endpoint, ensure that any DSP active on the original channel is moved to the new one

(closes issue ASTERISK-11370)
Reported by: mavetju
Tested by: mavetju


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=106038
By: Digium Subversion (svnbot) 2008-03-05 09:36:59.000-0600

Repository: asterisk
Revision: 106040

_U  trunk/
U   trunk/channels/chan_zap.c

------------------------------------------------------------------------
r106040 | kpfleming | 2008-03-05 09:36:50 -0600 (Wed, 05 Mar 2008) | 15 lines

Merged revisions 106038 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r106038 | kpfleming | 2008-03-05 09:32:35 -0600 (Wed, 05 Mar 2008) | 7 lines

when a PRI call must be moved to a different B channel at the request of the other endpoint, ensure that any DSP active on the original channel is moved to the new one

(closes issue ASTERISK-11370)
Reported by: mavetju
Tested by: mavetju


........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=106040
By: Digium Subversion (svnbot) 2008-03-05 09:39:30.000-0600

Repository: asterisk
Revision: 106041

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_zap.c

------------------------------------------------------------------------
r106041 | kpfleming | 2008-03-05 09:39:26 -0600 (Wed, 05 Mar 2008) | 23 lines

Merged revisions 106040 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r106040 | kpfleming | 2008-03-05 09:40:40 -0600 (Wed, 05 Mar 2008) | 15 lines

Merged revisions 106038 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r106038 | kpfleming | 2008-03-05 09:32:35 -0600 (Wed, 05 Mar 2008) | 7 lines

when a PRI call must be moved to a different B channel at the request of the other endpoint, ensure that any DSP active on the original channel is moved to the new one

(closes issue ASTERISK-11370)
Reported by: mavetju
Tested by: mavetju


........

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=106041
By: Digium Subversion (svnbot) 2008-03-05 13:40:30.000-0600

Repository: asterisk
Revision: 106172

_U  team/murf/sched-rbtree/
U   team/murf/sched-rbtree/CHANGES
U   team/murf/sched-rbtree/UPGRADE.txt
U   team/murf/sched-rbtree/apps/app_amd.c
U   team/murf/sched-rbtree/apps/app_dial.c
U   team/murf/sched-rbtree/apps/app_followme.c
U   team/murf/sched-rbtree/apps/app_meetme.c
U   team/murf/sched-rbtree/apps/app_minivm.c
U   team/murf/sched-rbtree/apps/app_record.c
U   team/murf/sched-rbtree/apps/app_talkdetect.c
U   team/murf/sched-rbtree/apps/app_voicemail.c
U   team/murf/sched-rbtree/apps/app_waitforsilence.c
U   team/murf/sched-rbtree/channels/chan_sip.c
U   team/murf/sched-rbtree/channels/chan_zap.c
A   team/murf/sched-rbtree/configs/dsp.conf.sample
U   team/murf/sched-rbtree/include/asterisk/dsp.h
U   team/murf/sched-rbtree/include/asterisk/sched.h
U   team/murf/sched-rbtree/main/app.c
U   team/murf/sched-rbtree/main/asterisk.c
U   team/murf/sched-rbtree/main/dsp.c
U   team/murf/sched-rbtree/main/loader.c
U   team/murf/sched-rbtree/res/res_agi.c

------------------------------------------------------------------------
r106172 | murf | 2008-03-05 13:40:24 -0600 (Wed, 05 Mar 2008) | 57 lines

Merged revisions 106003-106170 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r106036 | tilghman | 2008-03-05 08:23:32 -0700 (Wed, 05 Mar 2008) | 15 lines
 
 Merged revisions 106015 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
 r106015 | tilghman | 2008-03-05 09:17:16 -0600 (Wed, 05 Mar 2008) | 7 lines
 
 Correctly initialize retransid in SIP, and ensure that the warning when failing to delete a schedule entry can actually hit the log.
 (closes issue ASTERISK-11574)
  Reported by: slavon
  Patches:
        sch2.patch uploaded by slavon (license 288)
 (Patch slightly modified by me)
 
 ........
................
 r106040 | kpfleming | 2008-03-05 08:40:40 -0700 (Wed, 05 Mar 2008) | 15 lines
 
 Merged revisions 106038 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
 r106038 | kpfleming | 2008-03-05 09:32:35 -0600 (Wed, 05 Mar 2008) | 7 lines
 
 when a PRI call must be moved to a different B channel at the request of the other endpoint, ensure that any DSP active on the original channel is moved to the new one
 
 (closes issue ASTERISK-11370)
 Reported by: mavetju
 Tested by: mavetju
 
 
 ........
................
 r106072 | tilghman | 2008-03-05 09:23:44 -0700 (Wed, 05 Mar 2008) | 7 lines
 
 Create a centralized configuration option for silencethreshold
 (closes issue ASTERISK-10755)
  Reported by: philipps
  Patches:
        20080218__bug11236.diff.txt uploaded by Corydon76 (license 14)
  Tested by: philipps
................
 r106110 | file | 2008-03-05 09:39:22 -0700 (Wed, 05 Mar 2008) | 2 lines
 
 Fix code up to what it was meant to be.
................
 r106139 | tilghman | 2008-03-05 10:40:42 -0700 (Wed, 05 Mar 2008) | 3 lines
 
 Should check these values for non-NULL before scanning.
 (Closes issue ASTERISK-11580)
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=106172
By: Digium Subversion (svnbot) 2008-03-05 14:41:39.000-0600

Repository: asterisk
Revision: 106177

_U  team/murf/bug11210/
U   team/murf/bug11210/CHANGES
U   team/murf/bug11210/UPGRADE.txt
U   team/murf/bug11210/apps/app_amd.c
U   team/murf/bug11210/apps/app_dial.c
U   team/murf/bug11210/apps/app_followme.c
U   team/murf/bug11210/apps/app_meetme.c
U   team/murf/bug11210/apps/app_minivm.c
U   team/murf/bug11210/apps/app_record.c
U   team/murf/bug11210/apps/app_talkdetect.c
U   team/murf/bug11210/apps/app_voicemail.c
U   team/murf/bug11210/apps/app_waitforsilence.c
U   team/murf/bug11210/channels/chan_sip.c
U   team/murf/bug11210/channels/chan_zap.c
A   team/murf/bug11210/configs/dsp.conf.sample
U   team/murf/bug11210/include/asterisk/dsp.h
U   team/murf/bug11210/include/asterisk/sched.h
U   team/murf/bug11210/main/app.c
U   team/murf/bug11210/main/asterisk.c
U   team/murf/bug11210/main/dsp.c
U   team/murf/bug11210/main/loader.c
U   team/murf/bug11210/res/res_agi.c

------------------------------------------------------------------------
r106177 | murf | 2008-03-05 14:41:31 -0600 (Wed, 05 Mar 2008) | 57 lines

Merged revisions 106001-106176 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r106036 | tilghman | 2008-03-05 08:23:32 -0700 (Wed, 05 Mar 2008) | 15 lines
 
 Merged revisions 106015 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
 r106015 | tilghman | 2008-03-05 09:17:16 -0600 (Wed, 05 Mar 2008) | 7 lines
 
 Correctly initialize retransid in SIP, and ensure that the warning when failing to delete a schedule entry can actually hit the log.
 (closes issue ASTERISK-11574)
  Reported by: slavon
  Patches:
        sch2.patch uploaded by slavon (license 288)
 (Patch slightly modified by me)
 
 ........
................
 r106040 | kpfleming | 2008-03-05 08:40:40 -0700 (Wed, 05 Mar 2008) | 15 lines
 
 Merged revisions 106038 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
 r106038 | kpfleming | 2008-03-05 09:32:35 -0600 (Wed, 05 Mar 2008) | 7 lines
 
 when a PRI call must be moved to a different B channel at the request of the other endpoint, ensure that any DSP active on the original channel is moved to the new one
 
 (closes issue ASTERISK-11370)
 Reported by: mavetju
 Tested by: mavetju
 
 
 ........
................
 r106072 | tilghman | 2008-03-05 09:23:44 -0700 (Wed, 05 Mar 2008) | 7 lines
 
 Create a centralized configuration option for silencethreshold
 (closes issue ASTERISK-10755)
  Reported by: philipps
  Patches:
        20080218__bug11236.diff.txt uploaded by Corydon76 (license 14)
  Tested by: philipps
................
 r106110 | file | 2008-03-05 09:39:22 -0700 (Wed, 05 Mar 2008) | 2 lines
 
 Fix code up to what it was meant to be.
................
 r106139 | tilghman | 2008-03-05 10:40:42 -0700 (Wed, 05 Mar 2008) | 3 lines
 
 Should check these values for non-NULL before scanning.
 (Closes issue ASTERISK-11580)
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=106177