[Asterisk-Dev] Problems with call recording (and NEWJB?)

[Tamas J]

Hello,

Steve Kann wrote:
> 
> Tamas,
> 
>    Do calls which are not being monitored work well with the New JB?  I
> can see two possibilities here:
I did a test call without recording:
*CLI> iax2 show netstats
                                -------- LOCAL ---------------------
-------- REMOTE --------------------
Channel                    RTT  Jit  Del  Lost   %  Drop  OOO  Kpkts
Jit  Del  Lost   %  Drop  OOO  Kpkts
IAX2/Jalsovszky-notebook@   35   12   61     0   0     0    0      1
0    0     0   0     0    0      0

iax2 show channels showed:
Lag: 00000ms
Jitter: 0014ms
JitBuf: 0061ms
Format: speex

While I called myself, I didn't notice any problem in the voice call.
Both sides were ok.
Practically with call recording I got similar values:
*CLI> iax2 show netstats
                                -------- LOCAL ---------------------
-------- REMOTE --------------------
Channel                    RTT  Jit  Del  Lost   %  Drop  OOO  Kpkts
Jit  Del  Lost   %  Drop  OOO  Kpkts
IAX2/Jalsovszky-notebook@   42   16   61     0   0     0    0      1
0    0     0   0     0    0      0

> 
> a) There's a problem with the NEWJB handling something about your
> environment;  generally, you'd see this on the calls going IAX->*->PRI
> you mention.  See the new README.jitterbuffer, or my previous e-mails to
> the list for debugging steps here.  Do iax2 show netstats to see what
> the jitterbuffer is doing..
> 
> b) There's some strange interaction between res_monitor, (or more
> specifically, the monitoring stuff in channel.c, and ast_writestream and
> friends), and the new JB.   Perhaps it is barfing when it sees
> interpolation frames (voice frames with datalen==0), or something, but
> if you're recording to slinear, the PLC should actually make more normal
> voice frames in this case..

In my case there should not be any network issue, as I'm near to the
server. On another machine this problem occurs with clients on local LAN
using a/ulaw as well. In that case the network was:
IAX softphone -> LAN -> * in LAN -> PRI
In my test case:
IAX softphone -> ADSL (1024/256) -> * in a good IP connection -> PRI (telco)

I made a packet dump (attached to the mail - hopefully it will go through).
What elso should I include?

Thanks in advance!

Kind regards,
	Tamas

ps: I made a ticket for this issue yesterday: 0003826

> Tamas J wrote:
> 
>> Update:
>> 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.
>>
>> Regards,
>>     Tamas
>>
>> ps: probably I should prepare a bug ticket now...
>>
>> Tamas Jalsovszky wrote:
>>  
>>
>>> Update:
>>>
>>> I did more compilation and found:
>>> version CVS-D2005.03.17.00.00.00 still works, while version
>>> CVS-D2005.03.18.00.00.00 doesn't.
>>>
>>> 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.
>>>
>>> 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).
>>>
>>> Regards,
>>>     Tamas
>>>
>>> Tamas Jalsovszky wrote:
>>>
>>>   
>>>
>>>> Hello!
>>>>
>>>> I use call recording (Monitor application) and right upgraded to CVS
>>>> HEAD of Asterisk. For my surprise, the recording went really bad. This
>>>> means, that my 'in' call leg's file size started about 430MB.
>>>> Interesting is, that the 'out' recording is normal.
>>>> I'm recording into sln format and the wrong file consists of 0x00 data
>>>> at the beginning (I guess, the 1st unneeded megabytes).
>>>>
>>>> Version CVS-D2005.03.10.17.10.00 looks to be OK (the previouse
>>>> version I
>>>> used).
>>>>
>>>> I use:
>>>> exten => s,8,Monitor(sln,${RECORDDIR}/${subdir}/${CALLFILENAME},mb)
>>>> The filename is good, that shouldn't be the problem.
>>>>
>>>> Can anybody help?
>>>>
>>>> Thanks in advance,
>>>>     Tamas
>>>>     
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.zip
Type: application/x-zip-compressed
Size: 23442 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20050323/01288678/test.bin