Call file: Amazing adventures in the queue

Colleagues, please tell me how to solve my problem.

I need what the operators (members of the queue), if necessary, to automatically call some numbers.
For this, I create a call file.
The value of the “Channel:” field is set so that the first part of the call goes to the queue.
The values of the “Context:” and “Extension:” fields are set so that the answering agent first hears a voice message that this is not an incoming call, but a callback, and then was connected to the required number.

Unfortunately, the queue functionality assumes that the moment of answer, what causes transition to the second part of the call is not the member’s response, but the very moment of entering the queue.
When the queue’s member received the call, the voice message was already completely sounded and he hears either the dial tone of the connecting or the answer of that person. The operator does not understand at all what is happening.

Is it possible to make it so that the event that instructed the processor of call files to connect to the second number was not the entrance to the queue, but the response of a member of the queue?

Thanks in advance for your reply,
Ogogon.

You are clearly using a local channel, but didn’t say that in the above.

You will get this behaviour if the local channel explicitly answers the call.

I did not mention this because I could not imagine that it could play such a fatal role.

I really have a clever construction like “Local/REMOTE_NUMBER@dialplan_for_queue” in the “Channel:” field.
The dialplan first substitutes REMOTE_NUMBER in the CallerID so that the operator and his CRM understand what number they are working with, and then calls the Queue() function.

Further, according to my plan, the operator (a member of the queue) should take the call and start this second part of the connection, specified by the “Context:” and “Extension:” fields. Another context tells the operator that this is a callback and starts connecting it to a number.

And how should I fill in the “Channel:” field so that there is no such disgrace? So that the response of a queue member is considered as a response?
My task is simple - I need to put the call on a local queue.

I really need to see the code of the local channel.

It is not a case of what you must do , but what you must not do.

I didn’t quite understand what a “local channel code” is. Here is a call file and dialplans.

Here is a snippet of the script that builds the call file:

$ECHO "Channel: Local/${1}@recall-to-abandon" > "/var/spool/asterisk/tmp/$FNAME"
$ECHO "CallerID: Recall: ${1}<${1}>" >> "/var/spool/asterisk/tmp/$FNAME"
$ECHO "MaxRetries: 1" >> "/var/spool/asterisk/tmp/$FNAME"
$ECHO "RetryTime: 60" >> "/var/spool/asterisk/tmp/$FNAME"
$ECHO "WaitTime: 300" >> "/var/spool/asterisk/tmp/$FNAME"
$ECHO "Context: uplinks-for-abandon-recall" >> "/var/spool/asterisk/tmp/$FNAME"
$ECHO "Extension: ${1}" >> "/var/spool/asterisk/tmp/$FNAME"
$ECHO "Priority: 1" >> "/var/spool/asterisk/tmp/$FNAME"

Here is a dialplan for entering into the queue:

[recall-to-abandon]
;
exten => _+X.,1,NoOp([${STRFTIME(${EPOCH},,%H:%M:%S %d.%m.%Y)}] Recall to abandoned user ${EXTEN})
same  => n,Log(WARNING,ABANDON-RECALL to '${EXTEN}')
same  => n,Goto(queues,queue_common,noans)
;
exten => _X.,1,NoOp([${STRFTIME(${EPOCH},,%H:%M:%S %d.%m.%Y)}] Recall to abandoned user ${EXTEN})
same  => n,Log(WARNING,ABANDON-RECALL to '${EXTEN}')
same  => n,Goto(queues,queue_common,noans)

Extension without plus - in case when the number, for some reason, is not normalized to the ITU-T format.
The label ‘noans’ is an attempt to enter the dialplan after the Answer() function. Alas, she gave nothing.

[queues]
exten => queue_common,1,NoOp([${STRFTIME(${EPOCH},,%H:%M:%S %d.%m.%Y)}] Call from: '${CALLERID(num)' to Common queue)
same  => n,Answer()
same  => n(noans),Set(__CID_NUM=${CALLERID(num)})
same  => n,Set(CHANNEL(hangup_handler_push)=sub-incall3,s,1)
same  => n,Queue(q_common,Fr,,,300,,,sub-incall2)
same  => n(hang),HangUp()

The incallX subroutines are the entry of records into the DBMS. They do not affect anything else.

Here are the parameters of the queue itself:

[q_common]
strategy=ringall
autofill=yes
servicelevel=30
musicclass=queues
announce-frequency=45
announce-holdtime=no
announce-position=no
memberdelay=1;
ringinuse=yes
retry=1
setinterfacevar=yes
setqueueentryvar=yes
wrapuptime=0
member => Local/200@localext
...

This line, in the queues context, is causing your problem. You must let the queue answer the call, not explicitly answer it.

(You may need to explicitly answer for incoming PSTN calls, so that the caller can hear any announcements.)

I’m sorry, but I’m entering into context after this line. (Label ‘noans’.)

same => n,Goto(queues,queue_common,noans)

Or am I missing something?

Just a quick drive-by comment…

Your ‘create the call file’ shell script snippet can simplified like:

(
$ECHO "Channel: Local/${1}@recall-to-abandon"
$ECHO "CallerID: Recall: ${1}<${1}>"
$ECHO "MaxRetries: 1"
$ECHO "RetryTime: 60"
$ECHO "WaitTime: 300"
$ECHO "Context: uplinks-for-abandon-recall"
$ECHO "Extension: ${1}"
$ECHO "Priority: 1"
) > "/var/spool/asterisk/tmp/$FNAME"

Easier to read, easier to maintain.