[Home]

Summary:ASTERISK-16981: Voicemail notification - Incorrect VM Duration
Reporter:Mary Ciuciu (mciuciu)Labels:
Date Opened:2010-11-18 13:34:26.000-0600Date Closed:2011-09-20 17:42:40
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_voicemail
Versions:Frequency of
Occurrence
Related
Issues:
is related toASTERISK-02234 [patch] Empty messages should not result in a voicemail
Environment:Attachments:( 0) voicemail.conf
Description:Hello,

We are using Asterisk SVN-branch-1.8-r294905M on Linux CentOS 5.5.
The e-mail voicemail notification message reports an incorrect voicemail duration. For example although the voicemail recording is 20 seconds long the notif message displays a duration of 4 seconds. This did not happend on Asterisk vers 1.6 which we previously had.

Regards,
Mciuciu
Comments:By: Leif Madsen (lmadsen) 2010-12-06 13:56:35.000-0600

You'll have to provide at least a dialplan, voicemail.conf and console information with debug level logging so we can see what is happening and attempt to reproduce the issue.

Without being able to reproduce the issue it is going to be very difficult to resolve.
By: wurstsalat (wurstsalat) 2010-12-16 07:29:04.000-0600

I can confirm this with Asterisk 1.8.1 on Debian Lenny 64Bit using odbc_storage.

Additionally I recognised that when using attach=yes, the attached .WAV file has a different number than announced in the mail, e.g.

"just wanted to let you know you were just left a 0:01 long message (number 4)"

and attached is file msg0003.WAV.

I guess the problem is that msgnum starts counting with 0 instead of 1.
By: Matt Jordan (mjordan) 2011-07-01 12:39:37.805-0500

Mary Ciuciu or wurstsalat -

Is this still an issue?  If so, do you happen to know what your format parameter was in voicemail.conf?  The formats used and the order that they appear in that parameter help to determine how the duration is calculated.

Thanks

Matt
By: Matt Jordan (mjordan) 2011-08-04 08:02:38.084-0500

Mary Ciuciu or wurstsalat -

Is this still an issue? If so, do you happen to know what your format parameter was in voicemail.conf? The formats used and the order that they appear in that parameter help to determine how the duration is calculated.

Thanks

Matt

By: Leif Madsen (lmadsen) 2011-08-11 13:35:01.492-0500

Assigned to reporter as we need feedback.
By: Brad House (brad_mssw) 2011-08-22 10:26:07.192-0500

I, too, am experiencing this same issue. When leaving a 25s voicemail, the duration shows as 8s. This is especially a problem when max_secs=4 and say a real 10s voicemail is left, but it is calculated to be less than max_secs.

Asterisk 1.8.6.0-rc1 on Ubuntu 10.04 LTS amd64.  Could not use 1.8.5.0 as the binary packages for Ubuntu did not support PRI. Did not have this issue with 1.6.
By: Matt Jordan (mjordan) 2011-08-22 10:33:10.076-0500

Reassigning given Brad's feedback.
By: Brad House (brad_mssw) 2011-08-22 19:14:57.947-0500

FYI, pabelanger rebuilt the digium 1.8.5.0 binary package for ubuntu 10.04 amd64 to fix the PRI issue.  The voicemail issue remains, so this does not appear to be a recently introduced issue.
By: Brad House (brad_mssw) 2011-08-22 19:22:43.111-0500

FYI, tried these format strings as a test:  'gsm|wav', 'wav', 'wav49' (as well as the default 'wav49|gsm|wav') all experience the same issue
By: KevinH (kevinh001) 2011-08-22 20:31:01.058-0500

I too am experiencing this with 1.8.5. I'm using just 'wav' with an IMAP backend. The duration noted in the email is about 4 times less than what the voicemail message really is, as others have expressed above.
By: Karsten Wemheuer (kwemheuer) 2011-08-25 09:11:21.236-0500

I put some debug logging in the code trying to find the source of this issue.

