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