[OpenSIPS-Users] OPUS transcoding query

[Gregory Massel]

A few factors to consider:

_1. Quality_

1.1. If you transcode to PCMU using RTPengine, you will lose the 
wideband audio quality benefits of Opus. By contrast, if Asterisk 
accepts the calls using Opus, it will transcode internally to sln16 for 
purposes of media processing (playing IVRs, music-on-hold, etc.), 
allowing for superior audio quality on that media (IVR, MOH, etc.). If 
Asterisk is going to be generating media, it would be preferable to let 
it receive the call in Opus.

1.2. If Asterisk is merely bridging endpoints and not generating any 
media nor recording calls and its only media-processing role in your 
scenario is transcoding, then the call quality will, in any case, never 
be better than PCMU quality and there would be no difference in call 
quality whether transcoding within Asterisk or RTPengine.

1.3. If the other side supports some other wideband codec that Asterisk 
doesn't support, RTPengine may be better. E.g For a GSM Mobile network, 
they may support AMR-WB and RTPengine should be able to transcode Opus 
to AMR-WB. This would give a quality advantage to RTPengine over 
Asterisk (although Opus to AMR-WB may be computationally expensive).

1.4. If you're recording some (or all) of the calls within Asterisk, 
consider the format in which you're recording them and the call quality. 
Again, if Asterisk receives the call as Opus and records in a 
high-definition format (e.g. Sln16 or MP3), then the recordings will be 
superior versus if it receives the calls already transcoded to PCMU.

_2. Processing_

2.1. RTPengine is much more efficient at RTP proxying _when using 
in-kernel packet forwarding_ versus non-kernel packet forwarding. The 
difference in terms of CPU usage and system load is significant.

2.1. Per https://github.com/sipwise/rtpengine "Transcoding happens in 
userspace only, so in-kernel packet forwarding will _not be available 
for transcoded codecs_."

2.2. I've not seen any measured benchmarks of Asterisk versus 
RTPengine's _non-kernel_ packet forwarding, however, in my experience, 
both result in similar load on the same hardware. RTPengine does, 
however, materially outperform Asterisk in scenarios where in-kernel 
packet forwarding is possible (i.e. no transcoding required).

2.3. My scenarios never involved transcoding Opus. It's possible that 
either Asterisk or RTPengine may have a superior approach towards the 
transcoding, however, this is extremely unlikely (and even more unlikely 
to have a material impact on performance) as the codecs are the same and 
should follow the same algorithms.

_3. Scale_

3.1. Even on generous hardware, Asterisk is unlikely to comfortably 
transcode more than 1,000 simultaneous Opus-to-PCMU calls.

3.2. I'm not sure about RTPengine, however, it's probably safe to say 
that the transcoding itself is sufficiently computationally expensive 
that you'll encounter a similar limit.

3.3. Depending on your configuration, you may find it easier to have 
OpenSIPS direct calls through a pool of multiple RTPengine servers. By 
comparison, if you're directing calls through to a pool of Asterisk 
servers, you *MAY* have additional complexity (e.g. consider conference 
calls where the Asterisk server needs all the calls on one server in 
order to conference them).

3.4. If you're pushing the limits of Asterisk (e.g. using it to 
conferencing hundreds or thousands of participants), then it would 
almost certainly be wiser to have RTPengine first transcode to PCMU, as 
a single Asterisk box won't be able to perform that volume of 
transcoding and conferencing.

_4. Other_

4.1. WebRTC supports PCMU. Consider establishing the call PCMU-to-PCMU 
from the outset and avoiding transcoding altogether!

4.2. WebRTC generally requires that the media be encrypted with DTLS. If 
RTPengine is already performing the task of decrypting DTLS-encoded 
media, then you may get a performance advantage by transcoding to PCMU 
at the same time, particularly if Asterisk can then cut itself out of 
the media path and direct the media from the RTPengine to the other 
bridged endpoint. In essence, you're then only manipulating the media 
ONCE, not TWICE, cutting down on latency, network traffic, etc. If 
RTPengine first decrypts and then passes decrypted media to Asterisk and 
Asterisk then transcodes, this will likely be less efficient.


So obviously it's not as simple as saying one will always outperform the 
other, however, there are probably more scenarios in which option 2 
would be preferable.


On 2021-07-19 08:53, Mark Allen wrote:
> I wonder if anyone can offer any insights...
>
> We are using OpenSIPS 3.1 as a mid-registrar and in front of an 
> Asterisk box. We include incoming WebRTC traffic using the OPUS codec. 
> Which do you think would be the better option:
>
> 1 - Pass OPUS directly through to Asterisk
> 2 - Use RTPEngine to transcode OPUS to PCMU before passing it on to 
> Asterisk to reduce the workload on the Asterisk box
>
> If option 2 would be the more efficient option, are there any settings 
> we should consider to allow transcoding to be as efficient as possible?
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20210721/52fd5257/attachment.html>