Re: [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,  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 

Re: [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 

[OpenSIPS-Users] OpenSIPS 3.2.0 LTS goes stable

[Bogdan-Andrei Iancu]

   OpenSIPS 3.2.0 LTS


   goes from beta to stable



*It got stable!*

There were like two months of work, of testing, of reporting and of 
fixing, but we did it! The OpenSIPS 3.2 release passed all the tests and 
exams and now it is labelled as stable LTS release, the flagship of the 
OpenSIPS project.


Download it now 

*3.2 Philosophy*

The 3.2 release focuses on increasing OpenSIPS's ability to *integrate 
with cloud specific services / backends* and it brings more OpenSIPS 
capabilities for building *distributed (multi PoP/location/DC/zone) SIP 
services*. Main key features are:


 * Improved Clustering Engine and more cluster-enabled modules
 * RTP re-anchoring
 * Prometheus and Kafka support
 * WolfSSL replacing libSSL
 * DIAMETER support
 * B2B controlled via OpenSIPS scripting
 * Statistic series

Read more on 3.2



*3.3 Security audit*

As security is really important for us all, the OpenSIPS 3.2 is the 
first to benefit of a *professional security audit* 
 (pentests). It is a 
public endeavor, so consider being part of it.



Download and enjoy it as it's freshly baked for you!

Any questions? do not hesitate to contact us !




--
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] add_path_received and TLS - received address problem

[Liviu Chircu]

On 21.07.2021 17:47, Mark Allen wrote:
I'm seeing errors for pinger OPTIONS and Asterisk NOTIFY SIP messages 
going out to the NATed TLS UAC...


ERROR:core:unescape_user: invalid hex digit <37>
ERROR:path:path_rr_callback: failed to unescape 
received=sip:35.x.x.x:60026%%3btransport%%3dtls


The core problem seem to be those doubled '%%' strings, which are not 
supposed to work that way.  Which scenario of the two below would you 
say we are in, and with what degree of certainty? (i.e. if you could 
share a .pcap with me via email, that would be great!)


A.  OpenSIPS generates those erroneous '%%' strings right from the 
beginning, when building the Path headers and passing through the 
SUBSCRIBE or REGISTER requests.


B.  The Path headers are okay when generated by OpenSIPS (containing 
just '%3b' and '%3d'), but the issue is on the backend side, which 
originates ping messages with doubled '%%' strings in Route headers, 
which OpenSIPS is obviously having a hard time parsing/routing?


Thanks,

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com
OpenSIPS Summit 2021 Distributed | www.opensips.org/events


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] add_path_received and TLS - received address problem

[Mark Allen]

Hi Liviu - thanks for getting back to me.

I'm seeing errors for pinger OPTIONS and Asterisk NOTIFY SIP messages going
out to the NATed TLS UAC...

ERROR:core:unescape_user: invalid hex digit <37>
ERROR:path:path_rr_callback: failed to unescape
received=sip:35.x.x.x:60026%%3btransport%%3dtls
ERROR:core:tcp_connect_blocking_timeout: connect timed out, 99204 us
elapsed out of 10 us
ERROR:proto_tls:tls_sync_connect: tcp_blocking_connect failed
ERROR:proto_tls:proto_tls_send: connect failed
ERROR:tm:msg_send: send() to 35.210.77.199:50052 for proto tls/3 failed
ERROR:tm:t_forward_nonack: sending request failed




On Wed, 21 Jul 2021, 10:56 Liviu Chircu,  wrote:

> On 20.07.2021 13:26, Mark Allen wrote:
> > On registration add_path_received() works but the received address is
> > not formatted correctly. I am seeing '%%3b' instead of a semicolon,
> > and '%%3d' instead of an equals sign.
> >
> Hi Mark,
>
> How exactly is this peculiar formatting breaking your logic?  Because
> the '%'-escaping logic is by design, with a similar un-escaping logic
> being included in the code that parses those Path headers, so the UDP
> <-> TLS translation using Path headers should work just fine.
>
> See this commit for full details on how the escaping logic solves
> multiple problems with the original approach: [1].
>
> PS: with 3 years having passed since I wrote that commit, nowadays I
> would look at a different way of solving the same problem, as I vaguely
> recall that URI param values can be enclosed in double-quotes ("),
> allowing us to put anything in there, without affecting the semantics of
> the original URI.  Just an idea that we could research/confirm/infirm
> should we find any non-fixable issues with the current escaping approach.
>
> [1]: https://github.com/OpenSIPS/opensips/commit/b3bf15646affe981d4b26
>
> Best Regards,
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
> OpenSIPS Summit 2021 Distributed | www.opensips.org/events
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Opensips CP Permissions "RELOAD on SERVER" produces error

[Jeff Wilkie]

Opensips 3.1.2
CP 8.3.1
Debian 10

When adding permissions, I hit "Reload on Server" but I get the
following error:

Sending to *json:127.0.0.1:/mi * : MI command
failed with code -32601 (Method not found)

I
I don't get this error on any other page but this one when attempting to
"Reload on Server".  Is there something specifically wrong with this page
and how it uses the MI command structure?  Again, All other pages that use
the "Reload on Server" give a 200ok and work as expected.

Thanks,

Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] add_path_received and TLS - received address problem

[Liviu Chircu]

On 20.07.2021 13:26, Mark Allen wrote:
On registration add_path_received() works but the received address is 
not formatted correctly. I am seeing '%%3b' instead of a semicolon, 
and '%%3d' instead of an equals sign.



Hi Mark,

How exactly is this peculiar formatting breaking your logic?  Because 
the '%'-escaping logic is by design, with a similar un-escaping logic 
being included in the code that parses those Path headers, so the UDP 
<-> TLS translation using Path headers should work just fine.


See this commit for full details on how the escaping logic solves 
multiple problems with the original approach: [1].


PS: with 3 years having passed since I wrote that commit, nowadays I 
would look at a different way of solving the same problem, as I vaguely 
recall that URI param values can be enclosed in double-quotes ("), 
allowing us to put anything in there, without affecting the semantics of 
the original URI.  Just an idea that we could research/confirm/infirm 
should we find any non-fixable issues with the current escaping approach.


[1]: https://github.com/OpenSIPS/opensips/commit/b3bf15646affe981d4b26

Best Regards,

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com
OpenSIPS Summit 2021 Distributed | www.opensips.org/events


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users