<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>A few factors to consider:</p>
<p><u>1. Quality</u><br>
</p>
<p>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.<br>
</p>
<p>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.</p>
<p>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).</p>
<p>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.<br>
</p>
<p><u>2. Processing</u></p>
<p>2.1. RTPengine is much more efficient at RTP proxying <u>when
using in-kernel packet forwarding</u> versus non-kernel packet
forwarding. The difference in terms of CPU usage and system load
is significant.<br>
</p>
<p>2.1. Per <a class="moz-txt-link-freetext" href="https://github.com/sipwise/rtpengine">https://github.com/sipwise/rtpengine</a> "Transcoding
happens in userspace only, so in-kernel packet forwarding will <u>not
be available for transcoded codecs</u>."</p>
<p>2.2. I've not seen any measured benchmarks of Asterisk versus
RTPengine's <u>non-kernel</u> 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).<br>
</p>
<p>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.</p>
<p><u>3. Scale</u></p>
<p>3.1. Even on generous hardware, Asterisk is unlikely to
comfortably transcode more than 1,000 simultaneous Opus-to-PCMU
calls.<br>
</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p><u>4. Other</u><br>
</p>
<p>4.1. WebRTC supports PCMU. Consider establishing the call
PCMU-to-PCMU from the outset and avoiding transcoding altogether!</p>
<p>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.</p>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 2021-07-19 08:53, Mark Allen wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CADaqb1s0ZYs=-Q=eNO1RrVNQ4m2zd8RFc8T+LMh2+6yW5ptcNA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">I wonder if anyone can offer any insights...
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>1 - Pass OPUS directly through to Asterisk </div>
<div>2 - Use RTPEngine to transcode OPUS to PCMU before
passing it on to Asterisk to reduce the workload on the
Asterisk box</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<div class="moz-signature"><span
style="font-size:11.0pt;font-family:Assistant;color:#32444B"><br>
</span></div>
</body>
</html>