[Home]

Summary:ASTERISK-02913: [patch] app_record with silence detection gets read format stuck
Reporter:cmaj (cmaj)Labels:
Date Opened:2004-12-01 13:40:05.000-0600Date Closed:2004-12-21 15:19:50.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/CodecInterface
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_iax2_format_restricted.patch
( 1) chan_iax2_format_restricted.patch3
( 2) translate_patch_for_iax_recording_format_changes.diff
Description:I dial into a * box via Zap channel, then out to another box via IAX with ULAW codec (after disallow=all, first one allowed in iax.conf, followed by ALAW and GSM.)  I confirm it is ULAW from iax2 show channels on the CLI.

I am trying to record a series of separate prompts on the latter box in one call.  When using the silence detection option of app_record, the read format gets changed from ULAW to SLINEAR first because that's what the DSP wants.  But the value set in the integer rfmt (from chan->read_format) is 0.

After the recording, the app_record attempts to set the read format back to 0, which is the value of the rfmt variable set from chan->read_format before the recording started.  But 0 is UNKNOWN.  Attempting to record again is not possible (without hanging up) because now, to paraphrase the CLI, there's "no path to translate from UNKNOWN to ULAW."

****** ADDITIONAL INFORMATION ******

I'm not sure where the best place to fix this is.  If the value of chan->read_format should really be 0 initially for IAX, meaning I think allow any codec, then the bug is in translate.c

So my patch adjusts translate.c such that when the ast_translator_best_choice function is called and the requested destination is format 0, it is assumed that all codecs are available.  This has the affect, at least for me, of keeping the IAX as ULAW after recording and allowing me to make multiple recordings without hanging up in between.  It kind of lets the codec selection "reinitialize"

Comments:By: Anthony Minessale (anthm) 2004-12-01 14:46:48.000-0600

If the app is hitting app_record and has a read_format of 0 then
that is the real bug so that needs to be tracked down and fixed.
By: cmaj (cmaj) 2004-12-03 10:09:21.000-0600

To help narrow this down some more, I am just going to focus on the Stable CVS branch, ie. 1-0 checkout.  A patch yesterday (not sure by whom, no CVS history file) kind of beats the app into submission:

RCS file: /usr/cvsroot/asterisk/apps/app_record.c,v
retrieving revision 1.21.2.1
retrieving revision 1.21
diff -r1.21.2.1 -r1.21
304c304
<       if ((silence > 0) && rfmt) {
---
>       if (silence > 0) {

But the problem persists, the chan->readformat is still saying 0 when app_record starts.  This patch just makes it stay in SLINEAR.
By: cmaj (cmaj) 2004-12-03 10:27:13.000-0600

I think the second patch corrects the problem.  This is a modification in ast_iax2_new to set the read and write formats to the specified capability.  I can verify with some debugging output in app_record that the format is changing back and forth between 4 (ULAW) and 64 (SLINEAR).

However, it seems like the native format should not be set to the same value, although this breaks many other things.  While this is another problem, I don't get why the actual read and write formats were being set to theoretical values of 0 while the native format is set to the actual demonstrated capability instead of theoretical.  It would seem that should be the other way around.  It looks to be this way in both current and stable CVS.
By: Brian West (bkw918) 2004-12-03 10:39:12.000-0600

http://bugs.digium.com/bug_view_page.php?bug_id=0002519

Related I suspect.

bkw
By: cmaj (cmaj) 2004-12-06 11:42:43.000-0600

patch3 improves the codec selection in cases where the format is actually a list of several formats.  Also, it corrects another flaw in the protocol where a codec is not actually selected until voice begins to flow.  Although the message during the authentication shows the read/write format as 4/4, I kept getting an "Ooh, changed format" message, thus that part of the patch.
By: Olle Johansson (oej) 2004-12-19 07:45:58.000-0600

What's the current status of this? Ready for CVS or still under discussion?

Is this patch disclaimed?

---housekeeping
By: Mark Spencer (markster) 2004-12-19 13:30:30.000-0600

The attached patch is not correct because we cannot have the read and write formats be masks (the way nativeformats can be) but I've done a patch in CVS head that should take care of it properly.  Feel free to reopen if it doesn't.
By: Russell Bryant (russell) 2004-12-21 15:19:50.000-0600

the same fix has been applied to 1.0