[asterisk-bugs] [Asterisk 0013820]: Executing 'h' extension if parked channel hangs up

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13820 
====================================================================== 
Reported By:                mdu113
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13820
Category:                   Resources/res_features
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 152539 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-10-31 13:50 CDT
Last Modified:              2008-11-03 10:56 CST
====================================================================== 
Summary:                    Executing 'h' extension if parked channel hangs up
Description: 
I hope this is just an oversight and something that can be added easily.
Currently there's no way specify 'h' extension to be executed when parked
channel hangs up ("got tired of being parked" in asterisk language).
If I add "parkedcalls" context to my dialplan and create an 'h' extension
there, it creates 2 different contexts of the same name and 'h' extension
is not executed:
devel*CLI> dialplan show parkedcalls
[ Context 'parkedcalls' created by 'pbx_config' ]
  'h' =>            1. NoOp(Parking H extension)                 
[pbx_config]

[ Context 'parkedcalls' created by 'res_features' ]
  '700' =>          1. Park()                                    
[res_features]
devel*CLI>
-= 2 extensions (2 priorities) in 2 contexts. =-
I really need to be able to do some additional stuff on parked channel
hang up. 
I think the current behavior is incorrect or at least inconsistent.
====================================================================== 

---------------------------------------------------------------------- 
 (0094522) murf (administrator) - 2008-11-03 10:56
 http://bugs.digium.com/view.php?id=13820#c94522 
---------------------------------------------------------------------- 
Quite interesting. In a fairly recent fix to prevent crashes with early
parking,
I found that some code wasn't protected from operation on parked
channels.
Running the h-exten in main/pbx.c was one of those places. Since the
channel
being parked is given to the parking manager thread, the pbx thread should
not
be trying to run the h-exten for that channel any more; cases of "tired"
hangups could yield a crash. This has always been there. So, I ran an
experiment; I theorized that, if h-exten had always been run on parked
'tired' channels, and no-one complained until now (about
crashes/weirdness), then maybe some logical sequence of events I missed
made that code valid. So, I removed the parking restriction from the if
that wraps the h-exten run code, and tried the scenarios. Got crashes and
weird behavior.

This must be stuff that was always there. 

So replacing the conditional, I tried the 4 scenarios, and watched how the
h-exten was run.

A calls B, B answers; A parks B, B hangs up during A's parking exten
ann-ment
  -A  gets the hangup exten run

A calls B, B answers; A parks B, B hangs up before his parking time
expires.
  -A  gets the hangup exten run

A calls B, B answers; B parks A, A hangs up during B's parking exten
ann-ment
  -No h exten run on A (of course)

A calls B, B answers; B parks A, A hangs up before his parking time
expires.
  -No h exten run on A (of course)

So, for half the cases, the h-exten is run as normal.

I'll investigate to see how easy/hard it might be to make the parking
thread run the hangup routine, iff it was "channel" and not "peer" in the
call role. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-11-03 10:56 murf           Note Added: 0094522                          
======================================================================