[asterisk-dev] iLBC packet loss concealment

[Kevin P. Fleming]

Denis Smirnov wrote:

> Why transcode_via_sln was added, and used by default?

This option does _not_ change the transcoding path at all, in reality.

Example: let's say you have a channel A in GSM mode, and channel B in
iLBC mode

In the old mode (before the option was added, or when it is turned off),
channel A would have no 'read translator', and would have a 'write
translator' that allowed it to accept iLBC (this of course would mean
going from iLBC to SLIN and then to GSM). Similarly, channel B would
have no 'read translator', and would have a 'write translator' that
accepts GSM. As the audio packets pass through the Asterisk core,
(ast_read() and ast_write()) they would be in their original formats.

With transcode_via_sln turned on, channel will have a 'read translator'
that produces SLIN, and a 'write translator' that accepts SLIN. The same
will be true for channel B. The net result is still the same translation
path (GSM <-> SLIN <-> iLBC), but now when the packets pass through the
Asterisk core they are in SLIN mode. This allows things like Monitor(),
MixMonitor() and ChanSpy() to not require any additional translation
steps, because the audio frames are already in the proper format for them.

However... this option will cause any 'direct conversion' that is
possible to be avoided. There are not any current 'direct conversions'
available except for alaw <-> ulaw, though. I will think today about
changing this option to only take effect when the translation path
already goes via SLIN, so that 'direct conversions' that may be
available are not skipped.