In app_voicemail there is a call to function ast_play_and_record_full, which returns the duration of the recorded voicemail. The function ast_play_and_record_full calls __ast_play_and_record in app.c. The calculation of the duration can be found in this peace of code:
{code:title=app.c, Line 945|borderStyle=solid}
/*!\note
* Instead of asking how much time passed (end - start), calculate the number
* of seconds of audio which actually went into the file.  This fixes a
* problem where audio is stopped up on the network and never gets to us.
*
* Note that we still want to use the number of seconds passed for the max
* message, otherwise we could get a situation where this stream is never
* closed (which would create a resource leak).
*/
*duration = others[0] ? ast_tellstream(others[0]) / 8000 : 0;
{code}
At this point duration is set to a correct value. In the next lines the value is corrupted while doing some strange calculations:
{code:title=app.c|borderStyle=solid}
if (!prepend) {
/* Reduce duration by a total silence amount */
if (olddspsilence <= dspsilence) {
totalsilence += dspsilence;
}

        if (totalsilence > 0)
*duration -= (totalsilence - 200) / 1000;
if (*duration < 0) {
*duration = 0;
}
{code}
Maybe someone with a deeper knowledge of the silence calculation and the source of the variables taken into account in the lines above can check, why the duration is corrupted at this point.

By: Brad House (brad_mssw) 2011-08-25 20:59:38.352-0500

Hah, wow, think I figured out what it is actually doing thanks to Karsten's find.  Just made a test voicemail to confirm.  It is subtracting the total amount of silence in the call (e.g. silence BETWEEN WORDS).  Seriously, try it, leave a voicemail and just stream some monotonous tone, constantly ... try not to take a breath ;)  Guess what, the time reported is right when you do that.

So I really don't think it should be subtracting total silence from the duration.  Doesn't really make sense to me.  I guess this doesn't affect people that have a lot of background noise (or a device that doesn't cancel the background noise).
By: Matt Jordan (mjordan) 2011-08-30 09:15:54.213-0500

This was changed as part of the resolution for ASTERISK-2234.  The discussion there confirms what you suspected - the message duration consists only of those portions of the message that are not considered silence.

"I accumulate silence across the entire message because I want duration to be correct. I believe gsm doesn't record silence (neither duration nor file size increases), and truncates it.

Say you got a voicemail that a speaker was online for 60 seconds, but spoke for only 30 seconds of that time and the recording codec only recorded 30 seconds worth. You get notified of a 60 second voicemail, but the message is only 30 seconds long? I don't know which file formats this applies to, though..."

The issue reporter's position may not work for all formats, since not all truncate out the silence (WAV, apparently, being one of those).  Since this calculation approach was introduced deliberately, we'll have to discuss it a bit before we come up with a solution.

As an side, my Polycom phone has sufficient background noise that the only way I could reproduce this was to use my mute button.  Thanks everyone for posting your methods for reproducing this!

Would someone be willing to reduce the silencethreshold to see if this works around this problem for now?  Reducing it to something less than 128 should make the silence detection much more sensitive (your numbers should be divisible by 8 - so 96, 64 are good candidates)
By: Byron Clark (byronclark) 2011-08-30 10:01:23.056-0500

Setting silencethreshold=32 improves the situation, but does not resolve the issue for me. When leaving a 12 second message with some gaps, it is now reported as 7 seconds long instead of the 3 seconds I'm seeing when silencethreshold=128.
By: Matt Jordan (mjordan) 2011-08-30 10:34:39.115-0500

I've prototyped up a fix for this that only reduces the duration in the case of silence accumulated at the end of a message, but I'm still cleaning it up.  One scenario that is problematic is the following:

1. Assume you have a sufficiently long maxsilence parameter, say 10 seconds
2. Assume your minimum message duration is 4 seconds
3. Leave a voicemail with silence for the first 8 seconds
4. Speak for 2 seconds, resetting the maxsilence count
5. Leave silence for 8 seconds
6. Speak again for 1 second
7. Leave silence for 10 seconds.

The voicemail will end the call after the 10 seconds, with a reported message duration of 19 seconds, but in effect, we will have 'slipped by' the minimum message duration.  I'm not sure how problematic this scenario would be for people, but I have a feeling that this scenario was one of the issues that the original patch was attempting to address.
By: Gareth Blades (gblades_skymarket) 2012-01-17 09:10:26.380-0600

We are running Asterisk 1.8.6.0 and are experiencing this problem also.
What was the outcome of this bug as its unclear to me from the comments?
By: Brad House (brad_mssw) 2012-01-17 09:29:08.697-0600

This issue was corrected in 1.8.8.0
By: Josh Adams (jbillings86@gmail.com) 2012-12-11 08:58:30.034-0600

I am experiencing this issue in Asterisk 1.8.18.0. I recently upgraded from Asterisk 1.4.32 and did not have the issue.

@Brad: Can you provide more info about how this issue was corrected?