Queue and extension waiting music

Hi, I have a solution freepbx 15.0.23.17. We are trying to set different queue music. For example, I want that when you enter the queue you listen to a MoH but when the agent puts the user on hold it uses another one but I have not succeeded.

My queue already has a music on hold and I also set a music on hold on my extension, however, if I call my extension and put it on hold it plays perfectly but when I am in the queue and the call drops when I put it on hold it keeps playing the same audio of the MoH of the queue.

How can I configure this correctly?

You’ll need a custom dialplan to set the new MOH class after the queue agent has answered the channel.

You can try to use this: Using Dynamic Routes to run a dialplan sub when queue agent answers

1 Like

Hello, in which module can I see Dynamic Route in the GUI?

I do not see the Dynamic Route option in my modules.

If you use version 15, then you can install it using the Unsupported Repo.

Version 14 and below, use GitHub - johnfawcett/dynroute: Freepbx dynamic route module

Hi there,
So here is what we did:
exten => 401,n(qcall),Queue(401,${QOPTIONS},${QAANNOUNCE},${QMAXWAIT},${QAGI},extension_MoH,${QRULE},${QPOSITION})

where [extension-MoH] is

[extension_MoH]
exten => s,1,Set(CHANNEL(musicclass)=MoH-2022-new)
exten => s,n,NoOp(${CHANNEL(musicclass)})
exten => s,n,Return()

So it appears to execute correctly and runs through setting the variable, contents are displayed on the NoOp, however when we put the calling party on hold we get this:

– Executing [[email protected]:47] ExecIf(“PJSIP/9902-0001e119”, “1?Set(__MOHCLASS=OnHold-2022)”) in new stack
– Executing [[email protected]:48] ExecIf(“PJSIP/9902-0001e119”, “1?Set(CHANNEL(musicclass)=OnHold-2022)”) in new stack
– Executing [[email protected]:49] Set(“PJSIP/9902-0001e119”, “QMAXWAIT=”) in new stack
– Executing [[email protected]:50] Set(“PJSIP/9902-0001e119”, “VQ_MAXWAIT=”) in new stack
– Executing [[email protected]:51] Set(“PJSIP/9902-0001e119”, “QUEUENUM=401”) in new stack
– Executing [[email protected]:52] Set(“PJSIP/9902-0001e119”, “QUEUEJOINTIME=1661278932”) in new stack
– Executing [[email protected]:53] NoOp(“PJSIP/9902-0001e119”, “-1”) in new stack
– Executing [[email protected]:54] Queue(“PJSIP/9902-0001e119”, “401,t,extension_MoH,”) in new stack
– Started music on hold, class ‘OnHold-2022’, on channel ‘PJSIP/9902-0001e119’
– Called PJSIP/2005
– – LazyMembers debugging - Numbusies: 0, Nummems: 2
== Using SIP RTP Audio TOS bits 184
== Using SIP RTP Audio TOS bits 184 in TCLASS field.
== Using SIP RTP Audio CoS mark 5
– PJSIP/2005-0001e11a is ringing
– PJSIP/2005-0001e11a answered PJSIP/9902-0001e119
– Stopped music on hold on PJSIP/9902-0001e119
– PJSIP/2005-0001e11a Internal Gosub(extension_MoH,s,1) start
– Executing [[email protected]_MoH:1] Set(“PJSIP/2005-0001e11a”, “CHANNEL(musicclass)=MoH-2022-new”) in new stack
– Executing [[email protected]_MoH:2] Return(“PJSIP/2005-0001e11a”, “”) in new stack
== Spawn extension (from-internal, 401, 1) exited non-zero on ‘PJSIP/2005-0001e11a’
– PJSIP/2005-0001e11a Internal Gosub(extension_MoH,s,1) complete GOSUB_RETVAL=
– Channel PJSIP/2005-0001e11a joined ‘simple_bridge’ basic-bridge <4d53de90-f9d4-4802-aded-69e5a25cc414>
– Channel PJSIP/9902-0001e119 joined ‘simple_bridge’ basic-bridge <4d53de90-f9d4-4802-aded-69e5a25cc414>
– Started music on hold, class ‘OnHold-2022’, on channel ‘PJSIP/9902-0001e119’
– Stopped music on hold on PJSIP/9902-0001e119

