Summary:	ASTERISK-04872: [patch] A potential solution to PauseQueueMember / UnPause issues.
Reporter:	Corey Frang (gnarf)	Labels:
Date Opened:	2005-10-17 16:52:09	Date Closed:	2011-06-07 14:02:48
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app_queue.txt
Description:	So, PauseQueueMember works great. Only one problem, The Dial Plan logic offers >NO< way to guarntee to call UnPauseQueueMember when the channel hangs up.  I.E.: exten => 1234567,1,PauseQueueMember(|Agent/${CALLERID}) exten => 1234567,n,Dial(SIP/1234567@provider|120|g) exten => 1234567,n,UnPauseQueueMember(|Agent/${CALLERID}) If the >called< party hangs up, a "g" to the Dial() app will work.. If the >calling< party hangs up, the dialplan has no way to continue. I added an option "h" to the PauseQueueMember which monitors the channel that called PauseQueueMember, when that channel hangs up, it will UnPause on its own. I know that I should be doing more error checking / probably incrementing a "use" counter somewhere, but I haven't had the experience in working with ast_channels yet.  I would really appreciate it if someone could let me know whats missing from this patch, and help me build this up as what I see is an extremely useful option to the PauseQueueMember application
Comments:	By: Tilghman Lesher (tilghman) 2005-10-17 17:27:37 Please re-upload your patch in 'diff -u' format. By: Corey Frang (gnarf) 2005-10-17 17:36:03 doh, sorry, wasn't thinking straight :) By: Tilghman Lesher (tilghman) 2005-10-17 17:57:30 Okay, busy loop is a BAD idea... use pthread_yield() to relinquish control of the processor while you're waiting. Also, you're checking the existence of the channel currently in a way that has a race condition.  Instead of checking that, iterate through the list of channels using ast_channel_walk_locked(), and compare each channel pointer with your stored pointer.  If you don't find it, the channel is gone.  If and only if you find it, may you check to see if the channel is hungup yet.  (Otherwise, your channel could get gone and something else could be allocated in its place by the time CPU control returns to you.) By: Kevin P. Fleming (kpfleming) 2005-10-31 18:29:23.000-0600 Is there some reason I'm missing why you can't use the 'h' extension in the context that called PauseQueueMember() in the first place? By: BJ Weschke (bweschke) 2005-11-01 09:54:30.000-0600 None that I'm aware of. I've been using that approach in production for several months without any repercussions of agents being left in a perpetual paused state. I have already posted in forums and will send dial plan examples to anyone else looking for them again. By: Corey Frang (gnarf) 2005-11-01 10:04:46.000-0600 Nope, It was because I was trying it from the macro that it didn't work (the H extension in dialplan) There is one question I have though, how do you deal with attended transfers?  the H extension doesnt get called. By: BJ Weschke (bweschke) 2005-11-01 10:10:50.000-0600 It should. I was thinking the same thing, but I think the originating channel should have a hangup called on it once the atxfer is complete which should call the 'h' on that original channel that started the atxfer. If that doesn't happen then we probably need to open a bug on that behavior. By: Kevin P. Fleming (kpfleming) 2005-11-01 16:12:18.000-0600 Let's close this one for now... if you find a situation where the 'h' extension is not providing what you need, open a separate bug on that issue. Thanks!