[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-11-04 18:44 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0094575) murf (administrator) - 2008-11-04 18:44
 http://bugs.digium.com/view.php?id=13820#c94575 
---------------------------------------------------------------------- 
OK, doing it that way would have been difficult. Really quite tricky!

So, Russell advised using the masq_park_call stuff instead of park_call
stuff. which I did, and entirely got rid of the KEEPALIVE and
NO_HANGUP_PEER
stuff in the res_features.c and app_dial and app_queue code, simplifying
things
and making them more crash-resistant.

There are some minor differences, tho.

In the 4 scenarios I mentioned above, the hangup routine is run in all
four cases (good), but in the latter two cases (where B parks A), 
the channel name appears "Parked/DAHDI/1-1<ZOMBIE>", where it would
normally
have been just "DAHDI/1-1". The CDR's generated from these scenarios are 
as normal... they report DAHDI/1-1 and DAHDI/2-1 as previous.

(SIP (and other channel types) behave the same way).

I will continue testing to see how blindxfers, atxfers, etc, might or
(hopefully) might not have been affected. More to come.

I've attached the 13820.diff1 patch to this bug; please give it a spin and
let me know if there are problems.

Also, I noted that there are more than one way to park a channel:
1. Request a park via the manager interface: this uses the masq_park_call
   facility (which is good).
2. Via http://bugs.digium.com/view.php?id=700 (blind xfer feature to parking
exten) -- this I modified to 
   use masq_park_call_announce().
3. Via *3 (one-touch park feature)... this used masq_park_call_announce 
   in one case and the park_call facility in the other. Now, it just does
the
   masq_park_call thing.
4. Via the Park() app... This calls park_call_exec() which USED to return
   KEEPALIVE; I make it return 0 now; I did not update this to use the
   masq_park_call facility, because I wasn't certain that this would
   be of benefit. I'll research it out and see. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-11-04 18:44 murf           Note Added: 0094575                          
======================================================================