VQ Plus Queue Callback

[PitzKey (Itzik)]

Hello,

We installed now the VQplus callback module. We have it working by other clients, however, while I played with the settings now, I noticed two things.

1. The default announcement does not mention anything about callback or that the caller should press 1.
2. Periodic Announcement - Queue Callback ==>

When Handle Queue Announcements is set to Yes:

• It does NOT stop MOH while the announcement is played.
• It continues ringing the Agent’s phone while the announcement is played.

But when Handle Queue Announcements is set to No:

• MOH is stopped while the announcement is played.
• It stops ringing the agent’s phone.

Is there a way to combine the two, so it continues ringing the agent, and also stops MOH while the announcement is played to the caller?

Thanks

[PitzKey (Itzik)]

Looking at the logs, I see that when Handle Queue Announcements is set to Yes, it seems like VQplus is generating a ChanSpy call that plays the greeting, which is now obvious to me why it does not stop MOH.

-- Executing [[email protected]:64] Queue("SIP/SIPTrunk-0002f699", "88801,t,,,,,,,0,") in new stack
    -- Started music on hold, class 'default', on channel 'SIP/SIPTrunk-0002f699'
 Called 1630407528*[email protected]/n
    -- Executing [1630407528*[email protected]:1] Set("Local/1630407528*[email protected];2", "CDR_PROP(disable)=true") in new stack
    -- Executing [1630407528*[email protected]:2] Set("Local/1630407528*[email protected];2", "CHANNEL(language)=en") in new stack
    -- Executing [1630407528*[email protected]:3] Answer("Local/1630407528*[email protected];2", "") in new stack
    -- Local/1630407528*[email protected];1 answered
    -- Executing [1630407528*[email protected]_chanspy:1] Set("Local/1630407528*[email protected];1", "CDR_PROP(disable)=true") in new stack
    -- Executing [1630407528*[email protected]_chanspy:2] ChanSpy("Local/1630407528*[email protected];1", "SIP/SIPTrunk-0002f699,wqv(4)") in new stack
  == Spying on channel SIP/SIPTrunk-0002f699
    -- Attaching spy channel Local/1630407528*[email protected];1 to SIP/SIPTrunk-0002f699
    -- Attaching spy channel Local/1630407528*[email protected];1 to SIP/SIPTrunk-0002f699
    -- Executing [1630407528*[email protected]:4] GotoIf("Local/1630407528*[email protected];2", "0?pos:holdtime") in new stack
    -- Goto (queuecallback-playposition,1630407528*1594943,9)
    -- Executing [1630407528*[email protected]:9] GotoIf("Local/1630407528*[email protected];2", "0?playhold:periodic") in new stack
    -- Goto (queuecallback-playposition,1630407528*1594943,14)
    -- Executing [1630407528*[email protected]:14] GotoIf("Local/1630407528*[email protected];2", "1?periodicannounce:hangup") in new stack
    -- Goto (queuecallback-playposition,1630407528*1594943,15)
    -- Executing [1630407528*[email protected]:15] Playback("Local/1630407528*[email protected];2", "custom/ToRequestAcallbackPress1") in new stack
    -- <Local/1630407528*[email protected];2> Playing 'custom/ToRequestAcallbackPress1.slin' (language 'en')
    -- Executing [1630407528*[email protected]:16] Hangup("Local/1630407528*[email protected];2", "") in new stack
  == Spawn extension (queuecallback-playposition, 1630407528*1594943, 16) exited non-zero on 'Local/1630407528*[email protected];2'
  == Done Spying on channel SIP/SIPTrunk-0002f699
  == Spawn extension (queuecallback_chanspy, 1630407528*1594943, 2) exited non-zero on 'Local/1630407528*[email protected];1'

Sooo… This got me thinking if that dialplan can stop MOH on the channel, play the recording and start MOH again?
Looking through the Asterisk functions and applications, it seems like you can only manipulate the audio steams on the current channel, not on another channel.

With ARI, if the channel is in Statis, it is possible:
https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Channels+REST+API#Asterisk16ChannelsRESTAPI-stopMoh
https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Channels+REST+API#Asterisk16ChannelsRESTAPI-startMoh

Is there a way to do the equivalent in the dialplan, or through AGI/AMI?

THanks

[asherxtn (United States)]

Currently struggling with the same issue, as I understand it the advantage to have the callback daemon handle the announcements is that it has a more accurate wait time estimate, but with all the issues that it has it basically unusable.

You mentioned some issues, here are some more:

1. When you have the queue handling announcements you can have the position and wait time announced right when the user joins the queue, this doesn’t happen when callback handles announcements.
2. Even when the queue handles announcements there’s no option whatsoever to have the callback announcement played right away when the user joins the queue.

This is a bit frustrating as almost all this functionality already exists in the queue options, but it was somehow never added to the the callback feature, which btw is not cheap.