[asterisk-bugs] [Asterisk 0013640]: Crash in cdr code in specific one-touch parking scenario

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13640 
====================================================================== 
Reported By:                mdu113
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   13640
Category:                   CDR/General
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 147193 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-10-07 12:34 CDT
Last Modified:              2008-10-22 14:44 CDT
====================================================================== 
Summary:                    Crash in cdr code in specific one-touch parking
scenario
Description: 
Asterisk crashes in cdr code in ast_bridge_call() in the following
one-touch parking scenario: A calls B, B answers, A dials feature code to
park B. Asterisk plays MOH to B and parking announcement to A. Now if B
hangs up during parking announcement is being played to the A then asterisk
crashes immediately after it ends playing parking announcement to A.
I'm attaching backtrace in bt.txt
====================================================================== 

---------------------------------------------------------------------- 
 (0094162) murf (administrator) - 2008-10-22 14:44
 http://bugs.digium.com/view.php?id=13640#c94162 
---------------------------------------------------------------------- 
OK, Russell did not like the fact that my change required 
a call to the channel_find func at the end of every bridge,
so I changed it back, and spent the last two days theorizing,
plotting, formulating, experimenting, and came to these
conclusions:

1. The park stuff should NOT be calling ast_hangup(),
which will immediately terminate a channel that still
has refs in the bridge floating around.

2. Most channel drivers will mark the channel hung up
when you hang it up. At least, the dahdi chans appear
to, even if the channel struct itself is still alive 
and in the channel list.

3. The Dial app has provisions to NOT hangup 
the peer channel when it sees NO_HANGUP_PEER
as a return value from the ast_bridge_call,
which is pretty much what's going to happen
if the builtin_xfer or park_call_full funcs
are activated via the feature stuff. The diff
is that if peer hung up in the process, the
ast_check_hangup() call return TRUE.

I've attached patches for 1.4 and trunk,
that exploit the above facts to free up
the peer channel after the bridge ends,
rather than immediately on hangup of the
peer phone, and do it ONLY if the peer
channel has been hung up on the far end.

Also, I've got some debug thrown in that
I'll remove before committing (I promise),
and I had to apply some fixes to the trunk
version of dial, who was 'poisoning' the
result of the ast_bridge_call with peer 
hangup/gosub execution. (I added that stuff,
how sloppy of me).

Left to do: look at the other cases
of calling ast_hangup() in the parking
code; and make sure any similar code
in app_queue is also fixed in a similar
manner. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-22 14:44 murf           Note Added: 0094162                          
======================================================================