[OpenSIPS-Users] OPUS transcoding query

[Mark Allen]

Thanks very much for your reply. There's a lot to consider but it's really
helpful

On Wed, 21 Jul 2021, 18:27 Gregory Massel, <greg at switchtel.co.za> wrote:

> 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 listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> 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/05e7e526/attachment-0001.html>