[Home]

Summary:ASTERISK-03736: Call recording issue with new jitterbuffer
Reporter:jalsot (jalsot)Labels:
Date Opened:2005-03-22 04:38:18.000-0600Date Closed:2008-01-15 15:29:36.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Monitor application makes randomly big files on iax2 call legs (250MB, 450MB, 1.2GB, etc. for some seconds of call). The beginning of file consists of 0x00 bytes.

****** STEPS TO REPRODUCE ******

IAX2-> * -> Zap, Monitor to sln.
The 'in' leg's file size won't start from 0 bytes but from any other random number.

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

exten => s,n,Monitor(sln,${RECORDDIR}/${subdir}/${CALLFILENAME},mb)

CVS-D2005.03.17.00.00.00 works well, while version
CVS-D2005.03.18.00.00.00 doesn't (this time was the new jitterbuffer applied).

I tryed to call from IAX->*->PRI where the codec was alaw (also tryed speex with the same result). I also tryed to turn off plc (genericplc => false) but still got the same.

I also did a PRI->*->PRI with call recording and it looks the issue is not present in this case. This can tell us, that the problem is not with the recording itself.

Also did PRI->*->IAX2. This time I got the problem again, however now the 'out' leg was wrong (I'm getting big files time to time with different sizes).

I recompiled the CVS-HEAD with turned off NEWJB (in chan_iax2.c commented #define NEWJB) and surprisingly the problem went away. I have normal call recording now.

Unfortunately I don't have possibility to try other channels (e.g. SIP), so I cannot be sure that the chan_iax2 is itself broken or something else around new jitterbuffer.
Comments:By: stevekstevek (stevekstevek) 2005-03-23 06:08:16.000-0600

jalsot:

1) What is the source of the IAX2 call:  (i.e. what is calling this box).

2) In you mail on asterisk-dev, you mentioned a trace.  Can you either attach that here, or e-mail it to me (if it's either very large or sensitive in some way) [oops, nevermind, I got the attachment sent to -dev].  I'll investigate this when I get to the office today (have an old ethereal on my notebook :().
By: stevekstevek (stevekstevek) 2005-03-23 06:44:55.000-0600

Actually, the file you attached in e-mail is text output from either ethereal or tethereal.  It is kind of hard to manipulate it this way, but most importantly this format doesn't show the time the packets were captured.

It looks like the source of this call is a relatively modern iaxclient variant, though, based on it supporting speex and all.
By: jalsot (jalsot) 2005-03-25 08:46:56.000-0600

Sorry for long delay, I'm on a trip now and cannot reach my test environment. What I can tell is that I used iaxComm 1.0rc2 on Windows XP.
Were you able to artificially invoke this problem on your system? Do you think this problem somehow relates to our Linux box or configuration?
I would like to help as much as I can.

Please tell me what information would help (unfortunately I cannot reach my ethereal dump).
By: Mark Spencer (markster) 2005-03-26 11:52:32.000-0600

It sounds to me that the problem is in the ->samples field.  Some simple debug will probably indicate that number of samples is off, forcing the readstream to seek.  You could add some debug code to just before the if (ast_seekstream(chan->monitor, ...)) in ast_read / ast_write...
By: stevekstevek (stevekstevek) 2005-03-26 14:44:36.000-0600

I'll look into the samples field; I was thinking it was a different issue entirely, actually (some issue where there were too many INTERP frames being generated due to some set of inputs to the jitterbuffer; I want to update the jitterbuffer such that after sensing X number of lost frames, it goes into "silent" mode, and stops making INTERP frames, since PLC is pretty useless after 2 or 3 consecutive frames.).
By: Mark Spencer (markster) 2005-03-27 17:10:37.000-0600

Might be inteeresting to see what those files actually look like :)
By: stevekstevek (stevekstevek) 2005-03-28 17:04:04.000-0600

I don't seem to be able to reproduce this one..

I'm running CVS-HEAD, I an extensions like this:

exten => 506,1,Noop
exten => 506,n,Monitor(sln,/tmp/monitor/506,mb)
exten => 506,n,Dial(IAX2/guest@ast1/3871)      

It's not exactly like your setup, because you are using Zap, but I have different codecs on each leg, and I have "forcejitterbuffer=yes", which keeps the jitterbuffer in the loop.

I did this about 5 times, and each time, I get two files in /tmp/monitor, which are the same size, and have the correct audio:

stevek@canarsie:/tmp/monitor $ ls -ltr
-rw-r--r--  1 root root 719360 2005-03-28 17:51 506-in.sln
-rw-r--r--  1 root root 719520 2005-03-28 17:51 506-out.sln

I get these this on the console, though:
soxmix: Unknown output file format for '//tmp/monitor/506.sln': File type 'sln' is not known


As far as Mark's suggestion about samples being wrong, I think he's right.  In chan_iax2.c, we set up af.samples based on nonsense..

In the next couple of weeks, one of the additions to the jitterbuffer I'll make is to have asterisk (and iaxclient) tell it what is the "base" duration for the call, as it changes -- i.e. how long is an INTERP frame.  Presently, it's assuming it's the size of the last frame it passed through, which is usually, but not always correct.

Here's a small patch which will at least set samples to be the same value that the jitterbuffer expects:
Index: jitterbuf.c
===================================================================
RCS file: /usr/cvsroot/asterisk/jitterbuf.c,v
retrieving revision 1.1
diff -u -r1.1 jitterbuf.c
--- jitterbuf.c 17 Mar 2005 21:30:19 -0000      1.1
+++ jitterbuf.c 28 Mar 2005 23:01:48 -0000
@@ -659,6 +659,7 @@
    if(thists && thists < lastts) jb_warn("XXXX timestamp roll-back!!!\n");
    lastts = thists;
#endif
+    if(ret == JB_INTERP) frameout->ms = jb->info.last_voice_ms;
    return ret;
}

Can you give that a shot, jalsot?
By: jalsot (jalsot) 2005-03-29 01:38:19.000-0600

I updated to latest CVS HEAD and got the same issue. After applying your patch, the problem did not appear again, I have now normal file sizes and the recorded audio is good as well.

So the patch helped on the problem.

Can I use this patch for operation or this is just a temporary fix which should be avoided? What would be the next step?
Thanks for the fast troubleshooting!
By: stevekstevek (stevekstevek) 2005-03-29 06:38:51.000-0600

Jalsot,

The patch corrects a real problem, and you should use it, and it should be applied to CVS.

In the future, we may solve this problem a different way, but this is correct for now..
By: Mark Spencer (markster) 2005-03-31 15:58:54.000-0600

Fixed in CVS head, thanks!
By: Digium Subversion (svnbot) 2008-01-15 15:29:36.000-0600

Repository: asterisk
Revision: 5324

U   trunk/jitterbuf.c

------------------------------------------------------------------------
r5324 | markster | 2008-01-15 15:29:36 -0600 (Tue, 15 Jan 2008) | 2 lines

Fix jitter buffer for call recording (bug ASTERISK-3736)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=5324