And that’s it. It sets it then ignores it.

Good afternoon, Hello,

Do you have any ideas?

Well the issue here is how Music on Hold is handled. The moh_suggest for the endpoint is what will be applied to the endpoint’s channel for MoH and if the bridged channel doesn’t have MoH set then it will use the moh_suggest option.

When the call hits the queue the caller channel is being assigned MoH from the Queue, when the agent is answering and the gosub is running it is running on the agent’s channel. So now you have Channel A with one MoH class and Channel B with another MoH class. When B holds A, A will hear the MoH for its channel. Conversely, A puts B on hold now B will hear the MoH assigned to it.

You need a way to update the channel that the caller is on, not the agent. Or remove any MoH from the Queue (set nothing) and let the moh_suggest from the agent’s endpoint be used.

Try:

exten => s,1,Set(__CHANNEL(musicclass)=MoH-2022-new)

Hello, we have already tried the change but the same behavior occurs
image

You are still running a gosub on the Agent’s channel, the MoH needs to be updated or cleared from the Caller’s channel. Any gosub run on the Agent’s channel after the call is answered happens on the Agent’s channel.

This is probably going to require the B() option on the Queue, which is a predial handler that is run on the calling channel before the call is initiated to the Agent. Or you can still run the gosub and try MASTER_CHANNEL(musicclass)= because that will apply the the channel spawning the call…not sure how that would work with the queue. There is also the AGI option for the Queue that will execute an AGI action on the calling channel when it connects to an agent.

However, most of this isn’t available in standard queues without doing a lot of dialplan overriding, most of those features are part of Queues Pro.

Does Queue Pro have these features?

We tried to configure it as you mentioned and now it overwrites the MoH that has the Virtual Queue and not the one that has the real queue.

I offered a few, can you be a little more specific. And when did a virtual queue get involved?

Ok, we have been looking at the Queue Pro functionalities, the ones it provides are the following:

The only thing that resembles the scenario we want to create is a virtual queue that overwrites the queue, we thought it would work as desired, that is, in our inbound route we set it to fetch the virtual queue and that the destination of that virtual queue would be the real one but now it only leaves us the MoH of the Virtual queue and it does not even respect the queue’s MoH.

What is the actual goal here? Why does the queue have one MoH but you want an agent that answers to have another and override it? What is actually the end goal with the queue and the agents.

You’re asking how to do a single piece that impacts all the other pieces, so now it is time for the 50K view.

What we want to happen is the following:

When the customer enters the queue and is waiting to be assigned to an agent, a MoH is played, but when the agent has already answered and is interacting with the customer and wants to put him/her on hold, a different music is played. What is the purpose? In the queue initially to be able to tell the customer to wait while we are attending other customers and when the customer is already with the agent to make understand that the agent put him on hold to validate the requested request.

Alright so what you want to can’t be done in normally in FreePBX, Queues Pro or not. @lgaetz @kgupta I am tagging you because there are a few things I’ve noticed.

  1. The Queues don’t see to support the use of the AGI option which would allow an AGI script to be executed on the caller’s channel when connected to an Agent.

  2. The GoSub option doesn’t seem to be supported either. That would run a gosub on the agent channel when connected.

  3. It doesn’t seem the new queue pre-dial handler options introduced in 16 aren’t being used. There is both a b and B option now just like in Dial().

Now if I’m wrong about 1 and 2 that is because I don’t have the pro module and the documentation makes no mention of using those options.

@alisonseas You don’t use Virtual Queues for this. You need to use options that don’t exist in the GUI. You can use the AGI option as I explained before or you can use the B option to set it before the call is dialed to the agent. Of course, you can use the gosub you have but you need to set this on the channel the caller is on. MASTER_CHANNEL might do the trick but you may have to execute some AGI or a system call to set things on that specific channel.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.