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:
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.
Any ideas or feedback is greatly appreciated.
I think they are wrong, if both legs of the call are using the same codec there is no need to transcode.
Well…I was hoping they are wrong. Could you please have a look at this post and let’s know what you think of it?
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
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
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]
Thanks Ian, it’s clear to me, now.
Sorry, I read this quote but I didn’t really understand it completely.
At the end of the day, what is best combination of Codecs to use to minimise any impact on quality?
I believe if we could use alaw or ulaw all the way is best.
set transcode_via_sln=no and use alaw /ulaw, But are you sure the transcoding is the issue?
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.
Ok…where can I set transcode_via_sln=no ?
thanks for your help
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 ?
My setup is purely voip. I run a SIP trunk to my provider.
So the audio quality problem could be network related, I think you have to check how good is the net connection with your upstream provider.