I have read on a website that Asterisk always performs transcoding internally even if both legs of the IP call is using the same Codec.
Example: Calling party is using alaw, Called party is also using alaw, Asterisk in the middle would still transcode like this:
alaw–>internal Codec–>alaw.
Is this true? If it is, isn’t that what limits the scalability of Asterisk?
Is there a documented way to alter this behavior?
On the same website that I mentioned at the beginning, there exist a patch that they claim alters this know behavior of Asterisk and that positively impacts on quality of voice and also on scalability.
They say Asterisk internal format for audio is signed linear and so there is every time a transcoding and thus loss of audio quality, in the normal usage I think this loss isn’t important, at least in the box I installed I never found such problem.
I have to say that I don’t know much about Asterisk internal operating mode, I hope someone else with more knowledge will post more here.
Hopefully this will explain slin transcoding a bit more
[quote]Quote:
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. [/quote]
well…to be honest I am not sure that transcoding is the cause or my problems.
What I know for sure is, when my clients are directly connected to my upstream provider the quality is very good. But when they connect via my Asterisk server the difference in quality is very much noticeable.
I applied the patch from the website I mentioned in my previous post but no difference.
You find the parameter transcode_via_sln in the file asterisk.conf, don’t forget to uncomment the “options” section if is commented and restart Asterisk to apply the setting.
How are you connecting to the upstream provider, by pstn or voip ?