Feature #6474
openMake ortp dependency optional
0%
Description
Right now OsmoCNI suite as a whole has a hard compile-time dependency on ortp: without ortp, one cannot build libosmo-abis, and hence cannot proceed further. However, out of all components that are needed for a 2G-only network, only OsmoBTS uses osmo_ortp, the wrapper around ortp provided by libosmo-abis. Therefore, this heaviweight external sw suite (ortp plus bctoolbox) is needed only on those physical machines that are going to function as a BTS (the embedded Linux part of sysmoBTS, or a box driving an SDR with osmo-bts-trx), but is not truly needed when one is putting together the sw suite for a machine that will be an MSC server, or even a BSC server that is not a BTS.
Furthermore, even in the case of OsmoBTS where the dependency on ortp appears to be fully justified (it is used to implement the jitter buffer at the interface from incoming RTP to fixed-timing GSM TDMA output), there is an alternative on the horizon. As part of Themyscira Wireless project, I have a plan to write my own RTP-input jitter buffer implementation that will be specifically designed for the particular application of RTP transport in GSM RAN, as opposed to the "universal" approach of ortp. ThemWi will need this new jitter buffer implementation as part of our transcoding MGW from IP-based GSM RAN to IP-PSTN: the current version of this MGW translates the RTP stream from RAN without any buffering or retiming, but having gained more operational experience, I have come to realize that our MGW design should be changed to resync the stream toward IP-PSTN to a fixed time base at the MGW, exactly as if we had a TDM-PSTN interface rather than IP-PSTN. The new jitter buffer will thus be implemented first in themwi-mgw and proven there; once it is proven good in ThemWi realm, it can be ported to one of Osmocom libraries, and OsmoBTS can be outfitted with an option to use either ortp or the new ThemWi-based jitter buffer. At that point the dependency on ortp can be made fully optional for the entire OsmoCNI suite end to end.
I propose adding a --disable-ortp option to libosmo-abis that will cause osmo_ortp module and its header file to be excluded from compilation and installation, just like the already existing --disable-dahdi option in the same repository and various --disable-* options in libosmocore. With this option added and no other changes, there will be an immediate pain relief for anyone needing to compile OsmoCNI for a Slackware (or any other strict UNIX philosophy OS/distro) machine that will only be HLR/MSC/BSC/etc but not a BTS. Compiling OsmoBTS will still require an installation of libosmo-abis with ortp enabled (which would remain the default) - but some time in the future the dependency of OsmoBTS on ortp (by way of osmo_ortp) can also be made optional when the new ThemWi jitter buffer becomes a reality.
Updated by falconia 27 days ago
In https://gerrit.osmocom.org/c/libosmo-abis/+/36975 laforge wrote:
I actually consider it a bug that only osmo-bts is using libortp; all other RTP endpoints [in my plans so far] should also use it.
I may of course be convinced otherwise.
Can you please elaborate on your plans to expand ortp usage? Besides OsmoBTS, the only other RTP-touching component (not counting any 3G-only ones) is OsmoMGW - are you planning to add ortp dependency there? As I see it, current OsmoMGW is essentially two very different functions spliced into a single process:
- The function of OsmoMSC-associated OsmoMGW, and that of OsmoBSC-associated OsmoMGW with IP-based BTS, is a packet forwarder that merely passes through (forwards along) each RTP packet as it comes in. In this path there is NO latency-adding jitter buffer at all, be it ortp or some other, and I would be quite opposed to adding any such extra latency here.
- The function of OsmoBSC-associated OsmoMGW with E1-based BTS is an entirely different beast, and is much more akin to the upper layer of OsmoBTS in terms of interfacing from an incoming RTP stream to fixed GSM DL timing. I agree that this part of OsmoMGW is massively in need of improvement - but I haven't done any work in that area as I don't have any E1 BTS hardware.
If you plan on adding ortp jitter buffer to the E1 DL path in OsmoMGW, I won't be able to object to it, especially while my own alternative jitter buffer implementation is still a long time away - but in that case I would be arguing for a --disable-e1 build option in OsmoMGW that would disable the entire E1 subsystem with all of its dependencies, including the to-be-introduced dependency on ortp.
