Need help with a voicemail bug

I have a weird problem. This is with FreePBX but it’s an Asterisk (version 22.5.2) problem not a FreePBX problem.

We are finding that when we setup voicemail on extensions, that when people record greetings or they call each other and leave messages, using a video phone, that in many cases the greetings and messages are saved with video. The files are located in /var/spool/asterisk/voicemail/default/XXXX where XXXX is the extension number.

The messages and greeting files have an extension .h264 for the video and .wav for the audio.

Now, I don’t care if people do this - but the problem is that we are finding that during message playback, that the video portion playing back is EXTREMELY slow to the point that it is like 1 frame per every 2 seconds or so.

Is there any way we can set a flag in the system to NOT record the video portion of calls that have video? Obviously, these are NOT calls that are coming in from the PSTN - they are calls that are intraorganizational calls. PSTN calls don’t record video because there is no video from PSTN. If the phones are connected with each other normally then there’s no problem with the video, but if they leave a message the system tries recording the video and playing it back. I’m not sure if it’s the recording or the playback that’s slow but the slowness is interfering with proper operation of voicemail.

Thanks!

The video playback issue is a core video playback issue, it’s been around for awhile but noone has done any fixes to resolve it. There is no option that I’m aware of to disable video recording.

I notice this was discussed with regards to trunks, here:

and there is a solution dealing with the sip INVITE.

As a call to the voicemail system is, I believe, establishing a sip to sip connection from the extension to Asterisk, why not simply add an option in the Asterisk config file to have the voicemail system only offer a user selectable codec or set of codecs during negotiation instead of going off the list of allowed system codecs in asterisk config? The admin can then just specify voice codec for use with voicemail system. Then if the phone still sends video even after no video codec is available, you can mark this down as a braindead phone…

I was hesitant to mark this as a bug but it sounds like it is.

There does seem to be a hack in FreePBX:

Settings → Voicemail Admin → Settings → File Format and set the format to wav.

It’s a single SIP connection to Asterisk, and then internally things are done. Ultimately it’s code, so it could possibly be done if someone did it.

It’s a bug that video playback is slow. It would be a feature request for voicemail to have greater control over negotiated codecs.

Well voicemail video playback being slow may be a bug but it’s squashable with a feature request. :slight_smile:

No. It’s not. That doesn’t solve the fundamental problem of video playback being slow with ALL recording and playback.

Tried this hack and it did not work. Video is still being recorded to VMs.

My terrible hack is a script that runs every few minutes:

#!/bin/sh

cd /var/spool/asterisk/voicemail/default

find . -print | grep ‘msg[0-9][0-9][0-9][0-9]’.h264 |xargs rm

It works without trashing the temp files while the system is writing them out, but only after the system finishes and closes the temp file does it come along a few minutes later and delete the video file, leaving the recorded audio message.

I have to do the same thing looking for the recorded video greetings since those are the biggest culprit.

Maybe instead of

cd /var/spool/asterisk/voicemail/default
find . -print | grep ‘msg[0-9][0-9][0-9][0-9]’.h264 |xargs rm

this would work

find /var/spool/asterisk/voicemail/default/ -type f -regex ‘.*msg[0-9]*\.gsm’ -delete

There are a couple problems with that. First, while the message is being recorded the filename has “tmp” inserted in it so if your find ran at the precise instant someone was recording a message into a temporary file, the tempfile would be removed and that could mess up the voicemail process. Second, the video files are not recorded with a suffix of .gsm but instead .h264. We don’t want to remove the audio files but rather the recorded video files so when someone is accessing their mailbox they will only get audio files played back.

Otherwise, yes the find command could be written in one line without piping the output through xargs

Incidentally, this slow playback is a bug that was introduced to Asterisk by fixing another bug. It is documented here:

ASTERISK-28256: Video plays back in slow motion

ASTERISK-27125: Core/Codec: Video playback extremely slow, around 1FPS

ASTERISK-26554: format_h264: ControlPlayback() running slowly

The following patch was suggested in the last report:

“By: Adam Caldwell (alcanzar) 2021-10-05 17:55:08.994-0500

i got rid of the 1/10 speed by patching main/file.c:

In {{static enum fsread_res ast_readvideo_callback(struct ast_filestream *s)}}
Change this line to have /8 as shown:
{{ast_channel_vstreamid_set(s->owner, ast_sched_add(ast_channel_sched(s->owner), whennext / (ast_format_get_sample_rate(s->fmt->format) / 1000)/8, ast_fsread_video, s));}}

It works for me, but I’m not sure it’s the right fix… so just leaving this comment here.

I believe that the correct fix should look at the sample rate for the audio (8000) and divide it by the sample rate for the video (which comes up as 1000), but I’m not certain.”

So, I would put it to jcolp - you have your history of how the bug was introduced - you have a fix - why wasn’t it reviewed and put into the distribution?

Because noone took it from the issue tracker and put it through the actual code review and inclusion process. Sticking something up as an issue comment doesn’t guarantee that will happen.

I take it that process is here, then:

Code Contribution - Asterisk Documentation

I have a production environment and test/prototyping environment setup with these phones. I’ll see what I can do.

That is the current contribution process, yes.