Default music on hold not being respected.

VitalPBX - v3.2.4-5

On one system, when extensions are putting calls on hold or on park, callers are getting the ringback tone instead of the set music on hold set for the parking slots and extension.

Music on Hold set on the extension
image

Music on Hold set on the parking slot

So both locations have the Fun Times Music on hold set, this is moh2 in the db.

Here is the log section for a simple hold, as you can see the ringback class is being used.

[2023-09-05 09:40:29] VERBOSE[29382][C-000000d9] bridge_channel.c: Channel PJSIP/302-00000471 joined 'simple_bridge' basic-bridge <d8b946ff-e78a-4328-96e0-edf41c41ab88>
[2023-09-05 09:40:29] VERBOSE[29367][C-000000d9] bridge_channel.c: Channel Local/302@queue-call-to-agents-00000363;2 joined 'simple_bridge' basic-bridge <d8b946ff-e78a-4328-96e0-edf41c41ab88>
[2023-09-05 09:40:29] VERBOSE[29383][C-000000d9] bridge_channel.c: Channel Local/302@queue-call-to-agents-00000363;1 joined 'simple_bridge' basic-bridge <07a384e6-4168-43e6-b349-ee11758e8532>
[2023-09-05 09:40:29] VERBOSE[29365][C-000000d9] bridge_channel.c: Channel PJSIP/tv.in-00000470 joined 'simple_bridge' basic-bridge <07a384e6-4168-43e6-b349-ee11758e8532>
[2023-09-05 09:40:48] VERBOSE[29367][C-000000d9] res_musiconhold.c: Started music on hold, class 'ringback', on channel 'Local/302@queue-call-to-agents-00000363;2'
[2023-09-05 09:40:48] VERBOSE[29367][C-000000d9] res_musiconhold.c: Stopped music on hold on Local/302@queue-call-to-agents-00000363;2
[2023-09-05 09:40:48] VERBOSE[29367][C-000000d9] bridge_channel.c: Channel Local/302@queue-call-to-agents-00000363;2 left 'simple_bridge' basic-bridge <d8b946ff-e78a-4328-96e0-edf41c41ab88>

Calls are reaching the extensions via queue, which as always has been, has the default music on hold set to ringback. Nothing really changed config wise manually, just the update to this version on Sunday. I do not see this issue on other servers I have, though. So not really sure what could be happening.

If i call one of the slots directly I do get the proper music on hold oddly, moh2.

[2023-09-05 10:30:25] VERBOSE[8282][C-0000011c] bridge_channel.c: Channel PJSIP/999-000005d2 joined 'holding_bridge' parking-bridge <e6cd324f-07d2-4e8e-85f1-c2413421ee25>
[2023-09-05 10:30:25] VERBOSE[8282][C-0000011c] file.c: <PJSIP/999-000005d2> Playing 'digits/3.ulaw' (language 'en')
[2023-09-05 10:30:26] VERBOSE[8282][C-0000011c] file.c: <PJSIP/999-000005d2> Playing 'digits/7.ulaw' (language 'en')
[2023-09-05 10:30:27] VERBOSE[8282][C-0000011c] file.c: <PJSIP/999-000005d2> Playing 'digits/4.ulaw' (language 'en')
[2023-09-05 10:30:27] VERBOSE[8282][C-0000011c] res_musiconhold.c: Started music on hold, class 'moh2', on channel 'PJSIP/999-000005d2'
[2023-09-05 10:30:30] VERBOSE[8282][C-0000011c] res_musiconhold.c: Stopped music on hold on PJSIP/999-000005d2

Any idea why the ringback is being used instead of the proper music on hold?

It seems the issue is the music on hold value of the queues, anything set there takes precedence over what is set for the extension or the parking. Why the change in behavior, is this s a bug? Pretty much all the time, I want my onhold music for parking slots or the default hold to be different that what is being played on the queue as on hold music.

On 4.0.3-6, there is no apparent issue. The value of of the music on hold doesnt override the parking value which is what is expected. I guess this is a bug introduced in 3.2.4-5 or is this behavior going to be set in v4 of Vital eventually. I believe the current behavior should stay, not understand why we would woulnd’t want the ability to play different music on hold files if calls are answered in queue.

Any way to revert the change temporarily or at least manually on 3.2.4-5, still have several of those boxes online?

@miguel Would it be ok to use the before-bridging-call-hook to revert the music on hold inheritance from the queue?

Something like this:


[before-bridging-call-hook]
exten => s,1,NoOp(Resetting Music on Hold)
  ; Retrieve the MoH class for the extension
  same => n,Set(MOH_CLASS=${DB(${TENANT}/extensions/${CALL_DESTINATION}/moh)})
  same => n,GotoIf($["${MOH_CLASS}"=""]?end)
  same => n,Set(CHANNEL(musicclass)=${MOH_CLASS})
  same => n(end),Return()

Using before-bridging-call-hook is too late as it wont set the moh to the proper channel. I guess only way to revert to the previous behavior would be to modify the [sub-local-dialing] context direclty where the moh on is set for the channel. Can I override the part of the context needed in a custom conf file in order to conserve the original files intact?

