[Home]

Summary:ASTERISK-06728: [patch] Empty recordings with length of 4 seconds
Reporter:Marcus Hunger (fnordian)Labels:
Date Opened:2006-04-07 11:35:09Date Closed:2007-03-06 14:19:55.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_voicemail
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-trunk-audio_avail_2.patch
( 1) asterisk-trunk-audio_avail_3.patch
( 2) asterisk-trunk-audio_avail_4.patch
( 3) asterisk-trunk-audio_avail_5.patch
( 4) asterisk-trunk-audio_avail.patch
Description:Recently I found some voicemail-recordings in my voicebox, that claimed to be 4 seconds long, but the .wav-files were almost empty (a wave-header was there). I traced the problem to app.c, which threw a warning "Apr  7 18:19:12 WARNING[30378] app.c: No audio available on SIP/*********" followed by "user hungup".

ast_play_and_record() returns the duration of these failed recordings which is 4 seconds.

these 4 seconds come from the following code:

res = ast_waitfor(chan, 2000);
if (!res) {
  ast_log(LOG_DEBUG, "One waitfor failed, trying another\n");
  /* Try one more time in case of masq */
  res = ast_waitfor(chan, 2000);
  if (!res) {
     ast_log(LOG_WARNING, "No audio available on %s??\n", chan->name);
     res = -1;
  }
}

so the check for audio-availability lasts 4 seconds and then the function returns as if the user has hungup normally.

i created a patch so that ast_play_and_record() sets the duration to 0 seconds and app_voicemail does not create empty messages.
Comments:By: Marcus Hunger (fnordian) 2006-04-07 11:38:32

sorry, wrong category, this should be on "general" :-/
By: Tilghman Lesher (tilghman) 2006-04-07 14:39:40

Disclaimer?
By: Andrey S Pankov (casper) 2006-04-07 15:00:09

Not a good way to treat no audio conditions IMO...
By: Marcus Hunger (fnordian) 2006-04-07 15:14:50

sure, it's just a quick fix. but i think it's better to report 0 seconds than 4 seconds on a "no audio"-recording.
By: Andrey S Pankov (casper) 2006-04-07 16:41:03

This does not fix 4 sec. of no audio if it is in the end of a call.
By: Marcus Hunger (fnordian) 2006-04-07 17:54:54

so, what about decreasing the duration by 4 if we detect a "no audio for 4 seconds"?

maybe we should think about handling "no audio" in a special way. i don't need it right now, but there might be someone how does... what's left to do, if asterisk detects that it did not receive audiodata from the peer besides stopping the recording, closing the channel etc. . decreasing the recording's duration before returning is not such a bad idea. imo
By: Marcus Hunger (fnordian) 2006-04-10 09:45:33

The new patch decreases the duration of the recording by 4 if "No audio" gets triggered.
By: Andrey S Pankov (casper) 2006-04-10 11:49:33

Do you have a disclaimer on file?

Anyway, the patch still is not good enough. If I want 6 sec. of silence to be detected? It will fail after 4 sec., right? And what about ast_play_and_prepend?

Can you discuss the issue on asterisk-dev?

Relationships (that's for me, I'll add more later):
http://bugs.digium.com/view.php?id=6595 [not ready for trunk]
http://bugs.digium.com/view.php?id=6903 [fixed]
http://bugs.digium.com/view.php?id=6907 [?]


By: Marcus Hunger (fnordian) 2006-04-10 12:10:07

Disclaimer on File: yes.

I faxed http://www.digium.com/disclaim.changes to digium.
By: Andrey S Pankov (casper) 2006-04-12 10:03:47

What about addressing no audio condition when silence more than 4 sec. should be detected?
By: Marcus Hunger (fnordian) 2006-04-13 06:44:15

silence != "no audio"

anyway, there is no silence-truncation in ast_play_and_record if "no audio" is detected, but it is in ast_play_and_prepend.

silence in the end of the recording is truncated, but the duration is not decreased. this should be fixed, shouldn't it?

something like: *duration -= totalsilence / 1000;

comments?


By: Andrey S Pankov (casper) 2006-04-13 09:44:12

> silence != "no audio"

You are wrong... if silence suppression is turned on there will be no audio.
By: Marcus Hunger (fnordian) 2006-04-13 10:41:02

casper: sorry, you're right. i hope patch 4 adresses your issue.
By: Andrey S Pankov (casper) 2006-04-13 11:18:25

I'd suggest you to read the discussion in http://bugs.digium.com/view.php?id=6595
and ask on asterisk-dev whether double ast_waifor in case of masq is needed at all. If I'd prefer to ast_waitfor(chan, maxsilence). I may be wrong in any case.

I'd ask you to gather some advices/opinions on asterisk-dev.

It would be nice if you come up with a generic way to detect silence and use it for all of ast_play_and_record, _perpend, ast_getvoice. Maybe for app_amd and app_waitforsilence :)
By: Andrey S Pankov (casper) 2006-05-06 15:24:37

The patch should be updated for current trunk and then I hope to review it.

fnordian: could you handle the job please, thanks!


By: Serge Vecher (serge-v) 2006-05-19 13:48:23

*ping*
By: Andrey S Pankov (casper) 2006-05-19 15:50:00

That's better than nothing...

fnordian: can you confirm your patch solves the original problem you reported
please?

When I have time to do it I hope to fix that in a bit different way.
By: Serge Vecher (serge-v) 2006-06-30 13:40:22

is this actually still an issue in latest trunk with rev > 36000?
By: Andrey S Pankov (casper) 2006-06-30 16:21:59

vechers: yes... that should be fixed in the same way as for ASTERISK-6420 and related issues.
By: jmls (jmls) 2006-10-31 12:34:34.000-0600

can this issue be closed ? Or is it still needed ?
By: jmls (jmls) 2006-11-20 11:47:32.000-0600

ping. housekeeping
By: Serge Vecher (serge-v) 2006-11-21 09:19:20.000-0600

Mithraen: I think you are the most technically apt person that is still interested in this bug -- is the latest patch attached of any use. Is this even an issue in latest 1.4/trunk?
By: Marcus Hunger (fnordian) 2006-11-21 09:26:03.000-0600

I am still interested in this bug, but so far I was not yet able to check for it's existance in the current 1.4/trunk. sorry.
By: jmls (jmls) 2007-02-11 03:33:19.000-0600

fnordian, were you able to check the existence in 1.4 ?
By: Serge Vecher (serge-v) 2007-03-06 14:19:54.000-0600

there have been no confirmation of this bug from anyone. If you are able to reproduce this with 1.4.1 or the latest release, please feel free to reopen with relevant debugging information.