[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:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   13820
Category:                   Resources/res_features
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     assigned
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-12-23 19:39 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.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0013978 Asterisk 1.4.23 rc1 Blind Transfer to P...
====================================================================== 

---------------------------------------------------------------------- 
 (0096922) murf (administrator) - 2008-12-23 19:39
 http://bugs.digium.com/view.php?id=13820#c96922 
---------------------------------------------------------------------- 
OK, I've commit the masq_park branch to 1.4, and adapted it to trunk, and
1.6.0 and 1.6.1, see revs (1.4) 166093, (trunk) 166665, (1.6.0) 166729,
(1.6.1) 166730,
in the which I removed all the KEEPALIVE stuff; and in trunk and 1.6.x,
even 
the consts are removed. This gets rid of the crashes and hangups, etc.

But, it leaves us with strange behavior concerning CDRs and h-extens,
most
notably when "B parks A", after A calls B (an incoming call situation).
In these cases, the 'h' exten is run at that point in time where B
achieves the
park and is hung up; here the h-exten is run for the A channel, and that
channel has it name as "Parked/DAHDI/1-1<ZOMBIE>". It might seem strange
that when B
hangs up, you get the 'h' exten run on the A channel, but... that's the
way it is.

In the past, you'd have gotten no h-exten run at all in some situations.

In conference with Russell and Josh Colp, we decided that fixing this in
1.4
or 1.6.x would be impractical for the following reasons:

1. Any change would be invasive and change the basic structure of how
things are being done. Such extensive changes would not be appropriate for
a release.
2. To be honest, the fix is not yet obvious or forthcoming; we'll think
about it. If anyone has any bright ideas, let me know, but you'd better
explain how 
your cool fix will involve masquerades, and not louse up all the other
places it is done, and not louse up CDR generation. Good Luck!

I marked this bug as "not fixable", but I could also have marked as "won't
fix"...
It's kinda a cross between the two. Whatever the fix entails, I suggest
that it entail a different structuring of asterisk channel information, or
you'll end up in the same morass that CDR's are in. Also, the fix should
involve a fairly good specification for hangup exten execution in
situations that involve parks, xfers, and conferences! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-12-23 19:39 murf           Note Added: 0096922                          
======================================================================