[asterisk-bugs] [JIRA] Commented: (ASTERISK-20509) app_queue parameters setinterfacevar, setqueueentryvar, setqueuevar, membermacro are only used prior to bridging channel, but should happen any time app_queue attempts a connection to the member (regardless of whether it's answered)

[Matt Jordan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197949#comment-197949 ] 

Matt Jordan commented on ASTERISK-20509:
----------------------------------------

Pasting mine and Leif's conversation from asterisk-dev here:

{quote}
(09:35:26 AM) leifmadsen: mjordan: so I guess, think of it like a channel variable that was set with Set(__FOOBAR=baz), that would be available in the Local channel that the Queue() was calling, not just in the GoSub that the Dial (within the Local channel execution) was calling.
(09:35:35 AM) leifmadsen: mjordan: it should be relatively simple to lab up though yes
(09:35:43 AM) mjordan: leifmadsen: is it only with Local channels?
(09:36:02 AM) leifmadsen: mjordan: no, the Local channel really doesn't have anything to do with it -- it's when the values are available that the problem is
(09:36:18 AM) leifmadsen: it's just easiest to see with a Local channel since that's the only time you can execute dialplan :)
(09:36:28 AM) mjordan: leifmadsen: good.  I was hoping that it was just a temporal issue, and not a 'local channels can't see this' issue.
(09:36:33 AM) leifmadsen: nope
(09:36:40 AM) leifmadsen: it's just where the values are accessible
(09:36:42 AM) leifmadsen: so for example
(09:36:48 AM) leifmadsen: this is the same thing
(09:37:25 AM) leifmadsen: Queue --> Member --> Local --> Dial(...,U(some_subroutine)) --> [some_subroutine] --> DumpChan() --> Bridge()
(09:37:46 AM) leifmadsen: is the same as just using SIP channel (instead of Local) and the queuemacro functionality
(09:37:50 AM) mjordan: right
(09:38:18 AM) leifmadsen: basically, it would be nice if the channel variables were available when the SIP channel was called, not just prior to bridging
(09:38:35 AM) leifmadsen: so when the values are set, it almost seems like they just need to be moved up the stack
(09:39:00 AM) leifmadsen: and I think the change would be really quite safe since the values would still be available in the same location they are now, but also earlier
(09:39:44 AM) leifmadsen: I think that gives you enough info to understand though
(09:39:52 AM) mjordan: leifmadsen: indeed.
(09:40:09 AM) mjordan: I understand the issue, but I'm not sure of the answer :-)
{quote}

> app_queue parameters setinterfacevar, setqueueentryvar, setqueuevar, membermacro are only used prior to bridging channel, but should happen any time app_queue attempts a connection to the member (regardless of whether it's answered)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-20509
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20509
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: 1.8.16.0, 10.8.0, 11.0.0-beta2
>         Environment: Tested on typical Linux install (Ubuntu, RHEL, etc)
>            Reporter: Jim Van Meggelen
>            Severity: Minor
>
> When app_queue decides to present a call to a member (i.e. call has been in queue for a period of time waiting for a member to become available), an opportunity exists to perform further evaluation of the state of the queue immediately prior to completing the connection to the selected member. These channel variables (and macro) are potentially useful for performing routing decisions prior to connection. Unfortunately, they are only set prior to bridging the call to the member, and thus cannot be used under all circumstances.
> As an example, it might in some cases be desirable to route a call elsewhere (or even return congestion(), passing the call back into the queue with no loss of place in line), rather than connect to the selected agent. Perhaps the nature of the call has suddenly become such that this is no longer the best agent to handle this call, and the call should be returned to the queue to try another agent. Perhaps the nature of the call (or the state of the queue) is such that this call needs to be routed somewhere else, and the agent freed up to handle other calls currently waiting in the queue. Perhaps the agent forgot to answer the call (they are not at their desk), and rather than just blindly returning the call to the queue, it would be better to send the call elsewhere.
> This does not work. Instead, unless the call is actually answered by the member channel, none of the variables get set, and the macro is not triggered, and thus useful information is not available to any dialplan code happening in the macro (or a local channel defined as a member) until it's too late to make any routing decisions.
> What should happen instead, is that rather than setting these variables just prior to bridging the call, they should be set as soon as the attempt to connect to the member channel is initiated (i.e. at the moment the queue decides to ring the queue member). This would ensure that in all cases, the macro will be triggered, and cause these variables to be available regardless of the state returned by the member channel. As it stands now, unless the member channel is actually answered, these variables do not get set, which greatly limits their use, since they cannot be used to perform routing decisions.
> We are in the process of documenting this functionality for the 4th Edition of Asterisk, The Definitive Guide, and thus have to make a decision as to whether we document this limitation in app_queue, or see if it can be fixed. We decided that creating a bug for this would be appropriate.
> Either I, or Leif Madsen, can be contacted in regards to this (he is aware of this bug).
> Thanks and regards,
> Jim Van Meggelen

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira