Summary:	ASTERISK-02489: [patch] Add channel group setting to Dial()
Reporter:	Kevin P. Fleming (kpfleming)	Labels:
Date Opened:	2004-09-28 01:57:34	Date Closed:	2008-01-15 15:12:47.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_dial
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) dial_channel_group.patch ( 1) dial_channel_group-2.patch ( 2) dial_outbound_group.patch
Description:	Attached patch adds an optional fifth parameter to Dial(), which allows setting channel group (as in SetGroup()) for all channels created by the Dial app. This allows group-limit checking to include in-process Dial channels, and also relieves the user from having to put two groups on the calling channel (one for the caller, one for the callee).
Comments:	By: Kevin P. Fleming (kpfleming) 2004-09-28 01:58:41 Forgot to mention... this bug is dependent on bug 2529, as it needs the group core functions moved to app.c so it doesn't have to duplicate SetGroup's code. By: Mark Spencer (markster) 2004-09-28 08:39:44 You can already do this with the M option to dial and a macro which sets the group, right? By: Kevin P. Fleming (kpfleming) 2004-09-28 09:41:26 I don't believe the same functionality can be gained by using a Macro, no. First, the Macro is not run until a dialed channel is connected, so if you are using group-limiting for inbound calls to an extension, multiple calls can be delivered if they happen while the first one is still ringing (since the first channel's group has not been set yet). Second, I can't see any way to pass arguments to the Macro in M(), and without spending any time on it I don't know how the resulting Macro could figure out what extension number caused this Dial to occur. In my case, I also need an account ID (not the ACCOUNTCODE) and a call type (DID, internal, etc.) to be able to construct the desired group name. Since the Dial-ed channel is a new channel, running SetVar() on the calling channel won't pass these variables on to the dialed channel (the only variables passed on are ALERT_INFO, VXML_URL and the OSP stuff). They could conceivable be stored into global variables, but that would be nearly impossible to manage, in my opinion. It just seemed to be easier to do it this way; in addition, later this morning I'll be posting a mod to AddQueueMember to do the same sort of thing; when the Queue app places a call to an agent's channel, it will assign a computed channel group to the channel. Again, this is to be used for channel group-limiting, and will go a long way towards making this actually functional for people. Well, at least it has for me :-) By: Mark Spencer (markster) 2004-09-29 10:09:44 Would you be happy with a variable you could set like OUTBOUND_GROUP, rather than modify the dial command string? By: Kevin P. Fleming (kpfleming) 2004-09-29 10:27:46 I believe that would accomplish the same effect, although from the Astricon wishlist it appears that people are trying to reduce the number of channel variables, not increase them :-) However, I already have a patch to accomplish the same thing for queue calls (so channels created by app_queue when it calls members have a group assigned), and I don't think the same technique would work there. I did it this way for consistency in my own dial plan, but if you think there is a better way to accomplish it in Asterisk proper I'm all for it. By: Mark Spencer (markster) 2004-09-29 11:09:13 A dynamic channel variable, not one in the ast_channel structure :) By: Kevin P. Fleming (kpfleming) 2004-09-29 11:27:51 OK, that makes some sense. Let me play around with that and see if I can accomplish what I want to with it. I'll post back here in a day or two. By: Kevin P. Fleming (kpfleming) 2004-10-03 12:17:54 rediffed against current CVS I haven't had time yet to look at whether using a variable would solve the problem for me (paying work got in the way <G>), but will do so in the next couple of days. By: Olle Johansson (oej) 2004-10-11 13:29:46 Markster: A day or two??? :-) Any update?? By: Kevin P. Fleming (kpfleming) 2004-10-12 22:42:40 Sorry for the long delay... the box I was using for * development got put into production, so I had no machine to do development on. I've installed a new system this evening, and will get this resolved in the next 48 hours for sure :-) By: twisted (twisted) 2004-10-27 17:00:37 It's been a tad longer than 48 hours.  Need an update. --Housekeeping By: Mark Spencer (markster) 2004-10-31 20:53:38.000-0600 Well it looks like he doesn't have time to do it.  In the mean time you can use the "macro" to do it although it's not as clean. By: Kevin P. Fleming (kpfleming) 2004-11-01 17:16:45.000-0600 Sorry for the delay, my work time has not been Asterisk-friendly the last couple of weeks... I have uploaded the new patch, which uses OUTBOUND_GROUP as Mark suggested. It works fine for my application. By: Mark Spencer (markster) 2004-11-07 16:48:00.000-0600 Added to CVS. By: Russell Bryant (russell) 2004-11-07 18:27:08.000-0600 not included in 1.0 By: Digium Subversion (svnbot) 2008-01-15 15:12:47.000-0600 Repository: asterisk Revision: 4175 U   trunk/apps/app_dial.c ------------------------------------------------------------------------ r4175 | markster | 2008-01-15 15:12:47 -0600 (Tue, 15 Jan 2008) | 2 lines Add OUTBOUND_GROUP support (bug ASTERISK-2489) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=4175