Dear Osmocom community,
There is a new feature in OsmoBTS: ability to use twrtp+twjit instead of ortp. The patches were merged to master just over 24 h ago, and should now be included in the official nightly builds for Debian-style distros and for sysmoBTS hw.
The new vty setting is 'rtp library' under 'bts 0' node: if you set 'rtp library twrtp', the BTS application will use the new twrtp library to operate the RTP endpoint that goes with every TCH activated for a speech or CSD call, and it will use twjit component of twrtp for the tricky task of mapping received RTP packets to ticks of the internal fixed time base used for radio Tx - the jitter buffer function. When twrtp library is selected, the old 'rtp jitter-buffer' setting will have no effect - it is specific to the 3rd party ortp library which twrtp seeks to replace. Instead the way to configure the amount of jitter buffering (trade-off between added latency and ability to tolerate more jitter) and other twjit algorithm tunings is via the new 'twjit' vty node that appears under 'bts 0'.
The algorithm used by twjit, its theoretical basis and its tunable parameters are thoroughly documented. The document source lives in libosmo-netif along with the code; a PDF rendition can be found here:
https://www.freecalypso.org/TW-doc/twrtp-guide-osmo.pdf
My original reasons for developing twrtp+twjit and getting this facility integrated into Osmocom were and are:
1) I tried to understand the algorithm used by ortp for the jitter buffer function, and found it resistant to understanding. I naturally seek to eliminate non-understandable black boxes from my GSM networks, hence the project was undertaken to implement a replacement library whose algorithmic design is exactly what I want for high-quality GSM networks.
2) ortp is not a simple lean library, instead it drags a long chain of further dependencies along with it, many dealing with functionality that was never used in Osmocom. This unjustified increase in the list of dependencies is a major pain point for minimalist systems/distros such as Slackware.
When I embarked on this project in the Northern hemisphere summer of 2024, I assumed that everyone else in Osmocom was perfectly happy with ortp and that my networks would be the only ones using the alternative of twrtp+twjit. However, when twrtp and twjit were undergoing code review for integration into libosmo-netif, Pau indicated that others in Osmocom have also become somewhat dissatisfied with ortp external dependency, and very surprisingly to me, expressed a desire to eventually stop using ortp and use only twrtp instead. It does make sense, though: twrtp and twjit are built on top of libosmocore primitives (msgb, osmo_io etc) and specifically written for use in Osmocom environment, while ortp is non-native...
However, before there can be any talk about twrtp becoming the new default or removing support for ortp, the new config of OsmoBTS using twrtp+twjit needs to be tested a lot more extensively, by more than just me, in network environments that may be very different from mine. This invitation to test twrtp in OsmoBTS is the primary purpose of the present post. For everyone who feels brave or has some spare cycles, please try setting 'rtp library twrtp' in your OsmoBTS vty config, and then test some voice (or CSD) calls in your environment. Tests in GSM networks that aren't self-contained (can do more than internal switching between an MO leg and an MT leg inside the same network) would be particularly interesting: in a self-contained Osmocom network with internal MNCC the only possible RTP path is osmo-bts -> multiple osmo-mgw packet forwarder instances -> osmo-bts, while networks with external connectivity can be much more varied.
In any case, I would appreciate hearing some feedback regarding twrtp in OsmoBTS. :)
Happy hacking, Mother Mychaela