August 2025 - gerrit-log - lists.osmocom.org

[XL] Change in libosmo-netif[master]: bring twjit into libosmo-netif
by falconia 19 Aug '25

19 Aug '25

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); > > this smooth packet flow will be delivered to the fixed timing application perfectly in order, with […] 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); > Is there a twjit instance for every payload type or one for the complete RTP connection? The latter. > telephone-event payload may (and will) have equal timestamps as the audio payload. > > There are codecs that split frames over several RTP packets. The sequence number increases, but the timestamp does not. (video codecs) 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>

1 0

[M] Change in libosmocore[master]: osmo_io: Add unit test to verify segmentation process
by laforge 19 Aug '25

19 Aug '25

Attention is currently required from: jolly. laforge has posted comments on this change by jolly. ( https://gerrit.osmocom.org/c/libosmocore/+/40854?usp=email ) Change subject: osmo_io: Add unit test to verify segmentation process ...................................................................... Patch Set 3: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/40854?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I7d8feba9c8e8386c9fd144669f6ccd01d6bbbabb Gerrit-Change-Number: 40854 Gerrit-PatchSet: 3 Gerrit-Owner: jolly <andreas(a)eversberg.eu> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: jolly <andreas(a)eversberg.eu> Gerrit-Comment-Date: Tue, 19 Aug 2025 15:23:47 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

[S] Change in libosmocore[master]: Remove old empty io_uring
by laforge 19 Aug '25

19 Aug '25

Attention is currently required from: jolly. laforge has posted comments on this change by jolly. ( https://gerrit.osmocom.org/c/libosmocore/+/40855?usp=email ) Change subject: Remove old empty io_uring ...................................................................... Patch Set 4: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/40855?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: Id2d2a0400ad442198c684ea0ead4eaeaead4c53d Gerrit-Change-Number: 40855 Gerrit-PatchSet: 4 Gerrit-Owner: jolly <andreas(a)eversberg.eu> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: jolly <andreas(a)eversberg.eu> Gerrit-Comment-Date: Tue, 19 Aug 2025 15:23:27 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

[M] Change in osmo-ttcn3-hacks[master]: msc: add TC_silent_call_{start_stop,active_conn}
by laforge 19 Aug '25

19 Aug '25

laforge has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/40863?usp=email ) Change subject: msc: add TC_silent_call_{start_stop,active_conn} ...................................................................... Patch Set 4: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/40863?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I3ef22fbb5a05f69cc8aea7f42e05f6e1d6c4a8b6 Gerrit-Change-Number: 40863 Gerrit-PatchSet: 4 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: lynxis lazus <lynxis(a)fe80.eu> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 19 Aug 2025 15:21:30 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

[XL] Change in libosmo-netif[master]: bring twjit into libosmo-netif
by pespin 19 Aug '25

19 Aug '25

Attention is currently required from: falconia. pespin 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: (1 comment) File src/twjit.c: https://gerrit.osmocom.org/c/libosmo-netif/+/39280/comment/ca883c9f_1e2fa7d… : PS2, Line 504: rtph = osmo_rtp_get_hdr(msg); > this smooth packet flow will be delivered to the fixed timing application perfectly in order, without any disruptions - and I argue that this behavior is the best In here you are assuming that with an M bit set and no gap in the timestamp sequence means the data just be placed in sequence, which doesn't need to be necessarily the case. IMHO it makes more sense to apply handover since the newer flow after the M bit is the current one, which should take precedence over the old one. Otherwise it's like keep playing soft noise or music while there's already talk waiting to be played. > With my current algorithm, the duration of the gap delivered to the fixed timing application will be exactly what the RTP sender indicated in its timestamps No, it won't, because iiuc, due to the M bit, the timestamps before and after it are non-related. The fact that they may have some gap or not may be totally circumstantial. So to me you are treating the case where the new supposedly randomly taken tiemstamp (due to M bit) is in the 160-sequence different than the other 159 cases. -- 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: falconia <falcon(a)freecalypso.org> Gerrit-Comment-Date: Tue, 19 Aug 2025 14:17:47 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: falconia <falcon(a)freecalypso.org> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>

1 0

[XL] Change in libosmo-netif[master]: bring twjit into libosmo-netif
by jolly 19 Aug '25

19 Aug '25

Attention is currently required from: falconia, pespin. jolly 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: (1 comment) File src/twjit.c: https://gerrit.osmocom.org/c/libosmo-netif/+/39280/comment/489ebdbb_3dbbe7b… : PS5, Line 486: msgb_free(new_msg); Is there a twjit instance for every payload type or one for the complete RTP connection? telephone-event payload may (and will) have equal timestamps as the audio payload. There are codecs that split frames over several RTP packets. The sequence number increases, but the timestamp does not. (video codecs) -- 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: falconia <falcon(a)freecalypso.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 19 Aug 2025 13:56:26 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No

1 0

[XS] Change in osmo-pcu[master]: llc_queue_merge_prepend(): constify readonly ptr param
by pespin 19 Aug '25

19 Aug '25

pespin has submitted this change. ( https://gerrit.osmocom.org/c/osmo-pcu/+/40884?usp=email ) Change subject: llc_queue_merge_prepend(): constify readonly ptr param ...................................................................... llc_queue_merge_prepend(): constify readonly ptr param Change-Id: Ib96bc75535fff94f1d953e37d217a6f954de8ada --- M src/llc.c M src/llc.h 2 files changed, 2 insertions(+), 2 deletions(-) Approvals: Jenkins Builder: Verified fixeria: Looks good to me, but someone else must approve laforge: Looks good to me, approved diff --git a/src/llc.c b/src/llc.c index 45b8ac4..633ae49 100644 --- a/src/llc.c +++ b/src/llc.c @@ -234,7 +234,7 @@ } /* Prepend / Put back a previously dequeued LLC frame (llc_queue_dequeue()) */ -void llc_queue_merge_prepend(struct gprs_llc_queue *q, struct gprs_llc *llc) +void llc_queue_merge_prepend(struct gprs_llc_queue *q, const struct gprs_llc *llc) { struct MetaInfo *meta_storage; unsigned int len = llc_frame_length(llc); diff --git a/src/llc.h b/src/llc.h index 594f77f..b9f3180 100644 --- a/src/llc.h +++ b/src/llc.h @@ -138,7 +138,7 @@ void llc_queue_clear(struct gprs_llc_queue *q, struct gprs_rlcmac_bts *bts); void llc_queue_set_codel_interval(struct gprs_llc_queue *q, unsigned int interval); void llc_queue_move_and_merge(struct gprs_llc_queue *q, struct gprs_llc_queue *o); -void llc_queue_merge_prepend(struct gprs_llc_queue *q, struct gprs_llc *llc); +void llc_queue_merge_prepend(struct gprs_llc_queue *q, const struct gprs_llc *llc); void llc_queue_enqueue(struct gprs_llc_queue *q, struct msgb *llc_msg, const struct timespec *expire_time); struct msgb *llc_queue_dequeue(struct gprs_llc_queue *q, enum gprs_llc_queue_prio *out_prio, struct MetaInfo *out_info); -- To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/40884?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Change-Id: Ib96bc75535fff94f1d953e37d217a6f954de8ada Gerrit-Change-Number: 40884 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>

1 0

[M] Change in osmo-pcu[master]: llc_queue: Store MetaInfo in msgb headroom instead of cb[]
by pespin 19 Aug '25

19 Aug '25

pespin has submitted this change. ( https://gerrit.osmocom.org/c/osmo-pcu/+/40885?usp=email ) Change subject: llc_queue: Store MetaInfo in msgb headroom instead of cb[] ...................................................................... llc_queue: Store MetaInfo in msgb headroom instead of cb[] "sizeof(*meta_storage) <= sizeof(llc_msg->cb)" assert fails on debian 13 armv7l. Since struct MetaInfo cannot always fit inside msgb->cb, move the struct MetaInfo into the headroom of the msgb. Related: OS#6831 Change-Id: I98d966c257d50d3b2fc326dce85ead5591acf51f --- M src/gprs_ms.c M src/llc.c M src/llc.h M tests/llc/LlcTest.cpp 4 files changed, 35 insertions(+), 42 deletions(-) Approvals: fixeria: Looks good to me, but someone else must approve Jenkins Builder: Verified laforge: Looks good to me, approved diff --git a/src/gprs_ms.c b/src/gprs_ms.c index ff7316b..1577a4a 100644 --- a/src/gprs_ms.c +++ b/src/gprs_ms.c @@ -1369,13 +1369,10 @@ LOGPMS(ms, DTBFDL, LOGL_DEBUG, "appending %u bytes to DL LLC queue\n", len); - struct msgb *llc_msg = msgb_alloc(len, "llc_pdu_queue"); - if (!llc_msg) - return -ENOMEM; - llc_queue_calc_pdu_lifetime(ms->bts, pdu_delay_csec, &expire_time); - memcpy(msgb_put(llc_msg, len), data, len); - llc_queue_enqueue(ms_llc_queue(ms), llc_msg, &expire_time); + rc = llc_queue_enqueue(ms_llc_queue(ms), data, len, &expire_time); + if (rc < 0) + return rc; ms_start_llc_timer(ms); dl_tbf = ms_dl_tbf(ms); diff --git a/src/llc.c b/src/llc.c index 633ae49..478d23d 100644 --- a/src/llc.c +++ b/src/llc.c @@ -141,24 +141,34 @@ } } -void llc_queue_enqueue(struct gprs_llc_queue *q, struct msgb *llc_msg, const struct timespec *expire_time) +int llc_queue_enqueue(struct gprs_llc_queue *q, const uint8_t *data, uint16_t len, const struct timespec *expire_time) { + struct msgb *llc_msg; struct MetaInfo *meta_storage; - struct gprs_llc_hdr *llc_hdr = (struct gprs_llc_hdr *)msgb_data(llc_msg); + struct gprs_llc_hdr *llc_hdr; enum gprs_llc_queue_prio prio; - osmo_static_assert(sizeof(*meta_storage) <= sizeof(llc_msg->cb), info_does_not_fit); + llc_msg = msgb_alloc_headroom(sizeof(*meta_storage) + len, sizeof(*meta_storage), "llc_pdu_queue"); + if (!llc_msg) + return -ENOMEM; - prio = llc_sapi2prio(llc_hdr->sapi); - - q->queue_size += 1; - q->queue_octets += msgb_length(llc_msg); - - meta_storage = (struct MetaInfo *)&llc_msg->cb[0]; + /* Fist set up MetaInfo in the msgb headroom: */ + meta_storage = (struct MetaInfo *)llc_msg->head; osmo_clock_gettime(CLOCK_MONOTONIC, &meta_storage->recv_time); meta_storage->expire_time = *expire_time; + /* Copy PDU to msgb data: */ + llc_hdr = (struct gprs_llc_hdr *)msgb_put(llc_msg, len); + memcpy(llc_hdr, data, len); + + prio = llc_sapi2prio(llc_hdr->sapi); + + /* Append: */ + q->queue_size += 1; + q->queue_octets += msgb_length(llc_msg); msgb_enqueue(&q->pq[prio].queue, llc_msg); + + return 0; } void llc_queue_clear(struct gprs_llc_queue *q, struct gprs_rlcmac_bts *bts) @@ -205,8 +215,8 @@ msg = msg1; msg1 = NULL; } else { - const struct MetaInfo *mi1 = (struct MetaInfo *)&msg1->cb[0]; - const struct MetaInfo *mi2 = (struct MetaInfo *)&msg2->cb[0]; + const struct MetaInfo *mi1 = (struct MetaInfo *)msg1->head; + const struct MetaInfo *mi2 = (struct MetaInfo *)msg2->head; if (timespeccmp(&mi2->recv_time, &mi1->recv_time, >)) { msg = msg1; @@ -236,20 +246,21 @@ /* Prepend / Put back a previously dequeued LLC frame (llc_queue_dequeue()) */ void llc_queue_merge_prepend(struct gprs_llc_queue *q, const struct gprs_llc *llc) { + struct msgb *llc_msg; struct MetaInfo *meta_storage; unsigned int len = llc_frame_length(llc); - struct msgb *llc_msg = msgb_alloc(len, "llc_pdu_queue"); + llc_msg = msgb_alloc_headroom(sizeof(*meta_storage) + len, sizeof(*meta_storage), "llc_pdu_queue"); OSMO_ASSERT(llc_msg); - memcpy(msgb_put(llc_msg, len), llc->frame, len); - q->queue_size += 1; - q->queue_octets += msgb_length(llc_msg); - - meta_storage = (struct MetaInfo *)&llc_msg->cb[0]; + meta_storage = (struct MetaInfo *)llc_msg->head; memcpy(meta_storage, &llc->meta_info, sizeof(struct MetaInfo)); + memcpy(msgb_put(llc_msg, len), llc->frame, len); + /* Prepend: */ + q->queue_size += 1; + q->queue_octets += msgb_length(llc_msg); llist_add(&llc_msg->list, &q->pq[llc->prio].queue); } @@ -272,7 +283,7 @@ if (!msg) return NULL; - meta_storage = (struct MetaInfo *)&msg->cb[0]; + meta_storage = (struct MetaInfo *)msg->head; q->queue_size -= 1; q->queue_octets -= msgb_length(msg); @@ -305,7 +316,7 @@ timespecadd(&tv_now, &hyst_delta, &tv_now2); while ((msg = llc_queue_pick_msg(q, &prio))) { - info = (const struct MetaInfo *)&msg->cb[0]; + info = (const struct MetaInfo *)msg->head; const struct timespec *tv_disc = &info->expire_time; const struct timespec *tv_recv = &info->recv_time; diff --git a/src/llc.h b/src/llc.h index b9f3180..31e427d 100644 --- a/src/llc.h +++ b/src/llc.h @@ -139,7 +139,7 @@ void llc_queue_set_codel_interval(struct gprs_llc_queue *q, unsigned int interval); void llc_queue_move_and_merge(struct gprs_llc_queue *q, struct gprs_llc_queue *o); void llc_queue_merge_prepend(struct gprs_llc_queue *q, const struct gprs_llc *llc); -void llc_queue_enqueue(struct gprs_llc_queue *q, struct msgb *llc_msg, const struct timespec *expire_time); +int llc_queue_enqueue(struct gprs_llc_queue *q, const uint8_t *data, uint16_t len, const struct timespec *expire_time); struct msgb *llc_queue_dequeue(struct gprs_llc_queue *q, enum gprs_llc_queue_prio *out_prio, struct MetaInfo *out_info); static inline size_t llc_queue_size(const struct gprs_llc_queue *q) diff --git a/tests/llc/LlcTest.cpp b/tests/llc/LlcTest.cpp index 9ed6f21..c0101fb 100644 --- a/tests/llc/LlcTest.cpp +++ b/tests/llc/LlcTest.cpp @@ -56,21 +56,6 @@ return ms_llc_queue(ms); } -static void enqueue_data(gprs_llc_queue *queue, const uint8_t *data, size_t len, - const struct timespec *expire_time) -{ - struct timespec *tv; - uint8_t *msg_data; - struct msgb *llc_msg = msgb_alloc(len + sizeof(*tv) * 2, - "llc_pdu_queue"); - - msg_data = (uint8_t *)msgb_put(llc_msg, len); - - memcpy(msg_data, data, len); - - llc_queue_enqueue(queue, llc_msg, expire_time); -} - static void dequeue_and_check(gprs_llc_queue *queue, const uint8_t *exp_data, size_t len, const MetaInfo *exp_info) { @@ -96,7 +81,7 @@ static void enqueue_data(gprs_llc_queue *queue, const char *message, const struct timespec *expire_time) { - enqueue_data(queue, (uint8_t *)(message), strlen(message), expire_time); + llc_queue_enqueue(queue, (uint8_t *)(message), strlen(message), expire_time); } static void dequeue_and_check(gprs_llc_queue *queue, const char *exp_message, -- To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/40885?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Change-Id: I98d966c257d50d3b2fc326dce85ead5591acf51f Gerrit-Change-Number: 40885 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>

1 0

[XL] Change in libosmo-netif[master]: bring twjit into libosmo-netif
by falconia 18 Aug '25

18 Aug '25

Attention is currently required from: 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: (1 comment) File src/twjit.c: https://gerrit.osmocom.org/c/libosmo-netif/+/39280/comment/62e74621_c69d26c… : PS2, Line 504: rtph = osmo_rtp_get_hdr(msg); > Thanks. After having read your document: […] I still disagree. To see why, let us consider a scenario in which you (presumably) believe checking M bit would make a difference. This purported scenario would have to have these two properties: * SSRC stays the same, or else twjit would consider it a handover; * All timestamp increments are integral multiples of 160, for the same reason; * Sequence number does not matter at all, as twjit does not look at it except for staff-oriented counters and RTCP-mandated analytics - it does not affect any of twjit's actual decisions. With the above prerequisites established, the next question is: gap or no gap? Consider the no-gap case first: there is a perfectly smooth, uninterrupted flow of RTP packets, but one of them has M bit set. With current code, this smooth packet flow will be delivered to the fixed timing application perfectly in order, without any disruptions - and I argue that this behavior is the best. Your proposal of treating M bit as handover would cause twjit state transition to HANDOVER, which would result either in some packets before the handover event being dropped if the new flow becomes ready (flow start criteria) soon enough, or in a gap (not present in the incoming stream) being fed to the output if the old flow underruns before the new one is ready. How would such behavior be any better than what I have currently? Now consider M bit preceded by a gap: some packets omitted, then an RTP packet with M bit set. Here the question becomes: underrun or no underrun? If the gap is long enough for twjit to experience an underrun before the flow resumes, then it makes no difference whether the flow-resuming packet has M bit set or not: twjit is starting from EMPTY state in this case. Now consider the no-underrun case: the configured buffer depth is high enough, and the gap short enough, to where the flow-resuming packet arrives before the buffer underruns. With my current algorithm, the duration of the gap delivered to the fixed timing application will be exactly what the RTP sender indicated in its timestamps; with your proposed modification, the gap would be unpredictably lengthened or shortened based on how long it takes for the post-handover flow to reach ready state. How is your way any better? In summary, I still fail to see *even one* scenario in which your proposed modification to my core algorithm would make an improvement. -- 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: pespin <pespin(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Mon, 18 Aug 2025 17:58:50 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: falconia <falcon(a)freecalypso.org> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>

1 0

[XS] Change in osmo-pcu[master]: llc_queue_merge_prepend(): constify readonly ptr param
by laforge 18 Aug '25

18 Aug '25

Attention is currently required from: pespin. laforge has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/osmo-pcu/+/40884?usp=email ) Change subject: llc_queue_merge_prepend(): constify readonly ptr param ...................................................................... Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/40884?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Change-Id: Ib96bc75535fff94f1d953e37d217a6f954de8ada Gerrit-Change-Number: 40884 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Mon, 18 Aug 2025 17:38:11 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

2026

2025

2024

2023

2022

gerrit-log August 2025