Over the past week we’ve noticed that, when bridging a local channel created with ARI, audio processing uses excessive amounts of CPU time. After some digging, we determined the cause, have some recommendations, and have a patch up for review.

The cause:

When you create a local channel via ARI and don’t specify an “originator”
channel, there’s no information available to limit the codecs (actually formats) that the local channel can use. As a result, we add ALL audio formats to the channel’s capability list. When it comes time to make the local channel compatible with another channel, like adding it to a bridge, the make-compatible code chooses the best format available to preserve quality. Since all audio formats were in the local channel’s capability list this results in SLIN @ 192KHz being used. While this is best for preserving quality, it’s the worst for performance and overkill for most applications.

Recommendations:

If you need a local channel, create it after a remote channel like SIP or PJSIP and specify the remote channel as the local channel’s originator. When this happens, the local channel’s capability list will be limited to the remote channel’s capability list. If you have 2 local channels, you’ll probably need the patch…

Patch:

There’s a patch [1] up for review that adds a new parameter ‘formats’ to the ARI channels object. With it you can specify a comma-separated list of the formats that this channel can use if an originator isn’t available. For instance, if you know that your environment needs only ulaw, you can specify ‘formats: “ulaw”‘ in the JSON for ‘/ari/channels’. This prevents the addition of all audio formats to the capability list.

Codec vs Format:

Sometimes we use the terms interchangeably but a format is basically codec plus sample rate. For instance, the signed linear ‘slin’ codec could use many sample rates from the default of 8KHz up to 192KHz. The format is specific though: slin16 is signed linear at 16KHz. With this patch, the CLI command ‘core show codecs’ will show the default formats associated with each codec.

[1] https://gerrit.asterisk.org/2917