[asterisk-dev] 16khz/8khz Translation path

[Moises Silva]

On Mon, Sep 27, 2010 at 10:24 AM, Russell Bryant <russell at digium.com> wrote:

> On Mon, 2010-09-27 at 09:20 -0500, David Vossel wrote:
> > I have noticed this as well and this needs to be investigated.  It is
> possible that the second of audio we use to calculate the the least cost
> translation path is not accurate enough.   If it turns out that G722 is
> actually somehow more cost efficient than using the libresample library then
> we need to come up with a way to force lossless codec translations when they
> are available.
>
> I think that would be a good thing to put in there regardless.  It
> shouldn't be too hard since you already put in some good hooks for
> making the cost calculation take things other than time into account.
>

In this same note, it'd be nice if translators had a flag to decide whether
can be used as a step in the translation path or should only be used when
src/dst match. Sangoma has hardware doing direct conversions between g729,
ulaw, alaw, gsm and others without going thru linear (as far as asterisk
knows). Sometimes Asterisk however will calculate that is faster to
transcode between unrelated codecs, like ilbc and ulaw choosing something
like:

ilbc -> g729 -> ulaw

rather than

ilbc -> linear -> ulaw

Effectively using a g729 resource that could be needed for a real g729 call
and not just as a faster translation step.

Our current work around is give horribly bad cost to our translators by
faking the amount of time it takes to transcode that second of audio on
load. That way Asterisk only uses the translators when there is no other
option. But this is a horrible hack :-)

Another thing that could be useful for both, Digium and Sangoma transcoder
cards is a max use counter. Since the number of transcoders is limited, it'd
be nice if Asterisk could know that certain translators have reached its
limit and do not even try to use them (ie, disable them) so other codecs are
preferred if available.

I may be talking gibberish here though since I am not sure at what point the
legs decide the codec to use, they may not even know or check if there is
translators available and there would be always a race between check and
use.

Currently, as far as I remember, when a translator fails to be created (in
the case the hw limit was reached), Asterisk starts sending tons of warnings
to the CLI about unexpected frame format or something like that, but does
not hangup the call. I believe that was tested with Asterisk 1.4, can
somebody confirm what would be the expected behaviour here? shouldn't
Asterisk hangup the call?

Moises Silva
Senior Software Engineer
Sangoma Technologies Inc. | NEW 100 Renfrew Drive, Suite 100, Markham ON L3R
9R6 Canada
t. 1 905 474 1990 x128 | e. moy at sangoma.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100927/2a2d3acc/attachment.htm