Feature #6474


Make ortp dependency optional

Added by falconia about 1 month ago. Updated 13 days ago.

In Progress
Target version:
Start date:
Due date:
% Done:


Spec Reference:


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.


  • make ortp optional in libosmo-abis
  • develop new jitter buffer implementation (TW-Jit)
  • support both ortp and twjit options in OsmoBTS
  • make ortp build-optional in OsmoBTS
Actions #1

Updated by falconia about 1 month ago

In 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:

  1. 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.
  2. 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.

Actions #2

Updated by falconia 13 days ago

  • Checklist item make ortp optional in libosmo-abis added
  • Checklist item develop new jitter buffer implementation (TW-Jit) added
  • Checklist item support both ortp and twjit options in OsmoBTS added
  • Checklist item make ortp build-optional in OsmoBTS added
  • Status changed from New to In Progress
  • Assignee set to falconia
  • % Done changed from 0 to 10

The first step is done:

Thanks to this patch, anyone building OsmoCNI for a machine that will be HLR, MSC, BSC etc (anything other than BTS) can simply build libosmo-abis with --disable-ortp and no longer have to deal with that troublesome non-GSM software.

The remaining work is to bring TW-Jit (Themyscira Wireless alternative implementation of RTP input jitter buffer) into Osmocom and make it an option in OsmoBTS. From the perspective of a production GSM network operator, the objective here is to be able to deploy a network in which all RTP jitter buffer instances are TW-Jit rather than Belledonne ortp.

The problem with Belledonne software is that it failed our code quality audit, thus we (Themyscira Wireless) need a viable alternative which we can stand behind and fully maintain. The real objective is to eliminate all Belledonne code from the live executing code path in our production network, not just to ease Slackware build issues.


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)