Attention is currently required from: jolly, pespin. falconia has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-netif/+/39280?usp=email ) Change subject: bring twjit into libosmo-netif ...................................................................... Patch Set 5: (2 comments) File src/twjit.c: https://gerrit.osmocom.org/c/libosmo-netif/+/39280/comment/a5813703_ff54ac7… : PS2, Line 504: rtph = osmo_rtp_get_hdr(msg); The problem with your argument is that it violates the fundamental model of how twrtp+twjit solution is intended to be used. Please see my other reply to jolly's comment: the intended application of this library is to emulate, as faithfully as possible, what would happen if this RTP link were replaced with a true circuit-switched TDM connection. There are no marker bits in TDM, just a stream of G.711/CLEARMODE octets or Abis/Ater TRAU frames; presence of details such as comfort noise is an aspect of byte/frame stream content that is of no relevance to the transport mechanism, content which the transport mechanism is not allowed to mess with. In TDM-based GSM, if one BSS endpoint emits some number of gap-in-reception BFI frames in between valid speech frames, that gap MUST be delivered to the other end without any artificially induced phase shifts - while your obeyance to marker bits would cause said impermissible distortion. But since neither of us will ever change the other's mind, it seems, I just started working on separating the "true" version of twrtp+twjit, the one intended for use in future ThemWi CN software (beyond currently deployed prototype) and in `tw-e1abis-mgw`, from the Osmocom submission version being considered here. Once all ThemWi software can safely use a version of twrtp+twjit over which I exercise sole authority, the purpose scope of the present `libosmo-netif` patches will be reduced to just providing something that OsmoBTS will be able to use. I will then be more amenable to implementing the option you insist on, as long as it can be disabled in ThemWi deployments. File src/twjit.c: https://gerrit.osmocom.org/c/libosmo-netif/+/39280/comment/adee7280_ccf9f3c… : PS5, Line 486: msgb_free(new_msg); The latter. Both applications you are describing (telephone-event and video codecs) are explicitly, per design intent, outside the scope of application for ThemWi RTP endpoint library. This library is intended for those who have **no** love for packet world or for IETF inventions, who would not use RTP or any form of packet transport and would instead use only physical TDM circuits if one were infinitely rich, and who only do use RTP out of economic necessity. A circuit-switched connection carried via RTP using twrtp library is meant to emulate, as faithfully as possible, how that connection would work in a true circuit-switched architecture: either a 64 kbit/s channel carrying G.711 or ISDN data, or a submultiplexed channel carrying Abis/Ater. When either of these two types of circuit-switched connection is represented in RTP (using TW-TS-001 and TW-TS-002 to represent classic Abis/Ater, or using standard PCMU, PCMA or CLEARMODE payload formats for 64 kbit/s realm), the stream is expected to be perfectly smooth and continuous, with every emitted packet showing a timestamp increment of 160 units without fail. Shenanigans like you just described cannot occur in this environment. If the next objection is going to be along the lines of "that mentality does not belong in Osmocom", my response is: the whole reason why I seek to merge some version of twrtp into `libosmo*` is to make it possible (as an option) to use twrtp+twjit in OsmoBTS, instead of Belledonne ortp. I operate a production network where the BTS end of Abis RTP links is OsmoBTS, while the CN end (where Abis has conceptually turned into Ater) is Themyscira Wireless CN software using an external, not Osmo-incorporated, version of twrtp+twjit. Thus for UL traffic flowing from OsmoBTS to CN, the jitter buffer algorithm is mine, which is what I want. Now I seek to be able to use the same jitter buffer algorithm for the opposite traffic direction on the same link, as opposed to the mystery black box algorithm of Belledonne ortp - hence a need to be able to use the same jitter buffer algorithm in OsmoBTS. P.S. Ater is the not-quite-standardized name used by some vendors of TDM-based GSM BSS for the interface between the BSC and the MSC-colocated TRAU bank, carrying the same formats as Abis, but sharing the hierarchical position of A rather than Abis. In the context of Osmocom+ThemWi, when AoIP interface has been modified to use TW-TS formats, it effectively becomes Ater over IP. -- To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/39280?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-netif Gerrit-Branch: master Gerrit-Change-Id: Ia3be5834571ca18b68939abbcf1ce3a879156658 Gerrit-Change-Number: 39280 Gerrit-PatchSet: 5 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: jolly <andreas(a)eversberg.eu> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: jolly <andreas(a)eversberg.eu> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 19 Aug 2025 19:18:46 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: jolly <andreas(a)eversberg.eu> Comment-In-Reply-To: falconia <falcon(a)freecalypso.org> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>