[asterisk-bugs] [JIRA] (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:all-tabpanel ]

Matt Jordan updated ASTERISK-20509:
-----------------------------------

    Status: Open  (was: Triage)
    
> 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
>            Assignee: Matt Jordan
>            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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira