[asterisk-dev] Re: Help with 240 samples on frames read fromchan_iax

[Dan Austin]

Tilghman wrote:
> On Monday 06 November 2006 09:12, Moises Silva wrote:
>>    Well, now knowing the fundamental cause, im going to the hardest
>> part, finding a solution for the issue on app_conference code, I dont
>> think is a good idea rely on 20ms frames. Or is it possible to make
>> Asterisk use only 20ms frames?

> One could use the ast_smoother interface.  It was designed
specifically
> to take frames of variant sizes and produce frames of a single
expected
> size, precisely what you want to do.

> The basic interface is:

> Initialize with ast_smoother_new(), queue input frames with
> ast_smoother_feed(), get output frames with ast_smoother_read(),
> and when you're done, free the structure with ast_smoother_free().

While the code require seems to beyond my skills/experience, it
would be a major improvement is IAX were to become packetization
aware.  My efforts with RTP packetization showed that IAX will
pass unmolested whatever payload it receives.

So the issue with app_conference is multi-facted.  Sure it would
be nice if it did not assume 20ms, even though that was almost
reasonable assumption pre 1.4.  I say almost because before the
configuration packetization feature was added, I had found that in
most cases Asterisk would deal with any payload that it received.
It would only send 20ms payloads, Moises issue with app_conference
would occur on eny version because of the SPA defaults.

'Fixing' app_conference is a worthy endevour, but convincing
chan_iax to honor framing limits on both the send and receive
legs of a channel would be a big win.  Even better would be
the addition of an IE to convey the desired framing/payload would
allow Asterisk and endpoints to 'negotiate' symmetric packetization.
Chan_skinny has that feature, and it greatly reduces the amount
of effort to make sure all devices are using identical values
for framing.

Dan