[asterisk-bugs] [Asterisk 0018722]: When using ugc in dial - If first leg hangs up call is in limbo

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18722 
====================================================================== 
Reported By:                Dovid
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18722
Category:                   Applications/app_dial
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.8.2.3 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-02-01 05:40 CST
Last Modified:              2011-02-07 17:11 CST
====================================================================== 
Summary:                    When using ugc in dial - If first leg hangs up call
is in limbo
Description: 
Hi,

If phone1 calls phone2 with a gosub (sent because of u in dial string)
that sends that sends the called party to a macro where they have to enter
DTMF to have the call bridged, if the caller hangs up after the called
person picks up the first leg is in limbo.

1) phone1 calls phone2
2) phone2 picks up and is sent to a GoSub where a message is played for
phone2 to enter dtmf to bridge the calls.
3) phone2 does not enter anything and hears the message over and over.
4) phone1 hangs up the phone. Asterisk gets the BYE and sends a 200 in
response, however the call is not hung up and the call is in limbo till
phone2 enters DTMF or hangs up.

I will upload the full log as well as a tshark trace.
====================================================================== 

---------------------------------------------------------------------- 
 (0131626) jcovert (reporter) - 2011-02-07 17:11
 https://issues.asterisk.org/view.php?id=18722#c131626 
---------------------------------------------------------------------- 
You're right.  Sorry.

At first glance, when the gosub exits, the originating channel is no
longer in limbo, and hangs up.


I was going to continue to insist that there was no problem, because of
this:

... the Gosub sets a status (any status, really) and returns.

    -- Executing [s at do_dtmf_cc-take-call:3] GotoIf("SIP/x28-00000097",
"0?s,1") in new stack
    -- Executing [s at do_dtmf_cc-take-call:4] Set("SIP/x28-00000097",
"GOSUB_RESULT=CONTINUE") in new stack
    -- Executing [s at do_dtmf_cc-take-call:5] Return("SIP/x28-00000097", "")
in new stack
    -- Executing [s at app_dial_gosub_virtual_context:1]
NoOp("SIP/x28-00000097", "") in new stack
    -- Auto fallthrough, channel 'SIP/x28-00000097' status is 'UNKNOWN'

I thought maybe this was a potential but unimportant cleanup need:
[Feb  7 18:01:21] ERROR[5690]: app_dial.c:2523 dial_exec_full: Could not
stop autoservice on calling channel

And I thought this was a complete exit for the calling channel:
  == Spawn extension (bug-test, s, 2) exited non-zero on
'SIP/x37-00000096'
    -- Executing [h at bug-test:1] NoOp("SIP/x37-00000096",
"ABCDEFGHIJKLMNOPQRSTUVWXYZ") in new stack

After all:

asterisk*CLI> core show channels
Channel              Location             State   Application(Data)       
     
0 active channels
0 active calls
114 calls processed


However...

asterisk*CLI> sip show channels
Peer             User/ANR         Call ID          Format           Hold  
  Last Message    Expiry     Peer      
192.168.0.41     x37              3c64135d106d-aw  0x0 (nothing)    No    
  Rx: BYE                    x37       
192.168.0.41     x37              3c6412ca2d61-bk  0x0 (nothing)    No    
  Rx: BYE                    x37       
192.168.0.41     x37              3c64919923fe-jt  0x0 (nothing)    No    
  Rx: BYE                    x37       
192.168.0.41     x37              3c6417a5ed3f-i8  0x0 (nothing)    No    
  Rx: BYE                    x37       
192.168.0.41     x37              3c6415c7efe6-hp  0x0 (nothing)    No    
  Rx: BYE                    x37       
192.168.0.41     x37              3c6406d7aa5c-6m  0x0 (nothing)    No    
  Rx: BYE                    x37       
192.168.0.41     x37              3c649171941e-fh  0x0 (nothing)    No    
  Rx: BYE                    x37  

I admit to being wrong. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-02-07 17:11 jcovert        Note Added: 0131626                          
======================================================================