[Home]

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:18Date Closed:2008-10-31 13:44:42
Priority:MajorRegression?No
Status:Closed/CompleteComponents: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