[asterisk-dev] [Code Review] Channel Hangup Handlers

[kobaz]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1230/
-----------------------------------------------------------

(Updated March 16, 2012, 6:54 p.m.)


Review request for Asterisk Developers.


Changes
-------

Updated bug link


Summary
-------

This is the hangup handler patch, and associated 
helper function ast_pbx_exten_parse(), which I think is needed to 
separate the functionality of parsing a gosub target from actually going 
to the target.  It's been malloc debugged and valgrind debugged and tested
for several months in production environments.

Overview of module:
I find the 'h' extensions to be limited, cumbersome, and error prone 
when writing very complex dialplan, especially when using lots of gotos 
and gosubs.  Say you have a main dialplan entry point context called 
callqueue.  If at any point after callqueue runs, you want to run a 
hangup handler specific for the callqueue dialplan, you have to put an 
'h' extension in every single context you plan to possibly jump to after 
entering callqueue.  This solves that problem, and gives the added 
benefit of cascading hangup handlers.

For proof of concept development convenience, I used an existing 
function for setting up the hangup handlers, but it should probably be 
it's own function

Cascading hangup handlers are also possible, where as with standard 
dialplan h extensions, they are not:

context test {
   s => {
     goto fooTest, s, 1;
   }
}

context fooTest {
   s => {
     GoSub(barTest,s,1);
   }

   h => {
     NoOp(footest hangup);
   }
}

context barTest {
   s => {
     NoOp(something in bar);
     Hangup();
   }

   h => {
     NoOp(bartest hangup);
   }
}

Execution:
     -- Goto (fooTest,s,1)
     -- Executing [s at fooTest:1] Gosub("SIP/tipton-local-0000000b", 
"barTest,s,1") in new stack
     -- Executing [s at barTest:1] NoOp("SIP/tipton-local-0000000b", 
"something in bar") in new stack
     -- Executing [s at barTest:2] Hangup("SIP/tipton-local-0000000b", "") 
in new stack
   == Spawn extension (barTest, s, 2) exited non-zero on 
'SIP/intellasoft-tipton-local-0000000b'
     -- Executing [h at barTest:1] NoOp("SIP/tipton-local-0000000b", 
"bartest hangup") in new stack

Only the deepest 'h' exten will execute


Where as with this new method, you could call addhanguphandler as many 
times as you like, and they will all execute in the order of most 
recently added will execute first.

Cascading hangup handlers:
Set(CHANNEL(addhanguphandler)="callqueueHangupHandler,s,1");
Set(CHANNEL(addhanguphandler)="someotherHangupHandler,s,1");
Set(CHANNEL(addhanguphandler)="yetanotherHangupHandler,s,1");

**NOTE**: I have had nasty deadlock problems (as you can see a bunch of locking is commented out, but it works nonetheless (scary))
Maybe someone can help me with the locking.


This addresses bug ASTERISK-19549.
    https://issues.asterisk.org/jira/browse/ASTERISK-19549


Diffs
-----

  trunk/funcs/func_channel.c 320708 
  trunk/include/asterisk/channel.h 320708 
  trunk/include/asterisk/pbx.h 320708 
  trunk/main/channel.c 320708 
  trunk/main/cli.c 320708 
  trunk/main/pbx.c 320708 

Diff: https://reviewboard.asterisk.org/r/1230/diff


Testing
-------

Usage:
context callqueueHangupHandler {
   s => {
     // cleanup here
   }
}

context callqueue {
   s => {
     Set(CHANNEL(addhanguphandler)="callqueueHangupHandler,s,1");
     gosub(foo...)
     goto bar..;
   }
}

Execution:
1. callqueue: set(channel(addhanguphandler...)
2. gosub
3. goto bar
4. channel hangs up
5. channel launches dialplan @callqueueHangupHandler


Thanks,

kobaz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120316/5fdf75ae/attachment-0001.htm>