[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:              06-04-2008 08:58 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 - 06-04-08 08:58  
---------------------------------------------------------------------- 
the hfc chip can be configured to generate timer IRQs when X bytes are in
the fifo, where X can be a value of:

8bytes, 16bytes, 32bytes, 64bytes, 128bytes, 256bytes

where 256bytes = 32 ms , 128bytes = 16ms , 64bytes = 8ms  and so forth

This timer IRQ is syncronized by the Telco, which is necessary for Slip
free Audio transmission. 

So it is not possible to generate 20ms packets with the hfcmulti driver at
the moment. 

It would be possible to fill a smoother buffer in chan_misdn to produce
only 20ms packets, but this creates additional delay (which makes an
Echocancelor  mandatory). 

Anyway this requires some bit of work in chan_misdn. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-04-08 08:58  crich          Note Added: 0087791                          
======================================================================