I experienced something that I think should not happen in the way it does.
Given I have an invalid WAV file setup as a music on hold, for example a 32bit 44.1KHz WAV.
When a user with a MOH class using this file puts another user on hold
Then asterisk shows an error in the logs regarding the file
Then the two users can still hear each other as if the call was not on hold
[2023-04-18 14:55:49.5117] VERBOSE[6064][C-00000016] bridge_channel.c: Channel PJSIP/eg8otwpk-00000029 joined 'simple_bridge' basic-bridge <d4954226-56e1-42f9-a687-2343da8e2d23>
[...]
[2023-04-18 14:55:55.0747] VERBOSE[6064][C-00000016] res_musiconhold.c: Started music on hold, class 'moh-Tenant1-e91c7e54-2986-4ed2-9a5c-5b233b0f80a7', on channel 'PJSIP/eg8otwpk-00000029'
[2023-04-18 14:55:55.0750] VERBOSE[6134][C-00000016] res_rtp_asterisk.c: 0x7fcad410fe00 -- Strict RTP learning after ICE completion
[2023-04-18 14:55:55.0953] WARNING[6064][C-00000016] format_wav.c: Not a supported wav file format (3). Only PCM encoded, 16 bit, mono, 8kHz/16kHz files are supported with a lowercase '.wav' extension.
[2023-04-18 14:55:55.0953] WARNING[6064][C-00000016] file.c: Unable to open format wav
[2023-04-18 14:55:55.0954] WARNING[6064][C-00000016] res_musiconhold.c: Unable to open file '/var/lib/asterisk/moh/moh-Tenant1-e91c7e54-2986-4ed2-9a5c-5b233b0f80a7/test_invalide': No such file or directory
[2023-04-18 14:55:55.0954] VERBOSE[6064][C-00000016] res_musiconhold.c: Stopped music on hold on PJSIP/eg8otwpk-00000029
What should the behavior be in that case? Should the held user be hearing a silence? Should asterisk send a SIP message saying that it was not possible to put the call on hold?
The incoming side will be on hold (sendonly state), as Asterisk won’t try to reverse that. Asterisk doesn’t actually put the outgoing side on a SIP hold, unless you use moh_passthrough, in which case it doesn’t use MOH.
Do you have a valid default music class. I’d expect it to fallback to that. Without it, it might well continue to relay media. The traditional outgoing hold behaviour was to play a file.
Yes. The default music class is valid and configured. When I remove the custom moh from the endpoint I get the following:
[2023-04-21 10:02:42.2603] -- Channel PJSIP/eg8otwpk-0000000c joined 'simple_bridge' basic-bridge <2b2e8dc8-ffe6-45a3-aa9d-f1278570cc5f>
[...]
[2023-04-21 10:02:52.4653] -- Started music on hold, class 'default', on channel 'PJSIP/eg8otwpk-0000000c'
I am a developer at Wazo, which is a UC Platform based on asterisk. The moh files are created and added through our APIs in a multi-tenant fashion. We include the default asterisk music files with our distribution.
My file, test_invalide.wav, has the following permissions:
The default MOH class that works has the following:
root@ucengine-0:/var/lib/asterisk/moh/default# ls -la
total 17312
drwxrwsr-x 2 asterisk asterisk 4096 Mar 21 15:48 .
drwxrwsr-x 20 asterisk asterisk 4096 Apr 13 10:19 ..
-rw-rw---- 1 asterisk www-data 3908426 Dec 26 2009 macroform-cold_day.wav
-rw-rw---- 1 asterisk www-data 3019752 Dec 26 2009 macroform-robot_dity.wav
-rw-rw---- 1 asterisk www-data 4464220 Dec 26 2009 macroform-the_simplicity.wav
-rw-rw---- 1 asterisk www-data 1169586 Dec 26 2009 manolo_camp-morning_coffee.wav
-rw-rw---- 1 asterisk www-data 5147816 Dec 26 2009 reno_project-system.wav
We plan on adding validation on music files when uploading via our API but for now we have to deal with what exists. It seems like the issue appeared recently.
The setgid bit is set because we want to make sure that our configuration microservice can access those files to manage them. We want all the moh files to be in the same group as the microservice, which is in www-data.
I’m pretty sure that’s not relevant to my issue though.