Summary: | ASTERISK-12973: app_dial doesn't report back DIALSTATUS, ANSWEREDTIME and DIALEDTIME | ||
Reporter: | Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) | Labels: | |
Date Opened: | 2008-10-28 09:58:18 | Date Closed: | 2008-10-31 13:44:42 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Applications/app_dial |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | When performing a dial from the dialplan, upon disonnection the normal termination status variables are not set on the channel. Following below is a dumpchan showing that the variables are missing: -- Executing [s@macro-hangupcall:11] Hangup("Local/0732555999@from-internal-93e6,2", "") in new stack == Spawn extension (macro-hangupcall, s, 11) exited non-zero on 'Local/0732555999@from-internal-93e6,2' in macro 'hangupcall' == Spawn h extension (macro-hangupcall, s, 11) exited non-zero on 'Local/0732555999@from-internal-93e6,2' == Spawn extension (macro-hangupcall, s, 19) exited non-zero on 'Local/0732555999@from-internal-93e6,2' in macro 'dialout-trunk' == Spawn extension (macro-hangupcall, s, 19) exited non-zero on 'Local/0732555999@from-internal-93e6,2' -- Channel 0/23, span 1 got hangup request, cause 16 -- Executing [h@seocfwd_dial_extension:1] DumpChan("Zap/23-1", "") in new stack Dumping Info For Channel: Zap/23-1: ================================================================================ Info: Name= Zap/23-1 Type= Zap UniqueID= 1225207506.2 CallerID= 0546982826 CallerIDName= 0546982826 DNIDDigits= 0732557741 RDNIS= (N/A) State= Up (6) Rings= 1 NativeFormat= 0x48 (alaw|slin) WriteFormat= 0x48 (alaw|slin) ReadFormat= 0x48 (alaw|slin) 1stFileDescriptor= 31 Framesin= 388 Framesout= 95 TimetoHangup= 0 ElapsedTime= 0h0m7s Context= seocfwd_dial_extension Extension= h Priority= 1 CallGroup= PickupGroup= Application= DumpChan Data= (Empty) Blocking_in= (Not Blocking) Variables: BRIDGEPEER=Zap/1-1 DIALEDPEERNUMBER=0732555999@from-internal DIALEDPEERNAME=Local/0732555999@from-internal-93e6,1 did_exten=0 AGISTATUS=SUCCESS DID_EXTEN_0=0732555999 VIP_ACTIVE=1 id_session=4073a9b0d366bc7fb733a11b884b3835 OUT_PREFIX= OUT_TRUNK=g2 OUT_TECH=ZAP INBOUND_DID=0732557741 CALLINGPRES_SV=allowed FAX_RX=disabled LOOKUPBLSTATUS=NOTFOUND FROM_DID=0732557741 MACRO_DEPTH=1 CHAN=23 DID=0732557741 CALLEDTON=65 ANI2=0 TRANSFERCAPABILITY=SPEECH ================================================================================ -- Executing [h@seocfwd_dial_extension:2] Set("Zap/23-1", "CDR_LastState=EXTEN_SET_0732555999_") in new stack -- Executing [h@seocfwd_dial_extension:3] DeadAGI("Zap/23-1", "agiWrapper.agi|SEO_CFWD^db_registerCDR") in new stack In previous versions, DIALSTATUS, ANSWEREDTIME and DIALEDTIME were reported back to the channel structure, allowing for processing in the "h" extension upon hangup. | ||
Comments: | By: Leif Madsen (lmadsen) 2008-10-28 10:32:12 Can you please provide the dialplan you're using to reproduce this? By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2008-10-28 10:34:11 It's using FreePBX as the outbound routing logic, but nothing special in there. The variables ${DID_EXTEN_${did_exten}} reference a variable that looks like DID_EXTEN_1 and so on. [seocfwd_dial_extension] exten => _X.,1,dumpchan() ;;exten => _X.,n,Dial(${OUT_TECH}/${OUT_TRUNK}/${OUT_PREFIX}${DID_EXTEN_${did_exten}},120,r) exten => _X.,n,Dial(Local/${DID_EXTEN_${did_exten}}@from-internal) exten => h,1,dumpchan() exten => h,n,Set(CDR_LastState=EXTEN_SET_${DID_EXTEN_${did_exten}}_${CHANNEL(DIALSTATUS)}) exten => h,n,DeadAGI(agiWrapper.agi,SEO_CFWD^db_registerCDR) By: Leif Madsen (lmadsen) 2008-10-28 10:42:39 I can confirm this issue using the very simple dialplan as follows with latest 1.4: exten => _2XX,1,NoOp() exten => _2XX,n,Dial(SIP/${EXTEN},6) exten => _2XX,n,DumpChan() exten => h,1,DumpChan() When you answer the call, I'm missing the variables being set as mentioned in this bug report. If you don't answer the call, then DIALSTATUS=NOANSWER. EDIT: FYI, Asterisk SVN-branch-1.4-r152286 built by root @ development on a x86_64 running Linux on 2008-10-28 11:45:07 UTC By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2008-10-28 12:00:11 Ok, I don't if this will help much - I've tried reverting back versions. I currently have it working with Asterisk-1.4.21 - app_dial revision is now 119530. I'll try to find out what broke when - but it will take me time. By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2008-10-29 15:31:42 Well.... Too many revisions along the way, I seem to be doing something wrong in seeking the proper revision that broke it. I anybody taking a loot at this? By: Digium Subversion (svnbot) 2008-10-31 10:34:36 Repository: asterisk Revision: 153095 U branches/1.4/apps/app_dial.c U branches/1.4/include/asterisk/channel.h U branches/1.4/res/res_features.c ------------------------------------------------------------------------ r153095 | twilson | 2008-10-31 10:34:35 -0500 (Fri, 31 Oct 2008) | 5 lines Recent CDR fixes moved execution of the 'h' exten into the bridging code, so variables that were set after ast_bridge_call was called would not show up in the 'h' exten. Added a callback function to handle setting variables, etc. from w/in the bridging code. Calls back into a nested function within the function calling ast_bridge_call (closes issue ASTERISK-12973) Reported by: greenfieldtech ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=153095 By: Digium Subversion (svnbot) 2008-10-31 13:44:41 Repository: asterisk Revision: 153181 U trunk/apps/app_dial.c U trunk/apps/app_followme.c U trunk/apps/app_queue.c U trunk/include/asterisk/channel.h U trunk/main/features.c ------------------------------------------------------------------------ r153181 | twilson | 2008-10-31 13:44:40 -0500 (Fri, 31 Oct 2008) | 5 lines Recent CDR fixes moved execution of the 'h' exten into the bridging code, so variables that were set after ast_bridge_call was called would not show up in the 'h' exten. Added a callback function to handle setting variables, etc. from w/in the bridging code. Calls back into a nested function within the function calling ast_bridge_call (closes issue ASTERISK-12973) Reported by: greenfieldtech ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=153181 |