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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
