ARI Transcoding Trap

During my recent experiments with ARI stress testing, I’ve noticed that despite making all the right decisions for the most part, it does come short in certain specific situations and relies on the programmer to provide the missing bit of intelligence.

Every two- or multi-way conversation in ARI realm is handled by a bridge. There are few types of these objects available, depending on the transcoding capabilities required in each scenario. As described in the manual, the correct type is selected automatically and will even adapt to changing enviroment.

What the manual doesn’t tell you, is that unless you explicitly provide a reference channel when originating a B-leg from your bridge, it will default to Asterisk’s internal sln192 codec, which does result in transcoding on all channels involved in the conversation. Allegedly, this only affects Local/xxx endpoints, but they are commonly used in ARI environments, at least in my case.

For those using the official Python ARI SDK, the solution is as simple as providing the originator parameter when originating any consecutive channel from the bridge. In the most trivial example, it would look somewhat like this:

# A-Leg Setup
a_leg = client.channels.originate(endpoint='Local/xxx', app='ari-app')

# B-Leg Setup
b_leg = client.channels.originate(endpoint='Local/yyy', app='ari-app', originator=a_leg.id)

This simple recipe allows for enormous saving on resources. In our labs, it took an average load of a PBX server from 50% down to 1%. And with further performance improvements introduced in Asterisk 13.10, we actually observed higher CPU load on ARI daemons than on the boxes they controlled.

Obviously, this post only applies to two-way mixing bridges, because in more crowded setups, transcoding cannot be avoided.

1 thought on “ARI Transcoding Trap”

Leave a Reply

Your email address will not be published. Required fields are marked *