Summary:	ASTERISK-03985: SetGroup persists after call is transfered
Reporter:	nester (nester)	Labels:
Date Opened:	2005-04-25 15:18:51	Date Closed:	2011-06-07 14:10:36
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I am using SetGroup and CheckGroup to effectively disable Call Waiting. 1) A call comes in, I answer the call. 2) I transfer the call to another sip phone (using with a # transfer or the transfer button on my phone). 3) I hang up the phone. 4) The orignal caller speaks with the person I transfered the call to. 5) Another call comes into for me, CheckGroup says that I'm already on a call, dumps the call to my voicemail. 6) I do not get any more calls until the original call I transfered is terminated. ****** ADDITIONAL INFORMATION ****** Example of the dialplan logic I'm using. [macro-setgroup-did-test] exten => s,1,Wait(1) exten => s,2,Answer exten => s,3,SetGroup(${ARG1}) exten => s,4,CheckGroup(1) exten => s,5,Dial(Sip/${ARG1},20,t) exten => s,6,Voicemail(u${ARG1}) exten => s,7,Hangup exten => s,105,Voicemail(b${ARG1}) exten => s,106,Hangup
Comments:	By: Brian West (bkw918) 2005-04-25 22:18:06 Actually this is how it should behave.   CheckGroup(max[@category]) SetGroup(groupname[@category]) Might want to use the category options to tell them apart... /b By: nester (nester) 2005-04-25 23:32:45 I'm not sure I understand.. The documentation for the category feature is lacking. Setting a category will allow me to transfer a call and then take the next call? I tried this just now, but it doesn't seem to change the behavior. edited on: 04-25-05 23:33 By: Kevin P. Fleming (kpfleming) 2005-04-26 21:16:03 This has already been fixed in CVS HEAD, but I don't know if Russell will want to make a behavioral change in the stable branch. By: nester (nester) 2005-04-26 22:45:06 As a sidenote, I tried this in HEAD, and my existing config doesn't work at all. As in.... call waiting is not disabled at all. Transfers work fine though. If anyone is willing to help me figure out what is up with that, I'm on the irc channel as nestAr (nester was taken). I'd greatly appreciate it. Thanks. By: nester (nester) 2005-04-26 23:55:04 Ok, that's not totally correct. The example I posted above does work with HEAD. My more complicated real dialplan doesn't work, using Local/ extensions with AddQueueMember and Queues. By: Leif Madsen (lmadsen) 2005-04-27 12:00:58 I've been helping nester with his problems on IRC. I believe what he's trying to do is not a bug in SetGroup(), but rather a logic problem. kpfleming: what is the behavioral change to this? My understanding of how this should work is that when the call comes in, SetGroup increases the counter by one, and even if the call is transferred, the counter is not decremented until the call is dropped. This would be the ideal in my situation of trying to limit the number of simultaneous calls a PBX can place. If transferring the call were to decrement the counter, allowing another call to be placed, that would effectively over-ride the maximum number of calls a PBX might be able to accept / place (depending on which side of the call leg you implement SetGroup() on of course). On a side note since I haven't been able to find anything about what category is and what it does (and is it implemented in CheckGroup(), because show application checkgroup doesn't say it does). If someone minds giving me a quick rundown, I'll update the docs for it and submit a patch. By: Kevin P. Fleming (kpfleming) 2005-04-27 12:26:18 No, there is no 'counter'. Here is what happens: When you call SetGroup(foo) on a channel, a channel variable called GROUP gets set on the channel, with value 'foo'. If you call SetGroup(foo@bar), then a variable called GROUP_bar gets set, with value 'foo'. CheckGroup() just retrieves the current value of GROUP and scans all other channels for matching GROUP variables. Same goes for CheckGroup(foo) and CheckGroup(foo@bar). The fix that went into CVS HEAD was that when the channel masquerade occurs (part of a transfer operation), all channel variables with names that start with GROUP_ (or just plain GROUP) are dropped, so they don't carry over into the new channel. By: Leif Madsen (lmadsen) 2005-05-02 22:51:36 Is this still an issue? I don't believe this to be a bug. By: nester (nester) 2005-05-05 10:30:46 It might not be a bug, it's still an issue for me. I'm sure there's a workaround for this, but I can't get my mind around it. By: Michael Jerris (mikej) 2005-06-02 00:12:46 We still need a word on how you want to go on this one. By: Russell Bryant (russell) 2005-06-13 18:38:29 We can add the same fix to 1.0 as was added to CVS HEAD By: Russell Bryant (russell) 2005-06-14 18:05:11 I've put my patch for this up here in case someone else gets the chance to test it before I do.  :) By: Russell Bryant (russell) 2005-06-24 17:10:02 that didn't quite work ... d'oh! By: chadscott (chadscott) 2005-08-29 11:31:07 This fix has an unintended consequence that breaks my setup. When you drop the group as part of the masquerade, it breaks "agent-handler" type applications. For instance, I have 20 SIP phones in a queue, using "rrmemory".  The SIP phones will accept up to three calls, which allows the queue to annoyingly call-waiting beep them when they're on a queue call. What I was doing previously was a: [agent-handler] _XXXX,1,GROUP(${EXTEN}) _XXXX,n,GotoIf($[${GROUP_COUNT(${EXTEN})} > 1]?1001) _XXXX,n,Dial(SIP/${EXTEN},15) _XXXX,1001,Busy I would then register agents as Local/1234@agent-handler. This worked great right up until the fix.  Now I'm a bit stuck with having to change the SIP configuration to allow only one concurrent call (unacceptable) or write a whole lot of code in the dialplan to store this information in the Asterisk database. Help! By: Russell Bryant (russell) 2005-08-29 11:45:33 If you are having problems related to this with CVS HEAD, then something else has caused it.  The change being referred to here happened a *long* time ago.  It's still sitting here because nobody has written the equivalent code for this to be fixed in 1.0. By: chadscott (chadscott) 2005-08-29 11:52:33 I'm almost positive it's this.  We were running on 1.x for a long, long time and recently moved to CVS HEAD for several features we needed.  Once we moved, this stopped working and I just managed to figure out the problem today (we went live yesterday). If I do a "show channel", I see no group parameters after it attempts the agent-handler.  If the agents call out to a number directly (which also uses GROUP() in the dialplan), the group *is* set and is retained as expected.  However, if they transfer, the group disappears (unlike before). It's almost like this needs to be a configurable behavior and/or just provide a function like CLEAR_GROUPS(). If anyone has a suggestion about how better do the agent handling, I'm open. I just found the change to channel.c in January, so I'm sorry this seems a little tardy. :) By: Russell Bryant (russell) 2005-11-04 11:21:54.000-0600 I'm closing out most of the bugs related to 1.0 since at this point, only *severe* bug fixes and security fixes will go in.  If you still feel there is a problem related to cvs head, please report it as a separate bug.  Thanks!