[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)

Wed Oct 17 16:48:18 CDT 2012

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

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

So I played around with this a bit, and dug into where the macro should be called in {{app_queue}}.  As it turns out, the variables should be set on the calling/member channel prior to any macro or gosub being called - the "just before it gets bridged" does indeed to happen before the macro/gosub invocation.  So we're good there.

The problem here is that we're never actually bridged, since we aren't answered.  The diaplan execution in the {{[reject]}} context happens on the {{;2}} channel, as its the target of the Local channel dial.  That dialplan execution doesn't count as being bridged however, since there is no bidirectional flow of audio between the calling channel and whatever the Local channel is connected to.

Note that once I put an Answer() in the Local channel target (and some extra NOTICEs indicating when the variables are actually set and on what channels).  The dialplan execution is shown below:

{noformat}
    -- Executing [congest at reject:2] Answer("Local/congest at reject-00000000;2", "") in new stack
    -- Local/congest at reject-00000000;1 answered SIP/digium01-00000000
[Oct 17 16:41:59] NOTICE[14786][C-00000000]: app_queue.c:5430 try_calling: Setting variables on SIP/digium01-00000000, Local/congest at reject-00000000;1
[Oct 17 16:41:59] NOTICE[14786][C-00000000]: app_queue.c:5440 try_calling: Setting variables on SIP/digium01-00000000, Local/congest at reject-00000000;1
    -- Executing [s at macro-TestMemberMacro:1] Verbose("Local/congest at reject-00000000;1", "1,Testing entry vars") in new stack
 Testing entry vars
    -- Executing [s at macro-TestMemberMacro:2] DumpChan("Local/congest at reject-00000000;1", "") in new stack

Dumping Info For Channel: Local/congest at reject-00000000;1:
================================================================================
Info:
Name=               Local/congest at reject-00000000;1
Type=               Local
UniqueID=           Asterisk-01-1350510119.1
LinkedID=           Asterisk-01-1350510119.0
CallerIDNum=        103
CallerIDName=       (N/A)
ConnectedLineIDNum= 101
ConnectedLineIDName=Digium 01
DNIDDigits=         (N/A)
RDNIS=              (N/A)
Parkinglot=         
Language=           en
State=              Up (6)
Rings=              0
NativeFormat=       (ulaw)
WriteFormat=        ulaw
ReadFormat=         ulaw
RawWriteFormat=     ulaw
RawReadFormat=      ulaw
WriteTranscode=     No 
ReadTranscode=      No 
1stFileDescriptor=  -1
Framesin=           1 
Framesout=          0 
TimetoHangup=       0
ElapsedTime=        0h0m0s
DirectBridge=       <none>
IndirectBridge=     <none>
Context=            macro-TestMemberMacro
Extension=          s
Priority=           2
CallGroup=          
PickupGroup=        
Application=        DumpChan
Data=               (Empty)
Blocking_in=        (Not Blocking)

Variables:
MACRO_DEPTH=1
MACRO_PRIORITY=1
MACRO_CONTEXT=reject
MACRO_EXTEN=sales
QUEUESRVLEVELPERF=0.0
QUEUESRVLEVEL=0
QUEUEABANDONED=0
QUEUECOMPLETED=0
QUEUETALKTIME=0
QUEUEHOLDTIME=0
QUEUECALLS=1
QUEUESTRATEGY=rrmemory
QUEUEMAX=0
QUEUENAME=sales
QEORIGINALPOS=1
QEHOLDTIME=0
MEMBERREALTIME=0
MEMBERDYNAMIC=0
MEMBERPENALTY=0
MEMBERLASTCALL=0
MEMBERCALLS=0
MEMBERNAME=Local/congest at reject/n
MEMBERINTERFACE=Local/congest at reject/n
================================================================================
    -- Executing [congest at reject:3] Congestion("Local/congest at reject-00000000;2", "") in new stack
  == Spawn extension (reject, congest, 3) exited non-zero on 'Local/congest at reject-00000000;2'
  == Spawn extension (Services, sales, 2) exited non-zero on 'SIP/digium01-00000000'
{noformat}

Note that the channel variables are set on the calling channel and the {{;1}} side of the Local channel, which is sort of what we expected based on the problem report.

So all of this explains what is happening, but doesn't answer the question of whether or not this is a bug.

The use case you described is certainly valid (and is similar to problems that [Pre-Dial|https://wiki.asterisk.org/wiki/display/AST/Pre-Dial+Handlers] solved in Asterisk 11), but Pre-Dial wasn't implemented in Queues, so that's not really a workaround available here.

The implementation is actually doing what it describes - that is, right before the call is bridged, you get the Macro invocation.  So that also matches.

But it would be very useful if the channel variables were applied further before the Macro invocation, that is, before the Member itself was dialed but after channel creation (aka, Pre-Dial).

I'm leaning towards "feature request", or at the very least, application of a feature that was developed for other Asterisk apps.  I'm open to other suggestions however.

> 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