New rtp.io module (embedded RTPProxy)

[sobomax]

Summary
This PR includes a new rtp.io module which allows to provide media relaying and other RTP manipulations without external media relay.

Details
Traditionally, OpenSIPS only handles signalling, offloading media operation to the external relay. However in some situations using external relay may be undesirable from system complexity point of view and others, so having an option to handle it internally may be useful.

Solution
What rtp.io module does is it starts up a RTP handling threads in the main OpenSIPS process and let rtpproxy module access those threads via a 1:1 socketpair.

The module requires RTPProxy 3.1 or higher, compiled with --enable-librtpproxy.

When rtpproxy module is loaded without arguments and rtp.io is loaded as well, the sockets exported by the rtp.io will be used automatically in the set 0. Otherwise those sockets can be used as part of other set(s) by using "rtp.io:auto" moniker.

Provided is also a CI job that builds rtp.io in a rtpproxy container for all supported architectures and tests it using voiptests package.

Compatibility
None

Closing issues
None

[sobomax]

Need to work around issue with pushing to ghcr, so pipeline works in the PRs.

[github-actions]

Any updates here? No progress has been made in the last 30 days, marking as stale.

[github-actions]

Any updates here? No progress has been made in the last 30 days, marking as stale.

[liviuchircu]

Hey @sobomax ! I tried out the build & startup phase, feedback as follows (from least to most problematic):

1. if librtpproxy.a is built without libsrtp installed, then you install it meanwhile (to fix rtp.io.so build warning about missing libsrtp), you get a silent startup exit due to RTPProxy's rtpp_static_modules_lookup() not finding the dtls_gw module. Small problem at the end of the day, fully fixable through public builds and/or a proper developer README.md.
2. on my system, libsrtp2-1 package was built without AES GCM ciphers, hence there was no GCM define, hence few symbols were missing, such as: srtp_crypto_policy_set_aes_gcm_128_16_auth(), which gave a rtp.io loader error on startup. Also seems like a manageable problem.
3. OpenSIPS does not start anymore with a module which creates a dedicated proc, due to below assert. So it still looks like the PR is in WIP mode here, and we need a solution to restore FIFO/HTTPD/etc. functionality:

    opensips: rtp_io.c:228: child_init: Assertion `rank >= 0' failed.

4. Last but not least, below is how the process/thread architecture looks like, after RTPProxy is booted through the rtpp_main() function, called at mod_init(). We can see that it forks 12 threads in total, but they are part of the "Attendant" process. Which means that if any of them segfaults, the whole attendant process is going down, unable to do "emergency shutdown" things such as dumping usrloc/dialog data to DB, etc. I believe this also needs reworking, ideally we get the entire rtpp_main() to be called from a dedicated process, but I cannot tell the implications off the top of my head, as I haven't given it much though/testing -- maybe moving it there is simply not possible?!

Cheers!

[sobomax]

Hey @sobomax ! I tried out the build & startup phase, feedback as follows (from least to most problematic):

1. if librtpproxy.a is built without libsrtp installed, then you install it meanwhile (to fix rtp.io.so build warning about missing libsrtp), you get a silent startup exit due to RTPProxy's rtpp_static_modules_lookup() not finding the dtls_gw module. Small problem at the end of the day, fully fixable through public builds and/or a proper developer README.md.

Well, edge cases handling is somewhat obviously not very well handled since the module at the moment has only one user (us) and we know how to cook it. :)

Just open a PR against respective README.md in question as user #2. :)

2. on my system, libsrtp2-1 package was built without AES GCM ciphers, hence there was no GCM define, hence few symbols were missing, such as: srtp_crypto_policy_set_aes_gcm_128_16_auth(), which gave a rtp.io loader error on startup. Also seems like a manageable problem.

Well, again, this is more of a call for an action against rtpproxy repository. I build against latest ubuntu and debian on like 6 different architectures (see the appropriate CI pipeline attached). If one of libraries installed on your system @liviuchircu deviates from that and it bothers you, then just open a PR in the https://github.com/sippy/rtpproxy and we'll handle that edge case gracefully. :)

3. OpenSIPS does not start anymore with a module which creates a dedicated proc, due to below assert. So it still looks like the PR is in WIP mode here, and we need a solution to restore FIFO/HTTPD/etc. functionality:

    opensips: rtp_io.c:228: child_init: Assertion `rank >= 0' failed.

Fixed that, thanks for the reporting! We just never use any of the modules in question, so I put it as a safeguard since I did not know what negative value might mean in that somewhat critical code path.

Regarding WIP mode, no. The code is somewhat experimental, yes, but not not a work in progress. The PR is in fact comes with the full working CI pipeline (this is the first module to provide that and the first CI to actually run a call scenario against OpenSIPS in fact) that builds against latest ubuntu and debian releases across 6 architectures and runs against 2 of them (amd64 and riscv).

4. Last but not least, below is how the process/thread architecture looks like, after RTPProxy is booted through the rtpp_main() function, called at mod_init(). We can see that it forks 12 threads in total, but they are part of the "Attendant" process. Which means that if any of them segfaults, the whole attendant process is going down, unable to do "emergency shutdown" things such as dumping usrloc/dialog data to DB, etc. I believe this also needs reworking, ideally we get the entire rtpp_main() to be called from a dedicated process, but I cannot tell the implications off the top of my head, as I haven't given it much though/testing -- maybe moving it there is simply not possible?!

Since it's not impeding any of the functionality this should be more of a feature request than anything else. The last time I saw rtpproxy crashing in production is some 5 years ago across like 300+ systems deployed. And I went to the great deal to make it reality with the glitching and fuzzing CI runs. But no, moving processing to a separate PID is not impossible and is not that difficult if you have time. So, again, good feature request.

Thanks for a review, regards!

-Max

[liviuchircu]

Hey @sobomax -- sure, I can PR against rtpproxy project, or adjacent README.md files, to clarify the build hiccups I ran into. Small problems, at the end of the day -- not that time-consuming.

So we're only left with the threads started by "Attendant" which should get moved into a dedicated process for isolation purposes, before merging this PR.

[sobomax]

@liviuchircu PR updated to fix the noted deficiencies. I've also updated CI to remove 20.04 (being deprecated by the GitHub) and replace it with 24.04 where appropriate.

[liviuchircu]

Great work, @sobomax! Both of the big issues I noted above seem fixed now:

• you can freely load mi_fifo.so or mi_http.so functionality on top of rtp.io.so without breaking OpenSIPS startup
• indeed, the attendant process is no longer forking RTPProxy worker threads, which are nicely isolated as part of the "RTPProxy host process" OpenSIPS worker (see attached picture)

I for one am excited to see the new, self-contained RTPProxy module getting some usage and feedback from the community, it's time to merge it!!