In the call queue settings I have Others > Answer Channel marked as “No”. For my specific use case I have to have inbound calls only marked as answered when they actually connect with the queue member and not when the queue is entered.
Prior to 3.2.4 R4 my call queue music on hold worked great. No issues. After this update I now only get ring tones and none of my custom music on hold plays. Any suggestions here?
Anybody have any suggestions other than reverting to 3.2.4-4
On 3.2.4-5 they made a setting change that forces whatever you set on your queue for music on hold to be the music on hold that the call carries over until its end. So if you have Ringback set in your queues, and one of your agents answers the calls and puts that call on hold, they will get the ringback tone for the music on hold. If you set actual music on hold in the queue that is the one the call will use if they are put on hold.
I have a related post here: Default music on hold not being respected. - #8 by hlev
I have the MOH set in the queue and I get ring tones instead. I have had to disable the “Answer Channel” in the queue because it was registering the call as answered back to Twilio (and thereby my software) before an actual queue user picked the call up. Essentially it registered that the queue picked it up and assumed that someone in the queue picked up.
It would be really nice if there was a way to only mark a call as answered when a queue member actually answered it and not when the caller entered the queue. That’s what I’m looking to do here. My software that sends the call to the Queue is monitoring the call and when a caller hangs up while in the queue it marks the call as “hung up” and sends a missed call text to the caller.
So for now I cannot use music on hold. So trying to find a workaround.
Still trying to find a workaround. Anyone have any suggestions on sending MOH without marking the call as answered before someone picks up in the queue?
Still trying to get help with this. The issue is coming from this button. I need the On Hold music to play in the queue while also not passing that the channel was answered back to Twilio.
If I turn this on, it correctly plays the on hold music for the queue AND sends back a notification to Twilio that the call was answered.
If I turn this off, I lose the custom music on hold with just ringbacks playing. But it correctly marks the call answered when the Extension Follow Me phone number presses 1 to answer the call.
This worked in 3.2.4 R3 and stopped working in 3.2.4 R4. I’ve since upgraded to 4.0.4 R1 and the issue persists. If I cut the PBX off and restart while a call is in the queue, it correctly reports to Twilio that the call was dropped.
This has got to be a bug. @miguel is this something that y’all have identified as a bug?
The call must be answered if you want to hear the MoH. This is the expected behavior.
@miguel If the call is hung up while in the queue, it does not report back that the call was disconnected by the caller. It marks the call as complete back to Twilio. That can’t be expected behavior, right? Is there a way to mark that call as cancelled or no-answer back to Twilio? And not answered? This is a real problem when third party software is monitoring a call status via Twilio.
This is how it works! Actually, the tooltip explains what will happen if you disable the Answer event in the Queue.
@miguel Then this behavior is not happening. When a call comes in and “Answer Channel” is marked as “Yes” if the caller hangs up while in the queue before answered by a queue member the call is marked as “Completed” back to Twilio not “No Answer” or “Cancelled”. This behavior changed with 3.2.4 R4 and persists in both 3 and 4.
Again, Asterisk works that way. It cannot transmit audio if the channel isn’t answered. You can always ask for more information in the Asterisk forum.
@miguel not trying to be argumentative here…but this worked flawlessly with the “Answer Channel” marked “No” previous to 3.2.4 R4. Callers were given the music on hold set in the queue. When I upgraded to 3.2.4 R4 the queue no longer plays the music on hold with “Answer Channel” marked as “No”.
I switched the “Answer Channel” to “Yes” and now the call data does not reflect back to Twilio correctly, erroneously marking the call as answered when it was still ringing in the Queue.
Something within VitalPBX changed between the two versions and this no longer works. There is a bug in the code somewhere.
I also posted this in the Asterisk Community as well: Call marked As Answered Before Actually Answered In Queue - Asterisk Support - Asterisk Community
@miguel That was not the answer from the Asterisk team. The actual answer was just posted…
So essentially what he said is exactly what I have been saying. Early Media is not being properly supported by VitalPBX. There needs to be a setting to enable early media to be sent.
Something in the code changed between the one version to the other version. Looking at the code would likely show what changed immediately.
The Progress application is called before the Queue is invoked. Anyway, I don’t see they are giving you a real solution.
Anyway, David’s answers make sense.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
