[asterisk-bugs] [Asterisk 0010807]: Incorrectly sized IAX2 frames sent from mISDN with b410p

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10807 
====================================================================== 
Reported By:                ZX81
Assigned To:                crich
====================================================================== 
Project:                    Asterisk
Issue ID:                   10807
Category:                   Channels/chan_misdn
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.11  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             09-23-2007 04:27 CDT
Last Modified:              09-28-2007 02:17 CDT
====================================================================== 
Summary:                    Incorrectly sized IAX2 frames sent from mISDN with
b410p
Description: 
With the following setup

PSTN -- BRI --> B410P -> * -> IAX2 Phone/Softphone

The packet sizes are 16ms with a g711.ulaw or alaw codec to the phone.

The phone is expecting 20ms packets (and timestamp differences).

If we use the SIP component of the same softphone (and the same codec) we
get the following:

PSTN -- BRI --> B410P -> * -> SIP Phone/Softphone

With this setup there are no problems.

So, with IAX2 we get a distorted voice (sounds like it is playing 16ms of
samples followed by 4ms of silence every 20ms).

The problem does not occur if you are transcoding to GSM for example
(maybe because the packet sizes have to change anyway).

The reason that the problem occurred in IAX2 and not in SIP is because SIP
is using the ast_smoother.

I saw the patch on 10229 for a problem with choppy audio from incorrect
packet sizes for chan_mobile.  Basically adding a smoother in to the struct
and then initialising it if it hadn't been used followed by filling and
emptying it.

I added it to chan_iax2.c and the problem went away instantly.

My implementation of the smoother is probably somewhat lacking.

I think the problem may be caused by the mISDN channel reading 128 instead
of 160 bytes (is it bytes) from the PSTN.

I also saw the issue with choppy audio when using recent versions of GCC,
and tried the patches for it.

If someone wants me to upload a patch as an example I can, but I'm not
sure how many people will be able to test it (you'd need to have 128
instead of 160 coming in).

It may be that IAX2 is not the place to do the smoothing either.  Anyway
let me know and I'll help how I can.
====================================================================== 

---------------------------------------------------------------------- 
 crich - 09-28-07 02:17  
---------------------------------------------------------------------- 
Reading Audiodata from the hfcmulti chip is done in the timer interrupt
which can be configured to every 8 16 32 64 128 256 samples. So a mISDN
audio chunk is about of one of those sizes, you can configure that in the
misdn-init.conf with the poll parameter.

Anyways I think a Telephony device should be able to handle a different
paket size than the one itself uses. I've seen numerous SIP Phones sending
Audio with Packetsizes X and others using Packetsizes Y (Y!=X) and it still
worked flawlessly.. 

To achieve different chunksizes on needs to buffer the data, that could be
done in hfcmulti/mISDN_dsp/chan_misdn or even in Asterisks generic bridge. 
I thought it might be possible to use the generic jitterbuffer for such a
problem am i mistaken? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-28-07 02:17  crich          Note Added: 0071169                          
======================================================================