[asterisk-bugs] [Asterisk 0010807]: Incorrectly sized IAX2 frames sent from mISDN with b410p
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Aug 5 17:50:53 CDT 2008
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: 2007-09-23 04:27 CDT
Last Modified: 2008-08-05 17:50 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.
======================================================================
----------------------------------------------------------------------
(0091114) kpfleming (administrator) - 2008-08-05 17:50
http://bugs.digium.com/view.php?id=10807#c91114
----------------------------------------------------------------------
I don't believe there is any problem in Asterisk here at all; the IAX2
protocol allows for specification of media stream format and sampling rate,
but NOT framing rate. In other words, an IAX2 endpoint must be prepared to
receive media frames consisting of any legal number of bytes for the codec
in use. For sample-based codecs like G.711, this could be any amount from
one sample up to maximum size that can be carried in a UDP packet using
IAX2.
The only problem here is that the IAX2 implementation in the softphone you
are testing with assumes it will receive only media frames of 20ms of
samples, but that assumption is in error. It must be prepared to receive
frames with any number of samples, and do smoothing (and jitter handling)
on its own.
The same is true of any applications in Asterisk, by the way: if the
application requires frames of a known size, it must its own smoother to
achieve that.
Issue History
Date Modified Username Field Change
======================================================================
2008-08-05 17:50 kpfleming Note Added: 0091114
======================================================================
More information about the asterisk-bugs
mailing list