Dialplan: What comes first, serves first. Alphabetical order. So you can create a .conf file which comes first.
In that file you put only the context that you want to change. This will survive updates then.

Thanks @mo10, is it possible to override only a part of the context or should I just copy the full context to the new custom file?

This is how the section is currently set in v3.2.4-5

exten => moh,1,NoOp(Set Music on Hold)
 same => n,GotoIf($[${DB_EXISTS(${TENANT}/queues/${QUEUE_NUMBER}/moh)}]?:return)
 same => n,ExecIf($["${DB(${TENANT}/queues/${QUEUE_NUMBER}/moh)}"!=""]?Set(CHANNEL(musicclass)=${DB(${TENANT}/queues/${QUEUE_NUMBER}/moh)}):))
 same => n(return),Return()

Previous versions of the v3 line and currently the v4 has it like this:

exten => moh,1,NoOp(Set Music on Hold)
 same => n,GotoIf($[${DB_EXISTS(${TENANT}/queues/${QUEUE_NUMBER}/moh)}]?:try_extension)
 same => n,ExecIf($["${DB(${TENANT}/queues/${QUEUE_NUMBER}/moh)}"!=""]?Set(CHANNEL(musicclass)=${DB(${TENANT}/queues/${QUEUE_NUMBER}/moh)}):))
 same => n,Return()
 same => n(try_extension),ExecIf($[${DB_EXISTS(${TENANT}/extensions/${CALL_DESTINATION}/moh)}]?Set(CHANNEL(musicclass)=${DB(${TENANT}/extensions/${CALL_DESTINATION}/moh)}):)
 same => n,Return()

No sure exactly why it worked before or works in v4 currently, as to what I understand of the dialplan logic, it checks if the moh value exists for the queue, if there is a value and the value is not empty it sets the channel musicclass value to the value of set in the moh on the queue. In theory, there was always a value set in the queues moh setting, not sure if before it considered ringback as a nonexistant value and thats why it applies the music on hold value of the extension.

Couldn’t a better change be if the desired behavior is to inherit the music on hold of the queue, to first check if ringback is set as moh value for the queue, if it is set the music on hold to the value of the extensions otherwise keep using the value of the queue? I would still think having the option to define different music on hold for the queues, parking and regular hold is better than just inheriting the value but i guess some people do want moh inheritance. I just dont believe anybody would want that if ringback is set. Again not all queues need to be long queues and a lot of people prefer ringing than music on hold for short periods.

Something like that would work @miguel ?

exten => moh,1,NoOp(Set Music on Hold)
same => n,GotoIf($[${DB_EXISTS(${TENANT}/queues/${QUEUE_NUMBER}/moh)}]?:try_extension)
same => n,GotoIf($["${DB(${TENANT}/queues/${QUEUE_NUMBER}/moh)}"="ringback"]?try_extension)
same => n,ExecIf($["${DB(${TENANT}/queues/${QUEUE_NUMBER}/moh)}"!=""]?Set(CHANNEL(musicclass)=${DB(${TENANT}/queues/${QUEUE_NUMBER}/moh)}):))
same => n,Return()
same => n(try_extension),ExecIf($[${DB_EXISTS(${TENANT}/extensions/${CALL_DESTINATION}/moh)}]?Set(CHANNEL(musicclass)=${DB(${TENANT}/extensions/${CALL_DESTINATION}/moh)}):)
same => n,Return()

Did you ever find an answer to this question or find a solution for overriding just the moh extension? I ended up having to edit the exten block in the /etc/asterisk/vitalpbx/extensions__20-baseplan.conf file.

On v3 systems I also modified the extensions__20-baseplan.conf file, no other way to do it.

On v4 they implemented a force moh for the queues, which allows you to control from the gui if you want the moh set in the queue to be forced to the extensions or not. This is the best way in reality to control the moh, as many people dont want the queue music on hold to be the same as the parking or regular hold of the phones, not sure if they are going to be adding that to v3 though.

Thanks for the update. I am not an asterisk expert, and I wanted to make sure I wasn’t missing anything obvious. An upgrade to v4 is on the roadmap for me anyway, good to know this won’t be an issue in that version.

Is this bottom line of code what you input to fix the problem?

I ended up going with this on my v3 PBX’s

exten => moh,1,NoOp(Set Music on Hold)
 same => n,GotoIf($[${DB_EXISTS(${TENANT}/queues/${QUEUE_NUMBER}/moh)}]?:return)
 same => n,ExecIf($["${DB(${TENANT}/queues/${QUEUE_NUMBER}/moh)}"!=""]?Set(CHANNEL(musicclass)=${DB(${TENANT}/extensions/${CALL_DESTINATION}/moh)}):)
 same => n(return),Return()

This allows me to have ringback as music on hold for the queues and still have on hold according to what the extensions have defined.

Okay. Thank you.

I am going to try this fix next week.

We had our queues set to ringback for the music on hold and it was working great for months and then had a customer call in and that’s how I found this forum. Could not figure out what changed.

So, for the Call Park music on hold, where does it get that music on hold from? That is one thing that was confusing me as well. Does it come from the music on hold setting under Applications>Parking?

This always leave me to wonder what the music on hold option under the inbound routes even does, or if it does anything at all.